我正在尝试创建一个用户可以注册并创建配置文件的站点，因此我在数据库中使用两个MySQL表，例如users和user_profile。
users表格中有一个名为auto increment primary key的{{1}}。
user_id表具有相同的user_profile primary key，但它不是user_id。
* 请参阅说明为什么我有多个表格。
当用户注册时，注册表单中的数据会插入到用户中，然后auto increment会输入last_insert_id()表的user_id字段。我使用交易来确保这种情况始终发生。
我的问题是，这是不好的做法吗？
我应该为user_profile表格unique auto increment primary key，即使一个用户只能拥有一个个人资料吗？
创建这样的数据库可能还有其他缺点吗？
如果有人能解释为什么这是一个问题或者它没关系，我会很感激，我想确保我的数据库尽可能高效。
注意：我正在为user和user_profile使用单独的表，因为user_profile包含可能为null的字段，并且由于数据显示在公共上，因此将被请求远远超过用户表轮廓。
也许这也是不好的做法，应该把它们集中在一张桌子上？
答案 0 :(得分：11)
我发现这是一个很好的方法，如果你使用外键关系，我会给予奖励积分，最好在从用户表中删除用户时级联。
将一个表中的核心用户数据和另一个表中的选项配置文件数据分开 - 良好的工作。没有什么比这更加令人烦恼的了50场空白的90％空值。
答案 1 :(得分：1)
通常不赞成，但只要你能提供1对1关系的推理，我相信它很好。
当我有数百列时，我已经使用过它们（将它们拆分成单独的表更合乎逻辑） 或者我需要一个更薄的表来加速全扫描
在你的情况下，我会使用一个表并创建几个视图。
请参阅：http://dev.mysql.com/doc/refman/5.0/en/create-view.html
一般来说，单表方法更合乎逻辑，更快捷，更简单，占用空间更少。
答案 2 :(得分：0)
我不认为这是一种不好的做法。有时它非常有用，特别是如果您希望一个类处理身份验证，而不是加载所有配置文件数据。然后，您可以修改身份验证的工作方式，构建Web服务等，而不必担心维护有关配置文件信息的数据结构，这些信息可能会随着项目的发展而发生变化。
答案 3 :(得分：0)
这是非常好的做法。
正是编写良好的，模块化的，规范化的关系数据库结构的核心。