上保存的過濾條件我有一個產品表如下: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,
)
一籃子基礎上創建使用參數的搜索標準:
- MinimumPrice;
- MaximumPrice;
- 類別(可爲零至多);
- MinimumWarrantyPeriod
我需要保存這些參數,所以後來我知道這個籃子是如何產生的。
在未來,我將有更多的參數,所以我看到2個選項:
添加MinimumPrice,MaximumPrice和MinimumWarrantyPeriod爲籃表列,並添加BasketCategories和分類表,涉及一籃子分類。
使用參數表創建一個更靈活的設計:
創建表dbo.BasketParameters( BasketId詮釋不爲空, ParameterTypeId詮釋不爲空, 價值爲nvarchar(400)NOT NULL )
創建表dbo.ParameterType( ID INT NOT NULL 名稱爲nvarchar(80)NOT NULL )
參數類型MinimumPrice,MaximumPrice,分類,MinimumWarrantyPeriod等
所以每個籃我有BasketParameters名單,各不相同,讓每個價值。後來,如果我需要參數類型,我將它們添加到ParameterType表中...
應用程序將負責使用每個籃子參數來構建籃子...例如,我將有一個類別表,但將從BasketParameters中分離出來。
這是否有意義?你會用哪種方法?
實際上EAV是一個非常強大的解決方案,如果正確完成。我多次使用它作爲對更多標準關係數據的擴展,並取得了巨大成功。這就是說,EAV可能會被錯誤地使用,而且確實很糟糕。 –
@SeanLange事實上,它在某些情況下可能非常有用,但它聽起來像OPs數據結構相當好,靜態且不容易改變'太多',因此我會非常喜歡第一個解決方案 – Milney
我真的不喜歡第一個解決方案爲每種類型的過濾器添加新的列。特別是鑑於OP聲明過濾器將會改變。這需要在表中添加/刪除列以及每次更改過濾器選項時觸及它的所有查詢。這種方式打破了關係數據的觀點。 –