這是我關于堆疊溢位的第一個問題，我是一名全堆疊開發人員，我使用以下堆疊：Java - spring - angular - MySQL。我正在做一個副專案，我有一個資料庫設計問題。
我有一些在多個表之間通用的資訊，例如：
- 檔案資訊（最初可以在 FOLDER 和 CONTRACT 表中使用）。
- 型別資訊（表格：COURT、FOLDER、OPONENT、...）。
- 狀態（表格：合同、檔案夾、...）。
- 地址（表格：OFFICE、CLIENT、OPPONENT、COURT、...）。
避免重復并將核心表與“技術”表（可在許多表中使用的資訊）耦合。我正在考慮將“技術”表合并到一個功能表中。例如，我們可以有一個包含以下列的通用 DOCUMENT 表：
- ID
- 標題
- 描述
- 創立日期
- TYPE_DOCUMENT（檔案夾、合同、...）
- OBJECT_ID（TYPE_DOCUMENT 表的主鍵）
- 辦公室_ID
- PATT_DATA
例如，我們可以使用以下查詢檢索有關檔案的資訊：
SELECT * FROM DOCUMENT WHERE OFFICE_ID = "office 1 ID" AND TYPE_DOCUMENT = "CONTRACT" AND OBJECT_ID = "contract ID";
我們還可以使用以下索引來優化查詢： CREATE INDEX idx_document_retrieve ON DOCUMENT (OFFICE_ID, TYPE_DOCUMENT, OBJECT_ID);
我的問題是：
- 這是一個好的設計嗎？
- 有沒有更好的方法來實作這個設計。
- 我應該使用普通的資料庫設計嗎，例如一個檔案夾可以有很多檔案，所以我創建了一個folder_document 表，以folder_id 作為外鍵。并對所有表執行相同操作。
非常歡迎任何建議或注釋，并提前感謝您的幫助。
uj5u.com熱心網友回復：
您所描述的內容聽起來像是您正在嘗試決定是否去規范化以及去規范化多少。
答案是：這取決于您的查詢。非規范化使對您的資料執行某些查詢變得更方便或更高效，但代價是執行其他查詢變得更難或更低效。這也使得難以保持冗余資料同步。
因此，您希望最大限度地減少非規范化，并且僅當它在需要優化的查詢中為您提供良好的優勢時才這樣做。
規范化優化資料關系。這使得資料庫組織不會針對任何特定查詢進行優化，但同樣適合您的所有查詢，并且還具有防止資料例外的優勢。
非規范化針對特定查詢進行優化，但以其他查詢為代價。您需要了解哪些查詢需要優先處理，哪些查詢可能會受到影響，這取決于您。
如果您無法決定哪些查詢值得優先考慮，或者您無法預測將來是否會有其他新查詢，那么您應該堅持使用規范化設計。
Stack Overflow 上的任何人都無法比您更了解您的查詢。
uj5u.com熱心網友回復：
情況1： status
“狀態”通常是單個值。為了使其可讀，您可以使用ENUM. 如果您需要有關狀態的更多資訊，可以使用單獨的表格，其中PRIMARY KEY(status)包含有關狀態的其他列。
案例2： address
“地址”很龐大，可能有多個列。（但是，由于 inWHERE或ORDER BY子句很少需要“地址”的組成部分，因此很少有充分的理由將它以除TEXT嵌入換行符和嵌入換行符之外的任何形式使用。
但是，“address is usually implemented as several separate fields. In this case, a separate table is a good idea. It would have a columnid MEDIUMINT UNSIGNED AUTO_INCREMENT PRIMARY KEY and the various columns. Then, the other tables would simply refer to it with anaddress_id column andJOIN”在需要時添加到該表。即使許多表都有地址，這也很干凈并且運行良好。
一個警告：當您需要更改某個物體的地址時，請注意是否已洗掉重復地址。最好總是添加一個新地址并為任何不再需要的地址浪費空間。
討論
這兩種情況（狀態和訪問）可能是極端的。對于每個可能常見的列，決定哪個更有意義。正如比爾指出的那樣，您確實需要考慮查詢才能使模式“正確”。在決定索引以外的索引之前，您必須撰寫主要查詢PRIMARY KEY。（所以，我現在不會回答你關于索引的問題。）
千萬不能使用4個位元組INT的東西是小的，大多是不可變的，并且更易于閱讀：
- 2 位元組
country_code（美國、英國、日本、...） - 5 位元組
zip-code CHAR(5) CHARSET ascii；類似于 6 位元組postal_code - 1 位元組`ENUM('可能', '否', '是')
- 1 位元組`ENUM('not_specified', 'Male', 'Female', 'other'); 如果您嘗試列舉所有“其他”，這可能不太好。
- 1 位元組
ENUM('folder', ...)
您的“檔案夾”與“檔案”是一對多關系的一個例子。是的，它是通過doc_id表中的 實作的Folders。
“多對多”需要一個額外的表來連接兩個表。
列舉
有些人會反對使用ENUM. 在您的情況下，無法確保每個表使用相同的定義，例如doc_type. 在串列的末尾添加一個新選項很容易，但重新排列ENUM.
ID
id(or ID) 幾乎被普遍保留（按照慣例）來表示PRIMARY KEY表的 ，通常（但不一定）是AUTO_INCREMENT。請不要違反這個約定。請注意，在我上面的示例中，id是Addresses表的 PK ，但address_id在參考表中呼叫。您可以選擇FOREIGN KEY在兩個表之間創建一個。
轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/375634.html
上一篇：禁止通用函式中物件的非列舉鍵
下一篇：簡化泛型型別宣告