devise数据库来保存不同的元数据信息

所以我试图devise一个数据库,这将允许我连接一个产品与多个类别。 这部分我已经想通了。 但是,我无法解决的是持有不同types的产品细节的问题。

例如,产品可能是一本书(在这种情况下,我会需要元数据,像isbn,作者等书)或它可能是一个商业目录(其中有不同的元数据)。

我应该如何解决这个问题?

这被称为观测模式。

替代文字http://www.damirsystems.com/dp_images/observation_model_3.png

三个对象,例如

Book Title = 'Gone with the Wind' Author = 'Margaret Mitchell' ISBN = '978-1416548898' Cat Name = 'Phoebe' Color = 'Gray' TailLength = 9 'inch' Beer Bottle Volume = 500 'ml' Color = 'Green' 

这就是表格的样子:

 Entity EntityID Name Description 1 'Book' 'To read' 2 'Cat' 'Fury cat' 3 'Beer Bottle' 'To ship beer in' 

 PropertyType PropertyTypeID Name IsTrait Description 1 'Height' 'NO' 'For anything that has height' 2 'Width' 'NO' 'For anything that has width' 3 'Volume' 'NO' 'For things that can have volume' 4 'Title' 'YES' 'Some stuff has title' 5 'Author' 'YES' 'Things can be authored' 6 'Color' 'YES' 'Color of things' 7 'ISBN' 'YES' 'Books would need this' 8 'TailLength' 'NO' 'For stuff that has long tails' 9 'Name' 'YES' 'Name of things' 

 Property PropertyID EntityID PropertyTypeID 1 1 4 -- book, title 2 1 5 -- book, author 3 1 7 -- book, isbn 4 2 9 -- cat, name 5 2 6 -- cat, color 6 2 8 -- cat, tail length 7 3 3 -- beer bottle, volume 8 3 6 -- beer bottle, color 

 Measurement PropertyID Unit Value 6 'inch' 9 -- cat, tail length 7 'ml' 500 -- beer bottle, volume 

 Trait PropertyID Value 1 'Gone with the Wind' -- book, title 2 'Margaret Mitchell' -- book, author 3 '978-1416548898' -- book, isbn 4 'Phoebe' -- cat, name 5 'Gray' -- cat, color 8 'Green' -- beer bottle, color 

编辑:

杰弗里提出了一个有效的观点(见评论),所以我会扩大答案。

该模型允许使用任何types的属性dynamic(即时)创build任何数量的实体,而无需更改模式。 Hovewer,这种灵活性有一个价格 – 存储和search比平常的表devise更慢,更复杂。

时间是一个例子,但首先,为了让事情变得简单,我将把模型变成一个视图。

 create view vModel as select e.EntityId , x.Name as PropertyName , m.Value as MeasurementValue , m.Unit , t.Value as TraitValue from Entity as e join Property as p on p.EntityID = p.EntityID join PropertyType as x on x.PropertyTypeId = p.PropertyTypeId left join Measurement as m on m.PropertyId = p.PropertyId left join Trait as t on t.PropertyId = p.PropertyId ; 

从评论中使用Jefferey的例子

 with q_00 as ( -- all books select EntityID from vModel where PropertyName = 'object type' and TraitValue = 'book' ), q_01 as ( -- all US books select EntityID from vModel as a join q_00 as b on b.EntityID = a.EntityID where PropertyName = 'publisher country' and TraitValue = 'US' ), q_02 as ( -- all US books published in 2008 select EntityID from vModel as a join q_01 as b on b.EntityID = a.EntityID where PropertyName = 'year published' and MeasurementValue = 2008 ), q_03 as ( -- all US books published in 2008 not discontinued select EntityID from vModel as a join q_02 as b on b.EntityID = a.EntityID where PropertyName = 'is discontinued' and TraitValue = 'no' ), q_04 as ( -- all US books published in 2008 not discontinued that cost less than $50 select EntityID from vModel as a join q_03 as b on b.EntityID = a.EntityID where PropertyName = 'price' and MeasurementValue < 50 and MeasurementUnit = 'USD' ) select EntityID , max(case PropertyName when 'title' than TraitValue else null end) as Title , max(case PropertyName when 'ISBN' than TraitValue else null end) as ISBN from vModel as a join q_04 as b on b.EntityID = a.EntityID group by EntityID ; 

这看起来很复杂,但仔细观察,你可能会注意到CTE的模式。

现在假设我们有一个标准的固定模式devise,其中每个对象属性都有自己的列。 该查询将如下所示:

 select EntityID, Title, ISBN from vModel WHERE ObjectType = 'book' and PublisherCountry = 'US' and YearPublished = 2008 and IsDiscontinued = 'no' and Price < 50 and Currency = 'USD' ; 

我不打算回答,但现在接受的答案有一个非常糟糕的主意。 关系数据库不应该用来存储简单的属性值对。 这将导致很多问题。

处理这个问题的最好方法是为每种types创build一个单独的表格。

 Product ------- ProductId Description Price (other attributes common to all products) Book ---- ProductId (foreign key to Product.ProductId) ISBN Author (other attributes related to books) Electronics ----------- ProductId (foreign key to Product.ProductId) BatteriesRequired etc. 

每一张桌子的每一行都应该代表一个关于现实世界的命题,桌子的结构和它们的约束应该反映出被performance的现实。 越接近这个理想,数据越干净,报告和以其他方式扩展系统就越容易。 它也将运行更有效。

你可以使用无模式的方法:

将元数据保存在TEXT列中作为JSON对象(或者其他序列化,但是由于很快解释的原因,JSON更好)。

这种技术的优点:

  1. 更less的查询:您可以在一个查询中获得所有信息,无需“定向”查询(获取元元数据)和连接。

  2. 您可以随时添加/删除任何您想要的属性,无需更改表(这在某些数据库中是有问题的,例如,Mysqllocking了表,并且需要很长的时间处理巨大的表)

  3. 既然是JSON,你不需要在你的后端进行额外的处理。 您的网页(我假设它是一个Web应用程序)只是从您的Web服务读取JSON,就是这样,您可以使用JavaScript的JSON对象,不过你喜欢。

问题:

  1. 可能浪费的空间,如果你有100本同一作者的书,那么所有书只有author_id的作者表是更经济的空间明智的。

  2. 需要实现索引。 因为你的元数据是一个JSON对象,所以你没有索引。 但是为您需要的特定元数据实现特定的索引是相当容易的。 例如,你想按作者索引,所以你创build一个author_id和表author_id和item_id,当有人search作者,你可以查找这个表和项目本身。

根据规模,这可能是一个矫枉过正。 在较小规模的联接将工作得很好。

产品应该打字。 例如在产品表中包含type_id,指向您将支持的产品类别,并让您知道要查询哪些其他表以查找适当的相关属性。

在这类问题中,你有三个select:

  1. 用“通用”列创build一个表。 例如,如果您同时销售书籍和烤面包机,您的烤面包机可能没有ISBN和标题,但它们仍然有某种产品标识和说明。 所以给字段一般的名称,如“product_id”和“description”,书籍的product_id是一个ISBN,烤面包机的制造商的零件号码等。

当真实世界的实体都以相同的方式处理时,至less在大多数情况下都是如此,因此,即使不是“相同”的数据,也必须有至less一个一致的数据。 当存在真正的function差异时,这会被打破。 就像烤面包机,我们计算瓦特=伏特*安培数,可能没有相应的书本计算。 当你开始创buildpages_volts字段,其中包含书的页数和电烤炉的电压时,事情就会失去控制。

  1. 使用像Damirbuild议的财产/价值计划。 看到我的评论在他的职位的利弊在那里。

  2. 我通常会build议的是一种types/子types的scheme。 创build一个包含types代码和通用字段的“产品”表。 然后,对于每种真实types(书籍,烤面包机,猫,等等),都会创build一个与产品表连接的独立表格。 那么当你需要做特定书本的处理时,处理书本表。 当您需要进行通用处理时,请处理产品表。