这是一个以前可能已经问过的问题,但是我很难找到我的确切情况,所以我将解释我的情况以寻求一些反馈:
我有一个将注册位置的应用程序,我有几种类型的位置,每种位置类型都有一组不同的属性,但是我需要将注释与位置相关联,而不管它们的类型和其他类型的内容(主要是多媒体条目和评论)到所说的笔记。考虑到这一点,我想出了几个解决方案:
为每个位置类型创建一个表,并为每个带有外键的位置表创建一个“注释”表,这非常麻烦,因为我必须为每个评论表创建一个多媒体和评论表,例如:
位置类型A
- ID
- 属性1
- 属性2
LocationTypeA_Notes
- ID
- 属性1
- ...
- 位置类型A_fk
LocationTypeA_Notes_Multimedia
- ID
- 属性1
- ...
- LocationTypeA_Notes_fk
以此类推,这样做会很烦人,但是完成后,在这种结构上进行开发应该不会那么麻烦。
创建一个具有唯一标识符的表,用于该位置并指向那里的内容,如下所示:
地点
- ID
位置类型A
- ID
- 属性1
- 属性2
- 位置_fk
笔记
- ID
- 属性1
- ...
- 位置_fk
多媒体
- ID
- 属性1
- ...
- Notes_fk
如您所见,这要简单得多,也更容易开发,但我只是不喜欢只有 ID 的表的外观(是的,这确实是我对此的唯一反对意见,这是我最喜欢的选项, 老实说)。
类似于选项 2,但我会有一个巨大的属性表,形状如下:
地点
- ID
- 类型
属性
- 姓名
- 价值
以此类推,或者每个属性一个表;一个拉德鲁帕尔。这将是一个痛苦的开发,因为它需要几个插入/更新操作来在一个位置上做一些事情,并且属性表将比位置表大几倍(或者最终有大量的属性表);它也有代理键唯一表的相同问题(只是它现在有一个“类型”,我将使用它来以编程方式定义位置的行为),但这是一个很好的解决方案。
那么,对于这个问题:在性能和可扩展性方面哪个会是更好的解决方案?,您会选择哪种方案,或者您会提出哪些替代方案?我实现这些都没有问题,选项 2 和 3 将是一个有趣的发展,我从来没有做过这样的事情,但我不想选择在内容时会自行崩溃的选项增长一点;你可能在想“如果你知道 Drupal 的工作方式和你期望的一样,为什么不直接使用它?”,我在想“你显然不知道使用 Drupal 有多么困难,或者你是专家,我绝对不是”。
另外,既然我已经写了所有这些,您认为选项 2 总体上是一个好主意吗?您知道分组实体/模拟继承的更好方法吗?(请不要说“只使用继承!”,我仅限于使用 MySQL)。
感谢您的反馈,如果我写的太多而意思太少,我很抱歉。