mysql 主表和事务处理表之间的关系

2ic8powd  于 2022-11-21  发布在  Mysql
关注(0)|答案(1)|浏览(151)

在我的数据库设计中,我定义了主表(数据定义表,本质上是静态的),它将用于生成网页中的内容;和事务处理表,这些表将用于存储用户输入的数据(这些表本质上是动态的)。
请考虑以下示例:
由与 City 具有1:M关系的 State、与 Locality 具有1:M关系的 City 组成的一组主表。
一个事务处理表 User,用于存储用户输入的个人详细资料。User 表具有地址属性,如Address、State、City和Locality。这些属性可以定义为来自相应主表的1:M关系(StateCityLocality 表中的特定记录可以是 User 表中多个记录的一部分)。

我的疑问:

  • 上述设计是否正确?

  • 此外,我认为在 LocalityUser 表之间定义1:M关系就足够了,因为其他两个属性(City和State)可以从Master表之间的关系中获得。将ER设计更改为以下形式是否更好?

  • 有没有其他好的替代品来满足我的要求?

PS:我是数据库设计的初学者。

r3i60tvu

r3i60tvu1#

你有什么疑问吗?你有没有需要按statecity搜索?即使你按这些搜索,也可能不会影响我接下来要说的话...
由于localitycitystate是“嵌套”的,名称不太可能改变,我建议您的两个选项都是“过度规范化”的。
在我看来,正常化主要有两个原因:

  • 定位某个可能更改的字符串。通过将其放在一个单独的表中并指向该表,您可以只在一个位置更改它。在您的示例中不需要这样做。
  • 节省空间(从而提供速度等)。这确实适用于您的示例,但仅适用于locality级别,而不适用于address。您可能会认为citystate可以进行重复数据删除;我会用“增加的复杂性(额外的表)并不能保证最小的好处"来反驳。

旁注:如果localityzipcode,那么你的选项1至少在我所知道的一个地方有麻烦:洛斯阿尔托斯和洛斯阿尔托斯山(加州州的两个不同城市)* 都 * 有邮政编码为94022 * 和 * 94024的部分。

相关问题