相关疑难解决方法(0)

我想知道你是否有一个网站上有十几种不同类型的列表(商店,餐馆,俱乐部,酒店,活动)需要不同的字段,是否有一个好处,创建一个表定义如下所示的列
示例:

shop_id | name | X | Y | city | district | area | metro | station | address | phone | email | website | opening_hours

或者更类似于此的抽象方法:

object_id | name        
---------------
1         | Messy Joe's  
2         | Bate's Motel 

type_id | name
---------------
1       | hotel
2       | restaurant


object_id | type_id
---------------
1         | 2
2         | 1

field_id | name           | field_type
---------------
1        | address        | text
2        | opening_hours  | date 
3        | …

目标

找到一个完美,灵活的模式,用于存储许多不同类型的对象,在关系数据库中它们之间具有各种各样的链接.

问题

EAV是RDBMS正常限制的一种解决方法.

如果你要规范化EAV架构,那将是丑陋的.

理念

如果EAV正常化,那将是丑陋的.

我们传统上手工维护这些架构的事实是否限制了它们的复杂性和功能？

但如果以编程方式维护和查询,那有什么关系呢？

图表

如果n在n不同的表中有不同的实体,为什么不让代码生成n(n+1)/2链接表以及它们之间的查询？这不会导致规范化架构中的真实图形吗？

在高度相互关联的数据库中,总是会有比指数更多的边缘.为什么不专注于创建正确的标准化Verticle(n实体表)并让我们的代码保持边缘(n^x链接表)？

结论

系统能否规范化EAV并维护最终的复杂模式？

复杂的图形可以存储在(并保持真实)关系数据库中吗？

我确信之前已经完成了,但我从未见过它.我错过了什么？

示例问题

存储印刷品及其书目数据

• 许多属性可能不仅仅是字符串而是整个对象.
• 在库世界中,没有简单(和关系)模式可以在没有极其复杂的模式的情况下"无损地"存储数据.
• 许多不同类型的关联和关联对象
  • 及其相关属性(可能会有很大差异).
  • 他们之间有许多不同类型的关系.

问题

" 你想解决什么问题？ " -
皮特

我正在寻找关系数据库系统中EAV,图形和多态关系的规范化解决方案.

" 我不愿意成为那些在投入生产后必须理解或维护它的人. " -
安德鲁

这种"传统维护"正是我所说的应该是自动化的.这不是很大的咕噜声吗？

我一直在为即将开展的项目进行大量的数据库设计研究.

这是典型的内部平台的问题,我们的客户基本上要无限定制和打造产品的能力和对实体属性,收集他们从最终用户的价值,并能够显示在图形上收集到的信息.

临床医生将用它来帮助监测患者,为什么即使使用EAV,我们也需要为不同的试运行收集不同的信息.有时可能是他们那天吃的东西.其他可能是血糖,或血压(这实际上是两个数字),其他可能是多个问题(今天你的疼痛怎么从1-10？),所有这些都是我们永远不会真正知道的提前最终客户要求的是什么,或者真正接受的是什么.

我们还将在整个计划中一致地绘制这些数据,并在较不规则的基础上生成更大的报告.

理想情况下,我希望尽可能多地硬编码,因为我们使用SQL,并且坚持关系数据库最佳实践将简化数据库设计和应用程序设计(我正在编写这两者).

我们正在进行一些试运行,我的第一个倾向是从客户那里获取尽可能多的信息,对数据库中的表进行硬编码,然后从那里构建.如果我们发现我们需要使用属性表和attribue_value表来收集这些属性(以及有趣的实现表单构建器,如下拉菜单 - 从而下拉菜单选项和验证/需要),我们可以这样做后来发布.

我基本上经历了每个相关的堆栈溢出帖子; 大多数人说避免EAV,更好地了解应用程序的要求,并且,在某些时候,如果客户TRULY需要EAV实施,那么继续执行它.

• 有没有人曾经使用混合动力车型？你能讨论一下吗？

• 有没有人成功实施过EAV模型,你能讨论一下吗？

• 你有没有做过类似的决定,决定不为一个似乎可能成为候选人的项目实施EAV？结果怎么样？

以下是我在此过程中发现的一些有趣的读物:

http://decipherinfosys.wordpress.com/2007/01/29/name-value-pair-design/ 存储时间序列数据,关系数据还是非存储数据？ 数据库EAV优点/缺点和替代 实体 - 属性 - 值(EAV)的替代方案？

这个链接确实给了我很多洞察力.

有哪些好方法可以对需要查询的数据进行建模,但是哪些方法无法完全预先定义？

例如...说我想模拟有关世界各国的信息.每个国家都有人口,国旗和语言清单,这很容易.但是说我们也想模拟他们国家棒球队的输赢记录,当然并非所有国家都有.或者,我们想跟踪他们的国王和王后的血统(再次,显然不适用于大多数国家).或者,我们决定我们想要模拟平均氏族成员在一生中建立的蒙古包的数量.

无论如何,重点是,我们不会(也永远不会)知道在它袭击我们之前会发生什么.哪些方法既可扩展又可查询？

这可能是一个很好用于以文档为中心的数据库(MongoDB？),或者某些设计模式可能应用于经典的Relational数据库？