Redian新闻
>
Re: 来吧,大家可以拿钱去了,每人最少10刀
avatar
Re: 来吧,大家可以拿钱去了,每人最少10刀# Windows - 看得见风景的窗口
d*e
1
看到这样的新闻的时候,我真的有点被吓到了。这真的是我们当代文明的大学生做出来
的事情么?这则新闻向我们说到在广州的一名法律系的男生强奸了自己的女同学,我的
天那!我简直不敢相信,第一我不敢相信的是因为这残酷的事实,这真的是学生做出来
的事情吗?在校园这样安静又神圣的学习的地方,做出这样淫秽而且恐怖的事情。第二
个我不敢相信的是这则恐怖事件的男主角竟然是法律系的大学生,第一个他是一个大学
生肯定有一定的知识基础,学了这么多年的知识,竟然还能做出这样的事情,第二个他
的专业竟然是法律系,这难道不是知法犯法吗?这样的事件真的让我有些无语,我不知
道该用什么样的眼光来看待当代的大学生。好像曾经在大家的眼里,大学是一个神圣的
地方,无数的求知学子在这里学习知识,可是如今大学好像已经变成了非常混乱的地方
,她它和社会好像已经没有了什么区别。我真的不想再看到类似于这样恐怖的事件发生
在大学里了,它让我的三观再次刷新!
avatar
s*g
2
我有新旧两本护照,旧的已经过期,但有刚来美国入境的签证信息。递交材料的时候旧
护照也要复印吗?谢谢!
avatar
l*u
3
First of all, let me emphasize that "Fringe" rocks and I love "Fringe" and
Olivia very very much. Otherwise I wouldn't waste my time writing this piece.
In the past 16 episodes, Walter's underground lab has been featured as a
hospital with half a nurse (Astrid) and an amateur nurse practitioner (Peter
), a farm (the cow!), a morgue (so many dead bodies and, yes, the maggots
and baby monsters), a chemistry lab (antidote synthesis?), and a physics lab
, and maybe something else too. Well, don't ge
avatar
c*e
4
data warehouse里面,所有dimension table的数据要拷贝到新的fact table里面,觉
得这做法比较傻。
我知道这其实是想一劳永逸,只copy一次就够了。但是,table和table之间,应该用
foreign key之类的来维持数据的一致和可靠,这种copy已经脱离了relational
database的本意。
avatar
b*t
5
【 以下文字转载自 LosAngeles 讨论区 】
发信人: bluerat (bluerat), 信区: LosAngeles
标 题: Re: 来吧,大家可以拿钱去了,每人最少10刀
发信站: BBS 未名空间站 (Wed Nov 14 23:40:00 2012, 美东)
一个unit咋算?一盒里面不是三小盒吗;算几个unit
avatar
P*0
6
yes

【在 s**********g 的大作中提到】
: 我有新旧两本护照,旧的已经过期,但有刚来美国入境的签证信息。递交材料的时候旧
: 护照也要复印吗?谢谢!

avatar
t*u
7
看了两集,女人太丑
avatar
e*7
8
不是很明白,咋拷贝啊?
avatar
b*m
9
全都要。
avatar
g*g
10
你是凯丁吗?

【在 t***u 的大作中提到】
: 看了两集,女人太丑
avatar
E*e
11
没看明白...为啥要把所有dimension的数据拷到新的fact table 里呀?
avatar
y*5
12
Are you kidding me?!!
看来这个审美真的是难说啊,不同人的观点能天差地别。

【在 t***u 的大作中提到】
: 看了两集,女人太丑
avatar
y*g
13
我也不明白
Fact 和 dimension 不是独立的吗?
avatar
c*e
14
比如一個star schema,要把各个dimension table的数据拷贝到fact table里面,拷贝
完后,就只对这个fact table做各种query.

【在 e****7 的大作中提到】
: 不是很明白,咋拷贝啊?
avatar
n*w
15
没听说

【在 c*********e 的大作中提到】
: 比如一個star schema,要把各个dimension table的数据拷贝到fact table里面,拷贝
: 完后,就只对这个fact table做各种query.

avatar
l*t
16
你的意思是query的时候做 data base denomalization吧? 就是join fact table和
dimension table成一个大的data set, 这个都是query time或者 单独一个view,要
是都pre populate成为一个大table, 就失去了star schema的意义
avatar
e*7
17

嗯,看明白了,然后所有的dimension 都是degenerate dimension from fact.
数据量小,选用excel 做pivot table 还成,直接导入就完事。
大型olap 没见过这么搞的

【在 l******t 的大作中提到】
: 你的意思是query的时候做 data base denomalization吧? 就是join fact table和
: dimension table成一个大的data set, 这个都是query time或者 单独一个view,要
: 是都pre populate成为一个大table, 就失去了star schema的意义

avatar
c*e
18
data warehouse里面,所有dimension table的数据要拷贝到新的fact table里面,觉
得这做法比较傻。
我知道这其实是想一劳永逸,只copy一次就够了。但是,table和table之间,应该用
foreign key之类的来维持数据的一致和可靠,这种copy已经脱离了relational
database的本意。
avatar
e*7
19
不是很明白,咋拷贝啊?
avatar
E*e
20
没看明白...为啥要把所有dimension的数据拷到新的fact table 里呀?
avatar
y*g
21
我也不明白
Fact 和 dimension 不是独立的吗?
avatar
c*e
22
比如一個star schema,要把各个dimension table的数据拷贝到fact table里面,拷贝
完后,就只对这个fact table做各种query.

【在 e****7 的大作中提到】
: 不是很明白,咋拷贝啊?
avatar
n*w
23
没听说

【在 c*********e 的大作中提到】
: 比如一個star schema,要把各个dimension table的数据拷贝到fact table里面,拷贝
: 完后,就只对这个fact table做各种query.

avatar
l*t
24
你的意思是query的时候做 data base denomalization吧? 就是join fact table和
dimension table成一个大的data set, 这个都是query time或者 单独一个view,要
是都pre populate成为一个大table, 就失去了star schema的意义
avatar
e*7
25

嗯,看明白了,然后所有的dimension 都是degenerate dimension from fact.
数据量小,选用excel 做pivot table 还成,直接导入就完事。
大型olap 没见过这么搞的

【在 l******t 的大作中提到】
: 你的意思是query的时候做 data base denomalization吧? 就是join fact table和
: dimension table成一个大的data set, 这个都是query time或者 单独一个view,要
: 是都pre populate成为一个大table, 就失去了star schema的意义

avatar
y*w
26
纯粹反DW啊,

【在 c*********e 的大作中提到】
: data warehouse里面,所有dimension table的数据要拷贝到新的fact table里面,觉
: 得这做法比较傻。
: 我知道这其实是想一劳永逸,只copy一次就够了。但是,table和table之间,应该用
: foreign key之类的来维持数据的一致和可靠,这种copy已经脱离了relational
: database的本意。

avatar
s*o
27
貌似基本不懂的,DW是对付那些天天变的海量数据的,
一次导入EXCEL那不又是传统的家庭作坊么?

【在 y****w 的大作中提到】
: 纯粹反DW啊,
avatar
c*e
28
一次导入的是目前有的历史数据,这个数据量非常大,需要一次性导入fact table。此
后的数据只需要每天/星期/月update进fact table就可以了。

【在 s**********o 的大作中提到】
: 貌似基本不懂的,DW是对付那些天天变的海量数据的,
: 一次导入EXCEL那不又是传统的家庭作坊么?

avatar
s*o
29
人不是专门做了PARTITION么

【在 c*********e 的大作中提到】
: 一次导入的是目前有的历史数据,这个数据量非常大,需要一次性导入fact table。此
: 后的数据只需要每天/星期/月update进fact table就可以了。

avatar
e*7
30

这样一来你的ETL简化了只要导入FACT,所有DIM都是degenerate dimension 了。如果
数据量大,这个可能会比较低效率,除非OLAP process 系统对此优化了。
看你用啥系统,数据到底有多少,有多复杂了。

【在 c*********e 的大作中提到】
: 一次导入的是目前有的历史数据,这个数据量非常大,需要一次性导入fact table。此
: 后的数据只需要每天/星期/月update进fact table就可以了。

avatar
c*e
31
dimension table里并没有数据,只有一些dimension的数据,比如location dimension
table,就只有location id,location name,location description.其它就没有了。数
据还是在staging table里,通过join之类的最终导入fact table.

【在 e****7 的大作中提到】
:
: 这样一来你的ETL简化了只要导入FACT,所有DIM都是degenerate dimension 了。如果
: 数据量大,这个可能会比较低效率,除非OLAP process 系统对此优化了。
: 看你用啥系统,数据到底有多少,有多复杂了。

avatar
d*n
32
这点很重要啊。因为dimension会改变,如果不在原始数据还在etl的时候和fact联合的
话,以后也许就再也没机会了。
relation只是万不得已的时候才用的。至于fk,那是给前台input时候搞的,中间给自
己用就是枷锁。
在dw里面,其实单个数据可靠不可靠不重要。重要的是即使有一批不可靠数据,系统还
能容错,不可靠数据也不会影响结果。

【在 c*********e 的大作中提到】
: data warehouse里面,所有dimension table的数据要拷贝到新的fact table里面,觉
: 得这做法比较傻。
: 我知道这其实是想一劳永逸,只copy一次就够了。但是,table和table之间,应该用
: foreign key之类的来维持数据的一致和可靠,这种copy已经脱离了relational
: database的本意。

avatar
D*J
33
DW还是要避免过多的FK和JOIN吧。it is query optimized not change optimized.

【在 c*********e 的大作中提到】
: data warehouse里面,所有dimension table的数据要拷贝到新的fact table里面,觉
: 得这做法比较傻。
: 我知道这其实是想一劳永逸,只copy一次就够了。但是,table和table之间,应该用
: foreign key之类的来维持数据的一致和可靠,这种copy已经脱离了relational
: database的本意。

avatar
y*w
34
大的dw几十上百维度,这数据冗余足够杀死你想要的perf了。再说每个query涉及的维
度一般只是一个字集。 说dw,默认讨论的是海量数据。麻雀五脏俱全还是鸟但不能跟
鸵鸟火鸡比较运动能力啊

DW还是要避免过多的FK和JOIN吧。it is query optimized not change optimized.

【在 D*J 的大作中提到】
: DW还是要避免过多的FK和JOIN吧。it is query optimized not change optimized.
相关阅读
logo
联系我们隐私协议©2024 redian.news
Redian新闻
Redian.news刊载任何文章,不代表同意其说法或描述,仅为提供更多信息,也不构成任何建议。文章信息的合法性及真实性由其作者负责,与Redian.news及其运营公司无关。欢迎投稿,如发现稿件侵权,或作者不愿在本网发表文章,请版权拥有者通知本网处理。