действительно ли там такая вещь как запрос, являющийся слишком большим?

Я просто переименовывает метод тестового корпуса с подчеркиванием: test_myfunc становится _test_myfunc.

Количество символов не означает, что запрос должен быть оптимизирован - это то, что вы см. в тех символов, которые выполняют.

Вещи, такие как подзапросы на вершине подзапросов, это то, что я бы рассмотрел. Я также рассмотрю присоединившись, но он не должен долго сравнивать с ERD, чтобы знать, есть ли ненужное присоединение - первое, что я бы посмотрю, будет то, какие таблицы присоединяются, но не используются на выходе, что Хорошо, если таблицы являются ссылками / заметными / и т. Д.

Если вы хотите применять строгие категории и подкатегории, но также иметь возможность выполнять быстрый поиск с результатами, как вы описываете, вы можете сделать Таблица « тэг», в которой пользователи фактически не могут сами маркировать предметы, но сразу после назначения категории предмету заполняется таблица тэгов для этого предмета со всеми родительскими категориями вплоть до корневого узла дерева категорий.

Например, если имеется следующее: alt text http://img509.yfrog.com/img509/9845/photoho.jpg

Таблица тэга будет выглядеть примерно так:

   id   |   tag_name   |   tv_id
   1    |     "tv"     |     1
   2    |     "sd"     |     1    
   3    |     "crt"    |     1  
   4    |     "tv"     |     2  
   5    |     "HD"     |     2  
   6    |     "LCD"    |     2  
   7    |     "tv"     |     3  
   8    |     "HD"     |     3  
   9    |   "plasma"   |     3

Теперь ваш запрос будет выглядеть как предметы = Item.objects.filter (тэг = 'TV')

Там, где я работаю, мы создали хранимые процедуры, которые превышают 1000 символов. Я не могу сказать, что это было НЕОБХОДИМО, но иногда спешка выигрывает над эффективностью (особенно, когда быстрое исправление необходимо для клиента).

Сказав, что... если бы мне дали время, я бы попытался оптимизировать запрос настолько маленький/эффективный, насколько он может получить, без того, чтобы он был слишком запутанным. Я использовал вложенные хранимые процедуры, чтобы сделать вещи более четкими и/или функциями.

Как и в других языках, невозможно определить эффективность запроса на основе количества символов. Кроме того, 1000 символов - это не то, что я мог бы назвать «большим», особенно когда вы используете хорошие имена таблиц/столбцов, псевдонимы, которые имеют смысл, и т.д.

Если вы не достаточно комфортно с SQL, чтобы иметь возможность «очко» дизайн достоинств конкретного запроса, запустить его через профилировщик и изучить план выполнения. Это даст вам хорошее представление о проблемах, от которых пострадает данный код.

Мое правило большого пальца таково: напишите лучший, самый жесткий, самый простой код, который вы можете, и оптимизируйте, где необходимо - то есть, где вы видите узкое место производительности или где (как это часто бывает) вы шлепнете себя в голову и говорите «D'OH!» около трех часов ночи в отпуске.

Резюме: Код хорошо, и оптимизировать, где необходимо.

Как сказал Роберт, если вы не можете легко сказать, что делает запрос, его, вероятно, нужно упростить.

Я бы предположил, что это не персонажи, которые должны измерять размер / сложность запроса.

Я заваливаю его до:

• Что такое цель запроса?
• Использует ли он настроенную логику?
• делает его повторно использовать какие-либо компоненты?
• это присоединяется к неправильно / Плохо?
• Каковы последствия производительности?
• Проблемы ремонтопригодности - это написано так, что другой разработчик может ворчать свои намерения?

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

Когда я вижу сложный запрос, моя первая мысль - это возвращает то, что разработчик действительно намеревался вернуться (вы будете удивлены тем, как часто ответ на это нет), а затем я смотрю, чтобы это могло бы быть производительность настроена. Да, там много плохо написанных длинных запросов, но есть также столько или более, которые делают то, что они предназначены для того, чтобы сделать так же быстро, как это можно сделать без основной базы данных Redesign или более быстрого оборудования.

, где я работаю, мы создали сохраненные процедуры, которые превышают 1000 символов. Я не могу сказать, что это необходимо, но иногда спешность побеждает по поводу эффективности (в частности, при необходимости для клиента необходима быстрое исправление).

Сказав, что ... если учитывая время, я бы попытался оптимизировать запрос как маленький / эффективный, так как оно может получить без него. Я использовал вложенные хранимые процедуры, чтобы сделать вещи немного более понятными и / или функциями.