80 запросов слишком много?

Question

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

Iникогда раньше не использовал базу данных, и что-то подсказывает мне, что, возможно, у меня не должно быть 80 разных запросов, заполняющих 80 разных подотчетов.Я не знаю, может быть, все в порядке.Но это мой вопрос, есть ли причина, по которой я должен вернуться и повторить некоторые из этих запросов и объединить их, возможно, в 20 или 30 (что потребует от меня повторения подотчетов и основных отчетов), или это совершенно нормально?сохраните в моей базе данных столько запросов.

Имейте в виду, что каждый запрос, хотя и содержащий только 2 или 3 функции каждый, имеет очень специфическую задачу, от которой я не могу полностью избавиться, я мог бы толькодобавьте эти функции в более крупный запрос, объединив несколько типов запросов.Кроме того, как я уже сказал, я должен использовать эти запросы еженедельно, поэтому я не хочу создавать их на лету, как это делают некоторые люди.

В любом случае, есть ли непредвиденная проблемачто мне не хватает такого количества запросов, или это нормально?

Answer 1

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

Я бы просто позаботился о том, чтобы все запросы работали индивидуально с вашим целевым набором данных. Он может отлично работать против 50 строк в разработке, но у вас есть 1M строк в работе.

Но если он работает достаточно быстро для вашей производственной БД, то покончим с этим и решим другую проблему.

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

Answer 2

Это чертовски отчет. Наличие 80 запросов в базе данных не так уж и плохо. Имея 80 запросов для одного отчета ...

Если производительность не является проблемой, у вас может не быть проблемы.

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

Answer 3

Не зная всех подробностей, невозможно ответить, нужно ли вам иметь 20, 80 или 200 запросов. Тем не менее, наличие большего количества запросов ничего не повредит, и, как правило, для ваших запросов лучше сосредоточиться на том, для чего они конкретно нужны, а не на меньшем количестве запросов общего назначения, которые возвращают больше данных, чем действительно необходимо.

Если у вас меньше и менее сфокусированных запросов, и вам нужно изменить отчет / запрос для отображения дополнительных данных, вам, вероятно, придется вернуться и повторно протестировать все отчеты, основанные на том же запросе, для их данных, чтобы убедитесь, что они не были нарушены изменениями.

Answer 4

Почему запросы должны быть сохранены?У вас вполне может быть много подотчетов report / s, но вы можете просто сохранить SQL SELECT как свойства Recordsource рассматриваемых отчетов, без необходимости сохранять SQL как сохраненный запрос.

Я стараюсь свести к минимуму количество сохраненных запросов, потому что чем больше у вас запросов, тем сложнее их отслеживать.А потом вам в конечном итоге нужно придумать какие-то соглашения об именах, чтобы вы могли сказать, что к чему, и затем в конечном итоге вы получите беспорядок.

Кроме того, повторное использование не является причиной для этого,В общем, хорошо повторно использовать объекты, но проблема с сохраненными QueryDefs заключается в том, что нет простого способа проверить зависимости (хотя, если вы включите автозамену имени, вы увидите, где используется запрос).Таким образом, действительно легко, если вы повторно используете запросы, чтобы внести изменения в один контекст, который нарушает запрос в другом (их) контексте (ах), в котором он используется.Так что, в общем, я не использую повторно сохраненные запросы, за исключением случаев, когда набор данных действительно будет идентичен в 100% случаев (например, форма и отчет, которые представляют абсолютно одинаковые данные).

Так что, в принципе, я бы сказал, что 80 сохраненных запросов - это не проблема в приложении приличного размера, но из того, что вы описали, я не вижу причин, почему SQL должен вообще храниться в сохраненных запросах.В этом случае сохраненные запросы будут иметь нулевое значение.

См. Мой недавний пост по вопросу Практика проектирования запросов в SQL .