請教各位前輩 小弟剛換工作,遇到目前公司對於資料庫欄位名稱命名方式(無意義的命名)感到不習慣 所以想請前輩們針對此問題能提供小弟一些意見 目前公司對於無意義欄位名稱堅持的原因為 1.安全性考量:倘若資料庫及程式被盜走,沒有相關的文件說明,便不易了解其中的意涵 2.命名時節省時間,無須花費心思去做命名的動作 3.儘管有意義的名稱,經過長時間依然有可能會忘記 4.有些大系統採取此種方式命名,使用上也無其他問題 小弟支持有意義命名方式的原因為 1.可讀性高,增加開發、維護時的便利性 2.程式error時看錯誤訊息易於發覺問題所在 目前這問題主管說要再思考 所以想請前輩提供點意見,好讓小弟呈報主管參考 ~~應無所住而生其心~~

個人是傾向有意義的命名方式    貴公司堅持的無意義命名的原因…感覺像是推托之詞 一、若基於安全性考量，怎麼不保護資料，做資料加密 二、命名時省時間，那做無意義命名編碼時還要做對照表…日後要改程式還要翻相關文件…會省多少時間? 三、有意義的名稱目的就是為了幫助記憶，經過長時間或許會忘，但是無意義的名稱可能每天忘記 四、其它大系統也是這麼做，使用上當然是沒問題，但維護上呢?況且大系統不一定是設計良好的系統，要比較也要跟好的比 小弟就曾深受其害，以前的工作維護幾個系統，資料表名稱 > < src="http://delphi.ktop.com.tw/loadfile.php?TOPICID=8147403&CC=182217">

贊同  豬寶寶也遇過那種s01~s09的欄位名稱 後來是一邊看程式一邊猜內容 一邊查一邊罵 1.如果是基於安全考量 那為什麼不如ddy兄所說的欄位內容加密    2.那新進人員不就要花很長的時間去適應?..有節省到時間嗎? 再者a table的s00跟b table的s00 這二者代表的義思可能不同  二個programmer之間要怎麼溝通? 如果原來的人離職後..要接的人不就搞死    3.不會吧?..像訂單編號-->order_no 這樣相信經過再久也不會忘記吧? 4.有些大系統..但是這個只是少數吧?,大多數都是有義意的在命名吧?    豬寶寶想到的缺點 s00~s99 如果有人惡意的做手卻 您能快速的查出來嗎? 不是也要查到半死?        

引言: 個人是傾向有意義的命名方式 貴公司堅持的無意義命名的原因…感覺像是推托之詞 一、若基於安全性考量，怎麼不保護資料，做資料加密 二、命名時省時間，那做無意義命名編碼時還要做對照表…日後要改程式還要翻相關文件…會省多少時間? 三、有意義的名稱目的就是為了幫助記憶，經過長時間或許會忘，但是無意義的名稱可能每天忘記 四、其它大系統也是這麼做，使用上當然是沒問題，但維護上呢?況且大系統不一定是設計良好的系統，要比較也要跟好的比 小弟就曾深受其害，以前的工作維護幾個系統，資料表名稱 > < src="http://delphi.ktop.com.tw/loadfile.php?TOPICID=8147403&CC=182217">

感謝兩位前輩回應 小弟深知，要改變一個人的想法，不件容易的事 況且在目前又沒因此（無意義命名）造成重大影響 這影響可能是無形的 但小弟依然想試著說服主管 卻礙於表達能力有限，所學及經驗無法讓我提出有力的證據來影響大局 故希望藉此討論，讓小弟歸納整合一些重點，提供給主管參考 ~~應無所住而生其心~~

應該說是大部分的大系統都採用有意義的命名方式吧? 以我的經驗來說,不但是要有意義的命名, 而且連命名都還必須遵守嚴格的規定的: 如: 系統別 應用程式別 資料表名稱 欄位名稱 也必須採用 系統別 應用程式別 資料表簡碼 欄位名稱 例如: 財會系統取A 進銷存系統取S 會計總帳應用程式 取PAT 進貨管理應用程式 取TIN 那麼會計科目資料表可能會被命名為 APAT_SUBJECT 進貨單據主資料表可能會被命名為 STIN_MASTER 雖然規劃命名時會多花一些時間 但是將來寫程式,管理資料庫時,一眼就可以看出系統的大致分類與主要用途 這樣不是很好嗎? ～～～Delphi K.Top討論區站長～～～

------
～～～Delphi K.Top討論區站長～～～

提供一個另類一點的想法.. 如果你站在自己的立場上來想的話,嘿嘿,應該支持無意義的命名. 而且把程式寫的越亂越好,當然要自己想辦法維護,如此一來換成別人要去維護 你的程式將是非常的痛苦.這樣子公司就任你宰割了!! Best Regards, Rex Chiu

------
Best Regards,
Rex Chiu

如果只是要公司就任你宰割,這也未免眼光太短淺,好的設計習慣及規畫可以擴大自己的格局,設計較具規模的系統才會穩固,如果你是想只做一人設計師那無所謂,要成為優秀設計師的心態可不能這麼想.如果你是老板你會把重要的事交給只有知道那個人的手上,而自己很放心.

引言: 提供一個另類一點的想法.. 如果你站在自己的立場上來想的話,嘿嘿,應該支持無意義的命名. 而且把程式寫的越亂越好,當然要自己想辦法維護,如此一來換成別人要去維護 你的程式將是非常的痛苦.這樣子公司就任你宰割了!! Best Regards, Rex Chiu

我認為，這樣的想法太狹隘了 的確，這樣的作法，程式是只能讓自己維護了，但是也綁住了自己 不但公司痛苦，同事痛苦，自己更痛苦。除非你願意花個三、五年時間維護只有你自己可以維護的程式 程式為什麼要寫得清楚易懂？就是為了好交接。 交接出去就表示可以去做更新的，更重要的系統 交接出去就表示以後你可以對這一套系統不聞不問，休假時也不會被急 Call(就算會，也不會是第一順位) 這樣的人，對於公司才是能開疆闢土的戰將，而不是只會割據一方的諸侯 回到主題

• 安全性考量？ 支持 ddy 兄的意見，應考慮資料加密等安全性更高的動作
• 命名時節省時間？ 節省了一點命名的時間，卻浪費太多查表的時間。除非有良好的 Design-time tool 來輔助查表
• 儘管有意義的名稱,經過長時間依然有可能會忘記？ 好的系統，常用的欄位名稱是可以望文生義的，而且在不同 TABLE 中的命名也是相同的
• 有些大系統採取此種方式命名,使用上也無其他問題？ 誰知道「有些大系統」在哪裡？又有誰知道這些大系統用了哪些 Design-time tool 來支持這樣的命名系統？

就算是用有意義的命名，公司的研發人員還是要花心思去撰寫 Design-time tool 來減少開發過程中時間的浪費、無意義的瑣事、以及錯誤，這樣生產力才能提高，應付客戶需求改變的速度才能加快，大家也才有辦法可以準時下班 加油喔，喵～ 發表人 - sryang 於 2004/12/26 18:30:52

terrychen 所言 讓小弟想起一些開發的經驗 若您的系統是用 Tool 來開發,有些欄位會有中英文的對照 我的經驗是 有意義或無意義的命名,其實差不多,tool會管理的很好,查資料也很方便 但若是用 手工一行一行的打造,就考驗個人的記憶力了, 看別人留下的開發文件,是一種吃力的事, 況且寫程式的人,是不太用心於寫文件的, 我個人就是如此 -------------------------------- 這一網站,真的不錯!!

------
---------------------------------------
偶爾才來 KTOP ,交流條碼問題,在 FB [條碼標籤達人] 社團留言,感恩.

小弟盡了最大的努力去說服主管 但未成功，最終依然維持原議 還是感謝各位前輩提供寶貴的意見 現在只能尊重上頭決定 小弟公司並無任何的開發文件(小弟目前的工作是幫前人的程式撰寫文件) 也不是用TOOL開發程式 儘管不是很認同主管做法，又無法說服主管 那就遵從吧，這樣會太消極ㄇ？ 我也想不到其他做法了 ~~應無所住而生其心~~