|
|
|
Избитый вопрос - реализация каталога товаров
|
|||
|---|---|---|---|
|
#18+
On 07/18/2012 06:39 PM, MasterZiv wrote: > Но Тендер наверняка читал Дейта, так что опосредованно ... :-) Простите, Тенцер конечно. Извиняюсь, писал с мобильного в метро, не проверил. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.07.2012, 22:29 |
|
||
|
Избитый вопрос - реализация каталога товаров
|
|||
|---|---|---|---|
|
#18+
On 07/18/2012 08:14 PM, Digital God wrote: > Не вижу ничего трудоемкого в данной задаче. Есть модели проектирования со своими > плюсами и минусами. Надо выбрать одну и постараться компенсировать ее минусы > через какие-то методы Да главный -то минус -- сложность написания запросов. Решается их автоматической генерацией по метаданным. И применением OLAP для аналитики (как завещал великий Тенцер). (поиск через sphinx, грамотное индексирование, в конце > концов - масштабируемость ресурсов сервера). При чём тут сфинкс ? не понимаю... Сфинкс как раз шаг в противоположную сторону. Ну разве что ноги пошире расставить, чтобы стоять устойчиве... Хотя с другой стороны действительно -- тот же OLAP/DSS/FACETS и т.п. Я кстати сейчас Solr исследую на предмет Facet Browsing -- ничего так, прикольно, быстро, хоть и на Java. В обзорах пишуть, что типа Sphinx -у до них далеко ещё расти (сам не знаю, Sphinx не пользовал). > Каюсь, про RDF не знаю ничего. На днях обязательно почитаю и поищу примеры > реализации. http://www.rdfabout.com/intro/ (про Semantic Web только лапшу с ушей снимай, RDF далеко не только для Semantic Web служит) > Он вполне может быть решен через sphinx. Или sphinx не панацея от всего и вся? :) Как ? Не представляю. Конечно, не может быть он панацеей. > 1) Я просто писал пример на скорую руку, конечно ничего лишнего в конечном > результате не будет. > 2) согласен. поскольку типов данных не так много (строка, число и дата) - можно > обойтись 3 таблицами. Типов атрибутов должно быть порядка 10. Целое со знаком /без знака дробное с фиксированной точкой с плавающей Дата, дата и время, время, Деньги ( и кстати время-деньги :-) строка, текст, бинарка Ещё возможно тебе придётся реализовать какие-то домены из предметной области этих товаров. Типа списки значений (emum), и ещё надо видимо сделать ссылки на другие объекты (товары), чтобы можно было разные связи хранить. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.07.2012, 23:12 |
|
||
|
Избитый вопрос - реализация каталога товаров
|
|||
|---|---|---|---|
|
#18+
MasterZivДа главный -то минус -- сложность написания запросов. Решается их автоматической генерацией по метаданным. И применением OLAP для аналитики (как завещал великий Тенцер). Запросы как раз меньшее из зол :) MasterZivПри чём тут сфинкс ? не понимаю... Сфинкс как раз шаг в противоположную сторону. Ну разве что ноги пошире расставить, чтобы стоять устойчиве... Хотя с другой стороны действительно -- тот же OLAP/DSS/FACETS и т.п. Я кстати сейчас Solr исследую на предмет Facet Browsing -- ничего так, прикольно, быстро, хоть и на Java. В обзорах пишуть, что типа Sphinx -у до них далеко ещё расти (сам не знаю, Sphinx не пользовал). Сфинкс как и sorl позволяет сделать фасетный поиск(навигацию). Я использовал его на предыдущей работе - при грамотном использовании очень хороший инструмент. MasterZivТипов атрибутов должно быть порядка 10. Целое со знаком /без знака дробное с фиксированной точкой с плавающей Дата, дата и время, время, Деньги ( и кстати время-деньги :-) строка, текст, бинарка Ещё возможно тебе придётся реализовать какие-то домены из предметной области этих товаров. Типа списки значений (emum) Да, побольше 3 будет, согласен :) MasterZivи ещё надо видимо сделать ссылки на другие объекты (товары), чтобы можно было разные связи хранить. Не очень понял зачем ссылки на другие объекты? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.07.2012, 23:34 |
|
||
|
Избитый вопрос - реализация каталога товаров
|
|||
|---|---|---|---|
|
#18+
Digital GodВопрос в хранении товаров и их характеристик. Кол-во товаров несколько миллионов, кол-во характеристик к каждому из них - от 20 до 100 (а может и больше). Итак, речь идет о СОТНЯХ МИЛЛИОНОВ характеристик:) Скорее всего, Вы заблуждаетесь. А Ваши советчики заблуждаются, потому что находятся в рамках традиционных ограничений: 1) на число полей в таблице; 2) на для длину записи. Возьмите mumps и не мучайтесь - храните ОДИН тип сущности (Товар) в ОДНОЙ таблице - проверенное решение. Не нравится mumps, возьмите couchdb и т.п. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2012, 02:00 |
|
||
|
Избитый вопрос - реализация каталога товаров
|
|||
|---|---|---|---|
|
#18+
Ну, вот! Хана топику! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2012, 06:04 |
|
||
|
Избитый вопрос - реализация каталога товаров
|
|||
|---|---|---|---|
|
#18+
Digital God Он вполне может быть решен через sphinx. Или sphinx не панацея от всего и вся? :)К сожалению, я не знаю, что такое сфинкс, предположу, что это система полнотекстового поиска. То бишь вы сводите задачу к ОДНОМУ полю у товара - ОПИСАЛОВО и натравливаете на него ваш сфинкс. Другие поля, теоретически, позволяют дофильтровать результат поиска, но практически вы никогда не знаете каким набором признаков обладает выбранная строка. То есть как оно будет реализовано - через EAV ли, или через XML да хоть через CSV от производителя, это не суть дела важно. Сразу вижу достоинство - пополнятелю базы важно только занести товар в правильную категорию (не надо сопоставлять поля описания производителя с вашей системой) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2012, 07:18 |
|
||
|
Избитый вопрос - реализация каталога товаров
|
|||
|---|---|---|---|
|
#18+
zeon11Ну, вот! Хана топику! Разумеется, потому что задача яйца выеденного не стоит. Хорошо, что Вы это так быстро поняли. На этот раз:) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2012, 09:51 |
|
||
|
Избитый вопрос - реализация каталога товаров
|
|||
|---|---|---|---|
|
#18+
SERG1257Digital God Он вполне может быть решен через sphinx. Или sphinx не панацея от всего и вся? :)К сожалению, я не знаю, что такое сфинкс, предположу, что это система полнотекстового поиска. То бишь вы сводите задачу к ОДНОМУ полю у товара - ОПИСАЛОВО и натравливаете на него ваш сфинкс. Другие поля, теоретически, позволяют дофильтровать результат поиска, но практически вы никогда не знаете каким набором признаков обладает выбранная строка. То есть как оно будет реализовано - через EAV ли, или через XML да хоть через CSV от производителя, это не суть дела важно. Сразу вижу достоинство - пополнятелю базы важно только занести товар в правильную категорию (не надо сопоставлять поля описания производителя с вашей системой) С определением сфинкса Вы не ошиблись - это система полнотекстового поиска. Но со сведением задачи к одному полю - ошибаетесь. Сфинкса можно натравить на модель EAV и он прекрасно будет работать, шустро вытаскивая данные :) На тему пополнения базы - какую бы модель я не выбрал - реализовать удобное пополнение базы можно в любом случае. Будь то парсинг xml, csv или еще чего. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2012, 09:52 |
|
||
|
Избитый вопрос - реализация каталога товаров
|
|||
|---|---|---|---|
|
#18+
Бредятинаzeon11Ну, вот! Хана топику! Разумеется, потому что задача яйца выеденного не стоит. Хорошо, что Вы это так быстро поняли. На этот раз:) Да нет, это он о mumps (к стати не нашел инфу по бд), couchdb и прочих... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2012, 09:54 |
|
||
|
Избитый вопрос - реализация каталога товаров
|
|||
|---|---|---|---|
|
#18+
On 07/19/2012 12:34 AM, Digital God wrote: > и ещё надо видимо сделать ссылки на другие объекты (товары), чтобы можно > было разные связи хранить. > > > Не очень понял зачем ссылки на другие объекты? Я не знаю понадобится ли это конкретно тебе, но обычно связи между объектами нужны. ДЛя той предметной области например могу предположить, что нужны будут аналоги товаров. Чтобы их хранить, можно использовать связи между объектами. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2012, 10:28 |
|
||
|
Избитый вопрос - реализация каталога товаров
|
|||
|---|---|---|---|
|
#18+
On 07/19/2012 10:54 AM, Digital God wrote: > Да нет, это он о mumps (к стати не нашел инфу по бд), couchdb и прочих... cache например. (mumps - концепцию реализует). Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2012, 10:31 |
|
||
|
Избитый вопрос - реализация каталога товаров
|
|||
|---|---|---|---|
|
#18+
> Но Тенцер наверняка читал Дейта Смеетесь? > проблема единственно в том что нужно уметь делать правильно бд с EAV EAV - это всегда костыли. Их можно сделать более или менее удобными, но они останутся костылями. Чем меньше их в базе данных, тем лучше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2012, 10:35 |
|
||
|
Избитый вопрос - реализация каталога товаров
|
|||
|---|---|---|---|
|
#18+
Digital GodБредятинапропущено... Разумеется, потому что задача яйца выеденного не стоит. Хорошо, что Вы это так быстро поняли. На этот раз:) Да нет, это он о mumps (к стати не нашел инфу по бд), couchdb и прочих... Я конкретно объяснил с какими ограничениями сталкиваются разработчики при использовании "реляционных систем", и почему они ВЫНУЖДЕНЫ использовать EAV (кроме двух количественных ограничений часто ссылаются на трудности динамического добавления полей таблиц). mumps, к сожалению, остается единственной целостной технологией для создания СУБД:) couchdb, например, не обладает такой целостностью, и это вообще не технология, а продукт. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2012, 10:35 |
|
||
|
Избитый вопрос - реализация каталога товаров
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovDigital Godя и задал вопрос - по какой модели лучше делать базу для каталога. И получил ответ: EAV - единственная работоспособная модель. Про EAV точно вам скажу - тут уже пробегало - весело и задорно - вначале - и довольно гемморойно и печально в конце! Но классический вариант проектирования для каждого товара своей структуры - то же не очень - сначала надо поработать над его формализацией и правильно структурировать, а на это нужно время, а его всегда нету, а если этого не сделать - прийдется все время переделывать! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2012, 13:56 |
|
||
|
Избитый вопрос - реализация каталога товаров
|
|||
|---|---|---|---|
|
#18+
On 07/19/2012 11:35 AM, guest_20040621 wrote: > EAV - это всегда костыли. Их можно сделать более или менее удобными, но они > останутся костылями. Чем меньше их в базе данных, тем лучше. Почему костыли-то ? Нормальная реляционная модель. Всё по Дейту с Кодом. К тому же если надо в процессе эксплуатации создавать новые атрибуты, по-другому никак. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2012, 16:05 |
|
||
|
Избитый вопрос - реализация каталога товаров
|
|||
|---|---|---|---|
|
#18+
MasterZivOn 07/19/2012 11:35 AM, guest_20040621 wrote: > EAV - это всегда костыли. Их можно сделать более или менее удобными, но они > останутся костылями. Чем меньше их в базе данных, тем лучше. Почему костыли-то ? Нормальная реляционная модель. Всё по Дейту с Кодом. К тому же если надо в процессе эксплуатации создавать новые атрибуты, по-другому никак. Создавать не проблема - контролировать сложно Это как в жизни - наплодить детей не проблема - благо процесс приятен, а воспитать - тяжелый труд! Как насчет ограничений и "предпринимательских")))) правил? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2012, 16:12 |
|
||
|
Избитый вопрос - реализация каталога товаров
|
|||
|---|---|---|---|
|
#18+
> Почему костыли-то ? Потому, что структуры данных не существуют обособленно. Потому, что, когда вы добавите контекст, ограничения доступа, локализацию, синонимизацию, историю изменений и семантические отношения к EAV, получите такой геморрой, что традиционная реализация покажется верхом совершенства. > если надо в процессе эксплуатации создавать новые атрибуты, по-другому никак. Жизненный цикл базы данных и назначение EAV в этом контексте уже обсуждалось. Да, как временный коллектор - вполне. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2012, 16:16 |
|
||
|
Избитый вопрос - реализация каталога товаров
|
|||
|---|---|---|---|
|
#18+
MasterZivOn 07/19/2012 11:35 AM, guest_20040621 wrote: > EAV - это всегда костыли. Их можно сделать более или менее удобными, но они > останутся костылями. Чем меньше их в базе данных, тем лучше. Почему костыли-то ? Нормальная реляционная модель. Всё по Дейту с Кодом. К тому же если надо в процессе эксплуатации создавать новые атрибуты, по-другому никак. Это не так - это именно другая модель данных, а не по Кодду, и не по Дейту:). Которую как-то можно реализовать в среде "реляционной системы" (ни одна из таких систем, объективно, не поддерживает ни РМД, ни EAV). Для качественной реализации EAV нужна СУБД, которая поддерживает эту модель данных. А это около 12 чел.мес. в mumps и не могу точно сказать сколько, если использовать другие технологии и языки программирования (об этом своими словами сказал guest_20040621, подразумевая, правда, реализацию EAV-СУБД в реляционной системе). Про создание в процессе эксплуатации новых атрибутов - Вы не корректно опустили слова "в реляционной системе". Поскольку в СУБД новые атрибуты постоянно создаются и это не вызывает абсолютно никаких затруднений. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2012, 19:33 |
|
||
|
Избитый вопрос - реализация каталога товаров
|
|||
|---|---|---|---|
|
#18+
Еще раз повторю (не думаю, что автор топика умышленно игнорирует, просто не понял, скорее всего) - правильным решением является один объект (одна таблица) для этого одного типа сущности - Товара. Это эффективный способ организации данных, в сочетании с простым добавлением характеристик в процессе эксплуатации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2012, 19:37 |
|
||
|
Избитый вопрос - реализация каталога товаров
|
|||
|---|---|---|---|
|
#18+
БредятинаЕще раз повторю (не думаю, что автор топика умышленно игнорирует, просто не понял, скорее всего) - правильным решением является один объект (одна таблица) для этого одного типа сущности - Товара. Это эффективный способ организации данных, в сочетании с простым добавлением характеристик в процессе эксплуатации. Вы правы, я не игнорирую. Просто не особо понял как работать с mumps и прочими базами в ключе моей задачи. То есть что будет одна сущность - Товар, я понимаю. Но как в этом случае работать с разными наборами параметров. Да еще так чтобы это работало и работало быстро - не очень въезжаю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2012, 20:07 |
|
||
|
Избитый вопрос - реализация каталога товаров
|
|||
|---|---|---|---|
|
#18+
Digital GodБредятинаЕще раз повторю (не думаю, что автор топика умышленно игнорирует, просто не понял, скорее всего) - правильным решением является один объект (одна таблица) для этого одного типа сущности - Товара. Это эффективный способ организации данных, в сочетании с простым добавлением характеристик в процессе эксплуатации. Вы правы, я не игнорирую. Просто не особо понял как работать с mumps и прочими базами в ключе моей задачи. То есть что будет одна сущность - Товар, я понимаю. Но как в этом случае работать с разными наборами параметров. Да еще так чтобы это работало и работало быстро - не очень въезжаю. А это уже коммерческий вопрос. СУБД Вы, вероятно, не будете разрабатывать. Изучать технологию тоже вряд ли. Меня коммерческая составляющая не интересует, я только в техническом плане обсуждаю вопросы. Ваша задача легко решается специалистами, знакомыми с mumps. Причем, вариантов поддержки групп характеристик для товаров определенных классов существует несколько. Характеристик, скорее всего, у Вас будет всего лишь несколько тысяч. Примерно (идентификатор - название): 1 - Наименование 2 - Длина, мм ... 817 - Сопротивление, Ом ... 1344 - Объем, м куб. Данные будут храниться компактно. Например, данные об одном конкретном товаре с идентификатором 1345601, относящемся к классу, для которого определены характеристики 1,13,138,1209, будут храниться так: ^T(1345601,1)=Яблоко ^(13)=34 ^(138)=3.78 ^(1209)=6 Ничего лишнего:) Вооружившись такими минимальными знаниями, Вы можете спокойно продолжать реализовывать EAV в какой-нибудь реляционной системе, так как она распространенная и по ней есть специалисты:) То есть, вернетесь к коммерческой составляющей инженерного решения. Это нормально. Но не знать о технологиях БД, все-таки, нехорошо, если Вы разрабатываете приложение БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2012, 20:30 |
|
||
|
Избитый вопрос - реализация каталога товаров
|
|||
|---|---|---|---|
|
#18+
БредятинаDigital Godпропущено... Вы правы, я не игнорирую. Просто не особо понял как работать с mumps и прочими базами в ключе моей задачи. То есть что будет одна сущность - Товар, я понимаю. Но как в этом случае работать с разными наборами параметров. Да еще так чтобы это работало и работало быстро - не очень въезжаю. А это уже коммерческий вопрос. СУБД Вы, вероятно, не будете разрабатывать. Изучать технологию тоже вряд ли. Меня коммерческая составляющая не интересует, я только в техническом плане обсуждаю вопросы. Ваша задача легко решается специалистами, знакомыми с mumps. Причем, вариантов поддержки групп характеристик для товаров определенных классов существует несколько. Характеристик, скорее всего, у Вас будет всего лишь несколько тысяч. Примерно (идентификатор - название): 1 - Наименование 2 - Длина, мм ... 817 - Сопротивление, Ом ... 1344 - Объем, м куб. Данные будут храниться компактно. Например, данные об одном конкретном товаре с идентификатором 1345601, относящемся к классу, для которого определены характеристики 1,13,138,1209, будут храниться так: ^T(1345601,1)=Яблоко ^(13)=34 ^(138)=3.78 ^(1209)=6 Ничего лишнего:) Вооружившись такими минимальными знаниями, Вы можете спокойно продолжать реализовывать EAV в какой-нибудь реляционной системе, так как она распространенная и по ней есть специалисты:) То есть, вернетесь к коммерческой составляющей инженерного решения. Это нормально. Но не знать о технологиях БД, все-таки, нехорошо, если Вы разрабатываете приложение БД. Просто про Ваш mumps я что-то в интернете мало чего нашел, поэтому смутно представляю что это. Знания в проектировании у меня есть - просто я уже 5 лет поддерживаю и развиваю БД в банке и новых веяний в моделях для создания каталога не знаю - не интересовался просто. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2012, 23:02 |
|
||
|
Избитый вопрос - реализация каталога товаров
|
|||
|---|---|---|---|
|
#18+
Бредятина, и потом - как выглядит сущность в бд не суть важно. вопрос в том как она ее хранит. если на деле это тот же EAV с каким-то дополнениями - что мешает сделать тоже самое на реляционной бд? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2012, 23:27 |
|
||
|
Избитый вопрос - реализация каталога товаров
|
|||
|---|---|---|---|
|
#18+
Digital God Просто про Ваш mumps я что-то в интернете мало чего нашел, поэтому смутно представляю что это. Знания в проектировании у меня есть - просто я уже 5 лет поддерживаю и развиваю БД в банке и новых веяний в моделях для создания каталога не знаю - не интересовался просто. Следовательно, я достаточно точно описал ситуацию:) Не мой mumps, а единственную, к сожалению, на сегодняшний день целостную технологию БД. Которой уже 45 лет. Особо много Вам и не нужно искать. По причинам, о которых я написал ранее. Но это не по существу Вашей задачи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.07.2012, 08:40 |
|
||
|
Избитый вопрос - реализация каталога товаров
|
|||
|---|---|---|---|
|
#18+
Digital GodБредятина, и потом - как выглядит сущность в бд не суть важно. вопрос в том как она ее хранит. если на деле это тот же EAV с каким-то дополнениями - что мешает сделать тоже самое на реляционной бд? 1) Именно "как она ее хранит" я Вам и объяснил (разумеется, один из вариантов):) 2) В mumps нет никакой МД, ни EAV, ни какой другой. Так что не "тот же EAV". 3) Что мешает объяснил. Читайте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.07.2012, 08:45 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=37884684&tid=1540288]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
240ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
56ms |
get tp. blocked users: |
2ms |
| others: | 12ms |
| total: | 351ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...