数据库关系方案MySQL-profiles

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

情况是这样的：

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

如果你认为这不好，你能告诉我为什么吗？请让我知道图片有什么问题，因为我的其他开发工作将是徒劳的。
我确信您对该应用程序的发展方向有一定的了解。

---

如果你有任何进一步的建议，谢谢你的建议

不要为每个事件（如酒吧、组织者等）创建单独的表格，只创建一个表格配置文件（或事件），用于保存所有事件。在此表中添加名为event_description的列。这一点很重要，因为在我们当前的设计中，我们需要找到一个配置文件所属的事件，以便根据每个事件表进行验证。除此之外，高水平的ur设计看起来不错。

您好，谢谢您的回复。你的意思是我应该把所有关于酒吧、活动组织者、商店等的详细信息汇总到一张表中吗？我担心这会使表负担过重，因为表中会包含许多详细的、不相关的实体典型信息，或者该表与其他子表相关。活动组织者可以创建一个艺术家阵容，拥有艺术家简介（与组织者表相关），但实际上与商店无关。会有很多这样的例子。你对这个话题有什么看法？我坚信，只要所有事件都具有相似的特征，它们就应该放在同一张表中。过载是指性能问题吗？可以创建索引以在以后处理它，但最初的设计必须是正确的。正如我在回答中再次提到的，如果在您当前的设计中我给您一个配置文件id，您将如何在不扫描您创建的每个事件表的情况下确定它属于哪个事件。此外，如果将来有新的事件发生，你最终会创建新的表格，这是不对的。相似之处可以在同一张表中收集。通过重载表，我实际上是指重载一个包含大量不相关信息的表->但是，根据每个实体的各个特征识别共享信息似乎很重要。我明白你的意思；对于读取配置文件信息，它将只扫描一个表，而不是多个表，除非存在实体典型的信息请求。我看得对吗？如果没有人反对这个计划，我明天就接受你的答复。但正如你所说，事件中可能有一些不相关的细节。为此，我还建议为每个事件的行中的所有事件增加一个表（同样仅增加一个表），而不是将它们放在COL中。因此，新表可能会使用cols eventid、characterized、characterized detail和其他cols调用EventMoreDetails。好的，谢谢Nitin。原则很清楚，我会调查的！