3

我正在为一个建筑项目开发库存控制系统。店员负责添加新库存并将其分配给员工/从员工那里退还。项目（以及它们的属性）将非常多样化；例如钢结构、服装、工厂/机械、工具等。

我的问题是选择基于类/具体表继承还是基于 EAV 的模式。我不知道项目将具有哪些属性，因此大概类/具体表继承方法需要最终用户将新表添加到数据库中（这可能吗？）。

请参阅我提出的EAV 架构。这会是一个合理的解决方案吗？我想我说得对，要识别一个库存项目，有必要在“EV”表的查询中执行多个自连接吗？

NB 使用 PHP、MySQL 和 Zend 框架进行开发。

4

2 回答 2

1

  • 如果属性更改很少且相差甚远，请选择Table Inheritance，但对模式的更改应由您自己或 DBA 完成。根据用户输入以编程方式修改架构似乎是个坏主意。

  • 如果属性更改相当普遍，请考虑使用面向文档的数据库，例如MongoDB或CouchDB。

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

于 2010-08-04T23:53:23.233 回答
0

我会避免使用 EAV，除非我正在构建一个包含数千种产品的医疗存储库。类表继承是一个合适的解决方案，并且在运行时更改模式并不是一个坏主意。

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

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

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

表锁定问题也可以避免/最小化。更改大型表（即 100k+ 记录）时通常会发生锁定问题。然而，继承允许将产品分布在不同的集合中，因此每个表的记录量相对较少。

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

我很高兴在这里听到更多关于这个的意见。多谢你们。

于 2013-09-08T08:17:33.610 回答