Лично я бы не стал беспокоиться о чистом коде с точки зрения базы данных. Вам нужно беспокоиться о целостности данных, производительности и безопасности.
Я считаю, что по мере того, как вы лучше знакомитесь с моделью базы данных, вам станет легче понимать эти длинные процессы. Некоторые вещи, которые я делаю, чтобы помочь устранить неполадки позже: Если proc имеет динамический sql, всегда пишите его с режимом переменной отладки, который вы можете использовать для захвата построенного кода SQL. Это сэкономит часы времени на устранение неполадок.
Если процесс выполняет много работы, обязательно поместите его в транзакции с блоками Try Catch, чтобы все было отброшено в случае возникновения проблемы. Вы также можете воспользоваться тем фактом, что откаты не влияют на табличные переменные и сохраняют информацию об отладке и ошибках, которая вам понадобится в таблице исключений после отката. Это значительно облегчит проду, чтобы увидеть, что происходит, когда он терпит неудачу.
Старайтесь быть последовательными в своем интервале и структуре. Существуют различные инструменты, которые вы можете использовать для форматирования. И последовательное сглаживание тоже помогает. Псевдоним, на который ссылается каждое поле, потому что через 6 месяцев вы можете легко не вспомнить, из какого поля оно пришло. Лично мне намного легче понять длинные процессы, если все внутренние соединения находятся перед левыми соединениями. Это позволяет мне легко увидеть, в каких таблицах должны быть данные, и если результаты неверны, часто виновата одна из них, потому что это должно быть левое соединение.
Будьте последовательны в типах данных параметров. Сделайте их соответствующими типу данных базы данных поля, на которое вы будете ссылаться с этим параметром.
Храните все в системе контроля версий и безжалостно удаляйте весь закомментированный код. Если параметр не используется, избавьтесь от него. Если что-то жестко закодировано, вы можете преобразовать его в параметр, особенно если он используется более одного раза.
Если у вас есть какая-то бизнес-логика, в которой, возможно, будет непросто разобраться позже, оставьте поясняющий комментарий.
Старайтесь создавать новые процедуры по разделам, чтобы вы могли легко проверять результаты по ходу дела. Так, например, предположим, что вы составляете финансовый отчет обо всех возвращенных заказах. Вы можете сначала написать cte или временную таблицу или табличную переменную, чтобы получить все результаты. Затем вы можете присоединиться к этому, чтобы получить финансовые отчеты только для этих доходов и агрегировать их. Затем, наконец, вы присоедините все это к другим деталям, которые вам нужны в отчете. Таким образом, вы можете проверить, запустив только первую часть и увидев, что за период получено 2098 возвратов. После того, как вы агрегируете финансовую информацию, у вас должна быть одна запись для каждой из этих 2098 деклараций. Затем в конце вы увидите, что у вас все еще есть все необходимые записи. Это помогает убедиться, что вы ничего не потеряли по пути, присоединяясь, если только данные не являются такими, которые вам нужны, и вы понимаете, почему вы это сделали. Вы также можете увидеть, получаете ли вы дополнительные записи от соединений с одной ко многим таблицам, которые могут быть или не быть подходящими (именно поэтому понимание модели данных имеет решающее значение).
Если вы собираетесь писать сложный sql, вам нужно прочитать несколько книг по настройке производительности (узнать, какие конструкции, такие как коррелированные подзапросы и курсоры, и что использовать вместо них), чтобы избежать использования и как убедиться, что ваши предложения where доступны для анализа. Существует несколько книг по настройке производительности SQL Server. Вам также необходимо прочитать книгу об антипаттернах SQL, которая будет гораздо полезнее, чем чистые книги по коду: https://rads.stackoverflow.com/amzn/click/com/1934356557
person
HLGEM
schedule
28.07.2014
