Люди, отвечающие на этот вопрос, не приходят к нему с точки зрения доступа, поэтому я приведу некоторые наблюдения, как кто-то, кто профессионально разрабатывает приложения Access с 1996 года.
Прежде всего, есть несколько мест, где у вас будет SQL в приложении Access:
сохраненные запросы.
сохраненные свойства форм, отчетов, полей со списками и списков.
в коде VBA, где вы пишете SQL на лету.
Организованно управлять всеми этими операторами SQL сложно, если не невозможно. Но я не уверен, что оно того стоит!
Прежде всего, рассмотрим только сохраненные запросы. Если вы последуете совету сохранения запроса для каждой отдельной задачи, чтобы каждый оператор SQL использовался только в одном месте, у вас скоро будет беспорядок в списке запросов, и вы будете вынуждены заключить какое-то соглашение об именах следить за тем, что к чему. Из-за этого я обычно не сохраняю запросы, КРОМЕ ТОГО, где они ДОЛЖНЫ быть сохранены, или где будет полезна оптимизация, которая идет с сохраненным запросом (то есть, большой набор данных или сложные объединения / фильтрация).
Например, когда я впервые начал программировать в Access, я сохранял все источники строк в своих полях со списком как сохраненные запросы. Я разработал соглашение об именах, чтобы они не смешивались с другими запросами в списке запросов, поэтому им было нетрудно управлять. Сначала я думал, что буду повторно использовать сохраненные запросы, но быстро стало ясно, что мне нужно вносить изменения для отдельных обстоятельств, и изменение запроса, который использовался в другом месте, может изменить его результаты в других контекстах, так что на самом деле, не было никакой выгоды "общего кода" для сохраненных запросов (как я думал, что будет). Единственное место, где это было полезно, - это когда у меня было одно и то же поле со списком в нескольких формах, и тогда я мог сохранить источник строк для этого как сохраненный запрос, и если мне нужно было изменить его, я мог бы это сделать только в одном месте. Тем не менее, это было действительно только преимуществом для относительно сложного источника строк - простой SELECT в нескольких полях на самом деле не дает такого общего доступа, особенно когда он используется только в нескольких разных местах.
Короче говоря, я быстро пришел к выводу, что было проще сохранить операторы SQL там, где они использовались - поскольку их было очень мало для повторного использования, во-первых (как только я приобрел достаточно опыта, чтобы понять ловушки попыток используйте их повторно), это работало намного лучше, и это держало SQL близко к тому месту, где он использовался.
Для форм и отчетов я делаю некоторые из тех же вещей, но в целом использую сохраненные запросы, чтобы избежать необходимости писать слишком много сложных подвыборов для использования в качестве производных таблиц. Там, где я нуждался в них, всегда было проще написать и сохранить его, а затем использовать его с JOIN в другом операторе SQL, чем пытаться использовать встроенный подвыбор в качестве производной таблицы (что делает сложный SQL трудным для чтения - особенно когда вы не можете комментировать или форматировать SQL, как в случае с сохраненными запросами Access).
Как правило, я не сохраняю источники записей форм или отчетов, за исключением случаев, когда происходит реальное повторное использование (отчет часто использует тот же источник записей, что и форма, поэтому в таком случае полезно сохранить его , чтобы при изменении SQL-формы отчет, сопровождающий его, наследовал изменение).
Все это оставляет динамический SQL собранным в коде VBA. Я использую многое из этого, от динамической установки источников строк комбо / списков, до настройки источников записей подчиненных форм для целей фильтрации. Это сложнее в управлении, и иногда я использую строковые константы в модуле, чтобы сделать это проще. Например, в случае, когда вы пишете динамический SQL, где все остается тем же, кроме предложения WHERE, константа с SELECT и вторая константа с ORDER BY значительно упрощают сборку полного оператора SQL.
Я не знаю, действительно ли это отвечает на ваши вопросы, но за многие годы я понял, что преимущества повторного использования операторов SQL значительно перевешиваются из-за неопределенности, связанной с невозможностью легко отследить, где этот оператор SQL может использоваться. Я считаю, что хранение статистики SQL как можно ближе к месту ее использования является наилучшей практикой, поскольку это форма «самодокументирования» (хотя и не самая лучшая!).
Я делаю много исключений и сохраняю запросы, когда есть реальное и очевидное преимущество с точки зрения производительности или управления тем, что в противном случае стало бы гораздо более сложным для SQL. Однако я также хотел бы отметить, что не следует заходить слишком далеко в другом направлении, используя тонны вложенных сохраненных запросов, потому что тогда вы столкнетесь с другими проблемами (то есть проблемой «слишком много баз данных», которая на самом деле вызвана использованием до 2048 дескрипторов стола, доступных за один раз - это сделать проще, чем вы думаете).