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

Статус
В этой теме нельзя размещать новые ответы.

2cher777

Постоялец
Регистрация
10 Мар 2018
Сообщения
300
Реакции
133
EAV с раскидыванием по кучей таблиц усложняет разработку. Очень удобно использовать для хранения "необязательных" и "множественных" параметров NoSQL подход. Очень удобна MongoDB.
В MySQL есть давно Для просмотра ссылки Войди или Зарегистрируйся. Поберегите свои нервы, не используйте EAV.
С 8й версии мускула только поддерживается?
 

metal-stroi-komplekt

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

bobrowss

Создатель
Регистрация
5 Апр 2018
Сообщения
13
Реакции
2
Если товаров до 5000, то все будет летать на такой структуре
Почему только для 5000? Если привязан в использовании MySQL, то такая схема в принципе единственно верная для оптимальной работы.
 

metal-stroi-komplekt

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

bobrowss

Создатель
Регистрация
5 Апр 2018
Сообщения
13
Реакции
2

metal-stroi-komplekt

Гуру форума
Регистрация
23 Дек 2012
Сообщения
187
Реакции
71
если голый select - наверное да. тут речь о селекте, который будет обвешан условиями...
 

bobrowss

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

bettelli

Создатель
Регистрация
16 Сен 2017
Сообщения
26
Реакции
7
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.
 

tizor

Писатель
Регистрация
14 Окт 2018
Сообщения
8
Реакции
1
Да, что в mysql, что в pgsql давно уже есть парсинг json.
 
Статус
В этой теме нельзя размещать новые ответы.
Сверху