|
|
|
Каталог товаров для интернет магазина (EAV)
|
|||
|---|---|---|---|
|
#18+
Проектируется база под приложение аналогичное "яндекс-маркет". Думаю хранить отдельно таблицу категорий и отдельно товары. Для каждой группы товаров - разные наборы характеристик, почитал форум, нашел что мне нужен видимо EAV. Но никак не могу выбрать: 1) Как лучше - по таблице под каждый тип значения, или просто по столбцу? 2) Какой вариант хранения структуры лучше - рекурсивный (parentId) или вложенные множества? Может есть еще варианты хранения древовидных структур? --- Иисус Христос - Путь, Истина и Жизнь. Отвергающий Сына отвергает Отца ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2011, 12:24 |
|
||
|
Каталог товаров для интернет магазина (EAV)
|
|||
|---|---|---|---|
|
#18+
Клюшин Герман1) Как лучше - по таблице под каждый тип значения, или просто по столбцу? 2) Какой вариант хранения структуры лучше - рекурсивный (parentId) или вложенные множества? Может есть еще варианты хранения древовидных структур? 1) на мой взгляд все в одну таблицу значений, в одном и том же поле типа varchar или variant(в зависимости от СУБД). Это проще в сопровождении и разработке. Вариант с таблицей под каждый тип значений на мой взгляд особых преимуществ не дает. Не выносите только в EAV наименование и цену. Эти атрибуты есть у всех товаров (возможно какие то еще). 2) Сильно зависит от используемой СУБД. Современные промышленные поддерживают рекурсивные запросы по деревьям с возможностью получения различной информации по иерархии (connect by в Oracle и CTE/WITH в MSSQL), поэтому для таких СУБД нет смысла реализовывать дополнительный механизм на основе вложенных множеств. К тому же вложенные множества дают преимущества при поиске, но при update и insert могут стать узким местом если дерево большое, т.к. его приходится перенумеровывать полностью если новый узел добавляется близко к корню или к узлу имеющему большое поддерево. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2011, 22:51 |
|
||
|
Каталог товаров для интернет магазина (EAV)
|
|||
|---|---|---|---|
|
#18+
Клюшин ГерманПроектируется база под приложение аналогичное "яндекс-маркет". Две таблицы: собсно товары (наименование, код, что-то еще) и таблица атрибутов - код, имя атр. , значение - varchar, дата + метаописание - перечень всех атрибутов и их типов + одна или несколько таблиц классификаторов - они д.б. иерархическими ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2011, 09:19 |
|
||
|
Каталог товаров для интернет магазина (EAV)
|
|||
|---|---|---|---|
|
#18+
Роман Дынник1) на мой взгляд все в одну таблицу значений, в одном и том же поле типа varchar или variant(в зависимости от СУБД). Это проще в сопровождении и разработке. Вариант с таблицей под каждый тип значений на мой взгляд особых преимуществ не дает. Не выносите только в EAV наименование и цену. Эти атрибуты есть у всех товаров (возможно какие то еще). 2) Сильно зависит от используемой СУБД. Современные промышленные поддерживают рекурсивные запросы по деревьям с возможностью получения различной информации по иерархии (connect by в Oracle и CTE/WITH в MSSQL), поэтому для таких СУБД нет смысла реализовывать дополнительный механизм на основе вложенных множеств. К тому же вложенные множества дают преимущества при поиске, но при update и insert могут стать узким местом если дерево большое, т.к. его приходится перенумеровывать полностью если новый узел добавляется близко к корню или к узлу имеющему большое поддерево. СУБД скорее всего MySQL, потому надо придумывать какой нить изворот, чтобы создать дерево, и соответственно хранить параметры в varchare не получится, ибо нужен и поиск и сортировка по ним (или я что-то не так понял?) С другой стороны можно взять Firebird, с ним довольно долго работал, но имеет ли смысл использовать этот движок в web проекте, особенно если он будет довольно сильно нагружен (примерно 100 000 пользователей одновременно). Насчет Постгреса - сложно ли на него переквалифицироваться с MySQL? З.Ы. Насчет наименования и цены - ясное дело :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2011, 20:34 |
|
||
|
Каталог товаров для интернет магазина (EAV)
|
|||
|---|---|---|---|
|
#18+
Клюшин Герман(примерно 100 000 пользователей одновременно)ох уж мне эти прожектёры... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2011, 10:49 |
|
||
|
Каталог товаров для интернет магазина (EAV)
|
|||
|---|---|---|---|
|
#18+
miksoftКлюшин Герман(примерно 100 000 пользователей одновременно)ох уж мне эти прожектёры... Думаете нереальные данные? Для Яндекс маркета среднее посещаемость только по России в будние дни месяца Янв 2011 1 027 100 Дек 2010 1 062 900 Соответственно одновременно "сидит" на линии даже поболее :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2011, 12:55 |
|
||
|
Каталог товаров для интернет магазина (EAV)
|
|||
|---|---|---|---|
|
#18+
Клюшин Германmiksoftпропущено... ох уж мне эти прожектёры... Думаете нереальные данные? Для Яндекс маркета среднее посещаемость только по России в будние дни месяца Янв 2011 1 027 100 Дек 2010 1 062 900 Соответственно одновременно "сидит" на линии даже поболее :)Вы "дневная" от "одновременно" отличаете? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2011, 12:59 |
|
||
|
Каталог товаров для интернет магазина (EAV)
|
|||
|---|---|---|---|
|
#18+
miksoft, ну если всего в день более миллиона, то одновременная пиковая нагрузка в 100 000 может быть легко. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2011, 16:24 |
|
||
|
Каталог товаров для интернет магазина (EAV)
|
|||
|---|---|---|---|
|
#18+
Клюшин Германmiksoft, ну если всего в день более миллиона, то одновременная пиковая нагрузка в 100 000 может быть легко.Видимо, Ваша арифметика сильно отличается от общепринятой. Вот моя: Дано (или предполагается): 1) миллион пользователей в сутки 2) средний пользователь открывает 10 страниц 3) генерация одной страницы длится 1 секунду Тогда средняя интенсивность генерации страниц составляет: (1000000 пользвателей/сутки) / (24 часов/сутки) / (60 минут/час) / (60 секунд/минута) * 10 страниц/пользователь * 1 секунд/страница ~= 115 одновременных генераций страниц. Поправка на пиковые значения, максимум, один порядок. Т.е. пик составляет порядка тысячи одновременных генераций страниц. Возможно, я слегка ошибся в предположениях, но все равно не на два порядка. Да и вашему проекту до Яндекс.Маркета по посещаемости еще расти и расти. Я практически уверен, что чтобы достичь производительности, сравнимой с Я.М, вам придется переписывать всю систему с нуля. И, скорее всего, не один раз. Так что сейчас даже на три порядка меньшие цифры заморачиваться смысла не вижу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2011, 16:39 |
|
||
|
Каталог товаров для интернет магазина (EAV)
|
|||
|---|---|---|---|
|
#18+
Клюшин ГерманНасчет Постгреса - сложно ли на него переквалифицироваться с MySQL? Есть свои особенности БД, запросов и пр. Но если есть действительно уверенные знания а не "что-то слышал", то я думаю за пару месяцев легко освоите. Ну по ходу будете набивать шишек и получать практический опыт. Это собственно у всех так. Я б советовал при большом объеме сразу лепить на постгресе и не тратить время на мускул. Хотя опять таки все зависит от деталей. Но если это не ваше родное а делается на заказ клиенту то лепите на постгри. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2011, 17:50 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=37142220&tid=1542288]: |
0ms |
get settings: |
11ms |
get forum list: |
18ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
183ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
72ms |
get tp. blocked users: |
2ms |
| others: | 229ms |
| total: | 536ms |

| 0 / 0 |
