什么是基本信息的最佳架构设计？

Question

我们至少有50个对象（例如：city，country，color，personelType，organizationType等等...我们的应用程序包含相同的属性。这些属性包含：ID，Topic，Code，isActive

• 对于包含相同属性的这些对象，我们创建了两个对象，称为BaseInfo和BaseHeader。
• 对于此对象的设计表，我们创建一个称为Base-Header的表和另一个称为Base-Info的表。这些表的关系是：https://pasteboard.co/GQeV4Rl.png

现在，如果需要，开发人员会在Base-Header中添加新记录。例如，开发人员会看到Base-Header，如果city表中没有记录，则为城市对象添加一条记录：insert into Base-Header (id, topic) values (1, 'city');或颜色为insert into Base-Header (id, topic) values (2, 'color');。在此之后，所有开发人员都知道城市记录headerId中Base-Info字段的值为1，并且可以在应用程序中对此ID进行硬编码以获取城市数据。在我们的应用程序中具有相同状态的其他对象。

使用此计划，我们不需要为具有相同属性的city，color等创建表和对象。需要城市记录的其他表的所有外键，都附有Base-Info表。这种表和对象的设计是否正确？

• 考虑您拥有此架构[https://pasteboard.co/GQnqaT5.png]并更改为此[https://pasteboard.co/GQnqiCE.png]。通过这项工作，我们删除了具有相同道具的所有对象和表格。注意。查询未更改，并且未添加任何join或where子句。只是外键更改为Base_Info。这很复杂吗？

非常感谢...

Answer 1

我没有解决你的实际问题。但我可以建议你为上述问题设计数据库。如果它们不经常变化，您可以对对象列表（城市，国家，颜色，pesonnelType等）进行枚举，否则您可以将所有上述对象与id一起存储在单个表中。并在base-info表中添加一列来存储相应对象的id。因此，您最新的base-info表将有一个额外的列object-id。我认为你的问题会以这种方式解决..

Answer 2

听起来你正试图在这里采用EAV类型的方法。它不适合RDBMS。不是设计方面，不是性能方面，不是可用性方面。

如果BaseHeader的唯一目的是为实体提供类型，那么它并不是真正必要的。正如Lawakush指出的那样，您也可以使用enum字段（如果数据库支持它，否则您可以模拟它）而不是单独的表。

如果您要使用EAV模型，则会收到警告。你可以建模＆＃34;任何东西都可能看起来很棒，但你最终会得到一大堆无法维护的垃圾，由于数据库中缺乏适当的保护措施而导致数据被破坏：外键不能使用＆＃39;在EAV模型中工作得很好。

Answer 3

您需要至少3-6个月来首先分析业务需求。一旦到位，它将变得很方便。正如我在您的陈述中所注意到的那样，业务分析师似乎没有对其进行审核。你需要从BA的角度来看这个，所以一旦编译和总结，它将在技术角度清楚地进行数据仓库。