我正在社交网站上工作。现在我们的团队决定以非规范化的方式存储用户配置文件。所以我们的表结构就像这样
此处属性表示用户个人资料的一个字段，例如名字，姓氏，出生日期等...
和组表示一组字段的名称，例如个人详细信息，学术信息，成就等。
**
属性/组主 - 它创建 组和属性的层次结构。
**
Attribute_GroupId bigint
ParentId bigint
Attribute_GroupName nvarchar(1000)
ISAttribute bit
DisplayName nvarchar(1000)
DisplaySequence int
**
属性控制信息 - 存储哪些 必须在运行时填充控件 属性的时间以及它的时间 验证标准......
**
Attribute_ControlInfoId bigint
AttributeId bigint
ControlType nvarchar(1000)
DataType nvarchar(1000)
DefaultValue nvarchar(1000)
IsRequired bit
RegulareExpression nvarchar(1000)
**
最后属性值在哪里 每个属性，用户明智的价值观 将被存储
**
AttributeId bigint Checked
IsValueOrRefId bit Checked
Value nvarchar(MAX) Checked
ReferenceDataId bigint Checked
UserId bigint Checked
Unchecked
现在他们说我们将在属性值表上创建索引。那里也没有主键。
因为这个表中存储了大量数据。例如如果有5000万用户和30个属性，它将存储1500万条记录。在这种情况下，如果我们在表上创建索引，则不是Insert和Update语句将非常慢以及在为一个用户提取数据时。 quires也会很慢。
我认为有一个选项，而不是属性明智的值，我可以为一个用户存储一个XML记录。
所以，请有人帮我找出这个案例的最佳选择。我应该如何存储数据？
这里我不能制作硬代码表，因为管理员可以在任何时候添加新字段，所以我需要一些数据结构，我只需1-2步就可以轻松添加用户配置文件中的任何字段。
如果有人有更好的解决办法，请回复我。答案 0 :(得分：4)
你们需要一个dba！
这是其中一个EAV桌子，它会让你不顾一切！
答案 1 :(得分：4)
答案 2 :(得分：3)
查看那些突出设计选择有多糟糕的文章，以及如果您坚持使用该设计会遇到的潜在问题：
这似乎是一个相当常见的设计问题 - 对于程序员来说，使用属性/值表来解决它似乎是一个好主意 - 但从数据库性能的角度来看，它确实不是一个好主意。
此外：
现在他们说我们会创造 属性值表上的索引。那里 那里也没有主键。
正如一些SQL专家所说：“如果它没有主键，那么它就不是表格。”
您肯定需要找到一种方法来将主键放到表中 - 如果您没有可以使用的任何内容，请添加“INT IDENTITY（1,1）”类型的“ID”列它，并将主键放在该列上。你需要一把钥匙！数据库设计，第一课，前五分钟......
您需要重新考虑您的设计，并提出更聪明的内容来存储您需要的数据。