关于数据库设计基础的问题

Question

我正在尝试使用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表实际上并不能做太多事情，我有点想，你应该能够用数据库轻松地做一些非常复杂的事情。如果我继续我的设计，在我最终得到我想要的东西之前，我似乎会在一堆东西上循环。所以，我只是好奇，我是不是整个事情都搞错了。

有没有人知道关于使用数据库的基础知识的好入门？

Answer 1

关系数据库是基于Entity-Relationship Model的。如果您想掌握RDBSM背后的概念，请考虑先熟悉该理论。具体地说，就是关系模式(表、列、通过外键建立的关系等)是ERM的一个(或)应用。

另一个要搜索的关键字是Normalization。有不同的标准化“等级”和从一个等级到另一个等级的转换规则，该主题与您关于表结构的问题直接相关。一般的答案是，这要看情况。一般而言，规范化有助于保持数据的一致性-但完全规范化的表结构可能会导致性能损失(例如，经常使用的查询的许多连接)。

我建议先进行更严格的规范化，然后再检查性能。选择性反正规化可能会帮助提升性能。

Answer 2

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

可能是个小细节。你有国家和州。但imho美国是世界上的特定案例(类似的案例并不多)。可能是表国家，城市就足够了(+大陆)。

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