@likilix
Лицемер

Как сделать анализ и спроектировать сложный SQL-запрос?

Мне предстоит разработать сложный отчёт с различными итоговыми строками, который строится из 15-20 таблиц.

Есть ли какие-нибудь методики для предварительного анализа и проектирования SQL-кода, подобно как в ООП?
  • Вопрос задан
  • 509 просмотров
Пригласить эксперта
Ответы на вопрос 4
@Dmtm
Android
"надо проектировать так как надо, а как не надо - проектировать не надо" - какой еще анализ кроме общих правил SQL? типа по индексу лучше чем без, а JOIN лучше IN
есть же хранимые процедуры - не нужно умещать все в один запрос (и да, временные таблицы - это нормально)
Ответ написан
@FanatPHP
Чебуратор тега PHP
принцип очень простой.
Я его использую при оптимизации тормозящих запросов, только в другом направлении.

Если сложный запрос тормозит, то я по очереди из него выкидываю все джойны и подзапросы до тех пор, пока торможение сохраняется. И дальше уже занимаюсь оптимизацией упрощенной версии. Обычно это две-три таблицы.

Тот же самый принцип при проектировании, только в обратную сторону - сначала получаем базовые данные, голый хребет, без украшений. Если из связанной таблицы мы получаем значение по первичному ключу (скажем название категории по её айди), то добавляем её в последнюю очередь, поскольку она ни на что не влияет. Начинаем с основнй таблиы с данными - и вперёд

То есть грубо говоря сначала формируем логику, потом добавляем украшения.
Ответ написан
BojackHorseman
@BojackHorseman Куратор тега SQL
...в творческом отпуске...
SQL - "язык СТРУКТУРИРОВАННЫХ запросов". еще и декларативный, причем тут вообще ООП. PL/SQL - процедурный язык, что следует из названия. и для него применимы любые принципы программирования на процедурных языках.

вот и структурируйте. разбивайте на процедуры. алгоритмизируйте.
Ответ написан
@d-stream
Готовые решения - не подаю, но...
Как уже подметил Лентюй - SQL изначально был ориентирован на своего рода "ботаников" - чтобы они писали "что они хотят увидеть". Остальное - дело интерпретатора-планировщика.
И начинать надо именно с этого. В 90% случаев планировщик sql сможет построить план запроса так, что он окажется гораздо оптимальнее, чем наоптимизирует любитель.
И только в случае действительно медленного отклика - можно будет о тонких местах и погрузится в волшебный мир индексов-хэшей-лимитов памяти-хинтов и т.п. )
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы
18 сент. 2020, в 21:23
2500 руб./за проект
18 сент. 2020, в 20:16
13000 руб./за проект
18 сент. 2020, в 19:05
25000 руб./за проект