Почти все системы, над которыми мы работали, связаны с инфраструктурой баз данных, и, несмотря на то, что мы, как разработчики, любим кодирующую часть наших проектов, база данных является «душой» системы из-за ее огромной ценности и влияния, которое может а также: безопасность, производительность, политику компании и т. д.
Я всегда был сторонником идеи рекомендуемого подхода для каждого отдельного разработчика, который должен понимать, что работает весь процесс: интерфейс, бэкэнд, база данных, UX и т. Д. Конечно, разработчики в целом сильнее в одной конкретной области из-за редкое время для учебы, личной жизни и прочего. Это трудный вызов.
Учитывая огромное количество передовых практик и советов, которые мы можем найти в отношении базы данных, список, представленный в этой статье, является небольшой частью всего, что можно было бы сказать, и он будет время от времени изменяться.
1. Существует
Если вам нужно вернуть в запросе данные из одной таблицы, которая соответствует определенному условию из второй таблицы, вместо использования подзапроса в предложении WHERE с операцией IN лучше использовать EXISTS пункт:
В большинстве сценариев этот способ обеспечивает превосходную производительность для всех реляционных баз данных.
2. Правильно используйте типы boolean или int.
В случае, если для таблицы требуется таблица, конкретный столбец которой ссылается на логические значения, например, чтобы указать, активен регистр или нет, выберите для этого столбца логический тип, а не «трюки» как «Y» или «N», для активный флаг, как тип VARCHAR. Я видел это больше, чем вы думаете.
3. Преобразование с UPPER, TO_CHAR и другими в предложениях WHERE.
Избегайте преобразования типа и формата значений столбца в предложении WHERE для создания фильтров. Если вы это сделаете, база данных, естественно, проигнорирует автоматические индексы, созданные для этих столбцов, которые станут процессом намного быстрее. Всегда учитывайте возможность хранить данные в том формате, для которого они будут больше использоваться.
4. Не используйте HAVING для фильтров данных
Если запрос должен вернуть группу определенных данных, лучше всегда выполнять эту операцию в предложении WHERE, а не в предложении HAVING. Предложение HAVING следует использовать для операций агрегирования, а не для простых фильтров.
5. Избегайте установки значений в переменных с помощью DUAL.
Если у вас есть опыт работы с Oracle, вы, вероятно, часто использовали предложение DUAL во многих ситуациях, но я бы рекомендовал вам не использовать его для установки переменных в процедурах, потому что он имеет плохую производительность в критических системах:
6. Будьте осторожны с максимальными значениями последовательности.
В базах данных Oracle (и других) при создании объекта SEQUENCE укажите чрезвычайно высокое значение в свойстве MAXVALUE. Это позволит избежать проблем в производстве, если эта последовательность используется в миллионах операций.
7. Объектно-ориентированная структура отличается от структуры базы данных.
В случае, если разработчик не имеет большого опыта работы с моделью базы данных, довольно часто при создании базы данных он «думает как разработчик» с сильным влиянием со стороны кода. Однако ORM (Entity Framework и т. Д.) Очень помогают нам в нашей работе, мы должны помнить, что не всегда модель базы данных должна быть похожей на модель класса. Иногда нам приходится использовать Dapper или другие варианты, а не Entity Framework. В определенных сценариях это поможет с производительностью.
8. Использование электронных представлений о процедурах магазина.
Когда мы не используем процедуры и представления, каждый раз при выполнении определенного запроса SGBD необходимо анализировать синтаксис, ссылку на объект и другие дополнительные проверки.
Когда код, который должен быть выполнен, находится внутри процедуры или представления, база данных пропускает эти проверки. Итак, процесс идет быстрее.
9. Типы чрезвычайно важны.
Позаботьтесь о типах своих столбцов, чтобы убедиться, что системе, использующей базу данных, требуются именно эти типы. Например, если в столбце будет храниться значение datetime, создайте поле как datetime. Избегайте конверсий! Кроме того, это гарантирует, что операции INSERT и UPDATE завершатся ошибкой, если тип неверен. Это хорошо.
10. Введите необходимые данные на SELECT.
Это, пожалуй, самый очевидный совет: если вашему приложению требуется только два столбца в результате, почему определенный запрос возвращает 50 столбцов ?! Я знаю, что у вас есть такие случаи в вашей компании;)
Миссия на завтра: рефакторинг.
11. Используйте кеш
Для частых запросов к часто не обновляемым данным рассмотрите возможность использования кеша на уровне приложения.
12. Типы переменных и параметров
Используйте для переменных и параметров в процедурах магазина правильный тип, даже в функциях. Они должны быть связаны с типом данных.
13. Используйте ORDER BY и DISTINCT только при необходимости.
Во многих случаях для определенных функций не требуются разделы sort и independent. Иногда мы хотим, например, просто отображать список на экране без какой-либо причины, чтобы упорядочить список, и мы это делаем. Итак, делайте это, только если это необходимо.
14. Настройки информации о языке и культуре.
Настройте свою базу данных на правильную информацию о культуре, которая будет связана с сохраненными данными и совместима с бизнес-требованиями. Это позволит избежать проблем с производительностью.
15. Использование «многорядных VALUES»
Если вам нужно вставить несколько строк в одну таблицу последовательно, лучше использовать приведенный ниже синтаксис, потому что он повысит производительность в критически важных системах, а также сэкономит время при кодировании:
16. Отслеживайте запросы
Всегда внимательно следите за производительностью запросов не только во время разработки, но даже в производственной среде, используя для этого подходящие инструменты. Если у вас нет доступа к нему, предложите его тем, у кого он есть.
Очень важно получать предупреждения в случае, если запрос не имеет ожидаемой производительности для выполнения некоторых действий.
17. Используйте индекс в очень популярных столбцах.
Если необходимо создать индекс для повышения производительности запросов, задайте себе следующие вопросы:
Какой столбец требуется чаще всего?
Будет ли удобно изменить модель / структуру базы данных для повышения производительности?
18. Будьте осторожны при использовании индекса в часто обновляемых столбцах.
Использование индекса не всегда является хорошей альтернативой в определенных сценариях. Один из них - это когда индекс создается в столбцах, которые часто обновляются, с множеством транзакций. Даже при наличии благих намерений цель по увеличению производительности запросов может иметь противоположный результат для операций INSERT, DELETE и UPDATE в одной и той же таблице.
Таким образом, создание индекса требует перед этим тщательного анализа.
19. Индекс в столбцах, часто используемых в предложениях WHERE, JOIN, ORDER BY и TOP.
Хорошая практика - проверить, удобно ли создавать индекс в столбце, который часто используется в предложениях WHERE, JOIN, ORDER BY и TOP. В этом случае столбец является хорошим кандидатом для сопоставления индекса.
20. Не оставляйте внешние ключи на потом
Ребята, это очевидно: не создавайте фальшивых отношений между таблицами. Правильно создавайте внешние ключи и первичные ключи. (извиняюсь)
21. Оптимизированные журнальные таблицы
Каждая система содержит таблицы для регистрации системных и пользовательских операций по юридическим причинам. Но если ваша таблица журналов огромна, рассмотрите возможность перемещения старых данных и хранения данных в другом месте.
23. Таблицы без первичного ключа
Да, он существует в реальной жизни и на производстве во многих компаниях. Не делай этого, пожалуйста. Первичный ключ обязательно для реляционных баз данных.
24. Найдите время, чтобы спланировать свою базу данных.
База данных - одна из самых важных частей системы. Не стоит недооценивать работу, которую вам нужно потратить на планирование хорошей структуры.
25. Получите реальные знания о базах данных.
В наши дни многие разработчики используют только ORM для взаимодействия с базами данных и никогда не писали ни одного запроса вручную. Очень важно понимать, как работают SGBD, реляционные базы данных, стоимость операций и т. Д. Потратьте время на их изучение.
26. ИСПОЛЬЗУЙТЕ NOLOCK
Для SQL Server и других баз данных используйте NOLOCK, если запрос возвращает данные только для чтения.
27. Будьте осторожны с подзапросами.
Подзапросы часто используются во многих сценариях, но перед их использованием подумайте, как достичь той же цели в другом режиме. Если нет возможности, то воспользуйтесь.
28. Следите за исключениями SQL.
Часто проверяйте, нет ли в вашей системе исключений базы данных, таких как вставка недопустимых данных. Это могло вызвать ненужные проблемы с производительностью. Сначала исправьте свою систему.
29. Иногда пишите свои собственные запросы.
Иногда не стоит слишком доверять Entity Framework или другому ORM, чтобы сделать всю работу за вас. Для высокопроизводительных систем рассмотрите возможность создания пользовательских запросов для наиболее важных.
30. ОБНОВЛЕНИЕ без ГДЕ
Заключение
Надеюсь, эта статья вам помогла. Спасибо, что прочитали это.
Ниже мои профили в социальных сетях. Не стесняйтесь подключиться и задать вопрос. В этих профилях я часто делюсь контентом о веб-технологиях и ИТ-мероприятиях.
Twitter: https://twitter.com/alemalavasi
Linkedin: https://www.linkedin.com/in/alexandremalavasi/
Я также недавно создал канал Youtube, чтобы внести свой вклад в техническое сообщество, использующее эту платформу, с упором на .NET Core, Vue JS, Azure и другие. Если вам интересны эти темы, рекомендую подписаться.
Youtube: https://www.youtube.com/channel/UC-KFGgYiot1eA8QFqIgLmqA
Моя книга
Рад сообщить, что у меня вышла моя первая книга. Это подробный практический обзор наиболее распространенных шаблонов проектирования, используемых в приложениях .NET. Книга содержит сотни примеров кода и объяснений, основанных на реальных сценариях. В нем также есть много примеров объектно-ориентированного программирования, принципов SOLID и все способы познакомиться с .NET 5 и C #. Проверить это:
