数据库：拆分表
我最近读了很多关于数据库、冗余等的内容。
现在我正在构建一个用户表，它将保存所有信息 关于在我的系统中注册的用户。
用户表应包含：id(PK)、用户名、密码、电子邮件和地址（街道、 城市、邮政编码、国家）。
我是否应该拆分地址并创建另一个仅保存用户地址的表， 例如：id(PK)、街道、城市、邮政编码、国家/地区、user_id(FK)) ？ 我什至可以将邮政编码和国家/地区拆分到新表中。
这是否有意义，尤其是将邮政编码和国家/地区拆分到新表中？
干杯!
I've recently read alot about databases, redundancy, etc.
Now I'm building an users-table which will hold all informations
about the users registered at my system.
The users-table should hold: id(PK), username, password, email, and the address(street,
city, zipcode, country).
Should I split the address and create another table only holding the users-address,
like: id(PK), street, city, zipcode, country, user_id(FK)) ?
I even could split here the zipcode and country to new tables.
Does this make sense, especially the splitting of zipcode and country to a new table ?
Cheers!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
嗯，我在这里考虑了一些冗余方面的问题。
将例如国家/地区存储在单个表中不是更好吗
而不是一遍又一遍地把它写在我的用户表中？ ->冗余
Well I thought about some redundancy-aspects here.
Wouldn't it be better to store e.g. the country in a single table
instead of writing it over and over again in my users-table? -> redundancy
对于大多数情况，答案是否定的。为什么需要额外的连接来查找地址？为什么有两个具有一对一关系的表？
正如其他人所说，除非您确信性能会有所提高，否则不要让您的生活变得复杂。
For most cases the answer is no. Why have an extra join to find the address? And why have two tables with one-to-one relationship?
As other folks said, don't complicate your life unless you are sure about some performance gains.
我个人认为将这些详细信息拆分到单独的表中没有任何附加价值。
即使您不太可能经常使用地址/邮政编码，也始终可以使用
SELECT username,email..而不是SELECT *..仅选择必要的字段I personally don't see any added value on splitting these details into separated tables.
Even if you are not likely to use the address/zipcode very often, you can always select only the necessary fields using
SELECT username,email..instead ofSELECT *..您应该根据要求来执行此操作，而不是因为您可以。因此，您要么有功能需求（例如，您想要为每个用户存储多个地址），要么有想要解决的技术问题（性能、安全性等）。对我来说，后者在如此简单的表格设计中听起来不太可能，因此根据您提供的信息，我建议坚持使用单个表格。
You should do this based on a requirement, not because you can. So, either you should have a functional need (e.g., you want to store multiple addresses per user) or a technical issue that you want to solve (performance, security, etc.). To me, the latter sounds rather unlikely on such a straightforward table design, so with the information you are providing, I would suggest sticking with a single table.