[討論] 資料庫和SQL的專業是不是很不被重視?

[littlethe (東周流浪漢)]

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://www.ptt.cc/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
推 expup: 你遇到的是常態 看開點
推 aoksc: 應該算是你剛好都遇到技術都很low的公司吧…
→ aoksc: 我個人遇到的大概70~80%都算正常
→ aoksc: 我是有遇過單據流水號沒設pk 然後程式又寫超爛會重號
→ littlethe: 我的流水號是會跑出null值的
推 ripple0129: 不是不重視，是你在台灣
→ newversion: 因為還沒遇到 「每一秒鐘 38 萬筆交易」這種需求
推 deforest111: 我覺得有幾條是擔心資料外洩的保護方式（腦補？
推 evabioz: 古董級的技術債...
推 drajan: 就是一些連資料庫實務都完全不懂的門外漢
推 PasserDin: 4
推 Beramode: 歷史共業
推 JUNYOU01: 一堆連正規化都不知道，以為加個pid欄位就是 …
推 ChungLi5566: 傳產很常見 系統能動就好
→ keyboard56: 一般狀況是程式能動就好，等有遇到問題再解就好，導致
→ keyboard56: 後續接手的人不好維護，規劃不好的地方因爲年代久遠也
→ keyboard56: 不會去動它，就這樣循環下去...
推 bill0205: 遇到很多前輩也是這種的+1
→ dreamnook: 所謂技術債
推 knives: 因為你在台灣+1
推 Hordor: 因為你只能進去這種公司
推 iamshiao: 這是常態，因為資料庫上線後才發現設計瑕疵但資料已經進
→ iamshiao: 了，回頭修正成本很高，很多人選擇將錯就錯。
推 testPtt: 用這種方式排擠高手自己位子才坐得穩
推 hotkt247: 是不是ㄧ路用Left join真的要看狀況耶，有時需要inner j
→ hotkt247: oin就不用再加where條件了。不能用SP也好奇怪呀@@，不過
→ hotkt247: 還好我們公司沒有你說的那些限制
→ ChoDino: 從沒看過你說的這些設計，加油點到知名公司吧。
推 GoalBased: 自己選技術差的公司再來怪公司技術差
推 oneheat: datetime會有null的問題的樣子
推 vi000246: 還沒遇過 有幾點都好扯
推 lgzenith: log這條很難說正不正確，很多時候是辦公室政治問題
推 johnny94: 看到你這篇我真的心有戚戚焉
→ fidelity77: 臺灣軟體很多都是能work 就好了，只注重成本低，做得
→ fidelity77: 快
→ fidelity77: 好不好維護誰管你
→ tedmax100: 台灣的管理高層，99%都沒有技術底
推 f124: 資料庫又沒專人在管 系統可以動不要掛掉就好了你還要要啥
推 ccc1001: 我覺得你這是第八手了，趕快逃吧
→ ccc1001: 從沒遇過這種
推 cheng19: 前公司有碰過不准用SP 不過我沒問原因就是了
推 earny: 聽朋友說：請主管開char(21) 但主管堅持開int，問題是資料
→ earny: 長度就是21碼！雖然都是數字，但Int就是無法存進去
→ earny: 朋友的主管請他回去想辦法，你知道int跟char(21)差多少嗎？
→ earny: 還拿出紙筆算給朋友看....
推 cpper:  如果你有Oracle資料庫管理師證照又去找Oracle資料庫的管理
→ cpper: 工作，就不會發生這種你遇到的事情了
噓 jj0321: 某幾樓真愛講幹話
→ maxqq: 老闆通常都是，這個不重要以後再用。
→ maxqq: 問題發生：你怎麼沒弄，我覺得這個很重要啊
推 imlin01: 我遇過一些小公司還真的沒有專門管db的，主要是老闆不重
→ imlin01: 視，而且若是客戶又不懂，我就親眼看過某公家醫院外包的
→ imlin01: 系統table欄位全開成varchar(max)的
推 thinkniht: 那正常啊 對外包而言 能跑能驗收就好
推 abc0922001: 明明重視的話可以避免很多問題
→ fish0112: 很多是找寫java C#後端的人"兼"DB的 你覺得很專業嗎？
推 senjor: 你講的問題就算不是SQL專業的人其實只要有經驗就不會犯了
推 Hordor: 當資料庫不是需要每秒幾百幾千個交易的，BE 直接管就好，
→ Hordor: 幹嘛要DBA
推 JUNYOU01: 其實是資訊能力都不被重視
推 TAKADO: 公司不重視吧，你的問題如果是以資料庫當主力產品的公司
→ TAKADO: 應該就不會遇到，例如做data warehousing/mining的，至於
→ TAKADO: 其他很多都是產品會動就好，更別說其他慘業土法煉鋼的系
→ TAKADO: 統。我看過1x年年資的MIS被公司凹做出來的進銷存，整個系
→ TAKADO: 統就三個資料表，只有int跟varchar(max)，令人不忍直視。
推 vi000246: 2.3.5點正常人都能避免吧 也不會花多少時間
→ vi000246: 會這樣做的大概程式也寫得很差
推 JUNYOU01: 反正現在只要介面美美的就好，後端根本不重要
推 NUKnigel: 我在銀行跟電信待過 都沒你說的問題
→ littlethe: to earny,你朋友和那主管怎麼不用decimal(21,0)？聽你
→ littlethe: 狀況是適合這個，char很佔空間
推 t64141: 不良的設計見過，但沒遇過這麼離譜的
→ littlethe: 我是走Ms sql，這麼說來oracle狀況會好很多？
推 ChungLi5566: 10年後 就換後輩抱怨前人的code都沒資安
→ ChungLi5566: 以前寫程式沒要求這麼多,小公司也不太會搞提升案
推 abccbaandy: @imlin01 那種用一次的專案全開varchar(max)很正常吧
→ abccbaandy: 在那邊慢慢設計才真的浪費時間
→ abccbaandy: 關鍵字(外包)
推 johnny94: 樓上這種觀念才是真的浪費時間
推 newways: 全沒遇過...
推 senjor: 應該說，浪費時間要看是浪費誰的，自己方便，後面的人麻煩
→ senjor: 對很多人來講還是會選擇自己方便的方式去做 XDD
推 oneheat: 文人相輕啊，自己的方法永遠最好。老早就說還是show薪資
→ oneheat: 單比薪水最快
推 edward13: 竹科大廠用oracle，也請的起dba，所以不會有上述問題(?
推 Dnight: 電信業沒遇過這狀況
推 elements: 就是篇抱怨文 拍拍 但是還是要乖乖去上班喔
推 abccbaandy: 就沒有"後面的人"啊，就說一次性了
→ abccbaandy: 不過老是做這種，真的對自己技術沒什麼幫助就是了...
→ abccbaandy: 有機會還是跑吧
→ Weky: 常態  請一個懂的只會資料庫沒價值
推 mentha39: 應該是說會投資oracle的比較可能會重視資料庫
推 Adonisy: 現在資料庫都不便宜啊...
推 ilay: 去錯地方了，換別的地方吧
推 Hordor: 投資 oracle/mssql 只是需要原廠 support 與背書而已XD
→ newversion: 我遇過連 order by 都不知道的. 用土砲法去sort @.@
→ newversion: 一般人覺得只要會select insert update delete 就可以
→ newversion: 出來行走江湖了 XD
推 johnny94: 樓上，那種人還會跟你說這樣效率比較好
推 nova06091: 4
推 eeyellow: 很多是前朝遺毒啦...後面接手的人要改發現工程浩大
→ eeyellow: 只好一起歷史共業了
推 ncwd1225: 這太扯，比大學畢業專案還弱
推 alian954: 遇過幾個工程師資料庫table都不改名 各種複製 改程式改
→ alian954: 到很火
推 neo5277: 鼎新表示
→ littlethe: 我還真的和老闆講過我們的產品比大學畢業專題還爛
→ littlethe: 所以各位大學生，你們要對自己有信心
→ bobju: 原po還在上海嗎? 客戶主檔就命名為KHZD,姓名就叫XM 這種的
→ bobju: 一看就知是大陸的漢語拼音的命名方式
推 mathrew: 習慣就好  我們公司早期的資料庫欄位名稱還是中文
→ mathrew: 根本快吐血
推 prag222: 你有這些問題代表你離DBA還遠的很咧
推 touurtn: 很多年紀很大的碼農根本不在乎這些原則 尤其駐點維護
→ littlethe: To bobju:那是我以前在越南遇到的事，開這表的人是大
→ littlethe: 陸人
→ littlethe: 我是在左岸沒錯，然後很多人說上海有多強，我看了結果
→ littlethe: 不過爾爾，應該是我待的地方太爛
→ littlethe: 大陸人素質的落差比台灣大很多
→ littlethe: 謝謝大家的心理輔導，我現在好一點了
→ giantwinter: 4
推 imlin01: 開varchar(max)代表那間公司完全沒人懂db,完全沒有專業，
→ imlin01: 可悲的是user不懂，所以完全沒意見
推 earny: to littlethe其實我有跟我朋友提到，但最後主管是加開另一
→ earny: 個欄位，char(21)，保留原來的int。聽了之後完全被打敗。
→ earny: 朋友的主管就堅持int一定要存在...XD
→ earny: 真的令人搞不懂，堅持int，寧願加開另一個欄位XD
→ johnny94: 我覺得那是拉不下臉承認自己不懂
推 xo1100: 有遇過公司開發用C#不准用linq的
→ viper9709: 連續三家@@~這也太慘
→ littlethe: to earny:再加一個欄位哦...這真的就沒意義了
→ littlethe: 很多時候真的是對方拉不下臉,就利用權勢蠻幹或鬥爭
噓 darkMood: 是的，因為會動就好，2萬筆資料和2億筆資料前者隨便就好
→ SY082022: 系統會動就好，有問題了，下面的工程師會抗，上面的老闆
→ SY082022: 也不懂，什麼都規劃的那麼好，怎麼有源源不絕的專案給老
→ SY082022: 闆報告，我現在的公司就是這樣
推 te426odin: 我也遇過同事看不懂Linq所以不能用LINQ (還不是Lambai
→ te426odin: 還不是(lamba表示式喔)
推 quickey: 你遇到的是垃圾場不是資料庫
推 marc47: 沒好的系統分析師就會這樣