我推荐而不是试图水平扩展表,这是一个操作,你应该做出有意识的决定。
相反,我建议您将值存储为名称/值对。你可以拥有特定类型的表(假设你需要一个与键配对的整数值),然后你可以将这些选择到用户的字典中。
如果您担心复制关键值,您还可以拥有一个包含关键点的表格。
例如,你有一个UserDefinedKey
表
UserDefinedKeyId (int, PK) Key (varchar(?))
-------------------------- ----------------
1 'My Website'
2 'My favorite color'
然后,你将有一个UserDefinedString
表(字符串值)
UserDefinedStringId UserId UserDefinedKeyId Value
(int, PK) (int, FK) (int, FK) (varchar(max))
------------------- --------- ---------------- --------------
1 1 1 'http://stackoverflow.com'
2 1 2 'Blue'
3 2 2 'Red'
你可能会想放置一个唯一索引在UserId
和UserDefinedKeyId
字段,以防止人们输入同一个键的多个值(如果你想要的话,有一个单独的表没有独特的公司nstraint)。
然后,当您想为用户添加一个值时,将其添加到UserDefinedKey
表中,然后将您的逻辑从该表和其他包含该值的表中取出。
垂直存储值的另一个好处是您不会浪费空间用于没有被所有用户使用的值的列。
例如,假设你把修改表,上面的属性的方法,你会得到:
UserId WebSite Color
------ ------- -----
1 http://stackoverflow.com Blue
2 (null) Red
现在,让我们说,第三个用户出现时,并增加了一个Favorite Sports Team
价值,他们是谁使用它的人只有一个,表则是这样的:
UserId WebSite Color FavoriteSportsTeam
------ ------- ----- ------------------
1 http://stackoverflow.com Blue (null)
2 (null) Red (null)
3 (null) (null) Yankees
随着用户数量和属性的增长,你有会大大增加稀疏的数据量。
现在,假设您使用的是SQL Server 2008,您可以使用sparse columns,如果您不这样做,您的表格将会变得很大,但数据量不会太多。
另外,使用稀疏列并不能消除使用data definition language (DDL)来即时更改模式非常肮脏的事实。
此外,实体框架无法使其对象模型适应新的属性;每次添加属性时,都必须将该属性添加到对象模型中,重新编译并重新部署。
采用纵向方法,它需要更多的工作,授予,但它会非常灵活,并且更有效地利用您的数据库空间。
你想要完成什么?使用表'info2',您如何计划使用EF检索数据?我假设你有一些反映底层数据库权限结构的类?您如何计划在运行时改变这些以反映对数据库的更改? – itsmatt
什么即时通讯试图完成: 一个系统,可以存储有关任何信息,用户可以添加字段或新表,以便他们的愿望,以使一个完整的动态信息存储网站 – JensB