PHP Geek需要数据库设计帮助

Question

像大多数开发人员一样，我认为我一直在努力创建最优的代码和数据库模式。

然而，我有一种感觉，我正在设计我想要创建的数据库模式。

我有一个网络应用程序，在很短的时间内，将容纳许多用户。用户主要有客户、供应商、系统用户等。在这个行业中，它可能会快速增长。

在前面的模式中，我将这些用户分隔到不同的表中。

但是，我现在正在考虑使用一个名为: PEOPLE的表。

将会有以下表格：

人员，联系方式，住宅

它们通过PivotTables联系在一起，即: PivotContacts PivotResidences。

我的问题是，这被认为是好的/坏的设计。我是不是想多了，设计了一个简单的设置。

表People将呈指数级增长，并将保存大量数据-其他表也将与此相关。

我真的很欢迎大家的意见。

我的设计将扩展到10万条记录并保持中等速度。*最初将从1000条记录开始，并可能在一年内增长到大约100,000条记录。

Answer 1

对于可以登录并且可能被跟踪(上次登录，密码重试失败)的用户，最好有一个较小的表，也许还有一个单独的表用于写入(读取和写入数据之间的区别)。

一般来说，任何包含人员的表都有收集大量字段的趋势。保留在不同表中的功能差异保持了数据的整洁，对供应商表的索引更好/可能更优，对供应商数据的更改也是如此。SQL连接是可管理的，并且可以使用SQL视图来完成。

所以我会选择一个很薄的基表People和1:1的表SupplierPeople，SystemUsingPeople等等。并考虑发生了哪些更改:表被更新、插入和读取的频率。

还要考虑必须修改数据库方案，添加一个字段。

Answer 2

如果您只担心解决方案的可伸缩性，那么根据一些(重要的)假设，100K记录不是一个特别大的数字。

在现代硬件上运行的现代数据库软件(我假设您将使用MySQL，因为您是PHP手)可以轻松地处理包含数百万条记录的数据库，只要您有一个设计良好的表布局，并且可以使用索引。

您的设计-将"people“链接到"contacts”和"residences“可以使用主键/外键来加入；这应该很容易扩展到您的需求。

不过，值得考虑的是你可能要运行的查询--我猜你需要能够按姓名、地址、城市或最后联系日期等搜索“人”。这表明你可能需要free text searching -一旦你获得了大量记录，使用where name like '%Jones%'可能会很慢。

您可能还想考虑存档/历史策略--您是否需要存储某人住所的历史记录(这样您就可以知道他们下单时住在哪里)？