设计用于库存控制的'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。类表继承是一个合适的解决方案，在运行时更改模式并不是一个坏主意。

假设您正在建立一个在线商店，您是否拥有不同属性的不同产品。通常，产品使用一组属性。通过使用类表继承模式，每个产品集可以有一个表继承具有公共产品属性的公用表。当需要新属性时，您有两个选择：

• 更改集合表并添加具有属性名称
的新列
• 使用新列创建一个新集（即新表），并将当前产品集设置为继承新列，从而添加新属性。

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

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

例如，如果我们有10种不同类型的产品，我们有10个不同的表。假设我们每种类型有10 000个产品，这意味着我们有超过10万个产品，但是在集合中添加新属性实际上只会在表中添加10 000行的新列。在具有10k行的表中添加新列将花费不到一秒的时间，因此在处理类表继承时，在运行时更改数据库模式真的很糟糕吗？

我很高兴听到有关此问题的更多意见。谢谢你们。