在 CRM 中重新设计成员实体的建议
本文关键字:实体 成员 CRM | 更新日期: 2023-09-27 17:57:12
我们有一个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]
我正在考虑使这件事正常化。有什么建议吗?
数据库重构通常是一个非常复杂的过程。看看你是否可以通过RedGate获得SQL重构的许可证。
重构的一种方法是创建一个模拟当前表结构的视图。一旦外部应用程序从视图而不是表中读取,您就可以开始重构表(然后您只需修改视图,而不必修改应用程序)。当然,这对插入或更新数据没有帮助,这是另一回事:)
首先,如果字段已编号,则它通常是规范化的候选者。 考虑将地址详细信息移出以用于开始。 电话号码可以在其他地方并与类型一起存储,以节省可能未使用的大量字段的需要。 如果为类型指定了一个序列,则地址详细信息可以遵循类似的模式(例如,您可以派生字段的打印顺序)。
银行详细信息是另一个候选者。
这样想。 成员应仅包含与成员直接相关的详细信息。 不是会员的银行、地址等。 它应包含其名字,姓氏,成员的直接属性的详细信息。
考虑查看以下一些链接以获取想法:
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/