具有大量查询列的表的最佳实践

Question

OK so a little background...being a programmer-first with limited DB design experience, I made a couple newb mistakes, namely a unified code lookup table and an EAV implementation on another table. I'm currently trying to rework those into more of a traditional RDBMS, but I want to make absolute sure I'm doing it right this time.

My big problem table is a large table of 150 or so columns that contains client data we have to report to the State. Most of this data uses state-specific lookup values, so with my current design plan, I will end up with 75-100 FK's to different lookup tables.

Now we will need to do reporting on this data, so I will need to be able to easily reference both the code values & descriptions for each attribute. The only option I can think is to create two seperate views (or perhaps one massive view) that will flatten the data out for me. It seems like a fairly tedious process to create and maintain, especially given that the data collected can change. I'm ok doing the legwork if this is the standard practice, but I'm curious is there is a better method I'm just unaware of.

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

Answer 1

If you're mostly concerned about reporting, you may wish to construct a 'reporting' or 'analytics' database (usually performed with an ETL, or Extact/Transform/Load , tool). These databases are often selectively de-normalized - for instance, instead of having fk references to a 'gender' code table, you'd have 'Male' in your reporting table. The actual degree varies as necessary, and should probably be presented through a view, until there are specific performance-level problems.

However, for day-to-day work, such as what your 'live' data looks like, you'll want a normalized approach.
I'm assuming the Chart table has something like visitedOn , collectingCaregiverId , etc. Anything important, which is (almost) always collected, and 'static', should go in this table. Race, for example, isn't likely to change during the course of a visit (and arguably should be part of the static patient record).
Anything which is somewhat 'sparse', but often collected, probably needs to go in a 'related' table. Something like:

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)

... and so on.
Anything which is completely optional, and rarely collected, may end up in an EAV. Note that there may be more than one of these setups, based on 'area'; also, these should also be 'coded out', as much as possible:

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)

You'd have to re-assemble this for reporting, of course. This is the inherent 'weakness' of a 'transactional' database - the data quality is usually decent, and updates are simple, but sticking it all together in a 'readable' format can be painful. Construct views where possible, to stick relevant areas together.

Answer 2

I think the views, possibly smaller views, is the best thing you can do. How many? Depending on your situation and requirements. You may create a view for each report or group of your reports. It all depends... This is what I think and would do. FYI - I'm not a DBA, but developer.