我仍在扩展和开发我的应用程序。何时在主用户表中存储用户设置或信息不好？
我目前有一个35列的用户表。我搜寻了我的问题，但如果我正确或错误地对待，我仍然有点困惑。有人说用户表格其他说做关系。
除了用户名，用户名，电子邮件地址和密码外，我还存储每个用户的真实姓名，详细地址，年龄，个人资料图片名称，国家，社交网站，优惠账户（开/关）等
在我的应用程序中，每个用户都有一个配置文件页面，我查询用户表以查看用户是否存在或不是用户名（唯一），如果是我从用户表中获取我想要的而不是加入和做关系表等
我应该保持原样或更好地将用户表分成关系前。 user_details（生物，图像名称，国家等）和user_settings（高级，电子邮件通知等）？
我有我的应用程序的其他部分的关系，但你似乎无法理解为什么有些人喜欢做一个关系表来存储用户国家和其他相关信息。任何想法将不胜感激。
如果每个用户只有这些数据项中的每一个，那么我认为将其分解出来的唯一原因就是性能。就像如果每条用户记录中都挤满了50k的数据，并且90％的时间里唯一使用的是名称和密码，那么这可能会减慢操作这些记录的操作。
一般来说，除非您发现在实际操作中存在性能问题，或者有充分的理由相信会出现性能问题，否则我认为将数据库进行非规范化是一个糟糕的主意。许多数据库被严重破坏，因为“性能改进”是不必要的或者不会真正提高性能。
我有时试图打破人为理解的记录，以减少混乱。是的，如果字段较少，则更容易掌握记录中的内容。但是你必须知道还有其他的“附加”记录，如果你必须拖拽两条记录，那么当你关心它们的时候。所以一般我认为这是一个坏主意，但我不会排除它。
我认为我的用户数据库很低，我不应该分裂成关系。谢谢 – Billm
根据我的经验，你应该分开很多那些在连接表（如果你的表会有很多记录）。例如，您应该为地址信息添加一个表格，为联系人信息（电子邮件，电话，传真等）添加一个表格，以便您可以在这些表格中保留用户更改的历史记录，并且在您将只需要来自用户的原始数据（id，username，name），所以你不必从一个表中加载所有的数据。
您不需要有历史记录的其他设置（如活动/非活动，阻止，某些用户首选项），您可以保留在用户表中以便于访问。
没有正确或错误的答案，这是一个设计问题，您的设计应该反映您自己的业务需求。 – Shadow
35列是可以接受的，我要说的是，只要有必要，你应该开始将信息分解到新表中。在你的例子中，我可能会将“社交网站”存储在另一个具有1-N关系的表中，就是这样。这是因为用户可以有很多社交网站 – Borjante
是否有任何表格“大”（例如，生物，图片）？快速变化（喜欢）？ –