數據庫中的合理/合理字元限制是什麼，例如人名
這是關於數據庫管理員的一般問題。
數據庫中欄位的字元限制是否有某種標準化？在數據庫端為姓名、電話號碼等指定字元限制是有意義的，您知道輸入的數據類型，並且您希望輸入的數據是合理的，因此您限制了字元限制。但是你怎麼知道在這個瘋狂的世界裡有一個合理的限制，可能會有很多例外。
就我而言，它是英國本地公司的一個系統，只有 10-15 名員工。因此，如果需要，我可以返回並更改它，但我寧願輸入一個合理的限制開始。
對不起，如果這個問題已經被問過。如果有，我無法通過Google或類似的問題找到它。
我認為其中一些可以追溯到需求。您儲存了多少名稱？您是否曾經想將“名稱”分開（例如第一個、中間、最後一個）？你想處理多個中間名嗎？
如果您希望將每個名稱分開，我會說 50 個字元應該足夠了。（這對於大多數名稱來說已經綽綽有餘，但也會涵蓋更大的名稱。）我也可能會使用 VARCHAR 而不是 CHAR 作為名稱，因為它們變化很大。
如果您要將全名放在一個欄位中，那麼我會使用 150 - 200 個字元。
再次……這一切都回到了需求……你需要什麼？
雖然我不會對您允許的儲存內容失去控制，但使用 VARCHAR 或 NVARCHAR 類型來儲存字元串使其成為一個不那麼關鍵的問題 - 因為您只會使用數據實際消耗的儲存空間，而不是你的領域的全部長度，你可以在這裡更慷慨一點。考慮到稍後更改數據類型的一般痛苦，我會傾向於比您認為需要的更多 - 如果您猜得太高，則不會浪費空間，但如果您猜得太低，則會有一些表格涉及維護。
如果沒有什麼特別的理由讓我選擇較短的欄位長度，我通常會選擇 VARCHAR(255)。請記住，您始終可以控製表示層中允許的內容和顯示欄位的長度，而不管您在實際數據庫中使用哪種類型儲存數據，所以再次強調，此處過度調整不會造成任何傷害。
對於數字和固定寬度欄位，您必須更精確地使用您認為您將使用的內容，以免浪費空間，但對於 VARCHAR 欄位，沒有額外費用。