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