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

Question

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

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

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

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

Answer 1

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

Если у вас есть НЕКОТОРОЕ время, которое вы можете посвятить этому, то рефакторинг сейчас даст вам две вещи:

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

Answer 2

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

Answer 3

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

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

Answer 4

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

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

Answer 5

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

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