Re: [請益] 公司認為的碩士是什麼....

看板Soft_Job作者 (沒有暱稱)時間15年前 (2009/06/18 17:33), 編輯推噓54(54推 0噓 29→)
留言83則, 47人參與, 最新討論串9/13 (看更多)
話說在數年前, 來了一位112資訊相關研究所的應屆畢業生, 第一天上班,第一件任務-建員工table(for SQL server), 包含員工編號.姓名.地址... 搞了一天終於在下班前完成....... name type 編號 int 姓名-姓 nvarchar 姓名-名 nvarchar 地址-縣市 nvarchar 地址-區 nvarchar 地址-路 nvarchar ....... 怕有些同是112的看不懂,在此說明一下, 1.欄位名稱居然用中文!!!!! 2.型態最好都給我用n開頭的!!!! 3.你是覺得coding人員太閒嗎? 一個欄位可以完成的,給我分好幾個!!! 這就是對石頁士的看法. -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 203.79.199.38
→
06/18 17:42, , 1F
念資訊不一定修過資料庫的課程，有些只是會用
06/18 17:42, 1F
推
06/18 17:42, , 2F
就欄位該用幾個來說~是沒溝通好的問題吧~同樣是住址~不同
06/18 17:42, 2F
→
06/18 17:42, , 3F
修過的則可能出現過度正規化的毛病
06/18 17:42, 3F
→
06/18 17:43, , 4F
沒有去自修、或是工作經驗，很難設計出恰當的資料庫結構
06/18 17:43, 4F
→
06/18 17:43, , 5F
的需求就會有不同的設計~不是嗎?
06/18 17:43, 5F
→
06/18 17:44, , 6F
以上只是關聯式資料庫的問題。
06/18 17:44, 6F
→
06/18 17:44, , 7F
如果一個關聯式資料庫的老手突然去設計分散式資料庫，
06/18 17:44, 7F
推
06/18 17:44, , 8F
小弟不才, 我想請教第二點的問題是在...?
06/18 17:44, 8F
→
06/18 17:45, , 9F
設計出來的東西反而不能用
06/18 17:45, 9F
→
06/18 17:45, , 10F
推1F~應該根據需求去設計資料庫結構~哪有一概而論的...
06/18 17:45, 10F
推
06/18 17:46, , 11F
這幾個欄位用nvarchar還好吧
06/18 17:46, 11F
推
06/18 17:49, , 12F
其實我覺得問題最大的是那個 -
06/18 17:49, 12F
推
06/18 18:05, , 13F
nvarchar不錯啊!放unicode資料耶!地址分多個欄位，也可能啊!
06/18 18:05, 13F
推
06/18 18:07, , 14F
其實預期會使用中文的欄位最好都用nvarchar
06/18 18:07, 14F
推
06/18 18:21, , 15F
除了第一點外,其他我覺得還好啊...
06/18 18:21, 15F
推
06/18 18:45, , 16F
最大的問題就是,它是台大碩士...XD
06/18 18:45, 16F
→
06/18 18:46, , 17F
只要是台大碩士就是不能犯錯,不能有不會的東西.XD
06/18 18:46, 17F
推
06/18 19:03, , 18F
滿無聊的
06/18 19:03, 18F
推
06/18 19:21, , 19F
學CS的比較著重在演算法
06/18 19:21, 19F
推
06/18 19:29, , 20F
搞不好人家認為你們太遜 怕你們看不懂英文 ....
06/18 19:29, 20F
→
06/18 19:30, , 21F
切欄位結構是怕你們不會下like語法.......:P
06/18 19:30, 21F
推
06/18 19:38, , 22F
編號用int應該一下子就爆了XD
06/18 19:38, 22F
推
06/18 19:40, , 23F
不會有那麼多員工的吧XD
06/18 19:40, 23F
推
06/18 20:23, , 24F
重點是在下班前才完成吧。。。。
06/18 20:23, 24F
推
06/18 20:35, , 25F
弟一天啥事不知就推上火線 這種結果很意外嗎
06/18 20:35, 25F
推
06/18 20:39, , 26F
第一天應該是認識環境…然後教育訓練好幾天…你們有嗎？
06/18 20:39, 26F
推
06/18 20:44, , 27F
這因該要有設計 文件吧
06/18 20:44, 27F
推
06/18 21:04, , 28F
笑點在哪?
06/18 21:04, 28F
推
06/18 21:34, , 29F
不是唸資訊的就代表什麼都會啊...
06/18 21:34, 29F
推
06/18 21:36, , 30F
說不定大學專題跟碩士班是搞硬體的
06/18 21:36, 30F
推
06/18 21:36, , 31F
這個人一定修過CRM...
06/18 21:36, 31F
推
06/18 21:57, , 32F
上班第一天就做到這樣 還不差吧
06/18 21:57, 32F
推
06/18 22:08, , 33F
會出現這樣的情況，到底是誰有問題？
06/18 22:08, 33F
推
06/18 22:17, , 34F
好輕鬆的第一天~"~其實我最怕有欄位是放代號的
06/18 22:17, 34F
→
06/18 22:19, , 35F
到時候就會看到SQL用case程式在if個沒完
06/18 22:19, 35F
推
06/18 22:23, , 36F
除了欄位名稱其他也都還好吧
06/18 22:23, 36F
→
06/18 22:23, , 37F
編號用int 也是要看用途吧 我們公司也常用識別int阿
06/18 22:23, 37F
→
06/18 22:23, , 38F
unique又不用特殊組合 XD
06/18 22:23, 38F
推
06/18 22:30, , 39F
嫉妒...嗎?
06/18 22:30, 39F
推
06/18 22:34, , 40F
nvarchar是正解 做過全球的專案就會有此感受
06/18 22:34, 40F
→
06/18 22:36, , 41F
姓名分開也是正解 隨便舉例 發系統信 每個人姓擺後面
06/18 22:36, 41F
→
06/18 22:36, , 42F
台灣人姓擺前面 地址有時候也是這個意思
06/18 22:36, 42F
→
06/18 22:38, , 43F
（每個人）打錯 我是說美國人姓擺後面
06/18 22:38, 43F
→
06/18 22:39, , 44F
我們公司用Siebel（算是業界標竿的CRM之一）就是這樣設計
06/18 22:39, 44F
推
06/18 22:40, , 45F
欄位: A B C D E F G H.....
06/18 22:40, 45F
→
06/18 22:41, , 46F
TABLE 除了欄位用中文有點怪怪的 其他的並沒有做錯
06/18 22:41, 46F
推
06/18 22:44, , 47F
小公司用int不會爆吧...七、八年才到編號3XX = ="
06/18 22:44, 47F
推
06/18 22:56, , 48F
這和112有什麼關係?.大學碩所碰的東西本來就都還很小
06/18 22:56, 48F
→
06/18 22:57, , 49F
我相信..你和他說一下你要的功能和原因後
06/18 22:57, 49F
→
06/18 22:57, , 50F
他還是用的出來的...只是要點時間而己.
06/18 22:57, 50F
推
06/18 22:58, , 51F
主要是他的設計某些地方根本很對 結果反被批？！
06/18 22:58, 51F
推
06/18 23:00, , 52F
有沒有八卦是很多資深人員喜歡搞名校碩士~
06/18 23:00, 52F
推
06/18 23:17, , 53F
nvarchar哪裡有問題，不然游錫堃、陶喆等名存得進去嗎
06/18 23:17, 53F
推
06/18 23:19, , 54F
老鳥看菜鳥稍有不合意就處處挑毛病 是誰的問題還不一定
06/18 23:19, 54F
推
06/18 23:37, , 55F
看到112口氣都變了? 資訊科系會設這種欄位本來就不應該
06/18 23:37, 55F
→
06/18 23:39, , 56F
這資工/資管大三大四都不會這樣搞吧
06/18 23:39, 56F
推
06/18 23:42, , 57F
除了1之外，2,3問題在哪裡？
06/18 23:42, 57F
推
06/18 23:42, , 58F
要看怎麼分析設計的,說不定他以前的案子就是這樣分欄位
06/18 23:42, 58F
→
06/18 23:44, , 59F
沒事就用GUID那種才可怕
06/18 23:44, 59F
推
06/18 23:53, , 60F
真的社會新鮮人 跟有工作經驗的比起來 不會是滿正常的
06/18 23:53, 60F
→
06/18 23:54, , 61F
想想今天說他都不會時 你剛入社會時? 將心比心
06/18 23:54, 61F
推
06/19 00:05, , 62F
以物流業來說...地址欄位這樣開,程式比較好判斷~
06/19 00:05, 62F
→
06/19 00:06, , 63F
nvarchar型態,適用於多國語言~說不定賣到國外喔...
06/19 00:06, 63F
推
06/19 00:08, , 64F
舉這個例子是要說貴公司怎麼都沒教育訓練 就把新人推
06/19 00:08, 64F
→
06/19 00:08, , 65F
上火線嗎
06/19 00:08, 65F
推
06/19 00:15, , 66F
說真的, 沒訓練過就要他上, 叫愛因斯坦來也沒用..
06/19 00:15, 66F
推
06/19 00:25, , 67F
不過第一點就真的說不過去了，這不是有沒有訓練過的問題
06/19 00:25, 67F
推
06/19 00:50, , 68F
用中文真的不應該 但比較想鞭原po = =
06/19 00:50, 68F
推
06/19 01:02, , 69F
這個case對於資訊本科根本是小case,當作第一天上班
06/19 01:02, 69F
→
06/19 01:04, , 70F
的作業也不為過,原po也應該沒開規格吧.雙方都怪怪的
06/19 01:04, 70F
推
06/19 01:23, , 71F
1 是寫給你看的好嗎
06/19 01:23, 71F
推
06/19 01:25, , 72F
1.中文萬歲 2.硬碟大，電腦快，怕什麼 3.檢索卡快，哈
06/19 01:25, 72F
推
06/19 02:27, , 73F
中文欄位名很好啊，防到一堆打不出字的大陸駭客:)
06/19 02:27, 73F
→
06/19 02:28, , 74F
在一堆超有名大公司裏，看到中文table + 中文 field
06/19 02:28, 74F
推
06/19 04:22, , 75F
第一天報到,就叫人窩在坐位寫這個,還被嘲笑,這才莫名其妙吧
06/19 04:22, 75F
推
06/19 13:19, , 76F
我認識一個老頭寫電話系統 欄位也試用中文 賣超好的...
06/19 13:19, 76F
→
06/19 13:21, , 77F
我們編號是用varchar 然後長度4 反正估計可以用50年XD
06/19 13:21, 77F
推
06/19 13:28, , 78F
其實這個還好啦…還有更恐怖的XD
06/19 13:28, 78F
推
06/19 13:42, , 79F
更恐怖的是指? nvarchar 長度1 這樣嗎?
06/19 13:42, 79F
推
06/19 14:49, , 80F
現在112已經被認為是神人了，只要你不會的話 你就會被問
06/19 14:49, 80F
→
06/19 14:49, , 81F
說 啊你不是112master資訊所 畢業的嗎 怎麼這也不會啊???
06/19 14:49, 81F
推
06/20 14:25, , 82F
int 很大的 4bytes，除非你要做世界人口統計
06/20 14:25, 82F
推
06/27 20:45, , 83F
n開頭錯了嗎? 不是這才能吃utf8? 我記錯嗎?
06/27 20:45, 83F
‣ 更多 greatroy 的文章
文章代碼(AID): #1AEWdQT_ (Soft_Job)
討論串 (同標題文章)
以下文章回應了本文：
完整討論串 (本文為第 9 之 13 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共13篇)
‣ 更多 greatroy 的文章
文章代碼(AID): #1AEWdQT_ (Soft_Job)