2017-04-21 61 views
0

上保存的過濾條件我有一個產品表如下:SQL數據庫

create table dbo.Product ( 
    Id int not null 
    Name nvarchar (80) not null, 
    Price decimal not null 
) 

我創造籃如下(產品清單):

create table dbo.Baskets ( 
    Id int not null 
    Name nvarchar (80) not null 
) 

create table dbo.BasketProducts ( 
    BasketId int not null, 
    ProductId int not null, 
) 

一籃子基礎上創建使用參數的搜索標準:

  1. MinimumPrice;
  2. MaximumPrice;
  3. 類別(可爲零至多);
  4. MinimumWarrantyPeriod

我需要保存這些參數,所以後來我知道這個籃子是如何產生的。

在未來,我將有更多的參數,所以我看到2個選項:

  1. 添加MinimumPrice,MaximumPrice和MinimumWarrantyPeriod爲籃表列,並添加BasketCategories和分類表,涉及一籃子分類。

  2. 使用參數表創建一個更靈活的設計:

    創建表dbo.BasketParameters( BasketId詮釋不爲空, ParameterTypeId詮釋不爲空, 價值爲nvarchar(400)NOT NULL )

    創建表dbo.ParameterType( ID INT NOT NULL 名稱爲nvarchar(80)NOT NULL )

參數類型MinimumPrice,MaximumPrice,分類,MinimumWarrantyPeriod等

所以每個籃我有BasketParameters名單,各不相同,讓每個價值。後來,如果我需要參數類型,我將它們添加到ParameterType表中...

應用程序將負責使用每個籃子參數來構建籃子...例如,我將有一個類別表,但將從BasketParameters中分離出來。

這是否有意義?你會用哪種方法?

回答

0

您的第一個選擇是優越的(尤其是因爲您使用的是關係數據存儲,即SQL Server),因爲它是正確的參考。這將更容易維護和查詢以及更高性能。

你的第二個解決方案是相當於EVA表:https://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model

這通常是一個可怕的想法(如果你需要這種類型的靈活性,你應該使用文檔數據庫或其他的NoSQL解決方案,而不是)。這樣做的唯一好處是,如果您需要定期添加/刪除屬性或基於其他標準。

+0

實際上EAV是一個非常強大的解決方案,如果正確完成。我多次使用它作爲對更多標準關係數據的擴展,並取得了巨大成功。這就是說,EAV可能會被錯誤地使用,而且確實很糟糕。 –

+0

@SeanLange事實上,它在某些情況下可能非常有用,但它聽起來像OPs數據結構相當好,靜態且不容易改變'太多',因此我會非常喜歡第一個解決方案 – Milney

+0

我真的不喜歡第一個解決方案爲每種類型的過濾器添加新的列。特別是鑑於OP聲明過濾器將會改變。這需要在表中添加/刪除列以及每次更改過濾器選項時觸及它的所有查詢。這種方式打破了關係數據的觀點。 –