[英]Autonumber vs. Text String for primary key?
我正在嘗試為我剛剛遇到的問題找到最佳解決方案。 我討厭在不理解的情況下做事,所以我希望有人可以提供幫助。
我有一個 Access 數據庫,其中包含一個存儲酒店信息的表 - 然后是另一個存儲行程的表。 行程表將從酒店表上的酒店列表中進行選擇。
我想建立適當的關系,但是在連接到 Itineraries 表上的 Hotels 字段的 Hotels 表上使用自動編號主鍵將不起作用。 (因為自動編號 ID 與酒店名稱不匹配。)
是否更好:
A. 使用酒店名稱作為酒店表上的主鍵,即使字符串長度可能會很長?
B. 將 Itineraries 表上 Hotels 字段的顯示控件更改為列出 Hotels 表自動編號主鍵的組合框 - 但將其隱藏。 相反,它顯示帶有酒店名稱的列。 我在這里找到了解決方案: http : //www.trigonblue.com/accesslookup.htm
兩種解決方案似乎都不完美,因為我認為解決方案 A 可能會用長文本字符串減慢索引速度,如果在表中插入新字段,解決方案 B 就會混亂。
我不想在這里選擇錯誤的答案,並在路上遇到問題。
有人可以幫我嗎? 如果我需要澄清我的問題的任何部分,請告訴我。
謝謝!
您幾乎不應該使用名稱作為主鍵。 以CODE
或ID
的形式使用唯一 ID 是一種更安全的方法。 避免使用名稱允許您:
有時您已經有了代碼或 ID,或者您受到內部/外部規則的約束,但大多數時候自動編號的主鍵非常有用。 它是:
自動編號是設置主鍵的最有效方法,它是 DBMS 搜索以找到所需內容的最少工作。 如果您要在表中具有主鍵/外鍵關系,則尤其如此。
更不用說,這樣做有利於存儲目的和索引目的(對 Access 來說沒什么大不了的,但對其他人來說卻是)。
使用當前快速的計算機和對於幾十或可能是數百條記錄使用文本或數字PK沒有明顯區別,但對於數千條記錄和以上肯定會有不同的問題,數字是朋友CPU ,因為它是處理器最容易使用的數據類型。 如果我假設一個表將有數千條記錄,那么我將使用 Neumeric 並且最好使用 long 類型。
聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.