我正在创建一个应用程序,其中有两种不同类型的用户。我是否应该将所有用户数据放在一个表中,添加一个“角色”字段来标识用户类型,还是应该为每个用户类型创建一个单独的表?每个用户类型都需要一些他们不共同共享的字段。数据库架构问题
数据库架构问题
回答
真正的答案将取决于您的下游实施。在所有的现实中,我很可能会认为你可以通过角色做一些事情来识别用户并使用该角色来控制对其他必需字段的验证。但那可能不适合你的情况。
的关键将是确定这是一个独一无二的类的情况,还是你预计未来其他角色/ usertypes将需要此解决方案。此外,是否还有其他功能与指定核心用户功能(如验证等)重复需要的功能不同。
将两个用户表拆分可能会使身份验证更加困难,例如,如果两个用户类型都通过相同的登录页。
如果差异是一列,那么可以使用Role列来将它们放置到一个表中。如果您看到一个角色需要比另一个角色更多的信息,则可以为所有用户创建一个基表,然后将有问题的角色的其他信息存储到另一个表中,并将ID作为外键返回到包含该信息的表。
一般来说,最好的设计是有很少变化的细节表,另一个表与你的第1表保存信息的主键,它经常更改外键约束。
个人而言,我有一个字段类型,他们是什么样的用户,并与其他数据识别你需要更多的细节二级表中的一个“用户”表。
然后你就可以做,只要你需要的数据表之间的简单连接,但如果你只是搜索你的主要用户表,快速扫描会快很多。
正如您所说,为用户创建一个具有不同角色的单个表 - 只有所有用户的共同属性。在创建与用户表中的1-1关系其他2个表,并且这些表中保持的属性为每个用户类型
多少列是不同的为每个用户类型?
如果你有共同的50列,每种类型都有短短两年多是截然不同的 - 那么我很可能把那些两种类型的用户到同一个表,只是让那些额外的列空。
但是,如果这些类型的用户只共享两个,三个常见的列(ID
和Name
),每个都有独立的25-50列 - 其中一些你可能想使NOT NULL
该类型用户的 - 那么我d为每个用户类型使用一个基表(只有公共属性)和两个单独的“衍生”表,引用该基表。
事实上,每个用户类型都会有不与其他类型共享的字段,因此在没有任何其他信息的情况下,单独的表格会更简单。如果您使用一个表,那么您必须为所有用户属性添加列,并用很多NULL填充表,或者将所有属性收集到某种编码的clob或blob中,这非常不关系,但是在大数据和NoSQL环境,感觉很好玩。
如果您拥有数百个用户类型而不是两个,或者您有非常具体的原因用于某种非规格化,复杂或编码的属性信息,那么两个表应该没问题。然而,对“所有用户”的查询会很混乱,所以如果你的用户角色是不同的,那么去这条路线。
如果用户可以拥有多个角色,那么其他答案已经说明过,一个包含公共数据和多个表用于角色特定数据的表格可以很好地工作。
- 1. 数据库架构问题
- 2. 数据库架构问题
- 3. 数据库架构右键问题
- 4. 数据库结构问题
- 5. 数据库架构
- 6. 数据库架构
- 7. 比较SQL Server数据库架构和Oracle数据库架构
- 8. 核心数据架构问题NSDictionary?
- 9. SAAS架构和Salesforce数据库架构
- 10. 是否有数据库架构与UpperCamelCase/lowerCamelCase什么问题?
- 11. 创建数据库架构的问题sql server 2008
- 12. Zend框架多数据库问题
- 13. 数据库架构建议
- 14. 数据库架构建议
- 15. EtherPad数据库架构?
- 16. mysql数据库表架构
- 17. 更新数据库架构
- 18. CMS数据库架构
- 19. 数据库架构建议
- 20. 税收数据库架构
- 21. 数据库架构错误
- 22. SQL数据库结构问题
- 23. mysql数据库中的结构问题
- 24. 数据库效率/结构问题
- 25. 数据库体系结构问题
- 26. EJBs - 架构问题
- 27. GCC架构问题
- 28. WCF架构问题
- 29. Sidekiq架构问题
- 30. 类架构问题