類型表和軟件硬編碼值

DB model

（TEXT實際上是VARCHAR）

entity_group_type是不能在運行時修改的，但它會在不久的將來被修改開發團隊多次添加更多條目。

現在我需要檢索entity中給定entity_group_type的所有條目。該軟件應該如何處理這種查詢？我應該在軟件中硬編碼entity_group_type_id/name？如果是這樣，爲什麼我甚至需要這張桌子呢？還有什麼更好的，硬編碼_id或name？

或者這是錯誤的方式來構建我的數據？

在此先感謝！

來源

2013-02-01 m0skit0

以你的問題，一次一個：

你應該如何參考實體組中的軟件？硬編碼的身份證，或名稱？

以使您的代碼具有最高可讀性的方式引用實體組。所以，也許你使用了這個名字，或者是一個看起來像名字但是其值是id的常量。使用常量可以避免在按組類型查找實體時進行一次連接，但通常這並不是什麼問題。

爲什麼我甚至需要DB中的表格呢？這是錯誤的方式來構建我的數據？

這是一種完全可以接受的方式來構建您的數據。最正確的方法取決於你對數據做什麼，但對於大多數應用程序，你的結構是正確的。但是，您肯定不需要需要該數據庫中的表 - 您可以改爲在entity_group表上具有「group_type」字段。這裏有利弊：當前結構的

優點：

輕鬆添加描述entity_group_type領域。例如，您可能希望創建一些只能由管理員用戶查看或禁用的組類型，或者其他類型的組。如果這是未來的可能性，它幾乎需要這種數據庫結構。
能夠讓您的數據庫軟件實施參照完整性，這意味着entity_group和entity_group_type表之間的數據保持一致。

優勢在entity_group表中新增group_type領域：

可能在你的代碼更簡單的表示。對於exameple，如果您使用MVC體系結構，那麼擁有額外的表可能需要代碼中的另一個模型對象。這通常不是問題，可能有優勢，但有時候更簡單更好。
當您按實體組類型查找實體時，您的SQL語句會稍微簡單一些，因爲涉及的表/聯接會少一個。

我認爲在大多數情況下，您的當前結構是超前的，儘管它取決於您如何使用數據。除非你有充分的理由來構造數據，否則我會堅持你當前的結構。

來源

2013-05-15 21:00:31

謝謝，非常好的解釋利弊:) – m0skit0

考慮，你知道你的entity_group_type在運行時，那麼正確的找到所有entity_group s的那entity_group_type.name方式name，你可以使用一個連接：

SELECT entity_group._id, entity_group.name, entity_group_type.name AS groupTypeName 
FROM entity_group 
JOIN entity_group_type ON entity_group.id_type = entity_group_type._id 
WHERE entity_group_type.name = 'someGroupName';

這將導致所有entity_group信息爲given entity_group_type name。

是的，這是一種很好的或至少可能的方式來存儲這種信息。試想一下，entity_group_type最終會得到一個新的屬性，例如disabled。然後，仍然可以容易地找到所有，它們是（不）在disabled類型中。

來源

2013-02-01 13:22:55

謝謝，但我知道如何做查詢，這不是問題:) – m0skit0

然後，我沒有得到問題... entity_group_type可能會得到更多的條目，但它是無用的，因爲你想要總是得到那些'entity_group'無論如何，有特定的'id_type'？不過，我會用一個不言自明的名字，以便稍後可以更改該名稱的_id。 –

我從來沒有問過如何在quesion中進行查詢:)考慮你的答案，問題是在哪裏/如何存儲'someGroupName'字符串。我應該在軟件中硬編碼嗎？如果是這樣，爲什麼我甚至需要DB中的表格呢？硬編碼最好是：'name'還是'_id'？如果不是，我該如何處理這種情況？ – m0skit0

我認爲你應該在數據庫中確定地存儲entity_group_type在它自己的表中，根據你上面的設計圖。將該信息存儲在數據庫中可以根據該信息進行查詢，從而爲您的設計增加了靈活性。

一旦你在DB中獲得了這些信息，你的問題似乎是應該分解到它自己的表中，還是隻作爲列存儲在entity_type表中。我認爲你應該把它分解到它自己的表中，外鍵約束從entity_type到entity_group_type。

在其自己的表中有entity_group_type可以保留組類型，即使所有該類型的實體組都從數據庫中刪除。
您可以利用外鍵來確保entity_group_type名稱拼寫一致。插入的entity_group必須滿足外鍵約束，因此必須引用具有正確拼寫名稱的現有entity_group_type，或者插入將爲該新entity_group_type設置正確拼寫的entity_group_type。

使用您的entity_group_type表的合成密鑰，以減少名稱外觀外觀中的痛苦冗餘。這使得數據模型更爲DRY，並且允許將entity_group_type的名稱更新爲對一個表的簡單更新。

至於在您的應用程序邏輯中存儲entity_group_type，我會建議存儲名稱，並在需要時查找entity_group_type的ID。我認爲這會使應用程序代碼庫變得更可讀，而且我認爲我爲什麼認爲這些相關信息應該在數據庫中有一個表示形式是一個引人注目的論點。

來源

2013-05-15 06:28:02 pcurry

類型表和軟件硬編碼值

回答

相關問題