使用記錄ID內的「實體類型號」來識別實體

Question

我有一個現成的，現成的應用程序在我的公司工作，有其供應商已經實現了一個有趣的數據庫功能（許多之一） 。我之前沒有看到它用於製作，我希望能夠獲得更多的信息。

每個數據庫表指的是一個特定的實體類型。例如，TBL_Person,TBL_Organisation，TBL_Address。但是，對於每個表，ID始終始於相同的一組數字，例如，全部TBL_Address記錄以1401開頭，全部TBL_Person記錄以1500開頭。在那之後會附上獨特的部分。從我所看到的是，從純屬的發展來看

的優勢，如下：

• 這是一個巨大的數據庫（約600桌，許多有超過150列）。所以，如果在掃描表我找到列如WId，RId，LId，或UnhelpfullyNamed_Id，我立刻知道什麼它指的是（感謝他們也提供你在那裏輸入前四位數字一個小程序，它會告訴你什麼是實體是以及在哪個表中找到它）
• 它們在同一個表中存儲實體的不同變體 - 例如一個TBL_Vehicle記錄可能是汽車（1234），卡車（2345），摩托車（3456），所以你不需要使用繼承等，除非它是真正必要

缺點（在一般意義上，如果這是在別處使用）可能是：

• 鼓勵懶惰與表的設計 - 冗餘列，如果在同一個表中存儲許多實體類型
• 增加了對開發商看它是誰沒有意識到這一點

混亂

這個設計模式/功能是否有一個術語？有沒有其他衆所周知的數據庫可以實現這一點？還有其他的優勢嗎？

Answer 1

通過合併的兩個部分信息到單個字段，該「設計」違反atomicity原則，因此所述第一正常形式。

在邏輯上，同樣可能是由具有複合主鍵{type, id}實現。我猜測，「合併」類型和id的決定是由他們的應用程序設計和渴望擁有「簡單」密鑰驅動的。

Answer 2

在這樣的例子中，通常是首先NO數據庫設計。所有東西都是在應用程序級別（可能是OO）上設計和實現的，然後將東西存儲（保存）在某處 - 在這種情況下存儲在數據庫中。數據庫只是一個「應用程序下的存儲」。

在應用數據庫設計的情況下，使用以數據爲中心的模型。一旦完成，數據庫可以「獨立」 - 不需要應用程序從數據中理解。

可能涉及或可能不涉及ORM映射器，因此當涉及到這些大型表時，您可能正在尋找由映射器實現的單表繼承的結果。