我有一個DB（基於Postgres的）表，它在面向對象編程中的行爲就像一個超類。它有一個'type'列，它決定了哪些附加列應該出現在表格中（子類屬性）。但我不希望表中包含所有可能的列（所有可能類型的所有屬性）。所以我決定創建一個包含'key'和'value'列的表（即'filename'='/ file'或'some_value'='5'），它包含任何可能的屬性對象，不包含在超類表中。並且還使一個相關的表格包含可用的'鍵'值。其他領域的最佳數據庫結構實體
但是這樣的架構存在問題 - 「值」列默認情況下應該是字符串數據類型，以便能夠包含任何內容。但我不認爲轉換字符串是一個很好的決定。繞過這個限制的最好方法是什麼？
您正在試驗的設計是Entity-Attribute-Value的變體，它帶有很多問題和低效率。對於你在做什麼來說這不是一個好的解決方案，除非是最後的手段。
什麼可能是一個更好的解決方案是什麼fallen888描述：爲您的每個子類型創建一個「子類型」表。如果你有一個有限的子類型，這聽起來像你所擁有的。然後，您的子類型特定的屬性可以具有數據類型，並且還可以包含NOT NULL約束（如果適用），如果使用EAV設計，這是不可能的。
子類型表設計的另一個弱點是你不能僅僅因爲超類表中的主行表明它應該存在於子類型表中而強制該行存在。但這是比EAV設計引入的弱點更輕微的弱點。
編輯：關於評論對任何實體的更多信息，是的這是一個很常見的模式。謹防被稱爲「多態關聯」的破解，這是許多人在這種情況下使用的技術。
唯一的解決方法（同時保留您的strucure）是擁有獨立的表：
create table IntProps(...);
create table StringProps(...);
create table CurrencyProps(...);
但我不認爲這是個好主意......
一種常用的方法是具有鍵值表包含多列，每個數據類型一個，即StringValue，DecimalValue等。
只要知道您正在交易的數據庫架構的可查詢性和性能，您無需更改。你也可以考慮ORM映射或對象數據庫。
這是怎麼回事...每個子類型都有自己的數據庫表。基本/超級表只有一個varchar列，用於保存子類型數據庫表的名稱。然後你就可以有這樣的事情......
Entity
------
ID
Name
Type
SubTypeName (value of this column will be 'Dog')
Dog
---
VetName
VetNumber
etc
如果你不想讓你的（子）表名是在基表VARCHAR值，也可以只是一個亞型表，它的主鍵將在基表中。
您可以有每種類型的鍵/值表。可用表需要對特定鍵/類型對的可用性進行編碼，以指向正確鍵入的鍵/值表。
但是，這看起來像是一個非常低效的基於行的關係數據庫體系結構。
也許你應該看看面向列的關係數據庫？
感謝您的答案。我會更具體地解釋我需要什麼。 有需要編程一個博客+論壇網站，我一直在尋找WordPress DB structure。
強烈需要將評論放置到任何類型的「對象」，如博客條目或視頻文件附件。上述數據庫結構非常容易擴展，並滿足我們所有的需求是其選擇的理由。
但是，這並不遲到改變它，因爲這是在早期工程階段。此外，我們的模型現在像一個完全基於樹型層次結構的數據庫。現在我會接受Bill Karwin's and fallen888 answers，但也許我會走向完全錯誤的方向？
有關用戶能夠將新字段添加到表：
我很佩服這些人作出評論。
幾年前，我曾經對這種事情感興趣，但最近寫了很少的代碼（除了一點點的PHP和MYSQL）。
如果你想繼續前進，我認爲這很好 - 你可能會得到新的東西。
對不起，在計劃中倒入冷水 - 我很佩服你的努力。我個人的看法是，如果你在這個方向上走得夠遠，你最終將得到一個比SQL更能解釋更多自然語言的系統。 （大約在1970年，SQL實際上拼寫爲Sequel，實際上它代表「結構化的英語查詢語言」，但是在他們在1970年代將其標準化之後 - 我認爲有人說Oracle是19079年的第一個商業實現，「英語」我想他們認爲這只是英語的一小部分
因爲我沒有找到工作，所以我在這方面已經用盡了，沒有一份輕鬆的工作付賬單，在那裏我可以用這些想法進行實驗，這是一個有點難以專注於這個領域。
最良好的祝願所有。
對不起，我在上面寫了19079，我說的是一年1979年甲骨文得到了他們的第一份合同令狀爲CIA建立一個數據庫。