|
Задавайте вопросы, мы ответим
Вы не зашли.
Здравствуйте! Предупреждаю, что крайне слабо разбираюсь в sql. Делаю модуль с таблицами (в основном прайс-листы) на PHP, mySQL и JS. Могу изменять структуру таблиц и всего как угодно, но не могу понять как правильно.
Есть TABLES, которая хранит номера строк через запятую. Есть таблица со строками TABLES_STRINGS, которая хранит ID строк и номера блоков, из которых она состоит. Одна строка может быть в разных таблицах. В таблице TABLES_BLOCKS блоки хранят свои ID, NAME и какие-то свойства, но без содержимого. У каждого блока может быть неограниченное количество вариаций содержимого - они хранятся в таблице TABLES_BLOCKS_VAR со своими ID и т.п. Есть таблица TABLES_STRINGS_BLOCKS_VAR, которая хранит информацию о том, в какой таблице какая вариация блока в строке (TABLE_ID, STRING_ID, BLOCK_ID, VAR_ID).
Всё это сделано для сколь угодно таблиц(прайсов) с разным составом строк, но где-то может отличаться тайтл или цена или другой блок. Зато, если поменять цену в одном блоке, то цена поменяется во всех таблицах, где она есть. Какая-то синхронизация. Для sql я пользуюсь библиотекой ORM RedbeanPHP, в ней можно и простые запросы делать.
Вопросы:
1) Если писать вложенные запросы или JOIN-ами делать, будет ли какой-то профит в скорости? Стоит ли оно того?
2) Проще не париться и сделать несколькими запросами? можно упростить и хранить JSON в самой первой таблице с строками, блоками и их вариантами. Далее разобрать всё в PHP, но это уже будет не один запрос к базе, а как минимум 2-3. Стоит ли?
3) Многие ко многим, один ко многим - это моя тема, как то может помочь? Никак не могу понять(
Я уверен, что можно сделать лучше, но не понимаю как. Не хотелось бы месяцы тратить на изучение. Помогите, пожалуйста правильно раскидать задачу.
P.S. Есть таблица excel с демо-версией таблиц и запросом с JOIN-ами в прикреплённом и по ссылке на Я.диске: https://disk.yandex.ru/i/oR98-Pt62ZZeIw
Неактивен
Хранить через запятую - это очень порочная практика, крайне не рекомендуется. Хранить в json тоже нужно "с умом", то есть лишь тогда, когда это действительно нужно.
1) чаще join лучше чем вложенный запрос.
2) лучше несколько простых быстрых запросов, чем один сложный.
3) да, многие ко многим и один ко многим - похоже на то, что лучше использовать
>Не хотелось бы месяцы тратить на изучение.
Ну тогда нужно найти того, что потратит эти месяцы или уже потратил... что ж тут еще посоветовать ;-).
Неактивен
deadka написал:
Хранить через запятую - это очень порочная практика, крайне не рекомендуется. Хранить в json тоже нужно "с умом", то есть лишь тогда, когда это действительно нужно.
1) чаще join лучше чем вложенный запрос.
2) лучше несколько простых быстрых запросов, чем один сложный.
3) да, многие ко многим и один ко многим - похоже на то, что лучше использовать
>Не хотелось бы месяцы тратить на изучение.
Ну тогда нужно найти того, что потратит эти месяцы или уже потратил... что ж тут еще посоветовать ;-).
Благослови вас господь! Кто-то адекватный ответ написал в SQL-сообществе) А можно еще вопросик?) А если использовать JSON для хранения списка строк, блоков. Новые версии mySQL из коробки умеют JSON. Или это фуфло?
Неактивен
Умеют, начиная с 5.7
https://sqlinfo.ru/articles/info/20.html
Но, повторяю - не стоит это использовать без чОткого понимания, зачем это нужно
Неактивен
