相关疑难解决方法(0)

我们的数据库是基于EAV(实体 - 属性 - 值)模型设计的.那些使用EAV模型的人知道为了灵活性而附带的所有垃圾.

我向我的客户询问了使用EAV模型的原因(灵活性),他们的反应是:他们的实体随着时间而变化.因此,今天他们可能有一个具有一些属性的表,但在一个月的时间内,可能会添加一些新属性,或者可能会重命名现有属性.他们需要生成报告以回到任何阶段,并根据该阶段的实体形状查询数据.

我理解这对于传统的关系模型是不可行的,但我个人认为EAV是反模式的.是否有其他替代模型使我们能够捕获实体和实例更改的时间维度？

干杯,莫什

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

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        | …

我正在升级我刚才创建的支付管理系统.它目前有一个表可以接受每种付款方式.它仅限于能够支付一件事,这个升级是为了缓解.我一直在问我应该如何设计它的建议,我有以下工作的基本想法:

1. 每种付款类型都有一个表格,每个付款类型都有几个常用列.(目前的设计)
2. 使用带有公共列的中央表协调所有付款(统一付款ID,无论类型如何),并标识具有专用于该付款类型的列的另一个表和行ID.
3. 为所有付款类型设置一个表,并将未用于任何给定类型的列置空.
4. 使用中心表的想法,但将专用列存储在键/值表中.

我的目标是:不要过于缓慢,尽可能地自我记录,并在保持其他目标的同时最大限度地提高灵活性.

由于每个表中的重复列,我不太喜欢1.它反映了继承基类的支付类型类,该基类为所有支付类型提供功能... ORM反向？

我倾向于最多2,因为它就像当前的设计一样"类型安全"和自我记录.但是,与1一样,要添加新的付款方式,我需要添加一个新表.

我不喜欢3因为它的"浪费的空间",并且不能立即清楚哪些列用于哪种支付类型.文档可以减轻这种痛苦,但我公司的内部工具没有一种有效的方法来存储/查找技术文档.

我给出的4个论点是,它可以减少在添加新的付款方式时需要更改数据库,但是由于缺乏明确性,它甚至比3更糟.目前,更改数据库不是问题,但如果我们决定开始让客户保留自己的数据库,它可能会成为一个后勤噩梦.

所以,我当然有偏见.有没有人有更好的想法？您认为哪种设计最合适？我应该根据什么标准做出决定？

我有一个关于数据库的理论问题.为了使它更具体,我想到了一个例子.

假设我有一个商店和产品.我有很多不同的产品.并非每种产品都具有相同的适用性.例如,我可以用千兆字节定义硬盘的大小,但不能在CPU上使用相同的属性,因为它不适用.我想要的是一个数据库,我可以动态地向产品添加属性.我唯一能想到的是以下内容:

一个带有ID,名称和描述的产品表.

一个属性表,包含ID,Product_ID,Property和Value.

通过这种方式,我可能会获得一个巨大的,我认为不那么高效的属性表.这已经困扰了我很长一段时间了.有谁知道我的问题更好的解决方案？