Как записать параметры в БД

С 8й версии мускула только поддерживается?

 

MySQL 5.7.8, а также MariaDB 10.2.7, Percona 5.7

 

Если товаров до 5000, то все будет летать на такой структуре:
таблица товаров: ID , бла, блабла, ...
таблица опции: ID(int11), IDтовара(int11), ID_Тип-Опции(int11), Значение_Опции(var255)
ну до кучи можно еще и третью таблицу, где названия опции хранить, но проще в php подставлять НАЗВАНИЕ опции согласно ТИПа опции
Что такое ТипОпции? Это число (для экономного хранения в БД и быстрого поиска по числу!), например:
1 - это цвет, 2 - ширина, 3 - длина, 4 - вес, ...
В Значение_Опции соответственно пишем - голубой, или 436 или 623 или 3.400
Это немного не по стандартам, по стандарту - три таблицы, где в 3-ей будут храниться названия опции, но на малом магазе и так попрет! Т.е. названия опции ты простопомнишь и в php их подставляешь в зависимости от ID_Тип-Опции

 

Почему только для 5000? Если привязан в использовании MySQL, то такая схема в принципе единственно верная для оптимальной работы.

 

ну потому, что будет разбухшая таблица опции,если например берем 10000 товаров да по 5 опции, то что получится- 10000 строк в таблице product и 50000 строк в таблице опций))) И при выводе странички товара придется пробегать по всей таблице опций, чтобы найти все опции товара, опции редко идут по порядку, что-то добавляют к товару позже и т.д. Вот и получается вперемешку.. Но все решает эксперимент, да и запросы конструировать всяко проще всего на такой структуре, это к бабке не ходи!)))

 

Что значит пробегать? SELECT самая малая по затратам ресурсов в MySQL насколько мне известно.

 

если голый select - наверное да. тут речь о селекте, который будет обвешан условиями...

 

SELECT обвешанный LEFT JOIN - ами скорее. Но это только позволит затрагивать несколько таблиц. Но выгода в оптимизации хранения информации думаю очевидна. У меня есть проекты с миллионами записей в таблице, никакого торможения не замечается. Сейчас ведь уже новый миллениум. Серваки уже давно мультипроцессорные)

 

One common mistake is assuming that MySQL provides results on demand, rather than calculating and returning the full result set. We often see this in applications designed by people familiar with other database systems.

 

Да, что в mysql, что в pgsql давно уже есть парсинг json.