 |
|
Модераторы: LSD |
 
|
|
структура БД товары - свойства товаров, проблема со свойствами товаров 
| sergey_85 |
|
|||
|
Опытный  Профиль Группа: Участник Сообщений: 445 Регистрация: 17.4.2007 Где: Россия, Челябинск Репутация: нет Всего: 1 |
Привет!
Появилась такая вот задачка создать БД товары и их свойства (как в интернет магазине) Только есть небольшая проблема с таблицей свойства товаров. Свойства могут быть списком (да/нет, страна-производитель ), целым числом (вес, габариты), строкой короткой/длинной (название/описание). Как все это учесть и запихнуть в БД.
-------------------- A good design always pays off. |
|||
|
||||
Загрузка ...
| Zloxa |
|
|||
 Чо? Профиль Группа: Завсегдатай Сообщений: 3473 Регистрация: 12.9.2008 Репутация: 11 Всего: 161 |
недостатки такой модели тут Не смотря на минусы, справочник номенклатуры, одна из немногих областей применения, где EAV применять целесообразно. Однако есть ограничение области применения. Есть описательные свойства,- свойства которые желательно показать пользователю, но есть и системные свойства - свойства, на которые опирается функционал системы, исходя из которых строятся отчеты, от значений которых зависит бизнес логика. Так вот системные свойства, с помощью такой модели, лучше не реализовывать. Это сообщение отредактировал(а) Zloxa - 23.1.2009, 17:23 -------------------- Достоверно известно, что 89% людей доверяют статистике взятой с потолка  |
|||
|
||||
| vladimir74 |
|
|||
 Бывалый Профиль Группа: Участник Сообщений: 241 Регистрация: 28.11.2006 Репутация: нет Всего: 3 |
все смешалось, люди кони....
берем продукт, смотрим на него пристальным взглядом, и понимаем, что любой продукт можно имеет определенные данные. Номер продукта (от производителя или от посредника или свой номер в системе) описание продукта (часто делят на краткое и полное описание) страна изготови фирма изготовитель EAN Баркод вес, длина, ширина, высота вобщем существует еще множество полей, которые являются всегда отдельными полями в таблице products. НО камера 3.2 будет делиться только в случае если ты делаешь базу камер и тебе надо будет сортировать по пикселям. а вообще это скорее вссего часть краткого описания продукта... --------------------
* В доме помешанного не говорят о миксере.* На любой Ваш вопрос у меня есть любой мой ответ. |
|||
|
||||
| sergey_85 |
|
|||
|
Опытный Профиль Группа: Участник Сообщений: 445 Регистрация: 17.4.2007 Где: Россия, Челябинск Репутация: нет Всего: 1 |
Да vladimir74, мне и нужен потом поиск по параметра и подбор по параметрам иначе бы я не мучился  и затолкал бы все это скажем - в мемо поле.*а вообще сама база будет содержать разные категории товаров от болтов до различных измерительных приборов. Это сообщение отредактировал(а) sergey_85 - 22.1.2009, 20:45 -------------------- A good design always pays off. |
|||
|
||||
| vladimir74 |
|
|||
|
Бывалый Профиль Группа: Участник Сообщений: 241 Регистрация: 28.11.2006 Репутация: нет Всего: 3 |
вообще то это все очень индивидуально. Проще посмотреть по каким критериям т будешь делать сортировки. И насколько они часто будут использованы. При этом если в твоей базе будут и болты и видеокамеры и еще что то, то описать все точные свойства практически невозможно. Т.к. ты все равно не знаешь какие свойства нужны будут следующему товару. Тогда лучше ориентироваться на глобальные свойства (те что есть всегда), а поиск и сортировки организовывать программно. Плюс к этому часто используются dummy поля. Которые так раз и служат для работы с какими то либо заранее неизвестными свойствами... Чаще всего эти поля являются строковыми (так как их проще пкркводить в другие). Или же организуют так, чтоб поля можно было легко вводить в обиход в процессе работы. (Дезайнер форм в пользовательском интерфейсе) --------------------
* В доме помешанного не говорят о миксере.* На любой Ваш вопрос у меня есть любой мой ответ. |
|||
|
||||
| sergey_85 |
|
|||
|
Опытный Профиль Группа: Участник Сообщений: 445 Регистрация: 17.4.2007 Где: Россия, Челябинск Репутация: нет Всего: 1 |
Хорошо, vladimir74, поиск я организую общий по наименованию товара, также внесу в таблицу товары его общие сво-ва (например картинка, описание краткое/подробное, артикул ну т.д.) Подбор товара конечно же у всех свои параметры и их куча поэтому делаться будет безусловно программно (по заранне известному шаблону для опред. группы товаров)
Что касается строковых полей ну вот например какую длину взять такого поля если я хочу хранить путь до файла с инструкцией по применению и дату поступления в продажу в таких полях т.е. я хотел бы узнать оптимальный размер поля (50/256/1024 символов) Кто как думает? Это сообщение отредактировал(а) sergey_85 - 23.1.2009, 11:33 -------------------- A good design always pays off. |
|||
|
||||
| vladimir74 |
|
||||
|
Бывалый Профиль Группа: Участник Сообщений: 241 Регистрация: 28.11.2006 Репутация: нет Всего: 3 |
тут могу сказать только из своей практики... 64 (50) - маленькое поле зато хорошо себя ведет при поисках и сортировках 128 (100) - поля небольших орисаний 256 (250) - я не пользуюсь но встречал например в Online Shop дальше BLOB поля. Zloxa, как то я пропустил твой пост :( . Модель интересная но ИМХО сложно реализуемая и гдавное при большом колличестве товара с разными свойствами сравнительно медленая. (Во всяком случае на первый взгляд) P.S. там где я работаю сейчас, мы не пользуемся dummy. У нас есть свой дезайнер форм (хотя его и стоит подправить :( ). И по желанию заказчика мы добовляем поля к базе. Сами же запросы либо строятся динамически во время открытия формы либо изначально
C dummy полями я сталкивался лет 5 назад, когда работал с Navision. Основная проблема с ними - нужна очень четкая документация чтоб не запутаться!!!! --------------------
* В доме помешанного не говорят о миксере.* На любой Ваш вопрос у меня есть любой мой ответ. |
||||
|
|||||
| Zloxa |
|
||||
|
Чо? Профиль Группа: Завсегдатай Сообщений: 3473 Регистрация: 12.9.2008 Репутация: 11 Всего: 161 |
Минусы были мной указаны.
Подобные схемы(с гибким набором атрибутов), обычно применяют для того, чтобы минимизировать затраты на модернизацию ПО, при изменении бизнес требований к критериям фильтрации справочников. Если мы изменили назначение dummy поля, нам по всякому надо модифицировать клиентское ПО, для того, чтобы пользователь мог им пользоваться, а так же все фильтры, где использовалось старая трактовка этого поля (если таковая была) и не использовалась новая. В клиент-серверных приложениях, наращивание версии клиента - имеет наибольший вес в стоимости модернизации. Т.о. схема с dummy полями не позволяет нам в достаточной степени быть экономными. И, по трудозатратам модернизации, вполне сопоставима с добавлением нового поля в таблице. К тому же топикстартером заявлена потребность в задании списка допустимых значений атрибутов. Что касается медленности... отбор по не индексированному dummy полю врядли будет быстрее чем по индексированному полю "значение" таблицы Символьные_свойства_Товаров из моего примера. А индексировать все dummy поля.... неоправданно Это сообщение отредактировал(а) Zloxa - 23.1.2009, 14:17 -------------------- Достоверно известно, что 89% людей доверяют статистике взятой с потолка |
||||
|
|||||
| vladimir74 |
|
||||||||
|
Бывалый Профиль Группа: Участник Сообщений: 241 Регистрация: 28.11.2006 Репутация: нет Всего: 3 |
согласен...
мне кажется что ПО все равно придется видоизменять как минимум для показа значений нового свойства. (Или же опять возвращаемся к дезайнеру форм, позволяя пользователю самому добавлять/убирать новые поля на форме)
если оставлять dummy неиндексированными - то 99% с тобой согласен, но если все равно нам приходится тем или другим способом делать изменения, мы можем сразу проиндексировать новое задействованное поле.
а вот это точно надо запретить!! один клиент не имеет права использовать поле сначала для одного а потом для другого свойства. Иначе бед не наберешься. Я кстати написал что при использовании dummy нужно очень хорошо все документировать... P.S. если спросить меня - мне больше по нутру способ с добовлением полей в готовую систему чем способ с dummy. Хотя как я уже говорил, даже некоторые монстры не глумятся пользоваться этим способом. А вот хорошо это или плохо - решать надо самому. Насчет твоего способа - он в принципе интересен и в описании достаточно прост (его проблемы ты и в правду привел сам ;) ). Хотя честно не знаю стоит ли в данном случае "овчинка выделки"... Все таки как показывает практика (как минимум моя) основное колличество пользователей используют в конечном варианте определенное колличество глобально известных свойств товара. И новые поля приходится вводить очень редко.... Но это только моя практика... Это сообщение отредактировал(а) vladimir74 - 23.1.2009, 15:05 --------------------
* В доме помешанного не говорят о миксере.* На любой Ваш вопрос у меня есть любой мой ответ. |
||||||||
|
|||||||||
| Zloxa |
|
||||||||||
|
Чо? Профиль Группа: Завсегдатай Сообщений: 3473 Регистрация: 12.9.2008 Репутация: 11 Всего: 161 |
И сколько индексов нам при том придется содержать?
Использующие такую схему системы, как правило, отображают UDA(User Defined Attributes) как detail таблицу к справочнику. Т.е. показывают не для всех позиций а только для конкретных. Безусловно бизнес-пользователям это не нравится. А фигли делать?
Если знаешь что нельзя, но очень хочется, - то можно.  )
Мне тоже. Но есть и реалии жизни. Например, если решение тиражное, то далеко не всегда есть возможность добавить в табличку колоночку.
Наверно таки "гнушаются", потому как "глумиться" это чуть из другой оперы. (глумлюсь  )Мой пример тоже "слизан" с весьма пафосной системы. -------------------- Достоверно известно, что 89% людей доверяют статистике взятой с потолка |
||||||||||
|
|||||||||||
| vladimir74 |
|
||||||||||||
|
Бывалый Профиль Группа: Участник Сообщений: 241 Регистрация: 28.11.2006 Репутация: нет Всего: 3 |
хм видать я начал забывать русский  надо срочно своих учить русскому, а то так все забуду ..... Но уже таки да смущен....
по нормальному - только задействованные в данной системе
вот именно. А при условии что программ систем работы предприятий сегодня хватает (не то что было лет 10 тому назад  ) то приходится угождать пользователям. Уж такая у нас селяви
можно все, как минимум один раз... но если знаешь что это отрава - то лучше выбросить 
возможно, хотя если мы решились на такую нелегкую задачу, то можно и почесать головку и написать визуальный редактор ДБ таблиц. Знаю что это не там тоже есть много проблем. Но и задачу нам не из простейших поставили.... Хотя начиная строить свой редактор - нам придется воспользоваться твоей или похожей схемой (никуда не денешься). Но зато это юудет касаться только редактора а не всю программу. Но это мое мнение
вот именно по этому каждый выбирает то, что ему удобней. И вполне уверен что по описанной тобой схеме работает много софта, и программисты сидят и когда вылазят какие то проблемы матерят того кто придумал работать по этой схеме. Так же как и программисты других схем матерятся сталкиваясь с проблемами у себя. (И я такой же.... вот наал писать, и на полубукве меня отвлекли...) Это сообщение отредактировал(а) vladimir74 - 23.1.2009, 17:21 --------------------
* В доме помешанного не говорят о миксере.* На любой Ваш вопрос у меня есть любой мой ответ. |
||||||||||||
|
|||||||||||||
| Zloxa |
|
||||||||
|
Чо? Профиль Группа: Завсегдатай Сообщений: 3473 Регистрация: 12.9.2008 Репутация: 11 Всего: 161 |
Змеиный яд - отрава, но им лечатся
Я, лично, предпочел бы убедить пользователя, нежели угодить ему. "Хотелки" заказчика достаточно быстро оптимизируются, когда ему выставляется смета. Или же ему выставляется список рисков, с просьбой поставить подпись, что он ознакомлен с ними, но не меняет своего решения.
Кто-то материт, а кто-то наматывает на ус, и откладывает в долгосрочную память, для того чтобы быть более убедительным при следующем убеждении Я видел четыре или пять схем классификаторов номенклатуры. Приведенную выше, я нахожу наиболее простой жизнеспособной. Но ни в коем случае не единственной.
Это уж совсем черезчур. ХОтя примеров предостаточно. Взять тот же 1С. На скольки там клиентах он встает враскоряку? А тем не менее ведь жизнеспособен то, и спросом пользуется. Потому как гибкостью обеспечена тиражируемость. Это сообщение отредактировал(а) Zloxa - 23.1.2009, 18:32 -------------------- Достоверно известно, что 89% людей доверяют статистике взятой с потолка |
||||||||
|
|||||||||
|
|
| Правила форума "Общие вопросы по базам данных" | |
|
|
Данный форум предназначен для обсуждения вопросов о базах данных не попадающих под тематику других форумов:
Данный форум не предназначен для:
Если вы не соблюдаете эти правила, не удивляйтесь потом не найдя свою тему/сообщение.
Полезные советы: Если Вам понравилась атмосфера форума, заходите к нам чаще! С уважением, LSD, Zloxa. |
| 0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей) | |
| 0 Пользователей: | |
| « Предыдущая тема | СУБД, общие вопросы | Следующая тема » |
[ Время генерации скрипта: 0.0637 ] [ Использовано запросов: 22 ] [ GZIP включён ]
Реклама на сайте Информационное спонсорство
|
|
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности Powered by Invision Power Board(R) 1.3 © 2003 IPS, Inc. |