如何儲存具有 1000 多列的表，這些列大多為空
今天我必須重新啟動一個項目，由於業務的特殊性（房地產），我將不得不為房子/公寓/機庫/wahetever 儲存一張桌子。但是單行可以包含超過 1000 個標準，因此，列（是否有游泳池？壁爐？直升機停機坪，地下掩體？等等……
但正如你可以猜到的，這些行中的大多數將等於 null（誰家有直升機停機坪或掩體？很少人……）
因此，我想知道最有效地儲存它的想法是什麼？與哪個數據庫？磁碟空間、速度、記憶體使用等……但也讓編碼人員盡可能輕鬆地取回數據（例如，可以選擇拆分為多個表，但可以獲取數據這種架構很煩人）
另外，我更願意保留一個關係數據庫（mySQL，postgres …），但我願意接受建議。
感謝您的建議！
但是單行可以包含超過 1000 個條件
不，您是在基於有缺陷的關係模型預測數據設計。本末倒置。尾巴在搖狗。
我認為您的意思是單個實體可以具有 1000 個屬性。在這種情況下，特別是當大多數為空時，最好的解決方案通常是實體-屬性-值。大概有一些屬性將始終被填充，例如
CREATE TABLE house ( id INTEGER NOT NULL AUTOINCREMENT, owner_id INTEGER NOT NULL, address ....然後只將相關的屬性儲存在這樣的表中……
CREATE TABLE house_attribute ( house_id INTEGER NOT NULL, attribute VARCHAR(30), description VARCHAR(128) PRIMARY KEY (house_id, attribute) )您遲早會遇到的問題是，當您只有帶有“地下室”的房屋時，有人會想要帶有“地窖”的房屋。這部分是使用者界面問題，但它看起來也像是使用 ENUM 數據類型的情況。但是當你有很多 ENUM 數據類型並且條目數量在創建後發生變化時，它們可能很難管理。因此，您確實應該將 house_attributes.attribute 的可能值列表設置為單獨的表，並在 house_attribute.attribute 上設置外鍵約束。
查詢數據比使用大量列要復雜一些 - 但在一組屬性不完全匹配的情況下確實提供了一些靈活性：
SELECT house.id, house.address, GROUP_CONCAT(house_attribute.attribute) FROM house INNER JOIN house_attributes ON house.id=house_attribute.house_id WHERE house_attribute.attribute IN ('helipad', 'bunker', 'swimming pool'....) GROUP BY house.id, house.address ORDER BY COUNT(*) DESC;
這完全取決於您的確切案例以及您要儲存的數據。您是否需要為新數據執行大量插入操作，還是一直在更新數據？或者您將主要進行搜尋，而更新/插入可以忽略不計？
從您提供的資訊中粗略猜測，我將為每個對象創建一個包含基本屬性（唯一 ID、地址、地理位置、所有或大多數對象共享的屬性）的表，然後創建一個具有擴展屬性的表（objectid , 屬性名稱或 id, 屬性值）可能使用兩個值欄位 StringValue 和 NumberValue，以便更輕鬆地搜尋數字範圍（例如臥室數量：3-7）。如果設置了正確的索引，將這些組合到查詢中並不太複雜，並且可以很好地擴展。如果事情變得太大，您可以為每個屬性創建一個表，但這確實會使查詢更加複雜。
至於要使用的 dbms - 所有關係數據庫都可以用於這樣的事情。有些可能有太多列的限制，對於我前一段時間使用的某些數據庫，曾經有一個限制在 ~200，但不確定這是否仍然有效。
記憶體、磁碟等在不知道條目的大致數量和確切的數據模型的情況下是不可能回答的。