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

Question

[likilix]

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

Есть ли какие-нибудь методики для предварительного анализа и проектирования SQL-кода, подобно как в ООП?

Answer 1

[Dmtm]

"надо проектировать так как надо, а как не надо - проектировать не надо" - какой еще анализ кроме общих правил SQL? типа по индексу лучше чем без, а JOIN лучше IN
есть же хранимые процедуры - не нужно умещать все в один запрос (и да, временные таблицы - это нормально)

Comments

[Евгений]

>типа по индексу лучше чем без
Кроме тех случаев, когда по индексу хуже :)

[polzovatel_vue]

Я попробовал так. Но чистый лист выходит (в темплейте ничего нет)

Answer 2

[FanatPHP]

принцип очень простой.
Я его использую при оптимизации тормозящих запросов, только в другом направлении.

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

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

То есть грубо говоря сначала формируем логику, потом добавляем украшения.

Answer 3

[d-stream]

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