Проектирование базы данных каталога товаров

для 99% пхп кодеров это нафиг не надо, им бы просто запустить небольшой проект с 10-50 тысяч товаров максимум и чтобы работало на любом хостинге
А потом выесняется, что все сущности лежат в одной таблице с сотней атрибутов вида poleN.
 
А потом выесняется, что все сущности лежат в одной таблице с сотней атрибутов вида poleN.
даже если и так, что в этом плохого?
база должна разрабатываться под потребности конкретного проекта, а не по принципу "так должен кодить крутой спец по базам данных и всегда надо юзать sphinx"
 
max key length is 767 bytes
Да, длинные ключи - плохо (кушают память), хотя лимит можно поднять до 3072 через Для просмотра ссылки Войди или Зарегистрируйся. Так что да, без примари, но оставляем индекс product_id, attrib_id, все же быстрее.
search_hash - хорошее решение, но не для первичного ключа, из-за коллизий. А для индекса пойдет (не в вашем конкретном случае, а вообще). И туда лучше выбирать быструю хеш-функцию типа CRC32, писать/обновлять по триггеру, и выражение для обхода коллизий будет WHERE field_crc = CRC32('value') and field = 'value'.
для 99% пхп кодеров это нафиг не надо
ТС видео понравилось. Есть поновее. В нем просто заставляют задуматься над тем, что есть база данных. Что БД подходит для чего-то хорошо, а для чего-то плохо. Для транзакций и отношений - хорошо, но вот хитрый поиск по такой структуре может быть не быстрым. Поэтому существует такой термин как денормализация, чтобы движок БД не тратил время, "склеивая" уйму таблиц в одну мегатаблицу, которую еще потом и фильтровать-сортировать надо. А еще лучше сфинкс или монго ;)
база должна разрабатываться под потребности конкретного проекта
да, полностью согласен
ТС, посмотри еще в сторону инструмента pt-query-digest - он для мускула :) я бы забил таблицу тестовыми данными на 50-100 тыс, отключил кеш мускула и погонял разные выборки
(ну или SELECT SQL_NO_CACHE)

99% пхп не надо... да, а потом смотришь как сделаны популярные (!!!) опенсорс проекты типа виртуамарта, и диву даешься :) это каким же надо быть "профессионалом", чтобы делать так, как в нем накурочено :)
так что пусть лучше учится, делает свой движок, и чтобы мир был лучше, красивее и добрее :)
 
Последнее редактирование модератором:
10-50 тысяч товаров максимум
Я планирую около тысяч 600, а может вообще около 800 тысяч товаров, а опыта работы с такими большими базами данных у меня нет.
search_hash - хорошее решение, но не для первичного ключа, из-за коллизий
Просто я подумал брать хеш только поля Значение, и сделать составной трёхстолбцовый первичный ключ.

У одного товара в среднем 20 атрибутов, а это 16 000 000 записей в таблице атрибутов при 800 000 товаров. Я просто не знаю, как mysql будет с этим справляться.
 
Я планирую около тысяч 600, а может вообще около 800 тысяч товаров
ну раз так, тогда желаю успехов в освоении технологий
а по поводу потянет-непотянет: можно сделать тестовую базу, забить ее мусором и тестировать здесь и сейчас, а не тогда, когда будет 800 тыс реальных товаров
 
Возможно есть тогда смысл присмотреться к идеологии CQRS Для просмотра ссылки Войди или Зарегистрируйся

Конечно для такого объема предназначены корпоративные БД, типа MS SQL или Oracle. Они превосходно справляются с такими нагрузками, а вот насчет mysql я тоже не уверен, что потянет такой объем.
 
Я бы посоветовал таблицы атрибутов разделить на несколько таблиц по категориям товаров + одна общая для всех. Если это не сделать тогда на каждый товар может быть запись из 100 и больше атрибутов. Столкнулся с этим в системе "Мой склад" при импорте товаров с атрибутами - теперь при добавлении товара надо разыскивать атрибуты в огромнейшей форме, полей больше 100 точно, при том что категорий товара у меня 7.
 
Назад
Сверху