具有大量查找列的表的最佳实践答案

【问题标题】：Best practice for tables with large number of lookup columns具有大量查找列的表的最佳实践
【发布时间】：2013-02-08 08:18:07
【问题描述】：

好吧，所以有一点背景...作为一个程序员优先的数据库设计经验有限，我犯了几个新手错误，即统一代码查找表和另一个表上的 EAV 实现。我目前正在尝试将它们改造成更传统的 RDBMS，但我想确保这次我做对了。

我的大问题表是一个包含 150 列左右的大表，其中包含我们必须向州报告的客户数据。这些数据中的大部分使用特定于状态的查找值，因此根据我当前的设计计划，我最终会得到 75-100 个 FK 到不同的查找表。

现在我们需要对这些数据进行报告，因此我需要能够轻松引用每个属性的代码值和描述。我能想到的唯一选择是创建两个单独的视图（或者可能是一个大型视图），这将为我整理数据。创建和维护这似乎是一个相当乏味的过程，尤其是考虑到收集的数据可能会发生变化。如果这是标准做法，我可以做腿部工作，但我很好奇是否有更好的方法我只是不知道。

USE [TestCompany]
GO

/****** Object:  Table [CLI].[AttributesTable]    Script Date: 02/07/2013 15:01:34 ******/
SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

SET ANSI_PADDING ON
GO

CREATE TABLE [CLI].[AttributesTable](
    [AttributesTableID] [int] NOT NULL,
    [ChartID] [int] NOT NULL,
    [AdmitCounty] [int] NULL,
    [AdmissionReason] [int] NULL,
    [Gender] [int] NULL,
    [Race] [int] NULL,
    [Occupation] [int] NULL,
    [MaritalStatus] [int] NULL,
    [Education] [int] NULL,
    [SpecialEducation] [int] NULL,
    [Impairment] [int] NULL,
    [Hispanic] [int] NULL,
    [HearingStatus] [int] NULL,
    [ExpectedPaysource] [int] NULL,
    [PublicAssistance] [int] NULL,
    [Dietary] [int] NULL,
    [EmploymentStatus] [int] NULL,
    [LivingArrangements] [int] NULL,
    [IncomeSource] [int] NULL,
    [LegalStatus] [int] NULL,
    [CommitType] [int] NULL,
    [EnrolledInSchool] [nchar](10) NULL,
    [GradePointAverage] [int] NULL,
    [EducationProgram] [int] NULL,
    [HIV] [int] NULL,
    [SelfHelpPrograms] [int] NULL,
    [MediationPrescribed] [int] NULL,
    [DischargeReason] [int] NULL,
    [DischargeReferral] [int] NULL,

 CONSTRAINT [PK_AttributesTable] PRIMARY KEY CLUSTERED 
(
    [AttributesTableID] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]

GO

SET ANSI_PADDING OFF
GO

ALTER TABLE [CLI].[AttributesTable]  WITH CHECK ADD  CONSTRAINT [FK_AdmissionReason_Code] FOREIGN KEY([AdmissionReason])
REFERENCES [LKP].[AdmissionReasonCode] ([CodeID])
GO

ALTER TABLE [CLI].[AttributesTable] CHECK CONSTRAINT [FK_AdmissionReason_Code]
GO

ALTER TABLE [CLI].[AttributesTable]  WITH CHECK ADD  CONSTRAINT [FK_CommitType_Code] FOREIGN KEY([CommitType])
REFERENCES [LKP].[CommitTypeCode] ([CodeID])
GO

ALTER TABLE [CLI].[AttributesTable] CHECK CONSTRAINT [FK_CommitType_Code]
GO

ALTER TABLE [CLI].[AttributesTable]  WITH CHECK ADD  CONSTRAINT [FK_Dietary_Code] FOREIGN KEY([Dietary])
REFERENCES [LKP].[DietaryCode] ([CodeID])
GO

ALTER TABLE [CLI].[AttributesTable] CHECK CONSTRAINT [FK_Dietary_Code]
GO

ALTER TABLE [CLI].[AttributesTable]  WITH CHECK ADD  CONSTRAINT [FK_DischargeReason_Code] FOREIGN KEY([DischargeReason])
REFERENCES [LKP].[DischargeReasonCode] ([CodeID])
GO

ALTER TABLE [CLI].[AttributesTable] CHECK CONSTRAINT [FK_DischargeReason_Code]
GO

ALTER TABLE [CLI].[AttributesTable]  WITH CHECK ADD  CONSTRAINT [FK_DischargeReferral_Code] FOREIGN KEY([DischargeReferral])
REFERENCES [LKP].[DischargeReferralCode] ([CodeID])
GO

ALTER TABLE [CLI].[AttributesTable] CHECK CONSTRAINT [FK_DischargeReferral_Code]
GO

ALTER TABLE [CLI].[AttributesTable]  WITH CHECK ADD  CONSTRAINT [FK_AttributesTable_Chart] FOREIGN KEY([ChartID])
REFERENCES [CLI].[Chart] ([ChartID])
GO

ALTER TABLE [CLI].[AttributesTable] CHECK CONSTRAINT [FK_AttributesTable_Chart]
GO

ALTER TABLE [CLI].[AttributesTable]  WITH CHECK ADD  CONSTRAINT [FK_AttributesTable_CommitTypeCode] FOREIGN KEY([CommitType])
REFERENCES [LKP].[CommitTypeCode] ([CodeID])
GO

ALTER TABLE [CLI].[AttributesTable] CHECK CONSTRAINT [FK_AttributesTable_CommitTypeCode]
GO

ALTER TABLE [CLI].[AttributesTable]  WITH CHECK ADD  CONSTRAINT [FK_AttributesTable_EducationCode] FOREIGN KEY([Education])
REFERENCES [LKP].[EducationCode] ([CodeID])
GO

ALTER TABLE [CLI].[AttributesTable] CHECK CONSTRAINT [FK_AttributesTable_EducationCode]
GO

ALTER TABLE [CLI].[AttributesTable]  WITH CHECK ADD  CONSTRAINT [FK_AttributesTable_EducationProgramIndicatorCode] FOREIGN KEY([EducationProgram])
REFERENCES [LKP].[EducationProgramIndicatorCode] ([CodeID])
GO

ALTER TABLE [CLI].[AttributesTable] CHECK CONSTRAINT [FK_AttributesTable_EducationProgramIndicatorCode]
GO

ALTER TABLE [CLI].[AttributesTable]  WITH CHECK ADD  CONSTRAINT [FK_AttributesTable_EmploymentStatusCode] FOREIGN KEY([EmploymentStatus])
REFERENCES [LKP].[EmploymentStatusCode] ([CodeID])
GO

ALTER TABLE [CLI].[AttributesTable] CHECK CONSTRAINT [FK_AttributesTable_EmploymentStatusCode]
GO

ALTER TABLE [CLI].[AttributesTable]  WITH CHECK ADD  CONSTRAINT [FK_AttributesTable_GenderCode] FOREIGN KEY([Gender])
REFERENCES [LKP].[GenderCode] ([CodeID])
GO

ALTER TABLE [CLI].[AttributesTable] CHECK CONSTRAINT [FK_AttributesTable_GenderCode]
GO

ALTER TABLE [CLI].[AttributesTable]  WITH CHECK ADD  CONSTRAINT [FK_AttributesTable_GPACode] FOREIGN KEY([GradePointAverage])
REFERENCES [LKP].[GPACode] ([CodeID])
GO

ALTER TABLE [CLI].[AttributesTable] CHECK CONSTRAINT [FK_AttributesTable_GPACode]
GO

ALTER TABLE [CLI].[AttributesTable]  WITH CHECK ADD  CONSTRAINT [FK_AttributesTable_HearingStatusCode] FOREIGN KEY([HearingStatus])
REFERENCES [LKP].[HearingStatusCode] ([CodeID])
GO

ALTER TABLE [CLI].[AttributesTable] CHECK CONSTRAINT [FK_AttributesTable_HearingStatusCode]
GO

ALTER TABLE [CLI].[AttributesTable]  WITH CHECK ADD  CONSTRAINT [FK_AttributesTable_HispanicCode] FOREIGN KEY([Hispanic])
REFERENCES [LKP].[HispanicCode] ([CodeID])
GO

ALTER TABLE [CLI].[AttributesTable] CHECK CONSTRAINT [FK_AttributesTable_HispanicCode]
GO

ALTER TABLE [CLI].[AttributesTable]  WITH CHECK ADD  CONSTRAINT [FK_AttributesTable_HIVTestCode] FOREIGN KEY([HIV])
REFERENCES [LKP].[HIVTestCode] ([CodeID])
GO

ALTER TABLE [CLI].[AttributesTable] CHECK CONSTRAINT [FK_AttributesTable_HIVTestCode]
GO

ALTER TABLE [CLI].[AttributesTable]  WITH CHECK ADD  CONSTRAINT [FK_AttributesTable_ImpairmentCode] FOREIGN KEY([Impairment])
REFERENCES [LKP].[ImpairmentCode] ([CodeID])
GO

ALTER TABLE [CLI].[AttributesTable] CHECK CONSTRAINT [FK_AttributesTable_ImpairmentCode]
GO

ALTER TABLE [CLI].[AttributesTable]  WITH CHECK ADD  CONSTRAINT [FK_AttributesTable_IncomeSourceCode] FOREIGN KEY([IncomeSource])
REFERENCES [LKP].[IncomeSourceCode] ([CodeID])
GO

ALTER TABLE [CLI].[AttributesTable] CHECK CONSTRAINT [FK_AttributesTable_IncomeSourceCode]
GO

ALTER TABLE [CLI].[AttributesTable]  WITH CHECK ADD  CONSTRAINT [FK_AttributesTable_LegalStatusCode] FOREIGN KEY([LegalStatus])
REFERENCES [LKP].[LegalStatusCode] ([CodeID])
GO

ALTER TABLE [CLI].[AttributesTable] CHECK CONSTRAINT [FK_AttributesTable_LegalStatusCode]
GO

ALTER TABLE [CLI].[AttributesTable]  WITH CHECK ADD  CONSTRAINT [FK_AttributesTable_LivingArrangementCode] FOREIGN KEY([LivingArrangements])
REFERENCES [LKP].[LivingArrangementCode] ([CodeID])
GO

ALTER TABLE [CLI].[AttributesTable] CHECK CONSTRAINT [FK_AttributesTable_LivingArrangementCode]
GO

ALTER TABLE [CLI].[AttributesTable]  WITH CHECK ADD  CONSTRAINT [FK_AttributesTable_MaritalStatusCode] FOREIGN KEY([MaritalStatus])
REFERENCES [LKP].[MaritalStatusCode] ([CodeID])
GO

ALTER TABLE [CLI].[AttributesTable] CHECK CONSTRAINT [FK_AttributesTable_MaritalStatusCode]
GO

ALTER TABLE [CLI].[AttributesTable]  WITH CHECK ADD  CONSTRAINT [FK_AttributesTable_MedicationPrescribedCode] FOREIGN KEY([MediationPrescribed])
REFERENCES [LKP].[MedicationPrescribedCode] ([CodeID])
GO

ALTER TABLE [CLI].[AttributesTable] CHECK CONSTRAINT [FK_AttributesTable_MedicationPrescribedCode]
GO

ALTER TABLE [CLI].[AttributesTable]  WITH CHECK ADD  CONSTRAINT [FK_AttributesTable_PaySourceCode] FOREIGN KEY([ExpectedPaysource])
REFERENCES [LKP].[PaySourceCode] ([CodeID])
GO

ALTER TABLE [CLI].[AttributesTable] CHECK CONSTRAINT [FK_AttributesTable_PaySourceCode]
GO

【问题讨论】：

我们可以拿些样品吗？它可以让我们更好地为您提供建议。显然，首先酌情匿名。而你所在的公司并没有雇佣任何真正的 DBA？
好的，我会将部分数据库脚本附加到我的原始帖子中。我们的规模不是很大，但他们曾一度将一名 DBA 外包给我们，就如何最好地规范化我们的表提供建议。也许我们只是弄错了，因为她对我想出的 EAV 和查找模式没有任何问题。我当时认为它相当聪明：|。
请注意，EAV 可以是一个可接受的解决方案......它通常不是；大多数数据往往是相关的。诸如医学症状之类的东西通常符合条件 - 有大量的症状，但大多数患者只有少数几个 - 任何时候你（大部分）都有稀疏的属性。
...有趣的是我应该提到“医疗系统”...我个人对带有“table”后缀的表格有疑问（如果您将其换成视图会发生什么？），并且在复数意义。这个表和Chart是什么关系（主键可以是chartId）？为什么你有种族和西班牙裔的专栏？其中一些信息应该多久更改一次？还是患者图表的“历史”？哪些属性是相关的（可以移动到自己的表中）？您希望如何查询这些信息？为什么EnrolledInSchool 不是 fk 引用？
哈，它实际上并没有被称为“AttributesTable”，但另一个名字对你来说没有任何意义：P。 “种族”和“西班牙裔”实际上有不同的查找列……为什么我不知道，但这不在我们的掌控之中。 ChartID 也有点用词不当...我也将其“匿名化”了，基本上我们必须为客户多次报告此数据，以绘制进度图表。

标签： sql rdbms

【解决方案1】：

如果您最关心报告，您可能希望构建一个“报告”或“分析”数据库（通常使用 ETL 或 Extact/Transform/Load 工具执行）。这些数据库通常会选择性地去规范化——例如，您的报告表中不会有对“性别”代码表的 fk 引用，而是'Male'。实际程度根据需要变化，并且可能应该通过视图呈现，直到出现特定的性能级别问题。

但是，对于日常工作，例如您的“实时”数据是什么样的，您需要一种标准化的方法。
我假设Chart 表有类似visitedOn、collectingCaregiverId 等的东西。任何重要的东西，（几乎）总是收集和“静态”，都应该放在这个表中.例如，种族在就诊过程中不太可能发生变化（并且可以说应该是静态患者记录的一部分）。
任何有点“稀疏”但经常收集的东西，可能需要放入“相关”表中。比如：

Education_Status
=================
chart_id  -- fk reference to chart.id
school  -- fk reference to attribute-specific code table
program  -- see above
grade_point_average  -- DECIMAL(3, 2)

...等等。
任何完全可选的，很少收集的，都可能最终出现在 EAV 中。请注意，基于“区域”，这些设置可能不止一种；此外，这些也应尽可能“编码”：

Unusual_Symptom_Type
======================
id  -- autogen
name  -- varchar(20) (eg - 'Turning Blue', 'Allergic to Oxygen', etc)

Unusual_Symptom
====================
chart_id  -- fk reference to chart.id
unusual_symptom_type_id  -- fk reference to unusual_symptom_type.id
note -- varchar(20) (eg - 'Afternoon Sky', 'Combusts', etc)

当然，您必须重新组装它以进行报告。这是“事务性”数据库固有的“弱点”——数据质量通常不错，更新也很简单，但将它们以“可读”格式组合在一起可能会很痛苦。尽可能构建视图，将相关区域连接在一起。

【讨论】：

感谢您的帮助和建议！我们已经考虑将更多静态数据移动到单独的数据库中。我知道在没有看到我们所有的表格和业务逻辑的情况下很难给出建议，但我想我明白你所说的大致范围。

【解决方案2】：

我认为视图，可能是较小的视图，是你能做的最好的事情。多少？根据您的情况和要求。您可以为每个报告或报告组创建一个视图。这一切都取决于...这是我的想法和将做的。仅供参考 - 我不是 DBA，而是开发人员。

【讨论】：