Database 使用地址设计数据库的最佳实践

我正在研究一个设计案例，在这个案例中，他们讨论了如何处理正在开发的系统的数据库设计。该系统用于管理公共停车场。主要辩论是如何满足以下要求：

系统应允许管理各停车公司的信息

存储的数据是停车场的地址（详细信息、省、县、区）、名称、公司标识、车位号

系统应处理每个停车场产生的收入报告

这些报告应允许按省进行过滤，因为该公司按省拥有多个停车场，其中一些停车场位于同一地区

有人提到桌上停车场必须有省、县和区的立柱，这是每个停车场的特点

其他人说不应该这样。我想知道在这一点上，哪种方法是最好的数据库设计方法。 这可以归结为我的问题，在这种情况下（因为必须有例外），系统非常简单，这真的重要吗

---

如果这些报告允许按省进行筛选怎么办？由于一家公司可能在同一个省拥有多个停车场，其中一些停车场位于同一个地区。

根据您的要求，您需要决定采用何种模式

选项1-停车场立柱

如果在

停车场

表中添加

省

、

县

和

地区

的列，那么您就是在模拟每个停车场都有这些东西

本例中的模型不包括地区、县和省的主列表。您将无法验证为特定批次输入的详细信息是否有效

如果您从可信来源或您所在的地区等处获得停车场，请选择此选项。此选项不允许您存储任何其他信息。e、 g.如果您需要针对特定区域存储“区域管理器”，您将无处存储它

选项2-示范区、县和省

您可以为

省

、

县

和

区

创建表。他们的父母会有外键。在这种情况下，您确实有一个主列表（您需要保持最新）

然后在每个停车场上，您都有一个

地区的外键

（这意味着其他列）

---

如果要根据主列表验证地区等，请选择此选项。如果您有关于

地区

等的额外信息要存储，也可以选择此选项。

地区是否始终在县内，县是否始终在省内？或者它们能以奇怪的方式重叠吗？@WW。一个省有一个以上的县，一个县有一个以上的区，总是按照这个顺序。例如，不能有省、县、区、县。要小心，加利福尼亚旧金山市和县在县有一个城市。不清楚加利福尼亚州是否在你的职权范围内；听起来你可能在加拿大工作。你必须担心国际地址结构吗？@JonathanLeffler，我缺乏足够的地理知识，但我认为这意味着一个省可以有一个或多个Conties，而Conties又可以有一个或多个地区。此外，它似乎只适用于“本地”地址，也就是说，没有国际结构。完美地解释了两者之间的区别！非常感谢你的洞察力，我会记住的。