库存控制的'EAV'或'类/具体表继承'数据库的设计

Question

我正在开发一个建筑项目的库存控制系统。店主负责添加新的库存并将其分发/退回给员工。项目（因此它们的属性）将会变化很大。例如钢铁厂，服装，工厂/机械，工具等。

我的问题是要去Class/Concrete Table Inheritance或基于EAV的模式。我不知道项目将具有什么属性，因此推测类/具体表继承方法会要求最终用户向数据库添加新表（这是可能的吗？）。

请参阅我建议的EAV schema。这会是一个合理的解决方案吗？我认为我说得很对，要确定一个股票的项目，有必要在'EV'表上查询时执行多个自我加入。

N.B.使用PHP，MySQL和Zend Framework开发。

Answer 1

• 如果属性的变化是少之又少，去表继承，但对架构的更改应该由自己或DBA来完成。基于用户输入以编程方式修改您的模式似乎是一个坏主意。

• 如果属性的变化是相当普遍的，可以考虑使用document-oriented database像MongoDB或CouchDB。

• 如果属性更改很常见，而且仅限于关系数据库，请使用EAV。

Answer 2

我会避免EAV，除非我正在建立一个有成千上万种产品的医疗信息库。类表继承是一个适当的解决方案，在运行时改变模式并不是什么坏主意。

假设你正在建立一个网上商店，你有不同的产品具有不同的属性。通常，产品正在使用一组属性。通过使用Class Table Inheritance模式，您可以为每个产品组使用一个表，继承具有常见产品属性的公共表。当需要一个新的属性，你有两个选择：

• 改变安放台和带有属性名称
• 创建一个新的集（即新表）与新列添加一个新的列并设置当前产品设置为继承新产品，从而添加新的属性。

在运行时更改表可能确实会导致问题，因为在更改过程中发生锁定。然而，从MySQL 5.6开始，程序员可以指定一个LOCK类型，例如LOCK = NONE，也可以ALTER ONLINE | OFFLINE。显然，DB供应商正在朝这个方向努力，以便在运行期间进行数据库更改。

表锁定问题也可以避免/最小化。锁定问题通常发生在改变巨大的表格（即100k +记录）时。但是，继承允许分配不同集合中的产品，因此每个表的记录数量相对较少。

例如，如果我们有10种不同类型的产品，我们有10个不同的表格。假设我们每种类型都有10000个产品，这意味着我们有超过10万个产品，但是在一个集合中添加一个新属性实际上只会在具有10000个行的表中添加一个新列。在具有10k行的表中添加新列的时间会少于一秒，因此在处理类表时继续改变数据库模式继承真的是个坏主意？

我很乐意在这里听到更多意见。多谢你们。