3

我正在尝试使用 Sqlite3 来处理这些 SQL 内容。我有几个关于这个话题的问题。

数据库是否遵循基本结构？我很好奇我是否会将我的数据库建模为就像一个巨大的字典一样。

我正在考虑的问题：

如果我想要一个可以提取任何城市的邮政编码或其他一般信息的程序，我正在考虑一种嵌套表的结构。即：

Countries Table:
+----+--------+--------+---------+
| US | Canada | Mexico |  Etc... |
+----+--------+--------+---------+
  |
  |
  |
  |
  | States Table:
  +---------+----------+---------+--------+
  | Alabama | Arkansas | Georgia | Etc... |
  +---------+----------+---------+--------+
                  |
                  |
                  |
                  |
                  | Cities Table:
                +-----------+---------+--------+---------+
                | Alexander | Bauxite | Benton | Etc ... |
                +-----------+---------+--------+---------+
                                           |
                                           |
                     +-----+------------+---------+------+--------------------+                    
                     | Key | population | zipcode | size | other random stuff |
                     +-----+------------+---------+------+--------------------+

但是嵌套太多了吗..？这是一个糟糕的设计吗？最重要的东西，countries表格并没有真正做太多，我有点在我的脑海里有这样的想法，你应该能够使用数据库轻松地完成非常复杂的事情。如果我按照我的设计去做，在我最终得到我想要的东西之前，我似乎会遍历一堆东西。所以，我只是好奇我是否错误地处理了整个事情。

有谁知道使用数据库的基础知识的好入门？

4

2 回答 2

2

关系数据库基于实体关系模型。如果您想掌握 RDBSM 背后的概念，请考虑先熟悉该理论。具体而言，关系方案（表、列、通过外键的关系......）是 ERM 的一个（或那个）应用程序。

另一个要搜索的关键字是Normalization. 标准化有不同的“等级”和从一个等级转换为另一个等级的规则，该主题与您关于表结构的问题直接相关。一个普遍的答案是，这取决于。一般来说，规范化有助于保持数据的一致性——但完全规范化的表结构可能会导致性能损失（例如，经常使用查询的许多连接）。

我建议先进行更严格的标准化，然后检查性能。选择性非规范化可能有助于提高性能。

于 2012-12-12T22:18:45.510 回答
2

有许多范式（1NF、2NF、3NF、BCNF...）。更高的形式=更好的粒度（没有太多的冗余，更好的关系......）。

可能是一个小细节。你有国家和州。但是恕我直言，美国是世界上的具体案例（其他类似案例并不多）。可能是表州，城市就足够了（+大洲）。

设计依赖于目的（在某些情况下，较低的 NF 应该更有效，取决于许多因素 - 记录数、目的等）。你必须问几个问题。这个数据库的目的是什么？表城市是否足够，或者我也想使用村庄，所以应该是表城市？等等。但是你的设计几乎是好的；）

于 2012-12-12T22:19:33.877 回答