Предложение по изменению структуры участника в CRM - PullRequest
0 голосов
/ 23 мая 2011

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

Я думал о нормализации этой вещи.Есть предложения?

Ответы [ 2 ]

1 голос
/ 24 мая 2011

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

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

0 голосов
/ 23 мая 2011

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

Банковские реквизиты - другой кандидат.

Считай это так. Участник должен содержать детали, которые имеют непосредственное отношение к члену только . Не банк, адрес и т. Д. В нем должны быть указаны его имя, фамилия, прямые атрибуты участника.

Рассмотрите некоторые из этих ссылок для идеи:

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/

...