Speichern Filterkriterien auf einer SQL-Datenbank

Question

Ich habe eine Tabelle Produkte wie folgt:

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

I Baskets (Listen von Produkten) erschaffe wie folgt:

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, 
) 

Ein Korb erstellt basiert auf a Suchkriterien unter Verwendung von Parametern:

1. MinimumPrice;
2. MaximumPreis;
3. Kategorien (können null bis viele sein);
4. MinimumWarrantyPeriod

Ich brauche so um diese Parameter zu speichern und später weiß ich, wie der Korb erstellt wurde.

In Zukunft werde ich mehr Parameter hat, damit ich 2 Optionen:

1. hinzufügen Minimum, MaximumPrice und MinimumWarrantyPeriod als Spalt zum Warenkorb Tisch und eine BasketCategories und Kategorien Tabellen in dem Korb zu Kategorien beziehen.

2. erstellen flexibler Entwurf, der einen Parameter Tabelle:

   Tabelle dbo.BasketParameters erstellen ( BasketId int not null, ParameterTypeId int not null, Wert nvarchar (400) nicht null )

   Tabelle dbo.ParameterType ( Id int not null Namen nvarchar (80) nicht null )

erstellen

Parametertypen sind Minimum, MaximumPrice, Kategorien, MinimumWarrantyPeriod usw.

Also für jeden Korb Ich habe eine Liste von BasketParameters, die alle verschieden sind, jeweils auf Wert. Später, wenn ich für Parametertypen brauche, füge ich sie der ParameterType-Tabelle hinzu ...

Die Anwendung wird verantwortlich sein für die Verwendung jedes Basket-Parameters, um den Warenkorb zu erstellen ... Ich werde zum Beispiel eine Tabelle Kategorien haben, aber von den BasketParametern entkoppelt sein.

Macht das Sinn? Welchen Ansatz würden Sie verwenden?

Answer 1

Ihre erste Option ist besser (besonders, da Sie einen relationalen Datenspeicher verwenden, z. B. SQL Server), da sie ordnungsgemäß referenziell ist. Dies wird viel einfacher zu pflegen und abzufragen als auch viel leistungsfähiger.

Ihre zweite Lösung ist äquivalent zu einer EVA-Tabelle: https://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model

der in der Regel eine schreckliche Idee ist (und wenn Sie diese Art von Flexibilität benötigen, sollten Sie wahrscheinlich eine Dokumentendatenbank oder andere NoSQL-Lösung verwenden Sie stattdessen). Der einzige Vorteil besteht darin, dass Sie Attribute regelmäßig oder nach anderen Kriterien hinzufügen/entfernen müssen.