數據庫結構 - 存儲關係

Question

這是一個複雜的問題，所以我會盡量簡化它。

我的服務器上有一個mysql實例，它承載了許多用於不同目的的模式。模式通常（並非完美）以EAV的方式構成。我需要定期將信息轉入和轉出該結構。

示例1：爲了在網頁上呈現信息，我將信息粘貼到一個複雜的對象中，然後通過json傳遞到網頁，在那裏我將json轉換成一個複雜的javascript對象，然後我與knockoutjs和類似的東西出現。

結論：這導致了許多邏輯被放入多個地方，這樣我可以在值在頁面上與數據庫中的值相關聯。

例子2：爲了允許用戶從pdf導入信息，我有很多信息存儲在pdf表單域中。在這種情況下，我沒有寫pdf，所以表單字段的命名方式並不是這樣，所有這些邏輯都足夠容易爲CRUD寫入3次或更多次。

結論：這導致我將pdf表單域的列表複製到數據庫中的表中，以便我可以以某種方式將它們與應該放置數據的位置關聯起來。出現的問題是pdf上的字段需要與schema.table.column相關聯，並且我發現存儲該信息的唯一方式是通過VARCHAR

這兩個示例都沒有涉及少量的數據（類似於示例1中的6個表格和示例2中的大約1400個pdf表單字段）。鑑於例1所得邏輯存儲多個地方，似乎合乎邏輯建立例題，在那裏我可以存儲在那裏他們可以訪問和持續改變數據庫中的數據之間以及所有參與方法關係。

現在，很可能我只是很愚蠢，我的所有Google搜索都沒有遇到，有一種簡單的方法可以將這些數據與正確的schema.table.column相關聯如果是這種情況，我正確的做法是這裏的簡單答案。

但是，這是我感到困惑的地方。我總是被告知，你永遠不想在數據庫中存儲關於數據庫的信息，特別是不能以字符串（varchar）存儲。這在很多層面上似乎都是錯誤的，我只是無法弄清楚我是否愚蠢，並且最好遵循示例1，或者如果在這裏有一些技巧我錯過了數據庫結構。

Answer 1

不知道你從哪裏得到「......從來沒有......在數據庫中存儲關於數據庫的信息」。對於EAV模型，將元模型（實體類型及其可允許的屬性）存儲在數據庫本身中是正常的，因此它是自描述的。如果您不得不更改元模型，您是想更改代碼還是更改表中的幾行？

EAV數據庫的主要缺點是你失去了簡單連接的能力。連接類操作變得更加複雜。像生活中的其他事物一樣，您根據自己的要求做出權衡。我已經看到自我描述的EAV架構非常成功地使用。