标签: database-design

我即将开始从事电话词典类项目。它确认字典表中将有数十亿条记录，并且该字典表中的每个条目可能有参考字典表的进一步库存表。我之前没有使用过如此庞大的数据库。

InnoDB 有利于维护关系数据库。有类别和子类别引用，所以我将使用 InnoDB。会出现一种情况，我需要根据类别或子类别，甚至根据州和城市来显示总数。等等……它可以是任意组合。

我熟悉在大多数搜索列上创建索引。我听说过表分区也有助于加快查询速度。

我的问题是在创建此类将有数十亿行的数据库表时，在早期阶段我应该考虑哪些要点，以便以后当表变大时，我可以通过选择查询和 DML 查询将表性能保持在高水平（插入，更新）。

指导会给我很大帮助。

我正在使用 SQL Server Express 2008 R2。新创建的数据库的自动关闭属性将设置为与模型 db 相同的值。在我的例子中，我已经将模型的 autoclose 设置为 false，这样当我创建一个新数据库时，它也会将 autoclose 设置为 false。

如果我将自动关闭设置为 false 的数据库分离然后附加它，则自动关闭设置为 true。我期望 autoclose 为假，因为它将从模型数据库继承其属性。在我的情况下，分离和附加数据库会导致 autoclose 属性设置为 true。

为什么会这样？这个问题有什么解决办法吗？

我正在尝试汇总大约 500-1000 个处理各种小型企业问题（库存、采购订单等）的 MS Excel 文件，我目前正在尝试决定我应该使用哪种类型的 RDMS。为您提供更多详细信息，该数据库将主要由托管在网络服务器上的 1 到 2 人使用。目前，我一直在玩弄 MariaDB 和 Microsoft Access。Excel 数据很容易导入到 MS Access 中，在使用 MariaDB 导入相同的数据时，我遇到了一些障碍。数据库必须易于查询，并且必须能够轻松地从电子表格中导入数据。

我不确定要往哪个方向发展，我是继续使用 MariaDb 和 MySQL 还是继续使用 MS Access。或者，我应该使用其他东西吗？

实际上，我永远不会将客户的姓名存储在单独的表中。但为什么不呢？这是一对多的关系（一个人可以有一个名字，但这个名字可以被多人使用）。在多个表上分离一对多关系不是正确的设计，还是我遗漏了什么？

我是一名学生，我正在尝试设计一个简单的数据库，所以如果这些想法看起来很糟糕，请告诉我如何改进。

我脑子里有三张桌子，一张给教授，一张给学生。他们都有联系方式。我需要知道实现三者之间关系的最佳实践是什么。

我看到两种可能性：A）让教授和学生表都使用自动增量字段和补充默认初始化字段（假设教授为 1，学生为 2）。然后在第三个表 (Contacts) 中创建一个键作为唯一 ID 和默认初始化字段的组合。

B) 有 for 表而不是三个，有两个与 ContactStudents 和 ContactProfessors 相同的结构表，每个表都为相应的表服务。

从我的角度来看，我会选择第一个，因为如果我想向 Contact 表添加新字段，两者都会从中受益。

你认为哪一个最好，为什么？有没有另一种更好的方法来实现这一目标？

编辑：

在各种答案之后，在 zagrimsan 的建议下，我添加了以下要求：学生也可以是教授。一个人（教授的学生）可以有多个联系人。一个联系人可以被多个学生和教授（同种）重复使用，但不能同时被学生和教授重复使用，除非同一个学生也是教授。

我对数据建模很陌生，所以如果我错过了一些明显的东西，请原谅。我试图决定一个模式（或者可能是一个 DBMS）来处理一些数据，其中有很多可能的属性（可能是 60-100），但只有少数适​​用于每条记录。这是我看到的选项。

选项 1：非常宽的桌子

只需将每个属性包含为列，对于任何给定记录，大多数属性将为 NULL。

优点：保持架构简单，保持查询简单

缺点：不优雅，笨拙，添加/删除属性需要更改架构

选项 2：实体-属性-值模型

用于列出属性及其值的单独表格。这就是我之前看到这个问题的处理方式。例如，WordPress 在他们的*meta表格中使用了这样的东西。

优点：概念上易于理解，灵活

缺点：查询构造变得很痛苦，性能受到影响，最终会得到大量重复数据（即一遍又一遍地列出相同的属性名称）。

选项 3：NoSQL 文档或图形 DBMS

使用专为处理无模式数据而构建的 DBMS。我看过 MongoDB、RethinkDB 和 OrientDB。OrientDB 看起来很酷，但我不懂 Java，而且它似乎主要是 Java 的东西（例如，PHP 驱动程序看起来有问题）。

优点：专为处理灵活的模式而构建，速度快

缺点：关系似乎很困难，我没有使用它们的经验，似乎有很多重复的数据（例如，如果我想更改属性名称会发生​​什么？），查询似乎更复杂

附带说明一下，此应用程序不会获得很多流量，并且并发连接也很少。因此，可扩展性是一个相当小的问题。感谢您的任何建议。

因此，我正在尝试开发一个关系数据库（我正在使用 MySQL，计划在 Java 前端），其中有 3 个表（人员，我存储姓名和相关个人信息的位置...和消息（发送的每条消息的位置） ，则存储相关信息。每条消息都有一个ID#，您可以从中得出发送日期和时间、消息内容、消息发送者和消息接收者）。

我的问题是设置数据库，使每条消息只能有一个发件人，但有多个收件人。例如，我可以轻松处理从用户 6 发送到用户 3 的消息 ID 73。但是如果消息 ID 74 从用户 4 发送到用户 2、3 和 8，我将如何处理？有没有办法允许多个收件人？我是否需要重新考虑数据库的结构？有人有一些建议/提示吗？

假设我有一个非常简单的表来存储类似变量的数据，如下所示：

+-----------+-----------------+
|    key    |      value      |
+-----------+-----------------+
| site_url  | helloworld.com  |
| site_name | Hello World     |
| time_zone | Asia Taipei     |
+-----------+-----------------+