像大多数开发人员一样，我认为我一直在努力创建最优化的代码和数据库模式。
但是 - 我有一种感觉，我过度设计了我想要创建的数据库模式。
我有一个网络应用程序，它会在很短的时间内拥有很多用户。用户的形式有客户、供应商、系统用户。它处于一个可能快速增长的行业。
在以前的模式中，我将这些用户分隔在不同的表中。
但是，我现在正在考虑使用一张名为 PEOPLE 的桌子。
会有这些表：
人，联系方式，住宅
它们通过数据透视表关联，即：PivotContacts PivotResidences。
我的问题是这被认为是好/坏的设计。？我是否过度思考，过度设计了一个简单的设置。
表格 People 将呈指数增长，并将保存大量数据 - 其他表格将与之相关。
我真的很欢迎意见。
我的设计是否会扩展到 10 万条记录并保持中等速度。？* 最初将从 1000 条记录开始，并且可能会在 1 年内增长到大约 100,000 条。
对于可以登录并可能被跟踪（上次登录、密码重试失败）的用户，最好有一个小表，也许还有一个单独的表用于写入（读取和写入数据之间的区别）。
任何有一般人的表都有收集大量字段的趋势。保存在不同表中的功能区别使数据保持整洁，供应商表上的索引更好/可能更优化，供应商数据的更改也是如此。SQL JOIN 是可管理的，并且可以使用 SQL 视图来完成。
所以我会选择一个薄基表 People 和 1:1 表 SupplierPeople、SystemUsingPeople 等等。并考虑确实发生了哪些更改：更新、插入、读取表的频率。
还要考虑修改数据库方案，添加一个字段。
如果您只担心解决方案的可扩展性，那么 100K 记录并不是一个特别大的数字，这取决于一些（重要的）假设。
在现代硬件上运行的现代数据库软件（我假设你会使用 MySQL，因为你说你是 PHP 手）可以轻松处理具有数百万条记录的数据库，只要你有一个精心设计的表布局，并且可以使用索引。
您的设计 - 将“人”链接到“联系人”和“住所”可以使用主键/外键加入；这应该很容易扩展到您的要求。
不过，值得考虑您将要运行的可能查询 - 我猜您将需要能够按姓名、地址、城市或上次联系日期等搜索“人”。这个建议您可能需要自由文本搜索- 一旦您获得大量记录，使用where name like '%Jones%'可能会很慢。
您可能还需要考虑存档/历史策略 - 您是否需要存储某人住所的历史（以便您可以在他们下订单时找出他们居住的地方）？