|
|
|
Проектирование: объявление+тип товара+набор свойств
|
|||
|---|---|---|---|
|
#18+
Для начала постараюсь объяснить все в теории, надеюсь этого будет достаточно. Задача состоит в создании сайта объявлений. Основная нагрузка по идее будет ориентирована на поиск объявлений по заданным параметрам. Я определил для себя следующие сущности: 1. объявление (номер, дата, кто создал, ..., тип товара ) 2. тип товара я могу зафиксировать в N значений (компьютер, ноутбук, магнитофон), или же количество может увеличиваться 3. у каждого типа товаров есть набор свойств как уникальных так и пересекающихся. Ихнее количество может менятся. Как реализовать схему БД? Сколько и каких таблиц нужно и связи между ними. Подозреваю что есть "стандартное" решение такого рода задачи, как бы паттерн. То есть, если кортко: есть объект, у которого в зависимости от его типа может быть определенный набор параметров Еще вопросы, более конкретные: 2. У меня таблица "объявление" как бы главная, от нее я начинаю все "танцы". Правильный выбор в этом случае ? 3. Фиксированная длина "тип товара" в 5-10 значений повлечет за собой упрощение смемы/реализации ? Если да, то в чем отличие обеих вариантов, стоит ли жертвовать гибкостью в пользу удобства/скорости/... 4. В случае фиксированого количества типа товаров (комп, ноут, магнитофон) надо ли создавать отдельную таблицы comp_proprerties, notebook_properties или держать все свойства в 1 таблице ? У меня примерно 3-5 свойств общих + 2-4 уникальных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2010, 16:43 |
|
||
|
Проектирование: объявление+тип товара+набор свойств
|
|||
|---|---|---|---|
|
#18+
Наверное для начала нужно построить модель данных, а реализация БД зависит от СУБД. Большинство твоих вопросов связано с метаданными, которые очень полезно иметь в словаре БД а не в пользовательских таблицах. Я не вижу большого смысла делать свех гибкую систему. Всё равно формы для объявлений пользователи системы не будут делать. Пусть этим специалисты занимаются. А специалисты и таблички могут сделать и интерфейс подкрутить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2010, 18:26 |
|
||
|
Проектирование: объявление+тип товара+набор свойств
|
|||
|---|---|---|---|
|
#18+
Наверное для начала нужно построить модель данных, а реализация БД зависит от СУБД. в моем случае структура таблиц будет зависеть от базы данных? хм ... можно чуть подробнее тут ? я буду использовать mysql. Большинство твоих вопросов связано с метаданными, которые очень полезно иметь в словаре БД а не в пользовательских таблицах. Если тут имеется ввиду, чтобы вместо id name city1 vasya kiev2 petya moscow использовать id name city_id1 vasya 12 petya 2 city_id city_name1 Kiev2 Moscov , то это понятно Я не вижу большого смысла делать свех гибкую систему. Под гибкостью подразумевается правильное и грамотное проектирование, которое позволит безболезненно или с наименьшими телодвижениями расширять систему. Всё равно формы для объявлений пользователи системы не будут делать.Пусть этим специалисты занимаются. А специалисты и таблички могут сделать и интерфейс подкрутить. А я по вашему менеджер по продажам и занимаюсь проектированием базы данных ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2010, 20:04 |
|
||
|
Проектирование: объявление+тип товара+набор свойств
|
|||
|---|---|---|---|
|
#18+
fanat1kПодозреваю что есть "стандартное" решение такого рода задачи, как бы паттерн. Самое "стандартное" решение такой доски объявлений вот здесь Очень простое и достуное решение. Полистайте Коллега по разным объявлениям и если что-то будет непонятно - спросите. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2010, 21:56 |
|
||
|
Проектирование: объявление+тип товара+набор свойств
|
|||
|---|---|---|---|
|
#18+
fanat1kНаверное для начала нужно построить модель данных, а реализация БД зависит от СУБД. в моем случае структура таблиц будет зависеть от базы данных? хм ... можно чуть подробнее тут ? я буду использовать mysql. Не от БД, а от СУБД. И не только в твоём случае. fanat1k Большинство твоих вопросов связано с метаданными, которые очень полезно иметь в словаре БД а не в пользовательских таблицах. Если тут имеется ввиду, чтобы вместо id name city1 vasya kiev2 petya moscow Нет не это. Вот это. name type attr1 attr2HP комп tower серыйSONY ноут 3kg 15" field type meanattr1 комп корпусattr2 комп цветattr1 ноут массаattr2 ноут диагональ Здесь вместо того чтобы описание полей attr1, attr2 перенести в словарь в БД в виде полей (корпус, цвет, масса, диагональ) возможно даже в разных таблицах, был создан "костыль", который к модели данных никакого отношения не имеет. fanat1kА я по вашему менеджер по продажам и занимаюсь проектированием базы данных ? Если ты этим занимаешься и испытываешь затруднения, то наивно полагать что менеджер по продажам, которого тематика БД волновала только как отметка в аттестате, вообще сможет сделать что либо путное. Собственно ты сам ответил. fanat1kПод гибкостью подразумевается правильное и грамотное проектирование, которое позволит безболезненно или с наименьшими телодвижениями расширять систему. Только в первую очередь следет рассматривать потребительские свойства системы, а расширяемость это скорее средство достижения цели. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2010, 12:58 |
|
||
|
Проектирование: объявление+тип товара+набор свойств
|
|||
|---|---|---|---|
|
#18+
Vika Vinner, не понял полезность ресурса, что там смотреть, веб-морду доски объявлений ? mcureenab, cпасибо за ответы. Попробую привесты очень приближенные примеры. Подскажите как улучшить эту схему. Есть две таблички: advertisement id title device_type_id цена масса цвет диагональ корпуспроцессор винчестер память батарея формат песен радио диктофон1 продам 1(комп) Y YYNY Y YYNNNN2 продам 2(ноут)YYYYNYYYYNNN3 продам 3(плеер)YYYNNNNNNYYY device_type idtype1 комп2 ноут3 плеер Все поля необязательны, Y - может быть заполнено для этого типа устройства, N - не может быть заполнено, т.е. этот девайс не имеет таких свойств. Значения параметров могут быть вбиты в таблицу жестко (цена = 100, корпус=ATX) или же могут быть внешними ключами (для формата песен ограниченный список:mp3, wav, ogg) Недостатки которые вижу я: 1. Все выглядит коряво :) 2. Много пустых полей за счет того что что у определенных устройств есть уникальные свойства (для плеера наличике радио и диктофона). 3. На уровне БД нету четкого разделения каким устройствам принадлежат какие поля. Я на пользовательском уровне при заполнении формы показываю поля, которые надо заполнить для плеера (цена, масса, цвет, формат песен, радио, диктофон). А хочется чтобы глядя на структуру БД было видно, что эти поля (attr1, attr2, attr3) есть общие для всех, attr4,attr5 принадлежат компу, а att6, att7 плееру. И еще, правильно ли это (плюсы, минусы, плохой тон?) держать в ячейке таблицы имя другой таблицы, например advertisement id title device_type device_properties_table properties_id1 продам комп computer_properties 1 computer_properties id цена корпус цвет масса винчестер процессор1 150 tower black 2 205Gb 2GHz Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2010, 15:02 |
|
||
|
Проектирование: объявление+тип товара+набор свойств
|
|||
|---|---|---|---|
|
#18+
fanat1k Как реализовать схему БД? Сколько и каких таблиц нужно и связи между ними. Подозреваю что есть "стандартное" решение такого рода задачи, как бы паттерн. То есть, если кортко: есть объект, у которого в зависимости от его типа может быть определенный набор параметров На вскидку есть два полярных варианта: 1) для каждого типа товара - своя физическая структура (таблица). Выделить над ними вырожденный супертип с общими аттрибутами (название, описание). Такое решение потребует доработки на каждый чих (добавление/изменени параметров, типов товаров), причём как и базы так и сервера приложений. Запросы зато легкочитаемые и лекгопишущиеся :) 2) выделить сущности: "товар/объявление", "тип товара", "параметр типа", "параметр", "значение параметра". Не смотря на некоторую громоздкость, данную схему не надо будет курочить при добавлении/изменении типов товаров, их параметров. При должном подходе к оптимизации (материализованные представления, партицированные таблицы) обладает вполне сносным быстродействием. fanat1kЕще вопросы, более конкретные: 2. У меня таблица "объявление" как бы главная, от нее я начинаю все "танцы". Правильный выбор в этом случае ? "Как бы главная", "танцы"... Природа таблицы - журнал: много операций вставки, выборка в основном актуальных значений, cтарые данные отсекаются в архив, практически нет удалений и изменений. Что тут может быть главного? fanat1k3. Фиксированная длина "тип товара" в 5-10 значений повлечет за собой упрощение смемы/реализации ? Если да, то в чем отличие обеих вариантов, стоит ли жертвовать гибкостью в пользу удобства/скорости/... Универсальных систем не бывает. Любое решение - компромисс между удобством и быстродействием. Но это такие прописные истины, от которых самому тошно :) Если не лень (время позволяет), сделайте обе модели, залейте в них тестовых данных, погоняйте запросики - природа обеих подходов вам откроется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2010, 15:10 |
|
||
|
Проектирование: объявление+тип товара+набор свойств
|
|||
|---|---|---|---|
|
#18+
fanat1kVika Vinner, не понял полезность ресурса, что там смотреть, веб-морду доски объявлений ? Коллега, А Вы не поленились и посмотрели? Или Вы сделали вывод, что смотреть ТАМ нечего.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2010, 17:11 |
|
||
|
Проектирование: объявление+тип товара+набор свойств
|
|||
|---|---|---|---|
|
#18+
ineedyou Универсальных систем не бывает. Любое решение - компромисс между удобством и быстродействием. Но это такие прописные истины, от которых самому тошно :) Вот действительно золотые слова. И поверьте многие понятия об этом не имеют ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2010, 17:13 |
|
||
|
Проектирование: объявление+тип товара+набор свойств
|
|||
|---|---|---|---|
|
#18+
fanat1kВсе поля необязательны, Y - может быть заполнено для этого типа устройства, N - не может быть заполнено, т.е. этот девайс не имеет таких свойств . Значения параметров могут быть вбиты в таблицу жестко (цена = 100, корпус=ATX) или же могут быть внешними ключами (для формата песен ограниченный список:mp3, wav, ogg) Вы совершенно правильно задали вопрос о "СТАНДАРТНЫХ ПОДХОДАХ". Как реализовано? Матрично-перпендикулярно. Доски объявлений распределены по географическим признакам в самом высоком домейне. по логике: город.домейн.орг . Следующий уровень выводит Вас в необходимый ресурс - ДЕЙСТВИЕ:(продажи, предложения, квартиры...) город.домейн.орг/действие(все) Может тут же перевести в ТИПДЕЙСТВИЯ (электроника, мебель, комьютеры..., или комнаты, дома, койкоместа.. ....) город.домейн.орг/типдействия Заметьте - ничего лишнего: Только месторасположение, объект объявления, цена (если купля продажа), и само объявление. Ну ещё фото товара на продажу. Или квартиры на сдачу.. Вот это на мой взгляд обязательно. Всё. Никакой сложности в диагоналях, типах, комплектации никому это не надо. Простому человеку (а доска объявлений подразумевает совершенную неподготовленность пользователя) кроме цены и может быть цвета размера и срока годности ничего не надо. Главное чтобы костюмчик сидел © Смотрите - если я напишу объявление такого содержания: :Продаётся компьютер леново т61 чёрного цвета $450 в городе Гонолулу... И прикреплю фотку этого компъютера Вы всё поймёте - или у Вас будут вопросы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2010, 17:40 |
|
||
|
Проектирование: объявление+тип товара+набор свойств
|
|||
|---|---|---|---|
|
#18+
ineedyou На вскидку есть два полярных варианта: 1) для каждого типа товара - своя физическая структура (таблица). Выделить над ними вырожденный супертип с общими аттрибутами (название, описание). Такое решение потребует доработки на каждый чих (добавление/изменени параметров, типов товаров), причём как и базы так и сервера приложений. Запросы зато легкочитаемые и лекгопишущиеся :) 2) выделить сущности: "товар/объявление", "тип товара", "параметр типа", "параметр", "значение параметра". Не смотря на некоторую громоздкость, данную схему не надо будет курочить при добавлении/изменении типов товаров, их параметров. При должном подходе к оптимизации (материализованные представления, партицированные таблицы) обладает вполне сносным быстродействием. Спасибо, примерно это хотел услышать. Пока прояснений мало, все абстактно, но уже видно свет в конце тоннеля :) fanat1k 2. У меня таблица "объявление" как бы главная, от нее я начинаю все "танцы". Правильный выбор в этом случае ? ineedyou "Как бы главная", "танцы"... Природа таблицы - журнал: много операций вставки, выборка в основном актуальных значений, cтарые данные отсекаются в архив, практически нет удалений и изменений. Что тут может быть главного? Неправильно выразился, имел ввиду не таблица, а сущность ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2010, 18:50 |
|
||
|
Проектирование: объявление+тип товара+набор свойств
|
|||
|---|---|---|---|
|
#18+
Vika Vinnerfanat1kVika Vinner, не понял полезность ресурса, что там смотреть, веб-морду доски объявлений ? Коллега, А Вы не поленились и посмотрели? Или Вы сделали вывод, что смотреть ТАМ нечего.... Посмотрел еще раз, прочитал даже разъяснения, спасибо за теорию. И все равно сделал вывод что смотреть там мне нечего. Я вижу только интерфейс , а меня интересует реализация . Может в силу своей необразованности в даной области я не в силах проникнуть вглубь :). Не надо привязываться именно к системе объявлений и отговаривать меня избавиться от "лишних" параметров. Это только для примера. Вот другой пример: нужно хранить информацию о транспортных средствах и их характеристиках. Что имеем: 1. транспотрное средство 2. тип (велосипед, атомобиль, танк :) ) 3. свойства транспортных средств. (вес, скорость, количество педалей, дальность выстрела, тип горючего, и много-много другого) Необходимо реализовать хранение всего этого в БД. Суть остается та же: есть объект (транспортное средство) и в зависимости от его типа(вело, авто) ему надо прикрутить определенный набор параметров (как общие так и уникальные для данного транспортного средства). Хотелось бы увидеть 3-5 табличек (думаю этого достаточно) и связи между ними. Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2010, 19:13 |
|
||
|
Проектирование: объявление+тип товара+набор свойств
|
|||
|---|---|---|---|
|
#18+
fanat1kНе надо привязываться именно к системе объявлений и отговаривать меня избавиться от "лишних" параметров. Хорошо - не буду... Только разве тема не " объявление +тип товара+набор свойств"? В "Стандартном Решении" предложенном лет 15 назад и до сих пор успешно работающем и танки продавались, и велосипеды, и ещё масса чего, без всяких наборов свойств ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2010, 19:33 |
|
||
|
Проектирование: объявление+тип товара+набор свойств
|
|||
|---|---|---|---|
|
#18+
fanat1kДля начала постараюсь объяснить все в теории, надеюсь этого будет достаточно. Задача состоит в создании сайта объявлений. Основная нагрузка по идее будет ориентирована на поиск объявлений по заданным параметрам. Моё Вам пожелание - не усложняйте систему объявлений. Если идёт речь о сайте объявлений - поиск ведётся по цене местоположению и ключевым словам а не по параметрам. Всё что нужно Вашему клиенту - это найти товар по приемлемой цене и связаться с продавцом для вопросов. И всё. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2010, 19:41 |
|
||
|
Проектирование: объявление+тип товара+набор свойств
|
|||
|---|---|---|---|
|
#18+
Vika Vinner Моё Вам пожелание - не усложняйте систему объявлений. Если идёт речь о сайте объявлений - поиск ведётся по цене местоположению и ключевым словам а не по параметрам. Всё что нужно Вашему клиенту - это найти товар по приемлемой цене и связаться с продавцом для вопросов. И всё. Учту, спасибо. Для стандартного поиска так и сделаю. Плюс помимо обычного поиска хочу сделать кнопочку "расширенный поиск", где бы можно было поискать "танк, растаможен, пробег до 5000, цена от Х до У,башня (без башни или башня набекрень), цвет в горошек". :) При добавлении объявления все эти поля необязательные, т.е. мучать людей заполнением 20-ти характеристик товара не собираюсь :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2010, 20:44 |
|
||
|
Проектирование: объявление+тип товара+набор свойств
|
|||
|---|---|---|---|
|
#18+
fanat1kПлюс помимо обычного поиска хочу сделать кнопочку "расширенный поиск", Коллега, вообще то расширенный поиск мы делаем тогда если в обычный попало СЛИШКОМ МНОГО ТАНКОВ а ввиду того, что как я понимаю объявлений у Вас ожидается немного - мой совет постороннего (точнее посторонней) - лучше чтобы расширенным поиском никто не пользовался... Вероятность попадания в результат поиска именно того ТАНКА который Вы планируете искать равна ... нулю ... в общем очень маленькая ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2010, 04:31 |
|
||
|
Проектирование: объявление+тип товара+набор свойств
|
|||
|---|---|---|---|
|
#18+
За весь мой многолетний опыт общения с разного рода досками/аукционами, расширенным поиском по параметрам мне приходилось пользоваться очень нечасто, т.к. я спинным мозгом чувствую, что "на другом конце провода" продавец вполне мог и ошибиться при составлении объявления, например записав значение ПРОБЕГА в параметр ОБЪЁМ ДВИГАТЕЛЯ. Как негативное следствие часть предложений фильтрутеся. Болезнь неправильного/невнимательного заполнения анкеты продавцами слабоизлечима - ей страдают все справочно-поисково-торговые системы (ebay, market.yandex, price.ru, molotok...). Так что подумайте хорошенько, стоит ли тратить 90% времени на оттачивание функционала, которым будут пользоваться от силы 5% пользователей, к тому же результаты будут слабонадёжные. Может лучше подумать в сторону других механизмов, например полнотекстового поиска? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2010, 12:28 |
|
||
|
Проектирование: объявление+тип товара+набор свойств
|
|||
|---|---|---|---|
|
#18+
ineedyouЗа весь мой многолетний опыт общения с разного рода досками/аукционами, расширенным поиском по параметрам мне приходилось пользоваться очень нечасто, т.к. я спинным мозгом чувствую, что "на другом конце провода" продавец вполне мог и ошибиться при составлении объявления, например записав значение ПРОБЕГА в параметр ОБЪЁМ ДВИГАТЕЛЯ. Как негативное следствие часть предложений фильтрутеся. Болезнь неправильного/невнимательного заполнения анкеты продавцами слабоизлечима - ей страдают все справочно-поисково-торговые системы (ebay, market.yandex, price.ru, molotok...). Так что подумайте хорошенько, стоит ли тратить 90% времени на оттачивание функционала, которым будут пользоваться от силы 5% пользователей, к тому же результаты будут слабонадёжные. Может лучше подумать в сторону других механизмов, например полнотекстового поиска? А как же Yandex.Маркет ??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2010, 14:24 |
|
||
|
Проектирование: объявление+тип товара+набор свойств
|
|||
|---|---|---|---|
|
#18+
У яндекса тоже с этим проблемы были, но сейчас насколько я понимаю (http://partner.market.yandex.ru/legal/tt/) они перешли на другую схему - сами составляют/актуализируют каталоги товаров с характеристиками, оставляя магазинам только возможность указать список конечных позиций. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2010, 14:43 |
|
||
|
Проектирование: объявление+тип товара+набор свойств
|
|||
|---|---|---|---|
|
#18+
Остановился на втором варианте, предложенном ineedyou ineedyou выделить сущности: "товар/объявление", "тип товара", "параметр типа", "параметр", "значение параметра" ... Возникли трудности в хранении конечных параметров: одни вводятся пользователем произвольно, другие же я предоставляю выбрать из ограниченного списка. Решение подсказали в другой теме форума Всем пасибо! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.02.2010, 12:34 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=36456288&tid=1542843]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
54ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
69ms |
get tp. blocked users: |
1ms |
| others: | 244ms |
| total: | 404ms |

| 0 / 0 |
