Блог

Главная - Вопросы по программированию - Предложение по редизайну объекта-участника в CRM

Предложение по редизайну объекта-участника в CRM

#c# #.net #vb.net #visual-studio-2010 #normalization

#c# #.net #vb.net #visual-studio-2010 #нормализация

Вопрос:

У нас есть 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]

я думал о том, чтобы нормализовать эту ситуацию. Есть какие-нибудь предложения?

Комментарии:

1. Нормализацию и денормализацию следует выполнять осторожно в зависимости от использования данных и т.д. При взгляде на атрибуты, конечно, бросается в глаза множество пронумерованных полей, которые, безусловно, являются кандидатами на нормализацию и предоставили бы вам большую гибкость в отношении количества связанных значений. Но рекомендации обязательно зависят от домена.

Ответ №1:

Рефакторинг базы данных часто является довольно трудоемким процессом. Посмотрите, сможете ли вы получить лицензию на рефакторинг SQL от RedGate.

Один из подходов к рефакторингу заключается в создании представления, имитирующего текущую структуру таблицы. Как только внешние приложения начнут считывать данные из представления, а не из таблицы, вы можете начать рефакторинг таблиц (и тогда вам нужно будет изменить только представление, а не приложения). Конечно, это не помогает при вставке или обновлении данных, это уже другая история 🙂

Ответ №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/