重新设计CRM中的成员实体的建议答案

【问题标题】：Suggestion for redesigning the member entity in CRM重新设计CRM中的成员实体的建议
【发布时间】：2011-08-30 23:12:04
【问题描述】：

我们有一个 CRM，其中包含一个 memebr 实体作为系统中最重要的实体。问题是它有太多的属性，这使得它不规范。以下是属性：

[MEMBER ID]
  ,[FIRST NAME]
  ,[LAST NAME],[TITLE],[ADDRESS 1],[ADDRESS 2]
  ,[ADDRESS 3],[POST CODE],[TELEPHONE HOME]
  ,[TELEPHONE WORK],[GENDER],[DURATION OF MEMBERSHIP],[START DATE]
  ,[AMOUNT PAID],[BALANCE],[STATUS],[DOB]
  ,[MONTH FEE],[ORIGINAL START DATE],[PAYMENT TYPE]
  ,[HEAR],[Interest],[NUMBER MONTH FEES]
  ,[FIRST MF DUE DATE],[LAST VISIT],[CARD NUMBER]
  ,[BANK NAME],[SORT CODE],[ACCOUNT NUMBER]
  ,[DEFINE1],[DEFINE2],[DEFINE3],[DEFINE4]
  ,[DEFINE5],[DEFINE6],[DEFINE7],[DEFINE8],[DEPENDENT]
  ,[ROLL NO],[ALLOWED VISITS],[TOTAL VISITS],[CREDIT LIMIT]
  ,[JOINING FEE],[NON VAT MONTH FEE],[PAYMENT METHOD]
  ,[CentreId],[Letter Title],[Email Address]
  ,[Vehicle Registration],[Standing Order Reference],[Notes]
  ,[Outstanding Balance],[MobileNo],[FaxNo],[Nonparent Password]
  ,[Emergency Name1],[Emergency Relation1],[Emergency HomeTel1],[Emergency WorkTel1],[Emergency MobileNo1]
  ,[Emergency Name2],[Emergency Relation2],[Emergency HomeTel2]
  ,[Emergency WorkTel2],[Emergency MobileNo2],[Doctors Name],[Doctors Tel],[Medical Info]
  ,[Password],[MethodOfContact],[Address 4],[Address 5]
  ,[Address 6],[ExtRef1],[ExtRef2],[ExtRef3],[ExtRef4],[OnMailingList],[HasChildren]
  ,[ParentMemberId],[MedicalIllness],[MedicalQuestion],[COMMENTS]
  ,[MembershipFeePaid],[JoiningFeePaid],[IsDeleted]
  ,[Pending],[Induction],[UserName]
  ,[CompanyName],[RowVer],[MembershipProductId]
  ,[Id],[EmailVerified],[ConcessionTypeId]
  ,[MemberTypeId],[Age],[Renewal_Date]

我正在考虑使这件事正常化。有什么建议吗？

【问题讨论】：

归一化和非归一化应根据数据使用情况等仔细执行。查看属性时引人注目的当然是许多编号字段，它们肯定是归一化的候选者，会给您更大的灵活性关于关联值的数量。但建议必须是特定领域的。

标签： c# .net vb.net visual-studio-2010 normalization

【解决方案1】：

数据库重构通常是一个非常有趣的过程。看看你是否可以通过 RedGate 获得SQL Refactor 的许可证。

重构的一种方法是创建一个模拟当前表结构的视图。一旦外部应用程序从视图而不是表中读取，您就可以开始重构表（然后您只需要修改视图，而不是应用程序）。当然，这对插入或更新数据没有帮助，那是另一回事:)

【讨论】：

【解决方案2】：

首先，如果字段被编号，它通常是规范化的候选者。考虑将地址详细信息移出以开始。电话号码可以在其他地方并与类型一起存储，以节省拥有这么多可能未使用的字段的需要。如果为类型指定了一个序列，地址详细信息可以遵循类似的模式（例如，您可以推导出应打印字段的顺序）。

银行详细信息是另一个候选者。

这样考虑。成员应包含与成员直接相关的详细信息仅。不是会员的银行、地址等。它应该包含他们的名字、姓氏、会员的直接属性的详细信息。

考虑查看其中一些链接以获取想法：

http://databases.about.com/od/specificproducts/a/normalization.htm

http://support.microsoft.com/?id=209534

http://ipconflict.co.uk/2009/12/29/basic-guide-to-database-normalisation-first-normal-form/

【讨论】：