用於隨時間存儲不同varchar字段的模式？

我正在處理的這個應用需要存儲一些關於實體的元數據字段。問題是我們已經可以預見未來這些領域將發生很大變化。現在，每個實體的屬性都被轉換爲實體表中的一列，但在後面修改表格列將會代價高昂且容易出錯。用於隨時間存儲不同varchar字段的模式？

我應該去這樣的（鍵值存儲）而不是？

MetaDataField 
----- 
metaDataFieldID (PK), name 

FieldValue 
---------- 
EntityID (PK, FK), metaDataFieldID (PK, FK), value [varchar(255)]

p.s.我也想過在SQL Server 05+上使用XML。在與一些人交談之後，似乎這不是一個可行的解決方案，因爲這對於爲報告目的進行某些查詢而言太慢了。

來源

2010-05-14 Henry

你是對的，你不想在新的參數出現時改變你的數據模式！

我見過兩種做這種事的方法。其一，只需要一個「meta」文本字段，然後格式化該值以定義參數和值。的Joomla！這樣做，例如，跟蹤自定義文章屬性。它看起來像這樣：

ProductTable 
    id name  meta 
    -------------------------------------------------------------------------- 
    1 prod-a title:'a product title',desc:'a short description' 
    2 prod-b title:'second product',desc:'n/a' 
    3 prod-c title:'3rd product',desc:'please choose sm med or large'

處理這個另一種方法是使用附加表，就像這樣：

ProductTable 
    product_id  name 
    ----------------------- 
    1    prod-a 
    2    prod-b 
    3    prod-c 

MetaParametersTable 
    meta_id  name 
    -------------------- 
    1   title 
    2   desc 

ProductMetaMapping 
    product_id  meta_id  value 
    ------------------------------------- 
    1    1   a product title 
    1    2   a short description 
    2    1   second product 
    2    2   n/a 
    3    1   3rd product 
    3    2   please choose sm med or large

在這種情況下，查詢需要加入的表，但可以優化表格更好，可以查詢獨立元而不返回所有參數等。

它們之間的選擇將取決於複雜性，數據行是否需要具有不同的元數據以及數據如何被消耗。

來源

2010-05-14 21:24:18

Key Value表是一個好主意，它的工作速度比SQL Server 2005 XML索引快得多。我在一個項目中使用XML創建了相同類型的解決方案，並且必須將其更改爲索引鍵值表以獲得性能。我認爲SQL Server 2008 XML索引速度更快，但還沒有嘗試過。

來源

2010-05-14 20:31:13

哦，不知道它被稱爲鍵值表。謝謝！ – Henry 2010-05-14 20:37:18

XML速度僅取決於進入xml列的數據大小。我們有一個將數據填充到xml列並處理數據的項目。它速度非常快，直到你打到64kb左右。 63KB或更少的時間需要幾毫秒才能獲取或插入數據。 64KB和操作跳到了一整分鐘。去搞清楚。

除此之外，我們遇到的主要問題是複雜性。在sql server中處理xml數據並不是心存隱晦。

無論如何，最好的方法是將名稱/值對的表格綁定到相關實體。然後很容易支持具有不同屬性的實體或動態添加/刪除屬性。這也有警告。例如，如果你有不止10個屬性，那麼在代碼中做樞軸將會快得多。

來源

2010-05-14 20:37:05 NotMe

還有一個模式要考慮 - 稱爲觀察模式。見類似的問題/回答：one，two，three。

模式在Martin Fowler的書分析模式描述，本質上它是一個OO模式，但可以在數據庫架構來完成了。

來源

2010-05-15 14:35:06

「改變表格列後面的路將是代價高昂且容易出錯的嗎？」

「表列」，正如你命名的那樣，它恰好具有兩個屬性：名稱和數據類型。因此，「更改表列」只能引用兩件事：更改名稱或更改數據類型。

想要更改名稱確實是一個代價高昂且容易出錯的操作，但幸運的是，永遠不應該是它的真正商業需求。如果某個已建立的專欄看起來有些不合適，而且事後考慮到了，並且「它可能被賦予了更好的名字」，那麼事實並非如此！只要堅持使用舊的名字，即使只是事後考慮，它的選擇也很差。

想要改變數據類型的確是一個代價高昂的操作，容易破壞運行平穩的業務操作，但幸運的是，用戶輪到告訴你：「嗨，我知道我告訴過你這個屬性必須是一個Date，但是猜測是什麼，我錯了，它必須是一個Float。「在定義數據庫時，謹慎的做法可以避免出現相同性質但更可能發生的其他變化（例如從shortint到整數左右）。

其他類型的數據庫更改（例如添加新列）通常不會造成危險和/或破壞性。

所以，不要讓自己被那些模糊的標語短語所嚇倒，比如「更改數據庫是昂貴而危險的」。他們通常來自無知者，他們對數據庫管理知之甚少，無論如何都會參與到我們這個專業領域。

在EAV數據庫上維護查詢，約束和約束的實施很可能比「常規」數據庫結構更改要貴上千倍。

來源

2010-05-15 22:38:42

用於隨時間存儲不同varchar字段的模式？

回答

相關問題