1樓：劉鑫
經驗呀親。比如前面那位朋友說的NULL，NULL有意義的場合很多，我個人就反對有事兒沒事兒什麼都default，有些default是有必要的，有些就是偷懶。應用層建模也是經過反覆的，早年的空指標不好用，引發很多問題，新興的語言就逐步提供了 enumeration assoicated value ，特別是option型別。
為什麼？因為「空值」或者說「非預期結果」是乙個不可迴避的問題。這本身乙個複雜問題，不能一概而論。
id也是一樣，現在OLTP一般都是帶自動id，提供給應用層的軟體系統使用方便，但是也不一定是自增正整數，我司的專案核心模型就用的uuid，據我所知這麼做的也不止我們一家。OLAP就更不一定了。不是誰都跟鵝廠一樣動輒幾十個PB的規模，看你自己怎麼方便怎麼來。
自動主鍵有時候不能很好的表達業務。
好好學習，多積累經驗，見的鬼多了就對畫符有感覺了。
2樓：
1.能夠做到不為空就全部不為空，給defaut值。別人做不到是因為太懶了。
大型系統隨便就幾千張表，幾萬個字段，每個都這樣搞搞不過來，純粹是懶。default值在效能和邏輯上都優於null,而且不容易出bug
2.型別選擇該用啥，用啥即可。是日期就date，是數字就number,大檔案blob,其它情況全部varchar.
字段盡量多給，給到啥程度？看你對業務的理解和經驗。日後要增加長度及其痛苦的。
其他的都可以當特殊情況記。有兩種特殊情況，一種是國際化的時候，時間建議存int，因為時區的問題。一種是密碼，反正雜湊以後位數一樣，不妨char.
3.pk 。表可以有兩個主鍵，乙個叫id純數字，業務無關，乙個叫code ,varchar和日期業務等有關。
id做查詢時連線使用，code 前端傳過來定位唯一行。如果是ER正規化中的R表，可以沒有ID,採用復合主鍵，然而一定要有主鍵。否則資料庫亂套，違反第一正規化必然作死！
4. 冗餘，一直都存在。關係型資料庫發明以前都是這樣。網際網路應用，分庫分表也只能如此復古了。
但是需要區分，業務如此的情況。比如說:
使用者表，使用者銀行賬號表，付款表。付款表裡面的銀行資訊就不能是引用使用者銀行表的。因為，如果使用者更換了登記銀行卡，你是引用，歷史付款記錄就都錯了，這個必須做冗餘。
小白求教如何設計資料庫的表？
先把所有的類列出來，在把需要儲存在資料庫的類找到，把主外來鍵關係找到，你就可以建立表了，至於你如何約束字段，那就是你的事了，每張表的字段盡量不重複，至於索引，那就是你最常訪問的字段做最好。 符合BCNF正規化即可 一般人常規思考都能符合這個正規化 能記錄越多資訊越好 免得以後要實現新功能，結果資訊不...
如何擺脫現有關聯式資料庫的思想來設計 NoSQL 資料庫？
個人感覺是，如果資料只需要最新狀態，不在乎歷史資料，那麼NOSQL可以很好的完成需要，例如使用者當前指標 姓名，出生年月日，地點，級別，不需要歷史資料。永遠更新同乙個json payload.但似乎如果涉及到transactional 資料，感覺nosql不能很好的handle,例如我幾天買了三次東...
高併發場景下，怎麼保證快取和資料庫的資料一致性？具體解決方案是什麼？有哪些框架？具體怎麼實現？
看應用場景是頻繁讀 頻繁寫 頻繁讀寫。讀多的場景 記憶體 磁碟雙寫就可以。寫多的場景就需要考慮寫入削峰，可入kafka佇列快取寫入 leveldb記憶體 磁碟的多層快取削峰等。 目前的回答從方案上已經說的很全面了，說下我的看法，我比較傾向 白楊 小碼農xyz 的傾向，在我的業務經驗裡，如果我們需要做...