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

看板Soft_Job作者 (東周流浪漢)時間6年前 (2017/11/27 02:24), 6年前編輯推噓64(66推 2噓 72→)
留言140則, 69人參與, 7年前最新討論串1/9 (看更多)
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
推
11/27 02:46, 6年前 , 1F
你遇到的是常態 看開點
11/27 02:46, 1F
推
11/27 02:46, 6年前 , 2F
應該算是你剛好都遇到技術都很low的公司吧…
11/27 02:46, 2F
→
11/27 02:47, 6年前 , 3F
我個人遇到的大概70~80%都算正常
11/27 02:47, 3F
→
11/27 02:50, 6年前 , 4F
我是有遇過單據流水號沒設pk 然後程式又寫超爛會重號
11/27 02:50, 4F
→
11/27 03:13, 6年前 , 5F
我的流水號是會跑出null值的
11/27 03:13, 5F
推
11/27 03:29, 6年前 , 6F
不是不重視，是你在台灣
11/27 03:29, 6F
→
11/27 03:44, 6年前 , 7F
因為還沒遇到 「每一秒鐘 38 萬筆交易」這種需求
11/27 03:44, 7F
推
11/27 05:24, 6年前 , 8F
我覺得有幾條是擔心資料外洩的保護方式（腦補？
11/27 05:24, 8F
推
11/27 06:42, 6年前 , 9F
古董級的技術債...
11/27 06:42, 9F
推
11/27 07:03, 6年前 , 10F
就是一些連資料庫實務都完全不懂的門外漢
11/27 07:03, 10F
推
11/27 07:19, 6年前 , 11F
4
11/27 07:19, 11F
推
11/27 07:33, 6年前 , 12F
歷史共業
11/27 07:33, 12F
推
11/27 07:35, 6年前 , 13F
一堆連正規化都不知道，以為加個pid欄位就是 …
11/27 07:35, 13F
推
11/27 07:52, 6年前 , 14F
傳產很常見 系統能動就好
11/27 07:52, 14F
→
11/27 07:53, 6年前 , 15F
一般狀況是程式能動就好，等有遇到問題再解就好，導致
11/27 07:53, 15F
→
11/27 07:53, 6年前 , 16F
後續接手的人不好維護，規劃不好的地方因爲年代久遠也
11/27 07:53, 16F
→
11/27 07:53, 6年前 , 17F
不會去動它，就這樣循環下去...
11/27 07:53, 17F
推
11/27 07:57, 6年前 , 18F
遇到很多前輩也是這種的+1
11/27 07:57, 18F
→
11/27 08:11, 6年前 , 19F
所謂技術債
11/27 08:11, 19F
推
11/27 08:12, 6年前 , 20F
因為你在台灣+1
11/27 08:12, 20F
推
11/27 08:25, 6年前 , 21F
因為你只能進去這種公司
11/27 08:25, 21F
推
11/27 08:26, 6年前 , 22F
這是常態，因為資料庫上線後才發現設計瑕疵但資料已經進
11/27 08:26, 22F
→
11/27 08:26, 6年前 , 23F
了，回頭修正成本很高，很多人選擇將錯就錯。
11/27 08:26, 23F
推
11/27 08:31, 6年前 , 24F
用這種方式排擠高手自己位子才坐得穩
11/27 08:31, 24F
推
11/27 08:35, 6年前 , 25F
是不是ㄧ路用Left join真的要看狀況耶，有時需要inner j
11/27 08:35, 25F
→
11/27 08:35, 6年前 , 26F
oin就不用再加where條件了。不能用SP也好奇怪呀@@，不過
11/27 08:35, 26F
→
11/27 08:35, 6年前 , 27F
還好我們公司沒有你說的那些限制
11/27 08:35, 27F
→
11/27 08:38, 6年前 , 28F
從沒看過你說的這些設計，加油點到知名公司吧。
11/27 08:38, 28F
推
11/27 08:44, 6年前 , 29F
自己選技術差的公司再來怪公司技術差
11/27 08:44, 29F
推
11/27 08:44, 6年前 , 30F
datetime會有null的問題的樣子
11/27 08:44, 30F
推
11/27 08:51, 6年前 , 31F
還沒遇過 有幾點都好扯
11/27 08:51, 31F
推
11/27 09:04, 6年前 , 32F
log這條很難說正不正確，很多時候是辦公室政治問題
11/27 09:04, 32F
推
11/27 09:06, 6年前 , 33F
看到你這篇我真的心有戚戚焉
11/27 09:06, 33F
→
11/27 09:07, 6年前 , 34F
臺灣軟體很多都是能work 就好了，只注重成本低，做得
11/27 09:07, 34F
→
11/27 09:07, 6年前 , 35F
快
11/27 09:07, 35F
→
11/27 09:07, 6年前 , 36F
好不好維護誰管你
11/27 09:07, 36F
→
11/27 09:13, 6年前 , 37F
台灣的管理高層，99%都沒有技術底
11/27 09:13, 37F
推
11/27 09:16, 6年前 , 38F
資料庫又沒專人在管 系統可以動不要掛掉就好了你還要要啥
11/27 09:16, 38F
推
11/27 09:26, 6年前 , 39F
我覺得你這是第八手了，趕快逃吧
11/27 09:26, 39F
還有 61 則推文
推
11/27 18:49, 6年前 , 101F
很多是前朝遺毒啦...後面接手的人要改發現工程浩大
11/27 18:49, 101F
→
11/27 18:49, 6年前 , 102F
只好一起歷史共業了
11/27 18:49, 102F
推
11/27 19:07, 6年前 , 103F
這太扯，比大學畢業專案還弱
11/27 19:07, 103F
推
11/27 19:50, 6年前 , 104F
遇過幾個工程師資料庫table都不改名 各種複製 改程式改
11/27 19:50, 104F
→
11/27 19:50, 6年前 , 105F
到很火
11/27 19:50, 105F
推
11/27 20:08, 6年前 , 106F
鼎新表示
11/27 20:08, 106F
→
11/27 20:25, 6年前 , 107F
我還真的和老闆講過我們的產品比大學畢業專題還爛
11/27 20:25, 107F
→
11/27 20:26, 6年前 , 108F
所以各位大學生，你們要對自己有信心
11/27 20:26, 108F
→
11/27 20:50, 6年前 , 109F
原po還在上海嗎? 客戶主檔就命名為KHZD,姓名就叫XM 這種的
11/27 20:50, 109F
→
11/27 20:51, 6年前 , 110F
一看就知是大陸的漢語拼音的命名方式
11/27 20:51, 110F
推
11/27 21:13, 6年前 , 111F
習慣就好 我們公司早期的資料庫欄位名稱還是中文
11/27 21:13, 111F
→
11/27 21:13, 6年前 , 112F
根本快吐血
11/27 21:13, 112F
推
11/27 21:37, 6年前 , 113F
你有這些問題代表你離DBA還遠的很咧
11/27 21:37, 113F
推
11/27 23:35, 6年前 , 114F
很多年紀很大的碼農根本不在乎這些原則 尤其駐點維護
11/27 23:35, 114F
→
11/28 00:49, 6年前 , 115F
To bobju:那是我以前在越南遇到的事，開這表的人是大
11/28 00:49, 115F
→
11/28 00:49, 6年前 , 116F
陸人
11/28 00:49, 116F
→
11/28 00:52, 6年前 , 117F
我是在左岸沒錯，然後很多人說上海有多強，我看了結果
11/28 00:52, 117F
→
11/28 00:52, 6年前 , 118F
不過爾爾，應該是我待的地方太爛
11/28 00:52, 118F
→
11/28 00:53, 6年前 , 119F
大陸人素質的落差比台灣大很多
11/28 00:53, 119F
→
11/28 01:01, 6年前 , 120F
謝謝大家的心理輔導，我現在好一點了
11/28 01:01, 120F
→
11/28 03:28, 6年前 , 121F
4
11/28 03:28, 121F
推
11/28 09:54, 6年前 , 122F
開varchar(max)代表那間公司完全沒人懂db,完全沒有專業，
11/28 09:54, 122F
→
11/28 09:54, 6年前 , 123F
可悲的是user不懂，所以完全沒意見
11/28 09:54, 123F
推
11/28 10:47, 6年前 , 124F
to littlethe其實我有跟我朋友提到，但最後主管是加開另一
11/28 10:47, 124F
→
11/28 10:48, 6年前 , 125F
個欄位，char(21)，保留原來的int。聽了之後完全被打敗。
11/28 10:48, 125F
→
11/28 10:48, 6年前 , 126F
朋友的主管就堅持int一定要存在...XD
11/28 10:48, 126F
→
11/28 10:49, 6年前 , 127F
真的令人搞不懂，堅持int，寧願加開另一個欄位XD
11/28 10:49, 127F
→
11/28 12:13, 6年前 , 128F
我覺得那是拉不下臉承認自己不懂
11/28 12:13, 128F
推
11/28 15:44, 6年前 , 129F
有遇過公司開發用C#不准用linq的
11/28 15:44, 129F
→
11/28 23:10, 6年前 , 130F
連續三家@@~這也太慘
11/28 23:10, 130F
→
11/29 00:47, 6年前 , 131F
to earny:再加一個欄位哦...這真的就沒意義了
11/29 00:47, 131F
→
11/29 00:49, 6年前 , 132F
很多時候真的是對方拉不下臉,就利用權勢蠻幹或鬥爭
11/29 00:49, 132F
噓
11/29 01:42, 6年前 , 133F
是的，因為會動就好，2萬筆資料和2億筆資料前者隨便就好
11/29 01:42, 133F
→
11/29 13:40, 6年前 , 134F
系統會動就好，有問題了，下面的工程師會抗，上面的老闆
11/29 13:40, 134F
→
11/29 13:40, 6年前 , 135F
也不懂，什麼都規劃的那麼好，怎麼有源源不絕的專案給老
11/29 13:40, 135F
→
11/29 13:40, 6年前 , 136F
闆報告，我現在的公司就是這樣
11/29 13:40, 136F
推
11/29 16:18, 6年前 , 137F
我也遇過同事看不懂Linq所以不能用LINQ (還不是Lambai
11/29 16:18, 137F
→
11/29 16:18, 6年前 , 138F
還不是(lamba表示式喔)
11/29 16:18, 138F
推
11/29 16:33, 6年前 , 139F
你遇到的是垃圾場不是資料庫
11/29 16:33, 139F
推
01/17 11:55, 7年前 , 140F
沒好的系統分析師就會這樣
01/17 11:55, 140F
‣ 更多 littlethe 的文章
文章代碼(AID): #1Q6mRgE6 (Soft_Job)
討論串 (同標題文章)
以下文章回應了本文：
完整討論串 (本文為第 1 之 9 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共9篇)
‣ 更多 littlethe 的文章
文章代碼(AID): #1Q6mRgE6 (Soft_Job)