数据库关系方案 MySQL - 配置文件答案

【问题标题】：database relationship scheme MySQL - profiles数据库关系方案 MySQL - 配置文件
【发布时间】：2013-06-18 17:51:42
【问题描述】：

我想创建一个应用程序，在开始编程之前，我想听听您对基本模型的专业意见和建议。
很抱歉我没有在文本中绘制结构，但这似乎是展示我的案例的最清晰的方式。

情况是这样的：

用户可以交朋友；
用户可以为酒吧、餐馆、活动组织者或商店等一个或多个实体创建配置文件。这些主要类别的数量可能会增加（并且这些主要类别中也会有子类别）。创建实体配置文件时，profile_tbl、owner_tbl 和 bar/organizer_tbl 会立即更新，并自动为用户分配“root”用户角色状态。我想这必须通过 mySQL 事务来完成；
不同的配置文件具有不同的特征：酒吧、餐厅、活动、商店在某种程度上具有可比性，但它们具有许多不同的特征，这些特征将反映在它们的配置文件中。因此，我将它们分成单独的表。创建实体配置文件后，用户可以配置他们的实体配置文件；
一个用户只能成为同一个人资料（酒吧、餐厅、活动、商店）的所有者一次（这就是我在 owner_tbl 中创建复合 PK 的原因）；
具有个人资料和“root”用户角色状态的用户（场所的创始人）可以将共同管理权限授予其他用户。根据用户角色，用户将能够执行某些操作并具有某些查看权限。

如果你觉得不好，可以和我分享一下为什么吗？请让我知道图片有什么问题，因为我其余的开发工作将是徒劳的。
我很确定您对这个应用程序的去向有所了解。
如果您有任何进一步的建议，谢谢您的建议。

【问题讨论】：

【解决方案1】：

不要为每个事件（即酒吧、组织者等）创建单独的表格，而是只创建 1 个表格 profile_details（或事件）来保存所有事件。在此表中添加名为 event_description 的列。这很重要，因为在您当前的设计中，要查找配置文件属于什么事件，您可以针对每个事件表进行验证。除此之外，您的设计看起来还不错。

【讨论】：

您好，感谢您的回复。您的意思是我应该将有关酒吧、活动组织者、商店等的所有详细信息汇总到一张表中吗？恐怕这会使表格过载，因为表格中将包含更多详细且不相关的实体典型信息，或者与其他子表格相关联。例如。活动组织者可以创建一个艺术家阵容，具有艺术家个人资料（与组织者表相关），但它与例如商店无关。这样的例子会有很多。你对这个话题有什么看法？
我坚信，只要所有事件具有相似的特征，它们就应该放在一个表中。重载是指性能问题吗？可以创建索引以在以后处理它，但最初的设计必须是正确的。正如我在回答中提到的，如果在您当前的设计中我给您一个配置文件 ID，您将如何确定它属于哪个事件而不扫描您创建的每个事件表。此外，如果将来有新事件发生，您最终会创建不正确的新表格。
+1 好的，我明白你的意思了。相似之处可以聚集在同一张表中。通过重载表，我实际上是指用大量不相关的信息重载表 -> 但似乎用每个实体的个体特征来识别共享是很重要的。我明白你的意思；对于读取配置文件信息，它只会扫描一个表而不是多个表，除非请求的信息对于实体来说是典型的。我认为这是正确的方式吗？如果没有其他人反对该计划的进一步反对意见，我将在明天接受您的答复。
是的。但正如你所说，事件可能有一些不相关的细节。为此，我还建议在每个事件的行中为所有事件无关的详细信息添加 1 个表（同样只有 1 个），而不是将它们放在 cols 中。因此，新表可能会调用 EventMoreDetails，并带有 cols eventid、characterisid、characteristic detail 和其他 cols。
好的，谢谢尼廷。原理很清楚，我研究一下！