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

[nejtr0n]

для 99% пхп кодеров это нафиг не надо, им бы просто запустить небольшой проект с 10-50 тысяч товаров максимум и чтобы работало на любом хостинге

А потом выесняется, что все сущности лежат в одной таблице с сотней атрибутов вида poleN.

 

[denverkurt]

А потом выесняется, что все сущности лежат в одной таблице с сотней атрибутов вида poleN.

даже если и так, что в этом плохого?
база должна разрабатываться под потребности конкретного проекта, а не по принципу "так должен кодить крутой спец по базам данных и всегда надо юзать sphinx"

 

[Black Hat]

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% пхп не надо... да, а потом смотришь как сделаны популярные (!!!) опенсорс проекты типа виртуамарта, и диву даешься это каким же надо быть "профессионалом", чтобы делать так, как в нем накурочено
так что пусть лучше учится, делает свой движок, и чтобы мир был лучше, красивее и добрее

 

[grave_bird]

10-50 тысяч товаров максимум

Я планирую около тысяч 600, а может вообще около 800 тысяч товаров, а опыта работы с такими большими базами данных у меня нет.

search_hash - хорошее решение, но не для первичного ключа, из-за коллизий

Просто я подумал брать хеш только поля Значение, и сделать составной трёхстолбцовый первичный ключ.

У одного товара в среднем 20 атрибутов, а это 16 000 000 записей в таблице атрибутов при 800 000 товаров. Я просто не знаю, как mysql будет с этим справляться.

 

[denverkurt]

Я планирую около тысяч 600, а может вообще около 800 тысяч товаров

ну раз так, тогда желаю успехов в освоении технологий
а по поводу потянет-непотянет: можно сделать тестовую базу, забить ее мусором и тестировать здесь и сейчас, а не тогда, когда будет 800 тыс реальных товаров

 

[serebro.konst]

Возможно есть тогда смысл присмотреться к идеологии CQRS Для просмотра ссылки Войди или Зарегистрируйся

Конечно для такого объема предназначены корпоративные БД, типа MS SQL или Oracle. Они превосходно справляются с такими нагрузками, а вот насчет mysql я тоже не уверен, что потянет такой объем.

 

[GowarD]

Я бы посоветовал таблицы атрибутов разделить на несколько таблиц по категориям товаров + одна общая для всех. Если это не сделать тогда на каждый товар может быть запись из 100 и больше атрибутов. Столкнулся с этим в системе "Мой склад" при импорте товаров с атрибутами - теперь при добавлении товара надо разыскивать атрибуты в огромнейшей форме, полей больше 100 точно, при том что категорий товара у меня 7.