db設計評論/建議

Question

我正在重新設計一個藥房數據庫系統，並需要輸入信息來查看新設計是否最優或需要調整。

這裏是舊系統的快照..

可以看出，藥店錶店藥房信息，其地址和聯繫信息。爲了開具帳單（藥房組），藥店被分組在一起，或者用於銷售，宣傳其他目的（橫幅集團）。發票組可能有不同的物理地址，不同的聯繫信息。

這是我的新設計。我已將藥房和藥房組表格中的地址分成了自己的表格，併爲聯繫人制作了一張新表格。他們可能是技術聯繫人，帳戶聯繫人，所有者聯繫人等，因此是聯繫人表格。藥房和藥房組可以有單獨的聯繫信息，我想製作一個聯繫表，並有一個「linktype」和「linkid」欄來表明它是否與藥房聯繫人或藥房組聯繫，但我不確定這是否是一個正確的方法。這是一個好的設計，還是會因數據檢索而導致代價高昂？我注意到的另一件事是，在舊設計中，他們沒有創建任何外鍵約束，儘管藥房表對藥房組和橫幅組都有groupid和bannergroupid引用，可能爲節省數據檢索時間。這是一個好方法嗎？

Answer 1

您的設計看起來不錯。系統投入生產後，我總是喜歡在設計階段多花點時間重新組織數據。您事先不知道管理/銷售/財務人員會要求什麼樣的報告，適當的關係設計會給您更多的自由。

此外，您的性能問題不能只歸咎於幾個額外的JOIN。你應該總是看：

• 數據卷（和物理數據佈局），
• 交易量和密度，
• I/O，CPU，內存使用情況，
• 您的RDBMS的配置，
• SQL查詢質量。

在我看來，JOIN s將在此列表的底部。

至於RI constraints（參照完整性），我見過一些沒有任何主鍵/外鍵的項目以提高性能。主要藉口是：我們已將所有檢查嵌入應用程序和應用程序是系統中任何更改的唯一來源。另一方面，他們同意，不知道系統是否處於一致狀態（事實上，分析表明他們不是）。

我總是堅持在設計狀態上創建所有可能的鍵/約束，因爲總會有一些「牛仔」在身邊，他們會挖掘數據庫並「調整」他們看起來更合適的數據。但是，您可能需要暫時禁用或刪除批量數據操作的一些約束/索引，這也是official recommendation。

如果不確定，請創建2個測試數據庫，其中一個測試數據庫與另一個沒有限制。加載一些數據並比較查詢性能。我認爲它會相似。

在這裏，我對你的草圖的評論，決定都是你的。

• 您可能希望創建一個普通的contacts表你爲addresses的方式相同，即添加contact_id，owner_contact_id等列到目標的關係，而不是引用來自contacts表的關係;
• 由於您在contacttype表中只有一列（如果您有共同的contacts），最好將唯一的字段移開並避開此表;
• 你似乎有混合的單/複數名稱爲您的表，更好地堅持一個共同的模式在這裏。我個人比較喜歡單數;
• pharmacygroup您的PK名爲id，而其餘所有PK都遵循table id模式，如果您在此處使用通用模式，稍後編寫腳本將更容易;
• 在addresses表中，您有帶下劃線的字段，如street_name，而在其他地方您可以避免使用_ - 考慮使其相同;

• 參考文獻的命名有所不同。儘管它並不那麼重要，但我確實有一些系統必須依賴約束條件的名稱，所以最好在這裏使用一些模式。我用下面的一個：

  1. 前綴p_，f_，c_，t_，u_或i_小學，外鍵，檢查約束，觸發器，獨特等指標;
  2. 表名;
  3. 列約束名稱/索引/觸發器是指。

爲什麼我喜歡在命名單數形式表？因爲我總是使用table _id模式命名PK，並且IMHO pharmacy_id看起來好於pharmacies_id。我使用這種方法，因爲在將數據加載到主表之前執行數據一致性檢查時，我有許多通用腳本依賴於此模式。

編輯： 更多關於聯繫人。 您可以在所有表​​格中使用contact_id，使其成爲主要聯繫人，無論這在您的應用程序中可能意味着什麼。如果您需要更多聯繫人以便進行某些關係，則可以使用不同的前綴，如owner_contact_id，sales_contact_id等。

如果你指望一個巨大的聯繫人的數量是有一些關係，如pharmacygroup，那麼你就可以添加額外的表是這樣的：

CREATE TABLE pharmacygroupcontact (
    contactid  int4, 
    groupid  int4, 
    contact_desc text 
); 

這部分複製了你的初始groupcontacts，但由兩個FK和一個描述。 哪種方法更好我不知道，因爲我不知道如何設計應用程序。

Answer 2

你有2個聯繫表，我想創建一個，然後使用鏈接錶鏈接groupcontacts和pharmacycontacts。我肯定希望將FK和PK關係設置爲。