Как мне «рефакторировать» SQL-запросы?

Question

У меня есть несколько запросов MS Access (в представлениях и хранимых процедурах), которые я конвертирую в SQL Server 2000 (T-SQL). Из-за ограничений Access в отношении подзапросов и ограничений оригинального разработчика было создано много представлений, которые функционируют только как подзапросы для других представлений.

У меня нет четкой спецификации бизнес-требований, кроме как «делать то, что делает приложение Access», и половины страницы заметок в отчетах/выдержках из CSV, но приложение Access даже не делает то, что я подозреваю требуется должным образом.

Поэтому я должен принять подход «снизу вверх» и «скопировать» БД доступа в T-SQL, где я бы обычно лучше понимал требования и применял подход сверху вниз, создавая новые запросы для удовлетворения четко определенные требования.

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

Answer 1

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

Answer 2

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

Например, SQL Server может рассказать вам, какие виды, хранимые процедуры и т. Д. Опираться на конкретный вид, поэтому вы можете видеть, есть ли представление одно или если оно фактически используется в нескольких местах , Это поможет вам определить, какие взгляды важнее, чем это.

Answer 3

Я бы, вероятно, начал с базы данных Access, выполнял запросы на месте и видел, что такое набор результатов. Часто вы можете понять, что выполняет запрос, а затем вернуться к своему собственному дизайну для его выполнения. (Чтобы быть основательным, вам все равно нужно понять намерение). И это звучит как лучший отчет о требованиях, которые вы получите - «Как будто это реализовано сейчас».

Помимо этого, вы подходите, это лучшее, что я могу придумать. Как только они появятся в SQL Server, просто начните тестирование и grokking.

Answer 4

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

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

Answer 5

Это зависит от вашей временной шкалы. Если вам нужно как можно быстрее запустить проект (я знаю, что это верно для проекта КАЖДЫЙ, но если это действительно верно для вас), то да, дублируйте функциональность и инфраструктуру от Access, а затем выполните рефакторинг позже или как ты иди.

Если у вас есть какое-то время вы можете посвятить его, а затем рефакторинга теперь будет давать вам две вещи:

1. Вы будете счастливы с кодом, и он будет (скорее всего) работать лучше, так как фактический анализ был выполнен, а не транскодирующий эквивалент копии-пасты
2. Вероятнее всего, вы получите более полное представление о том, что такое настоящие бизнес-правила, поскольку вы почти наверняка столкнетесь с вещами, которые не находятся в спецификации (особенно учитывая, как вы их описываете)