Модераторы: LSD
  

Поиск:

Ответ в темуСоздание новой темы Создание опроса
> Изменяемые свойства объектов (товаров) 
V
    Опции темы
isergey
Дата 9.7.2009, 17:50 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Новичок



Профиль
Группа: Участник
Сообщений: 30
Регистрация: 28.5.2008

Репутация: нет
Всего: нет



Наверное моя проблема стара, и скорее всего она EAV, но все же я спрошу.
Итак, задача - в интернет магазине есть товары, у этих товаров есть свойства. По этим свойствам происходит фильтрация. Проблема в том, что заказчик хочет иметь возможность добавлять новый тип товара со своим набором свойств (допустим будет форма "создать тип товара с набором характеристик").
Допустим, он торговал сотовыми телефонами и вдруг решил торговать, ну допустим, картошкой smile Понятно, что кроме названия, веса smile и стоимости их мало что объединяет. В связи с этим возникает проблема хранения свойств и их добавления.

Варианты моего видения решения этой проблемы:
1) Есть 3 таблицы: объектов ,  таблица свойств объектов (номер объекта, идентификатор свойства, значение свойства), в которой одному объекту сопоставляется несколько свойств) есть таблица, ну и третья таблица - справочник свойств.

В принципе такая система имеет право на существование, но существенным недостатком такого подхода, думаю,  таблица свойств объектов (которая будет содержать на порядок больше записей чем объектов) и высокий риск нарушить целостность данных (мало ли изменится идентификатор объектов). И что будет с быстродействием?

2) Тут уже приходится модифицировать саму базу. Т.е. при создании нового типа товара, создается новая таблица объектов ( допустим таблица "картошка"), в которой будут содержаться объекты. Такой вариант вполне возможен, но если у объекта захотят изменить количество свойств? И это не одна проблема.

3) Хранение свойств, например, в XML. А как осуществлять фильтрацию объектов? А как работают с XML разне СУБД? Допустим, нужно посчитать количество картофелин диаметр которых > 5 см?

Еще раз повторюсь, может быть эта проблема не стояла бы так остро, если бы заказчик не хотел самостоятельно изменять и добавлять свойства. 

Поделитесь своим опытом в решении данной проблемы.
PM MAIL   Вверх
former
Дата 9.7.2009, 21:27 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


MEMS Expert
***


Профиль
Группа: Завсегдатай
Сообщений: 1166
Регистрация: 1.3.2006
Где: Россия

Репутация: нет
Всего: 17



Цитата(isergey @  9.7.2009,  17:50 Найти цитируемый пост)
1) Есть 3 таблицы: объектов ,  таблица свойств объектов (номер объекта, идентификатор свойства, значение свойства), в которой одному объекту сопоставляется несколько свойств) есть таблица, ну и третья таблица - справочник свойств.

Я за данный вариант. Реализовывал подобным образом в одной информационной системе. Только вместо товаров были датчики различных производителей и типов, с различным набором характеристик.
Цитата(isergey @  9.7.2009,  17:50 Найти цитируемый пост)
и высокий риск нарушить целостность данных (мало ли изменится идентификатор объектов).

??? Это же нарушение бизнес правил в ходе проектирования.
Цитата(isergey @  9.7.2009,  17:50 Найти цитируемый пост)
И что будет с быстродействием?

Проиндексировать и все будет в порядке. А если еще и кеш задействовать!
Цитата(isergey @  9.7.2009,  17:50 Найти цитируемый пост)
2) Тут уже приходится модифицировать саму базу. Т.е. при создании нового типа товара, создается новая таблица объектов ( допустим таблица "картошка"), в которой будут содержаться объекты. Такой вариант вполне возможен, но если у объекта захотят изменить количество свойств? И это не одна проблема.

Все объекты БД должны быть созданы на этапе проектирования. Крайний случай.
Цитата(isergey @  9.7.2009,  17:50 Найти цитируемый пост)
3) Хранение свойств, например, в XML. А как осуществлять фильтрацию объектов? А как работают с XML разне СУБД? Допустим, нужно посчитать количество картофелин диаметр которых > 5 см?

Думаю, что нет.



--------------------
Достаточно снизить уровень мышления, чтобы иные почувствовали почву под ногами.
PM MAIL   Вверх
LSD
Дата 10.7.2009, 12:27 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Leprechaun Software Developer
****


Профиль
Группа: Модератор
Сообщений: 15718
Регистрация: 24.3.2004
Где: Dublin

Репутация: 24
Всего: 538



Либо 1 либо 3 вариант, все зависит от СУБД (сможет ли она нормально работать с XML) и от конкретной задачи.

Например если будет что-то наподобие Яндекс.Маркета, где обмен данными идет в XML, то возможно 3 вариант будет предпочтительней. С другой стороны, если внутри приложения работа идет с объектами а не с XML, то не очень логично будет пред записью в БД перегонять данные в XML, а при чтении из БД парсить XML.


--------------------
Disclaimer: this post contains explicit depictions of personal opinion. So, if it sounds sarcastic, don't take it seriously. If it sounds dangerous, do not try this at home or at all. And if it offends you, just don't read it.
PM MAIL WWW   Вверх
Zloxa
Дата 10.7.2009, 12:52 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Чо?
****


Профиль
Группа: Завсегдатай
Сообщений: 3473
Регистрация: 12.9.2008

Репутация: 11
Всего: 161



Вариант 1) Ты верно оценил риски. 
1.1)Самый большой риск - рассогласование данных. Однако справочник товаров весьма редко редактируется и уж тем более в многопользовательском режиме. Если ты сериализуешь доступ пользователей на редактирование по товару(один товар(и его аттрибуты) в один момент времени может изменять лишь один пользователь) и доступ на редактирование по свойству (справочник своейсв и свойство товаров в один момент времени может измеять лишь один пользователь.Особенно это касается свойств, значения которых задаются списком), думаю вполне можно будет избежать рассогласования, а вероятность дедлока бесконечно низка. Удаление товаров можно запретить(пользователь может помечать на удаление, удаление производится ночным батчем в монопольном режиме).
1.2) Производительность. Показать справочник товаров списком, со всеми определенными пользователями свойствами - практически не реально. Потому избавить пользователей от такой возможности - список определенных пользователем свойств показывать только для одного товара. Можно, конечно, сделать и динамическое формирование запроса, который будет формироваться в зависимости от списка свойств, который определил пользователь. Но контролировать план выполнения этого запроса на этапе проектирования нельзя, от того, лучше таки пользователя избавить от этой очевидно необходимой возможности.
1.3) Для того чтобы определяемое пользователем свойство влияло на бизнес логику приложения, необходима доработка приложения. В виду этого, организация хранения таким способом свойств возможна только для свойств, не влияющих на бизнес логику. Свойтсва же влияющие на бизнес логику лучше хранить способом 2). Как раз таки изза тогО, что определяемые пользователем свойства "ни на что" не влияют, еще очень велик риск, что пользователи будут весьма пофигистично относиться к ведению этих свойств, что очень обидно, ибо для реализации этой возможности придется затратить не мало каллорий.
Вариант 2) ИМХО Лучший вариант. Однако если заказчик не пробиваем - не канает ;)
Вариант 3) Разные СУБД с XML работают очень по разному. Если платформа БД не определена, думаю следует отказаться от этого варианта.

МОЕ ИМХО.
Любое стремление к универсальности - следствие недостаточного понимания конечных условий эксплуатации. Типа мы тут заложим возможность, а далее, додумаем. Любая же гибкость достигается потерей прочности. Я понимаю такое стремление у производителей тиражных продуктов. Разработчик заведомо не знает потребителя, оттого гибкость продукта расшираяет список потенциальных потребителей. Однако желания универсализации в индивидуальных решениях мне не понятно. Это дорого и не практично. 

Это сообщение отредактировал(а) Zloxa - 10.7.2009, 12:56


--------------------
Достоверно известно, что 89% людей доверяют статистике взятой с потолка smile
PM   Вверх
former
Дата 13.7.2009, 14:18 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


MEMS Expert
***


Профиль
Группа: Завсегдатай
Сообщений: 1166
Регистрация: 1.3.2006
Где: Россия

Репутация: нет
Всего: 17



Цитата(Zloxa @  10.7.2009,  12:52 Найти цитируемый пост)
Любое стремление к универсальности - следствие недостаточного понимания конечных условий эксплуатации. Типа мы тут заложим возможность, а далее, додумаем. Любая же гибкость достигается потерей прочности. Я понимаю такое стремление у производителей тиражных продуктов. Разработчик заведомо не знает потребителя, оттого гибкость продукта расшираяет список потенциальных потребителей. Однако желания универсализации в индивидуальных решениях мне не понятно. Это дорого и не практично. 

Уважаемый Zloxa!
В большей степени я с Вами согласен. Однако, в своей практике, я пару раз сталкивался с ситуацией, когда заказчик говорит, что у него сейчас нет таких данных, но, возможно, они появятся в будущем и их нужно будет вносить или появятся другие данные и потребуется реструктуризация. И тут приходится искать компромисс между универсальностью/гибкостью и  "потерей прочности".


--------------------
Достаточно снизить уровень мышления, чтобы иные почувствовали почву под ногами.
PM MAIL   Вверх
LSD
Дата 13.7.2009, 17:52 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Leprechaun Software Developer
****


Профиль
Группа: Модератор
Сообщений: 15718
Регистрация: 24.3.2004
Где: Dublin

Репутация: 24
Всего: 538



Цитата(Zloxa @  10.7.2009,  12:52 Найти цитируемый пост)
Любое стремление к универсальности - следствие недостаточного понимания конечных условий эксплуатации. Типа мы тут заложим возможность, а далее, додумаем. Любая же гибкость достигается потерей прочности. Я понимаю такое стремление у производителей тиражных продуктов. Разработчик заведомо не знает потребителя, оттого гибкость продукта расшираяет список потенциальных потребителей. Однако желания универсализации в индивидуальных решениях мне не понятно. Это дорого и не практично. 

И как ты предлагаешь реализовывать что нибудь наподобие Яндекс.Маркета?


--------------------
Disclaimer: this post contains explicit depictions of personal opinion. So, if it sounds sarcastic, don't take it seriously. If it sounds dangerous, do not try this at home or at all. And if it offends you, just don't read it.
PM MAIL WWW   Вверх
Zloxa
Дата 13.7.2009, 22:30 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Чо?
****


Профиль
Группа: Завсегдатай
Сообщений: 3473
Регистрация: 12.9.2008

Репутация: 11
Всего: 161



Цитата(LSD @  13.7.2009,  17:52 Найти цитируемый пост)
нибудь наподобие Яндекс.Маркета

Да, прошу прощения, забываю, что помимо ЕРП, бывают еще и ЕШопы ;)
Для чего нить "на поподбие", Метод 1 таки предпочтительнее по причинам:
1) Изменение схемы данных(реализация способом 2) требует прекращения обслуживания пользователей. Пусть кратковременного, но все равно может нанести имиджевый ущерб.
2) На сколько я понял, там нет проблемы конкурентной модификации атрибутов справочника, партнеры скорее всего выставляются в оговоренном формате, а накат данных производится по регламенту, исключающему рассогласование данных, т.е. самый основной риск(1.1) здесь полностью вырожден.

UPD.
Однако, все же, "Чтото вроде" Яндыкс-Маркета, это скорее исключение нежели правило. По кр. мере я намного чаще встречаюсь с ситуацией, когда нагороженный огород против alter table add column не имеет приемуществ, лишь недостатки.

UPD2
Полазив еще по указанному ресурсу, пришел к выводу, что отнюдь не факт что "звуковые карты" и "видоекарты" это суть одна таблица. По крайней мере ни одного представления, где комплектующие шли бы в одном списке (за исключением результата fulltext поиска) где можно было бы отобрать одновременно и звуковухи и видюхи, по общему набору аттрибутов, я не нашел. Ну и в чем тогда целесообразность объединения их в одну сущность с гибким набором атрибутов?

Это сообщение отредактировал(а) Zloxa - 13.7.2009, 23:26


--------------------
Достоверно известно, что 89% людей доверяют статистике взятой с потолка smile
PM   Вверх
LSD
Дата 14.7.2009, 18:19 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Leprechaun Software Developer
****


Профиль
Группа: Модератор
Сообщений: 15718
Регистрация: 24.3.2004
Где: Dublin

Репутация: 24
Всего: 538



1. Я говорил исключительно про:
Цитата(Zloxa @  10.7.2009,  12:52 Найти цитируемый пост)
Любое стремление к универсальности - следствие недостаточного понимания конечных условий эксплуатации. Типа мы тут заложим возможность, а далее, додумаем.


2. Ты же понимаешь, что за DDL в продакшн базе дба бъют сильно и больно smile 
И если Яндекс может себе позволить содержать штат админов, которые на каждую новую категорию будут создавать таблицу, добавлять поле и т.п. То большинство компаний - нет.


--------------------
Disclaimer: this post contains explicit depictions of personal opinion. So, if it sounds sarcastic, don't take it seriously. If it sounds dangerous, do not try this at home or at all. And if it offends you, just don't read it.
PM MAIL WWW   Вверх
Zloxa
Дата 14.7.2009, 22:55 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Чо?
****


Профиль
Группа: Завсегдатай
Сообщений: 3473
Регистрация: 12.9.2008

Репутация: 11
Всего: 161



Цитата(LSD @  14.7.2009,  18:19 Найти цитируемый пост)
2. Ты же понимаешь, что за DDL в продакшн базе дба бъют сильно и больно smile 

И это достаточное основания отказаться от словаря метаданных СУБД и городить свой огород, который изначально будет выполнять те же функции только заметно хуже?
Цитата(LSD @  14.7.2009,  18:19 Найти цитируемый пост)
То большинство компаний - нет. 

Хочуны заказчкиов, это основание ;) И в этом контексте EAV это компромиссное решение, не правильное.


--------------------
Достоверно известно, что 89% людей доверяют статистике взятой с потолка smile
PM   Вверх
LSD
Дата 15.7.2009, 14:19 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Leprechaun Software Developer
****


Профиль
Группа: Модератор
Сообщений: 15718
Регистрация: 24.3.2004
Где: Dublin

Репутация: 24
Всего: 538



Цитата(Zloxa @  14.7.2009,  22:55 Найти цитируемый пост)
И это достаточное основания отказаться от словаря метаданных СУБД и городить свой огород, который изначально будет выполнять те же функции только заметно хуже?

Он:
1. проще
2. ориентирован на конкретную задачу, а значит справляется с ней лучше
3. транзакционен и поддерживается механизмами обеспечения целостности СУБД


--------------------
Disclaimer: this post contains explicit depictions of personal opinion. So, if it sounds sarcastic, don't take it seriously. If it sounds dangerous, do not try this at home or at all. And if it offends you, just don't read it.
PM MAIL WWW   Вверх
Zloxa
Дата 15.7.2009, 14:41 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Чо?
****


Профиль
Группа: Завсегдатай
Сообщений: 3473
Регистрация: 12.9.2008

Репутация: 11
Всего: 161



Цитата(LSD @  15.7.2009,  14:19 Найти цитируемый пост)
Он:
1. проще
2. ориентирован на конкретную задачу, а значит справляется с ней лучше
3. транзакционен и поддерживается механизмами обеспечения целостности СУБД

Чтото у меня складывается ощущение что мы говорим с тобой о разных вещах. Ибо все три перечисленных тобой пункта, с моей точки зрения - преимущества alter table smile

Я говорю об Определяемых Пользователем Атрибутах (User Defined Attributes).
1) Реализация конкурентной модификации справочника и UDA - задача весьма не тривиальная
2) Применение UDA универсализует (деконкретезирует) область применения продукта
3) Реализация механизма UDA это фактически отказ от контроля достаточности и целостности данных средствами СУБД

Если мы все же говорим об одном и том же, видимо мы зашли в тупик, т.к. уровень абстракции на котором мы говорим избыточнен, надо переходить от беседы на пальцах к беседе на SQL smile


--------------------
Достоверно известно, что 89% людей доверяют статистике взятой с потолка smile
PM   Вверх
Zloxa
Дата 15.7.2009, 15:57 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Чо?
****


Профиль
Группа: Завсегдатай
Сообщений: 3473
Регистрация: 12.9.2008

Репутация: 11
Всего: 161



Чота перечитал я головной пост и подумал что меня чересчур обуяла фантазия на тему EAV. В моей фантазии, я дошел до метосущностей и метоотношений между ними. Пожалуй, меня малость подзанесло и я описал недостатки не той модели которую представил ТС. Наверное то от скуки. Слезно прошу прощения.

Это сообщение отредактировал(а) Zloxa - 15.7.2009, 15:57


--------------------
Достоверно известно, что 89% людей доверяют статистике взятой с потолка smile
PM   Вверх
  
Ответ в темуСоздание новой темы Создание опроса
Правила форума "Общие вопросы по базам данных"
LSD
Zloxa

Данный форум предназначен для обсуждения вопросов о базах данных не попадающих под тематику других форумов:

  • вопросам по СУБД для которых нет отдельных подфорумов
  • вопросам которые затрагивают несколько разных СУБД (например проблема выбора)
  • инструменты для работы с СУБД
  • вопросы проектирования БД
  • теоретически вопросы о СУБД

Данный форум не предназначен для:

  • вопросов о поиске разлиных БД (если не понимаете чем БД отличается от СУБД то: а) вам не сюда; б) Google в помощь)
  • обсуждения проблем с доступом к СУБД из различных ЯП (для этого есть соответсвующие форумы по каждому ЯП)
  • обсуждения проблем с написание SQL запросов, для этого есть форум Составление SQL-запросов
  • просьб о написании курсовой, реферата и т.п., для этого есть Центр помощи или фриланс биржа
  • объявлений о найме специалистов, для этого есть раздел Объявления о найме специалистов

Если вы не соблюдаете эти правила, не удивляйтесь потом не найдя свою тему/сообщение. ;)


Полезные советы:

При написании сообщения постарайтесь дать теме максимально понятное название. В теме максимально подробно опишите проблему. Если применимо укажите: название базы данных и версии (MySQL 4.1, MS SQL Server 2000 и т.п.); используемых язык программирования; способа доступа (ADO, BDE и т.д.); сообщения об ошибках.

Для вставки кода используйте теги [code=sql] [/code].

Литературу по базам данных можно поискать здесь.

Действия модераторов можно обсудить здесь.


Если Вам понравилась атмосфера форума, заходите к нам чаще! С уважением, LSD, Zloxa.

 
1 Пользователей читают эту тему (1 Гостей и 0 Скрытых Пользователей)
0 Пользователей:
« Предыдущая тема | СУБД, общие вопросы | Следующая тема »


 




[ Время генерации скрипта: 0.0742 ]   [ Использовано запросов: 21 ]   [ GZIP включён ]


Реклама на сайте     Информационное спонсорство

 
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности     Powered by Invision Power Board(R) 1.3 © 2003  IPS, Inc.