Xpoint
   [напомнить пароль]

Составные свойства объекта

Метки: [без меток]
2006-05-15 11:29:16 [обр] kuglik[досье]

В продолжение тем
Много полей vs. Много таблиц
Реализация каталога разнотипной продукции
Увеличение скорости выборки из каталога товаров
о методах хранения и доступа свойств объекта. Но в отдичие от них вопрос будет не о простых, а о составных свойствах.

Во-первых, что я подразумеваю под составными свойствами. Это такие свойства, которые не могут быть описаны одним типом данных.

Например, адрес: улица, город, индекс, страна; контактное лицо: адрес (который уже сам по себе составной), телефоны (в разных комбинациях), прочее (всё что угодно).

Рассмотрим информацию о клиенте. Есть основная информация которая расположена в таблице клиентов. Кроме того есть дополнительные простые свойсва, которые хранятся в отдельной таблице и связаны с клиентами через номер клиента и номер свойства в дополнительной таблице. На сегодняшний день в основной таблице есть два набора полей адресов (city1, city2, street1, street2 и т.д.). Так было спроектировано ещё до меня и до недавнего времени не мешало. Возникла необходимость вводить дополнительные адреса, причём заранее их количество не известно. Можно поступить как с простыми свойствами и хранить по отдельности город, улицу и т.п. как не связанные между собой данные, но тогда существенно усложняется выборка и не понятно как будут идентифицированы эти поля. Т.е. для уникальных свойств имеем таблицу описания свойств в которой им дано уникальное имя и номер. В этом же случае получается, что городов, также как и улиц может быть несколько. Не называть же их снова город1, город2. Тем более заранее не известно их возможное кол-во.

Логично было бы вынести адреса в отдельную таблицу и связываться уже с ней. Такой вариант мне нравится существенно больше. Но есть пара возражений: логика получения свойств объекта делится на не формализуемые куски. Т.е. у объекта есть основные св-ва, дополнительные простые и дополнительные составные, а составные, в свою очередь, тоже могут быть составными. Это больше похоже на внешние документы, напрмер накладные, счета и т.п., относящиеся к клиенту, но в отличие от них адрес должен таскаться за клиентом постоянно.

Как правильно организовать подобное?

спустя 20 дней [обр] Сергей Ульянов[досье]

Может я не совсем правильно понял, но все-таки.
Таблица групп свойств:

idparent_idname

Таблица самих свойств (дополнительные простые и дополнительные составные):

idgroup_idclient_idnamevalue

Соответственно у простых свойств group_id = NULL.
Здесь я привел упрощенную схему, без учита типа данных отдельного свойства.
Как видно из таблицы групп свойств, группа также может содержаться в иной группе.

Powered by POEM™ Engine Copyright © 2002-2005