g*****a
发帖数: 29 | 1 我是学统计的,现在用SAS将数据存储在一个大的DATASET中.(每年的数据量不到1万(2-3M)
.
有学计算机的人建议应该将数据存在ACCESS的几个表中(如把学生相关信息放在一个表中,
老师相关信息放在一个表中),说这样可以减少REDUNDANCY,BLAH,BLAH.
我现在做分析时用这个DATASET觉得很舒服,若用他说的,可能我还要编程序做关系数据库
的连接,我感觉反而增加工作量.
哪位比较明白的,给说说用这样的DATA STRUCTURE到底有什么好处,若用处不大,我怎样反
驳呢? |
|
i****a
发帖数: 36252 | 2 clustering, replication, log shipping, mirroring, full backup, diff
backup, log backup, restore from full/diff/log backup, transaction,
partition, server upgrade, basic SAN knowledge, DR, performance
monitoring/tuning, Dynamic Management views, sql profiler, perfmon, sql
counters, database size management, resource governor, locks, index,
statistic, jobs, maintenance plan, SSIS, stored proc, function, trigger,
SQL, encryption, backup compression, security, etc |
|
B*****g
发帖数: 34098 | 3 从哪儿copy的？这个可以贴在简历上，haha。 |
|
|
|
g*******g
发帖数: 108 | 6 VLDB, very large database ...
requirements usually involve , table partition, parallel query, bulk load.
google VLDB process, tables partition parallel query etc. will give you more
details. Pretty much everyone knew the advantage/pro of a tech solution, it
would be impressive if you can tell interviewee the risk/con
of a solution. (table partition, parallel query )
if you have specific questions. ask in CINAOUG, people will help you there
quicker i think.
Chinese in North America Oracle User Gr... 阅读全帖 |
|
g***l
发帖数: 18555 | 7 不知道你所说的处理是什么意思，是ADMINISTRATION啊，还是编程序，你什么都会的话
，我会觉得你什么都不会，纸上谈兵，我几个问题就能把你问趴下。 |
|
|
g***l
发帖数: 18555 | 9 我公司正在收简历，看了几个，根本什么都不会。每一个我都能针对性的问出7，8，10
来个问题，不用问很难的就能把人难住。LOL |
|
|
|
|
vn
发帖数: 6191 | 13 你们这种态度就是在比谁更牛
这simpleDB和曾哥说的围绕sql server有多大关系啊。。。
强烈建议讲点实用的 |
|
vn
发帖数: 6191 | 14 你们这种态度就是在比谁更牛
这simpleDB和曾哥说的围绕sql server有多大关系啊。。。
强烈建议讲点实用的 |
|
i*****8
发帖数: 132 | 15 什么馊主意，
现在的移动设备OS都是IOS，android， linux，做底层开发需要的人很少，市场非常有
限，
没有经验根本入不了门
剩下的都是App开发，和嵌入式没什么关系。
这年头还是搞IT工作好找钱也多，没看老印全往这块挤，说明人家对市场把握的很清楚。 |
|
E*****e
发帖数: 197 | 16 同意. OLAP Cube 对用户而言很直观，不需要知道这背后的数据结构和相互关系，只要
把所需要的field放进report里就好了
Excel |
|
s********e
发帖数: 893 | 17 你说的这种情况要把这一个table分成多个。比如一个是每个record都unique的基本信
息表包括SSN，姓名等。 PK就是SSN。
然后建一个location/address表。同样一个人可以有多个地址。比如From_Date=10/01/
2008 To_Date=07/30/2012是一个地址，From_date=07/31/2012,To_Date is null 是另
一个地址。
如果是地址更新就只增添一个记录在这个表格。每次保证current地址的To_Date is
null。
如果有电话信息，也可以再建立一个专门存电话的table。电话又分固定电话和cell，
那就在表里加一个Type field。
电话也会和地址有关系。通常搬家了电话也换了，所以可以给每个地址加个sequence。
电话和地址通过这个sequence连接起来。
同样也可以建立一个职业表格，包括每个SSN不同时间段的职业title，employer，起
始日期等。 |
|
p***c
发帖数: 5202 | 18 有吧，有很多东西传统关系数据库用起来很缩手缩脚，我们目前有个项目就要用graph
db。。。我还准备学习一下，概念上还是突然接受不了，哈哈。就和当年star schema
一样，问自己很多遍为什么要酱紫啊 |
|
w****n
发帖数: 1737 | 19 hehe 居然在这碰到， 这世界说大也大说小也小啊。 还在老地方。 你也还是老地方？
服务器上
客户端用来收集数据。 目前只用关系数据，估计SQL够了。
从客户端收到数据， 到数据传到服务器， 再从服务器计算传回客户端，全程不超过《
=0.1秒
有什么选择呢？ |
|
s**********o
发帖数: 14359 | 20 SQL SERVER 2014已经有INMEMORY DATABASE功能了，ORACLE有EXADATA
硬件其实跟搞开发的没太多关系，你只要知道个原理会用，INTERVIEW
的时候可以吹嘘一翻 |
|
r********3
发帖数: 2998 | 21 1.恶补Java, J2EE或者C#+SQL。
这方面想在学校混好不容易。因为你如果出去说，这方面和在行的话。别人会问你一些
实际的项目怎么用的。你1年半在学校估计做不到这种大系统。
2.C/C++这个也不存在恶补不恶补，好好学就是。会C/C++和会Java不冲突的。基本上都
是触类旁通的。
3.从来没有SQL Programming这类说法。SQL不过是一个关系数据库的接口语言而已。你
要搞database的，里面的东西何止SQL那么简单。一般我认识国内这个行业的朋友，都
是写存储过程，维护database的。你必须很熟悉一种database的实际产品。比如说
Oracle，DB2这些。你在学校估计也没这个环境去弄。 |
|
d****i
发帖数: 4809 | 22 按照这种趋势，NoSQL有没有可能取代传统的SQL关系数据库？ |
|
g*****g
发帖数: 34805 | 23 stateful session bean没啥大用，是scale的大忌。单节点的时候看着很方便，等你量
上来了，单节点撑不住，立马面临程序重写。同样的需求，你把它扔进一个关系数据库
，不就简单多了。 |
|
|
c***d
发帖数: 996 | 25 我们作programming, 本质上就是对信息进行加工整理。 一个根本的问题就是怎么对信
息建模。 关系数据库给我们提供了一种选择， 加上事务性成就了三十年的基本后台架
构。 然后是xml， 对schema的定义能力有了一大步的扩展。目前json无疑是表达能力
和工程性能最好的数据模型， 这个是革命性的。 这好像坦克对大刀长矛， 根本没有
悬念。
我一直想找crawford聊聊他当时到底是怎么想出来这个东西的， 可惜他一直很忙。 |
|
g*****g
发帖数: 34805 | 26 我提过很多次，哪有那么多复杂多线程的应用。互联网应用大部分用户是不相干的，相
干的部分冲突在关系数据库解决。
经典的例子就是卖东西的网站。 |
|
g*****g
发帖数: 34805 | 27 因为它的架构做错了，前后端紧密耦合，下单既出票。每秒百万次的余票更新，一下子
要压到后台关系数据库上，顶不住。所以它干脆就不在前端堆机器，让app server拒绝
request. |
|
g*****g
发帖数: 34805 | 28 你就想像大家都排一个很长的队伍，人远比票多，有退票立马被waiting list吃掉了。
出票退票都在后端关系数据库上，当然是立刻放出的，我可没让退票也去排队。
是你理解能力太弱了，我整个架构每个细节都解释过10遍以上，你还是理解不了。 |
|
g*****g
发帖数: 34805 | 29 这种死锁关系数据库已经解决了几十年了，根本不用你操心。简单的实现就是排序的表
，顺序锁，哪会有死锁出现。
对应用是透明的。
msg |
|
g*****g
发帖数: 34805 | 30 我的设计，每个人只用下一次单子，等3分钟，你下多单子没用。单子没处理之前还可
以随便改。单子还支持备选车次，多人等等。整个系统没scale out的只有后台的关系
数据库，3分钟就等在那上面。 |
|
n*****t
发帖数: 22014 | 31 赵策，别胡扯了，这个 SQL 跟 DBA 有毛关系啊，语法不对都无所谓、不用忘了，拿个
思路那么难吗？ |
|
a*********a
发帖数: 3656 | 32 我在学校，企业里处理过大量数据。几乎没用过关系数据库，何谈传统？从来都用的是
几百到几千个core的cluster（当然是内部共享的），没有个cluster，我都不能想象怎
么干活。cloud是cluster的延伸而已。 |
|
g*****g
发帖数: 34805 | 33 企业计算，即便今天，还是主要基于关系数据库的。你跟我装有用吗？还能改变现实不
成？
小企业，以前根本没能力起一个成百上千机器的数据中心，更遑论用这么多机器做数据
收集和处理，雇人做这个级别数据的处理应用。而今天就像MySQL上写个CRUD一样都成
为可能。 |
|
b*******s
发帖数: 5216 | 34 nosql流行就是因为关系数据库太笨拙丑陋了
ivory |
|
|
d***a
发帖数: 13752 | 36 我觉得语言可以多学，学上十几种都没有关系
但别被绑在一种语言上，用新的语言几天就能上手
最重要的，不要象这个版上，为了用什么语言，吵来吵去... :) |
|
c*********e
发帖数: 16335 | 37 数据库用的oracle的。难怪双11那么多人上网，硬是没瘫痪。原来是请的sun的java工
程师来写的。那个时候竟然还没spring,nnd. |
|
g*****g
发帖数: 34805 | 38 数据库是自定制的MySQL, 这个级别统统如此。 |
|
n*w
发帖数: 3393 | 39 用关系数据库的话，我会加个PK（articleid，tagid）。 |
|
g*****g
发帖数: 34805 | 40 关系数据库做个B tree索引，插入再读出，不是一样要等索引做完。做索引不就是排序
。 |
|
g*****g
发帖数: 34805 | 41 你都没问到点子上，要说清楚是多大的数据，每秒多少，总量有没有上限。数据直接有
没有关系，对数据一致性要求多高。访问延迟要求。 |
|
i**i
发帖数: 1500 | 42 将来数据结构如果能统一成json的话 -- json只是数据的表示而已.
换nosql可能会好一点 -- no way. nosql和关系数据库一样历史悠久. 两者各有千秋.
类库换os也很蛋疼 -- 为毛换os? |
|
g*****g
发帖数: 34805 | 43 因为我老是做系统架构设计的，不是像你一样只会写个driver。你为你自己负责，我老
要为一个项目成败负责。可行性分析是必须的，可执行性也是必须的。所以我老能把一
个架构做得跟拼积木一样，每个轮子都是可靠的，不需要什么牛逼算法，每秒百万次写
也是benchmark过的，全靠轮子牛逼，写1M跟写1没有本质区别，你还想要什么源码？直
接抄C* HelloWorld都可以。
。http://techblog.netflix.com/2011/11/benchmarking-cassandra-scalability-on.html
后台关系数据库都不用换，性能也是按最保守的估计。就这样还能有很大余量。当你能
像我一样把一个方案做到这么鲁棒就根本没有人会来质疑能不能实现，无论是外行还是
内行都能理解，只有对非实时不满的。系统架构本来就是这样，方案说破了很朴素，但
是设计错了一个team的人遭殃。
反观你，除了一张嘴我行我就是行，还是屁都没有。让你吹破天还不是外行？你那1M
TCP连接就跟太监的太阳系计数器一样是看上去很美罢了。换成一个实际的系统要收发
个消息，10000都够呛。
至于太监为啥太监... 阅读全帖 |
|
k***5
发帖数: 583 | 44 关系数据库太死板了，一旦表定义了，要改很痛苦。
至于说“很多应该几年后都back fire”有些过，做好index的话没那么夸张。 |
|
|
l******n
发帖数: 9344 | 46 你想找相似的column吧？
我做过这个，用metadata就可以，然后考虑计算问题需要用到特殊的sampling
这个和dl一点关系都没有 |
|
w***g
发帖数: 5958 | 47 django作为model + restful server用。
django的ORM基本上还看不出来落后的迹象，框架也还可以。
用decoration做URL routing也有包可以加进去。
我确实太依赖关系数据库建模和ORM了。不然绝对上flask。
python/flask还有个意想不到的好处。就是现在的deep learning
框架都大的要死，对多线程支持并不好。用python反正也不用搞
线程了，就是一个进程配一个tensorflow或者caffe，然后用gunicorn
管理多个进程。写起来糙快猛。
后台template系统确实整个概念已经out了。这个我一年前就抛弃了。
vue和别的js框架发起的好处是，C++可以配js做用户界面了，qt啥的
都可以抛弃了。
o |
|
f******2
发帖数: 2455 | 48 一个http request激发一个caffe的计算？不会吧？
: django作为model restful server用。
: django的ORM基本上还看不出来落后的迹象，框架也还可以。
: 用decoration做URL routing也有包可以加进去。
: 我确实太依赖关系数据库建模和ORM了。不然绝对上flask。
: python/flask还有个意想不到的好处。就是现在的deep learning
: 框架都大的要死，对多线程支持并不好。用python反正也不用搞
: 线程了，就是一个进程配一个tensorflow或者caffe，然后用gunicorn
: 管理多个进程。写起来糙快猛。
: 后台template系统确实整个概念已经out了。这个我一年前就抛弃了。
: o
|
|
d***y
发帖数: 8536 | 49 1 你和老板自己决定是否放在论文里。好多论文数据库可以自己规定public available
的时间，比如你现在毕业可以让论文3年后在让别人看
2 你可以原封不动的抄发表的论文，但需要到发表论文的杂志社弄个permit。一般很简
单，直接网上申请就可以了，放在自己的博士论文里的内容是不收费的。 |
|
M*P
发帖数: 6456 | 50 要看你怎么算“实质性益处”了。比如你要是做玉米，估计human genome跟你没关系。
不过其实还是有关系，因为测序玉米也是用了HGP期间发展的算法。要是做疾病相关研
究的人，如果现在还认为HGP没有意义，就好像计算机普及之后还说算盘也可以算一样
。从那些只用过算盘的人的角度看，你的话确实没错。
有1 |
|
