2017-04-21 42 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声明过滤器将会改变。这需要在表中添加/删除列以及每次更改过滤器选项时触及它的所有查询。这种方式打破了关系数据的观点。 –