作者littlethe (东周流浪汉)
看板Soft_Job
标题[讨论] 资料库和SQL的专业是不是很不被重视?
时间Mon Nov 27 02:24:33 2017
HI大家好,
小弟我是很喜欢研究资料库的人,
但待过几间公司後,
真的对资料库或SQL看到好多很奇怪的事,
我不知道是不是我运气太差一直遇到,
还是资料库真的很不被重视,
我遇到状况有:
1.主管只准许用left join来关连表,其他join不准用,
也不准用SP或变数或其他T-SQL的东西,只能在程式中拼接sql
2.表和栏位命名,用拼音的第一个字母组成,
例如客户主档就命名为KHZD,姓名就叫XM
3.时间全部都用字元存,而且有的存的方式是"2017/11/27 01:27:30"
都用字元存之前有板友聊过,但这种存法我相信比他看到的更夸张
4.做任何动作都塞好几列log,几天之内就加了几千万列log,把硬碟给塞爆
5.一个表搞到上百个栏位,大部份是没用或重覆,或是可以分割
6.没设主档,主档的资料全部写在明细里,
要秀主档的资料时,
就把明细group by来找,
明细也非常非常的大
7.重要的表没有栏位记录修改时间
8.重要的表没有加主键,重覆的资料可以直接加上去
9.在SP里,把sql存在变数里拼接,而不是直接写sql跑,
例如
declare @sql varchar(500)
set @sql = 'select * from table_a'
exec(@sql)
而且这样写不是因为有特殊目的,是一般的sp对方也这样写,直接写sql都可以跑的
10.栏位名字用a,b,c,d命名,各种资料都往里面塞,
所以a有时候是姓名,有时候是物品名,有时候是其他东西
11.拿之前的资料库改,但里面表名和栏位名都不改,
有什麽就塞,变成部门资料塞的是门店资料,
销售金额里存的不是销售金额,
客户编号存的是票据单号
12.要用其他资料库的表时(两个资料库在同一台伺服器上),不是直接连结,
而是定时把另一个资料库的表复制到自己资料库,再去读取
如果只是一家公司资料库乱设也就算了,
但我现在已经连续看到3家资料库都乱七八糟,
我真的很好奇是不是一般公司是不重视资料库?
也很少看到有人懂资料库,
而且很多状况其实已经不是不专业问题,
是没常识了...
我自己是有做过web和app,
业界的web和app当然问题也很多,
但问题的夸张程度都没有资料库来得夸张,
资料库不是非常重要的地方吗?
怎麽会出现那麽多奇怪的事?
是我太大惊小怪了吗?
还是是我运气不好,
其实大部份公司的资料库还算正常,不会这样?
--
和会你走到最後的人,
不是你最爱的人,
也不是最爱你的人,
而是和你最有缘的人
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 116.232.251.210
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1511720682.A.386.html
※ 编辑: littlethe (116.232.251.210), 11/27/2017 02:35:34
※ 编辑: littlethe (116.232.251.210), 11/27/2017 02:41:00
1F：推 expup: 你遇到的是常态 看开点 11/27 02:46
2F：推 aoksc: 应该算是你刚好都遇到技术都很low的公司吧… 11/27 02:46
3F：→ aoksc: 我个人遇到的大概70~80%都算正常 11/27 02:47
4F：→ aoksc: 我是有遇过单据流水号没设pk 然後程式又写超烂会重号 11/27 02:50
5F：→ littlethe: 我的流水号是会跑出null值的 11/27 03:13
6F：推 ripple0129: 不是不重视，是你在台湾 11/27 03:29
7F：→ newversion: 因为还没遇到 「每一秒钟 38 万笔交易」这种需求 11/27 03:44
8F：推 deforest111: 我觉得有几条是担心资料外泄的保护方式（脑补？ 11/27 05:24
9F：推 evabioz: 古董级的技术债... 11/27 06:42
10F：推 drajan: 就是一些连资料库实务都完全不懂的门外汉 11/27 07:03
11F：推 PasserDin: 4 11/27 07:19
12F：推 Beramode: 历史共业 11/27 07:33
13F：推 JUNYOU01: 一堆连正规化都不知道，以为加个pid栏位就是 … 11/27 07:35
14F：推 ChungLi5566: 传产很常见 系统能动就好 11/27 07:52
15F：→ keyboard56: 一般状况是程式能动就好，等有遇到问题再解就好，导致 11/27 07:53
16F：→ keyboard56: 後续接手的人不好维护，规划不好的地方因爲年代久远也 11/27 07:53
17F：→ keyboard56: 不会去动它，就这样循环下去... 11/27 07:53
18F：推 bill0205: 遇到很多前辈也是这种的+1 11/27 07:57
19F：→ dreamnook: 所谓技术债 11/27 08:11
20F：推 knives: 因为你在台湾+1 11/27 08:12
21F：推 Hordor: 因为你只能进去这种公司 11/27 08:25
22F：推 iamshiao: 这是常态，因为资料库上线後才发现设计瑕疵但资料已经进 11/27 08:26
23F：→ iamshiao: 了，回头修正成本很高，很多人选择将错就错。 11/27 08:26
24F：推 testPtt: 用这种方式排挤高手自己位子才坐得稳 11/27 08:31
25F：推 hotkt247: 是不是ㄧ路用Left join真的要看状况耶，有时需要inner j 11/27 08:35
26F：→ hotkt247: oin就不用再加where条件了。不能用SP也好奇怪呀@@，不过 11/27 08:35
27F：→ hotkt247: 还好我们公司没有你说的那些限制 11/27 08:35
28F：→ ChoDino: 从没看过你说的这些设计，加油点到知名公司吧。 11/27 08:38
29F：推 GoalBased: 自己选技术差的公司再来怪公司技术差 11/27 08:44
30F：推 oneheat: datetime会有null的问题的样子 11/27 08:44
31F：推 vi000246: 还没遇过 有几点都好扯 11/27 08:51
32F：推 lgzenith: log这条很难说正不正确，很多时候是办公室政治问题 11/27 09:04
33F：推 johnny94: 看到你这篇我真的心有戚戚焉 11/27 09:06
34F：→ fidelity77: 台湾软体很多都是能work 就好了，只注重成本低，做得 11/27 09:07
35F：→ fidelity77: 快 11/27 09:07
36F：→ fidelity77: 好不好维护谁管你 11/27 09:07
37F：→ tedmax100: 台湾的管理高层，99%都没有技术底 11/27 09:13
38F：推 f124: 资料库又没专人在管 系统可以动不要挂掉就好了你还要要啥 11/27 09:16
39F：推 ccc1001: 我觉得你这是第八手了，赶快逃吧 11/27 09:26
40F：→ ccc1001: 从没遇过这种 11/27 09:26
41F：推 cheng19: 前公司有碰过不准用SP 不过我没问原因就是了 11/27 09:35
42F：推 earny: 听朋友说：请主管开char(21) 但主管坚持开int，问题是资料 11/27 09:47
43F：→ earny: 长度就是21码！虽然都是数字，但Int就是无法存进去 11/27 09:47
44F：→ earny: 朋友的主管请他回去想办法，你知道int跟char(21)差多少吗？ 11/27 09:48
45F：→ earny: 还拿出纸笔算给朋友看.... 11/27 09:49
46F：推 cpper: 如果你有Oracle资料库管理师证照又去找Oracle资料库的管理 11/27 10:05
47F：→ cpper: 工作，就不会发生这种你遇到的事情了 11/27 10:05
48F：嘘 jj0321: 某几楼真爱讲干话 11/27 10:13
49F：→ maxqq: 老板通常都是，这个不重要以後再用。 11/27 10:13
50F：→ maxqq: 问题发生：你怎麽没弄，我觉得这个很重要啊 11/27 10:14
51F：推 imlin01: 我遇过一些小公司还真的没有专门管db的，主要是老板不重 11/27 10:28
52F：→ imlin01: 视，而且若是客户又不懂，我就亲眼看过某公家医院外包的 11/27 10:29
53F：→ imlin01: 系统table栏位全开成varchar(max)的 11/27 10:29
54F：推 thinkniht: 那正常啊 对外包而言 能跑能验收就好 11/27 10:37
55F：推 abc0922001: 明明重视的话可以避免很多问题 11/27 10:47
56F：→ fish0112: 很多是找写java C#後端的人"兼"DB的 你觉得很专业吗？ 11/27 11:08
57F：推 senjor: 你讲的问题就算不是SQL专业的人其实只要有经验就不会犯了 11/27 11:25
58F：推 Hordor: 当资料库不是需要每秒几百几千个交易的，BE 直接管就好， 11/27 11:32
59F：→ Hordor: 干嘛要DBA 11/27 11:32
60F：推 JUNYOU01: 其实是资讯能力都不被重视 11/27 11:47
61F：推 TAKADO: 公司不重视吧，你的问题如果是以资料库当主力产品的公司 11/27 12:13
62F：→ TAKADO: 应该就不会遇到，例如做data warehousing/mining的，至於 11/27 12:13
63F：→ TAKADO: 其他很多都是产品会动就好，更别说其他惨业土法炼钢的系 11/27 12:13
64F：→ TAKADO: 统。我看过1x年年资的MIS被公司凹做出来的进销存，整个系 11/27 12:13
65F：→ TAKADO: 统就三个资料表，只有int跟varchar(max)，令人不忍直视。 11/27 12:13
66F：推 vi000246: 2.3.5点正常人都能避免吧 也不会花多少时间 11/27 12:13
67F：→ vi000246: 会这样做的大概程式也写得很差 11/27 12:15
68F：推 JUNYOU01: 反正现在只要介面美美的就好，後端根本不重要 11/27 12:44
69F：推 NUKnigel: 我在银行跟电信待过 都没你说的问题 11/27 12:50
70F：→ littlethe: to earny,你朋友和那主管怎麽不用decimal(21,0)？听你 11/27 12:57
71F：→ littlethe: 状况是适合这个，char很占空间 11/27 12:57
72F：推 t64141: 不良的设计见过，但没遇过这麽离谱的 11/27 13:00
73F：→ littlethe: 我是走Ms sql，这麽说来oracle状况会好很多？ 11/27 13:01
74F：推 ChungLi5566: 10年後 就换後辈抱怨前人的code都没资安 11/27 13:36
75F：→ ChungLi5566: 以前写程式没要求这麽多,小公司也不太会搞提升案 11/27 13:37
76F：推 abccbaandy: @imlin01 那种用一次的专案全开varchar(max)很正常吧 11/27 14:00
77F：→ abccbaandy: 在那边慢慢设计才真的浪费时间 11/27 14:00
78F：→ abccbaandy: 关键字(外包) 11/27 14:01
79F：推 johnny94: 楼上这种观念才是真的浪费时间 11/27 14:03
80F：推 newways: 全没遇过... 11/27 14:05
81F：推 senjor: 应该说，浪费时间要看是浪费谁的，自己方便，後面的人麻烦 11/27 14:08
82F：→ senjor: 对很多人来讲还是会选择自己方便的方式去做 XDD 11/27 14:08
83F：推 oneheat: 文人相轻啊，自己的方法永远最好。老早就说还是show薪资 11/27 14:27
84F：→ oneheat: 单比薪水最快 11/27 14:27
85F：推 edward13: 竹科大厂用oracle，也请的起dba，所以不会有上述问题(? 11/27 14:42
86F：推 Dnight: 电信业没遇过这状况 11/27 15:03
87F：推 elements: 就是篇抱怨文 拍拍 但是还是要乖乖去上班喔 11/27 15:16
88F：推 abccbaandy: 就没有"後面的人"啊，就说一次性了 11/27 15:19
89F：→ abccbaandy: 不过老是做这种，真的对自己技术没什麽帮助就是了... 11/27 15:21
90F：→ abccbaandy: 有机会还是跑吧 11/27 15:21
91F：→ Weky: 常态 请一个懂的只会资料库没价值 11/27 16:28
92F：推 mentha39: 应该是说会投资oracle的比较可能会重视资料库 11/27 16:37
93F：推 Adonisy: 现在资料库都不便宜啊... 11/27 16:53
94F：推 ilay: 去错地方了，换别的地方吧 11/27 17:03
95F：推 Hordor: 投资 oracle/mssql 只是需要原厂 support 与背书而已XD 11/27 17:05
96F：→ newversion: 我遇过连 order by 都不知道的. 用土炮法去sort @.@ 11/27 17:24
97F：→ newversion: 一般人觉得只要会select insert update delete 就可以 11/27 17:26
98F：→ newversion: 出来行走江湖了 XD 11/27 17:26
99F：推 johnny94: 楼上，那种人还会跟你说这样效率比较好 11/27 17:30
100F：推 nova06091: 4 11/27 18:32
101F：推 eeyellow: 很多是前朝遗毒啦...後面接手的人要改发现工程浩大 11/27 18:49
102F：→ eeyellow: 只好一起历史共业了 11/27 18:49
103F：推 ncwd1225: 这太扯，比大学毕业专案还弱 11/27 19:07
104F：推 alian954: 遇过几个工程师资料库table都不改名 各种复制 改程式改 11/27 19:50
105F：→ alian954: 到很火 11/27 19:50
106F：推 neo5277: 鼎新表示 11/27 20:08
107F：→ littlethe: 我还真的和老板讲过我们的产品比大学毕业专题还烂 11/27 20:25
108F：→ littlethe: 所以各位大学生，你们要对自己有信心 11/27 20:26
109F：→ bobju: 原po还在上海吗? 客户主档就命名为KHZD,姓名就叫XM 这种的 11/27 20:50
110F：→ bobju: 一看就知是大陆的汉语拼音的命名方式 11/27 20:51
111F：推 mathrew: 习惯就好 我们公司早期的资料库栏位名称还是中文 11/27 21:13
112F：→ mathrew: 根本快吐血 11/27 21:13
113F：推 prag222: 你有这些问题代表你离DBA还远的很咧 11/27 21:37
114F：推 touurtn: 很多年纪很大的码农根本不在乎这些原则 尤其驻点维护 11/27 23:35
115F：→ littlethe: To bobju:那是我以前在越南遇到的事，开这表的人是大 11/28 00:49
116F：→ littlethe: 陆人 11/28 00:49
117F：→ littlethe: 我是在左岸没错，然後很多人说上海有多强，我看了结果 11/28 00:52
118F：→ littlethe: 不过尔尔，应该是我待的地方太烂 11/28 00:52
119F：→ littlethe: 大陆人素质的落差比台湾大很多 11/28 00:53
120F：→ littlethe: 谢谢大家的心理辅导，我现在好一点了 11/28 01:01
121F：→ giantwinter: 4 11/28 03:28
122F：推 imlin01: 开varchar(max)代表那间公司完全没人懂db,完全没有专业， 11/28 09:54
123F：→ imlin01: 可悲的是user不懂，所以完全没意见 11/28 09:54
124F：推 earny: to littlethe其实我有跟我朋友提到，但最後主管是加开另一 11/28 10:47
125F：→ earny: 个栏位，char(21)，保留原来的int。听了之後完全被打败。 11/28 10:48
126F：→ earny: 朋友的主管就坚持int一定要存在...XD 11/28 10:48
127F：→ earny: 真的令人搞不懂，坚持int，宁愿加开另一个栏位XD 11/28 10:49
128F：→ johnny94: 我觉得那是拉不下脸承认自己不懂 11/28 12:13
129F：推 xo1100: 有遇过公司开发用C#不准用linq的 11/28 15:44
130F：→ viper9709: 连续三家@@~这也太惨 11/28 23:10
131F：→ littlethe: to earny:再加一个栏位哦...这真的就没意义了 11/29 00:47
132F：→ littlethe: 很多时候真的是对方拉不下脸,就利用权势蛮干或斗争 11/29 00:49
133F：嘘 darkMood: 是的，因为会动就好，2万笔资料和2亿笔资料前者随便就好 11/29 01:42
134F：→ SY082022: 系统会动就好，有问题了，下面的工程师会抗，上面的老板 11/29 13:40
135F：→ SY082022: 也不懂，什麽都规划的那麽好，怎麽有源源不绝的专案给老 11/29 13:40
136F：→ SY082022: 板报告，我现在的公司就是这样 11/29 13:40
137F：推 te426odin: 我也遇过同事看不懂Linq所以不能用LINQ (还不是Lambai 11/29 16:18
138F：→ te426odin: 还不是(lamba表示式喔) 11/29 16:18
139F：推 quickey: 你遇到的是垃圾场不是资料库 11/29 16:33
140F：推 marc47: 没好的系统分析师就会这样 01/17 11:55