Redian新闻
>
女子网恋高富帅,见面不满意自杀
avatar
女子网恋高富帅,见面不满意自杀# Internet - 有缘千里一线牵
r*n
1
移民局相关部门在近年增加人员和执法力度,以及采用了新的案件处理系统,审查长期
未决案件以提高公众对其工作的信心。在全美范围内,截至2018年3月29日,洛杉矶在
全国拥有最多进行中的庇护申请面谈案件。
对于近年来大受华人欢迎的EB-5投资移民,报告称项目对外国投资者仍然具有吸引力,
但包括国会议员在内的各方越来越多地关注欺诈和滥用行为,这些行为破坏了该项目最
初的目的,并减损了该项目提供的潜在利益。移民局正通过一系列改革试图解决这些问
题,这些改革将改善EB-5项目的完整性。EB-5项目的申请人数在2014年达到最高峰后,
逐渐开始缓慢回落。
投资移民每年1万的配额没有变,前段时间它达到了历史上的最高峰,就是申请的人特
别多,但1万个配额从1990年颁布以来都没有改变过。从上世纪不太欢迎,到2008年左
右变成比较受欢迎的政策,投资移民的需求也提高了。由于配额没有改变,申请人多就
变得等待时间比较长。比如说排期碰到财政年度年尾的时候,有时候一排排个好几年都
有可能。所以投资移民的朋友们会望而却步,想着花了钱投了资,还要等这么长时间,
就可能要么改换别的方式,要么改换别的国家。这和经济学市场供需规律有相似之处。
除了配额是一定的以外,移民局在过去几年确实在加强监控。很多本世纪初的投资移民
区域中心项目到现在没剩几个,现在又有900多个项目,这里面当然会出现良莠不齐的
现象。这使得美国政府、移民局等开始注重保护外国投资人,也是消费者的利益,因此
在审查审核等方面也都在加强。有的投资者本来就是要直投,确实想要在这里做生意,
那在EB-5投资移民都这么慢这么繁琐的情况下,可能就会选择做贸易公司、旅游公司、
餐馆等,也就是拿所谓L1签证。L1签证和EB-5投资移民都有配额的要求,但它的配额是
职业类移民里面的第一类优先,所以配额比较多。因此,当看到EB-5投资移民很慢的时
候,真正想着做生意的朋友们就会考虑换种方式,如去做跨国公司。
avatar
l*8
2
OK
O(∩_∩)O哈哈~
avatar
h*6
3
为啥Oracle stored procedure 里面不建议用 temporary table? 谢谢。
avatar
p*v
4
在我初中的时候就很流行网恋了,为什么现在还在流行,所以我他们为什么要网恋就很搞不懂。看见这个新闻真是惊呆了不知道这个姑娘是单纯呢还是傻。
网恋还以为遇见了白马王子,而且对方还是高富帅?怎么可能,现在那个高富帅会网恋,别人在现实生活中都是大把漂亮女朋友好吗?哪里有那么多时间来和你网恋!所以这个姑娘一定是生活在象牙塔里没有经历过风浪的女孩。更奇葩的是,她竟然在见面后觉得男子与照片不符自杀,而且跳楼、吞玻璃、割腕、吞安眠药等方法都试了,没有死也是命大,说明上天还是眷顾她的。我觉得真是奇怪的姑娘,为了一个第一次见面的人居然可以那么坚定地放弃生命,舍弃陪伴自己那么多年的父母和好友,难道二十多年的父母情不能跟一个男的比吗?反正自己这辈子都不可能因为哪个男的去做这种事情。
奇葩年年有,今年特别多,所以看见这些事情我也只能叹一口气了,替他们的父母不值。等到以后自己心智成熟了,想起这段往事,会不会觉得很丢脸,肯定想要扇自己两巴掌吧。
avatar
Y*e
5
小白好
avatar
B*g
6
only use tt when you have to

【在 h*****6 的大作中提到】
: 为啥Oracle stored procedure 里面不建议用 temporary table? 谢谢。
avatar
y*w
7
谁建议的? 如果temp table解决问题最合适,为什么不用? 乱七八糟流行的坏主意多
了。有些成为坏主意就是因为不分场合的乱用,

【在 h*****6 的大作中提到】
: 为啥Oracle stored procedure 里面不建议用 temporary table? 谢谢。
avatar
h*6
8
现在组的manager说的。
俺的工作涉及把TSQL stored procedure code转成PL SQL, 有的 TSQL stored
procedure 有两三千行代码,好几个TEMP tables, 如果PL SQL 不用TEMP table,就只
能用 Associative Array or nested table, 处理数据,最后写到表里,中间过程不用
TEMP table,都在memory内。
Stroed procedure 的功能就是把几个millions records 级别的表join在一起,做一些
很简单判别,加减,再写进原来的表或不同的表。
这样的stored procedure有20多个,用linux cron job,每晚跑一次。
如果PL SQL stored procedure 用TEMP table, 转变从TSQL到PLSQL就很容易。不用的
话,大的stored procedure还是挺complex的。
avatar
B*g
9
你们公司要parttime remote consultant吗?本人价格厚道,人超所值,哈哈。
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTIO

【在 h*****6 的大作中提到】
: 现在组的manager说的。
: 俺的工作涉及把TSQL stored procedure code转成PL SQL, 有的 TSQL stored
: procedure 有两三千行代码,好几个TEMP tables, 如果PL SQL 不用TEMP table,就只
: 能用 Associative Array or nested table, 处理数据,最后写到表里,中间过程不用
: TEMP table,都在memory内。
: Stroed procedure 的功能就是把几个millions records 级别的表join在一起,做一些
: 很简单判别,加减,再写进原来的表或不同的表。
: 这样的stored procedure有20多个,用linux cron job,每晚跑一次。
: 如果PL SQL stored procedure 用TEMP table, 转变从TSQL到PLSQL就很容易。不用的
: 话,大的stored procedure还是挺complex的。

avatar
y*w
10
1. manager不是技术标准。要有你自己的判断。当然如果你的方法没有明显优势,听人家的。
2. tsql有很多temp table,最好你分析分析是不是有必要换成collection。基本面上我是持怀疑态度的,小的转换无所谓,大临时表你要用collection性能要吃紧。
3. 在转换时间,运行效率间权衡,直接转很可能是最合理的。beijing转的那个连接让我很吃惊,大概就是把临时表换成自查询了?那sql server原先自己也能这么干啊。做成临时表示不是有原因?很可能就是性能,加个索引嘛。

【在 h*****6 的大作中提到】
: 现在组的manager说的。
: 俺的工作涉及把TSQL stored procedure code转成PL SQL, 有的 TSQL stored
: procedure 有两三千行代码,好几个TEMP tables, 如果PL SQL 不用TEMP table,就只
: 能用 Associative Array or nested table, 处理数据,最后写到表里,中间过程不用
: TEMP table,都在memory内。
: Stroed procedure 的功能就是把几个millions records 级别的表join在一起,做一些
: 很简单判别,加减,再写进原来的表或不同的表。
: 这样的stored procedure有20多个,用linux cron job,每晚跑一次。
: 如果PL SQL stored procedure 用TEMP table, 转变从TSQL到PLSQL就很容易。不用的
: 话,大的stored procedure还是挺complex的。

avatar
B*g
11
个人觉得大量的数据根本就不应该放到tt、collection里去。

人家的。
我是持怀疑态度的,小的转换无所谓,大临时表你要用collection性能要吃紧。
让我很吃惊,大概就是把临时表换成自查询了?那sql server原先自己也能这么干啊。
做成临时表示不是有原因?很可能就是性能,加个索引嘛。

【在 y****w 的大作中提到】
: 1. manager不是技术标准。要有你自己的判断。当然如果你的方法没有明显优势,听人家的。
: 2. tsql有很多temp table,最好你分析分析是不是有必要换成collection。基本面上我是持怀疑态度的,小的转换无所谓,大临时表你要用collection性能要吃紧。
: 3. 在转换时间,运行效率间权衡,直接转很可能是最合理的。beijing转的那个连接让我很吃惊,大概就是把临时表换成自查询了?那sql server原先自己也能这么干啊。做成临时表示不是有原因?很可能就是性能,加个索引嘛。

avatar
y*w
12
有些大库在做某些查询的时候,把中间结果放到tt加个index,比直接一个sql写出来好很多。抓到老鼠就是展招。
btw,对于collection,个人觉得就是给程序员手头的方便,别指望真能处理大数据。

【在 B*****g 的大作中提到】
: 个人觉得大量的数据根本就不应该放到tt、collection里去。
:
: 人家的。
: 我是持怀疑态度的,小的转换无所谓,大临时表你要用collection性能要吃紧。
: 让我很吃惊,大概就是把临时表换成自查询了?那sql server原先自己也能这么干啊。
: 做成临时表示不是有原因?很可能就是性能,加个索引嘛。

avatar
B*g
13
大量查询最好分成小块来做,想想往一个temp table里存百万个数据(假设有100个
session在run?)。。。。
collection处理大数据的效果很好,具体请见CINAOUG系列文章,hoho

好很多。抓到老鼠就是展招。

【在 y****w 的大作中提到】
: 有些大库在做某些查询的时候,把中间结果放到tt加个index,比直接一个sql写出来好很多。抓到老鼠就是展招。
: btw,对于collection,个人觉得就是给程序员手头的方便,别指望真能处理大数据。

avatar
y*w
14
对我这儿来说,放几百万小意思. 要分成10w的小块,经常要慢个n>10倍的。
说真的,你去做下试验看看多大批次总体效果最好。我有时候就不明白大家为什么对现
代数据库的大数据处理能力不放心

【在 B*****g 的大作中提到】
: 大量查询最好分成小块来做,想想往一个temp table里存百万个数据(假设有100个
: session在run?)。。。。
: collection处理大数据的效果很好,具体请见CINAOUG系列文章,hoho
:
: 好很多。抓到老鼠就是展招。

avatar
B*g
15
放心,所以就是inline table,hoho,DBA不让。基于网上post和个人测试,oracle处
理数据,一般bulk每次1万-10万最快。
另外,你的EXP是DB2,oracle不一定同理工作,而且还是case by case。你举个例子为
啥要用temp table吧。俺也有例子,哈哈。

【在 y****w 的大作中提到】
: 对我这儿来说,放几百万小意思. 要分成10w的小块,经常要慢个n>10倍的。
: 说真的,你去做下试验看看多大批次总体效果最好。我有时候就不明白大家为什么对现
: 代数据库的大数据处理能力不放心

avatar
y*w
16
这也太累了。还是老原则,具体情况具体分析,没有必然差劲的技术,也没有银子子弹。
btw,上面我说催着改了的是sql server。

【在 B*****g 的大作中提到】
: 放心,所以就是inline table,hoho,DBA不让。基于网上post和个人测试,oracle处
: 理数据,一般bulk每次1万-10万最快。
: 另外,你的EXP是DB2,oracle不一定同理工作,而且还是case by case。你举个例子为
: 啥要用temp table吧。俺也有例子,哈哈。

avatar
B*g
17
就SQL Server转Orcle来说,把SP里的tt转成collection或者其他基本上是正确的。就是
用tt,也不要在SP做create/drop。

弹。
oracle处
子为

【在 y****w 的大作中提到】
: 这也太累了。还是老原则,具体情况具体分析,没有必然差劲的技术,也没有银子子弹。
: btw,上面我说催着改了的是sql server。

avatar
g*l
18
我不是ORACLE的,但是这样,CREATE TEMP TABLE就要产生IO,现在SERVER的主要问题
是HIGH IO WAIT,DISK的读写速度现在是BOTTLE NECK,内存啥的越来越大,现在都是
尽量用内存或者CACHE,避免读写DISK
avatar
h*6
19
你指的的Oracle用tt是指global temporary table吗?就是那种手动创建,一直存在数
据库里
面,不是sp自动创建,tt表名字整个DB unique, 在sp里面插入删除数据时把这样的tt
作为临时的地
方,sp最后把tt表内容清空。好像和一个空的permanent表没有啥区别了。
能简单介绍一下Oracle sp里面create/drop table的危害吗?我想我manager说的就是
不要在SP
做create/drop,俺不懂为啥?谢谢。

就是

【在 B*****g 的大作中提到】
: 就SQL Server转Orcle来说,把SP里的tt转成collection或者其他基本上是正确的。就是
: 用tt,也不要在SP做create/drop。
:
: 弹。
: oracle处
: 子为

avatar
B*g
20
tt和普通table有区别,tt是per session的。不同的session可以同时run多个SP(用同
一个tt),各个session之间互不影响,session结束后自动清除。普通table不行。
In oracle, create/drop tt是DDL,不易在SP中作(DBA正常的DDL除外)。而且一般
DBA也不会让你在SP里用DDL,如果DBA让你这样做了,换DBA吧。一般来说SP里也基本上
用不到tt。具体看我贴的唐木开特的link

tt

【在 h*****6 的大作中提到】
: 你指的的Oracle用tt是指global temporary table吗?就是那种手动创建,一直存在数
: 据库里
: 面,不是sp自动创建,tt表名字整个DB unique, 在sp里面插入删除数据时把这样的tt
: 作为临时的地
: 方,sp最后把tt表内容清空。好像和一个空的permanent表没有啥区别了。
: 能简单介绍一下Oracle sp里面create/drop table的危害吗?我想我manager说的就是
: 不要在SP
: 做create/drop,俺不懂为啥?谢谢。
:
: 就是

相关阅读
logo
联系我们隐私协议©2024 redian.news
Redian新闻
Redian.news刊载任何文章,不代表同意其说法或描述,仅为提供更多信息,也不构成任何建议。文章信息的合法性及真实性由其作者负责,与Redian.news及其运营公司无关。欢迎投稿,如发现稿件侵权,或作者不愿在本网发表文章,请版权拥有者通知本网处理。