数据库建模-mysql
我正在设计一个数据库，该数据库最终将拥有数千个用户。每个用户都有您的个人资料和相关的特定数据。
在您看来，最好使用一个表来存储 id、用户名、activationLink 和哈希值，再使用另一个表来存储地址、年龄、照片、工作，或者最好使用一个唯一的表来存储所有内容？
谢谢你的时间
I am doing the design of a database, that will have eventually thousands of users. Each user has your profile and specific data associated.
In your opinion, it is best practice a table for id, username, activationLink and hash and another for address, age, photo, job, or it is best a unique table for all stuff?
thanks for your time
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果：
然后将它们保存在一个表中，否则将它们拆分。
在您的模型中，
activationLink似乎每次激活仅查询一次，因此我将其移动到一个单独的表中（这将允许在帐户激活后将其删除）。地址、年龄、照片和工作通常与用户名一起显示，因此最好将它们合并到一个表中。
If:
then keep them in a single table, otherwies split them.
In your model,
activationLinkseems to be queried for only once per activation, so I'd move it into a separate table (which would allow deleting it after the account had been activated).Address, age, photo and job are usually shown along with the username, so it would be better to merge them into a single table.
不要让您的初始设计限制您将来扩展需求的能力（或使其变得困难）。
地址，因此您可以将其放入users表中 - 如果您希望他们能够存储“工作”和“家庭”，该怎么办“未来的地址，还是过去地址的历史？users.photo中，那么您必须更改数据结构以允许用户拥有个人资料照片的历史记录正如 Quassnoi 提到的，每个决策都会对性能产生影响 - 表越多意味着复杂性越高，查询速度越慢的可能性就越大。不要为了它而创建新表，而是要仔细考虑您的数据模型，因为它很快就会变得很难更改。
任何与
user实体存在严格的一对一关系、并且不太可能更改且需要历史记录（出生日期就是一个很好的例子）的值都应在表中包含核心定义。任何潜在的一对多关系（即使它们现在不是）都是它们自己的表的良好候选者。Don't allow your initial design to limit the ability (or just make it difficult) to expand your requirements in the future.
addressso you might put it in theuserstable - what if you want them to be able to store "work" and "home" addresses in future, or a history of past addresses?users.photo, then you'd have to change your data structure to allow a user to have a history of profile photosAs Quassnoi mentions, there are performance implications for each of these decisions - more tables means more complexity, and more potential for slow queries. Don't create new tables for the sake of it, but consider your data model carefully as it quickly becomes very hard to change it.
Any values that are a strict 1-to-1 relationship with a
userentity, and are unlikely to ever change and require a history for (date of birth is a good example) should go in the table with the core definition. Any potential 1-to-many relationships (even if they aren't right now) are good candidates for their own tables.