Привет, Хабр! Представляю Вашему вниманию небольшой список рекомендаций по разработке и сопровождению баз данных. Надеюсь будет полезным!

Я постарался составить достаточно универсальный список, но все же, некоторые советы могут быть не применимы к определенным базам данных (версиям) и типам приложений. Большинство рекомендаций было мной использовано в реальных проектах, например, в одном из проектов простое увеличение FetchSize позволили ускорить загрузку приложения в три раза.

Проектирование

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

   Наиболее частый анти-паттерн в схемах это широкая таблица.

   Приведу парочку таблиц, с которыми мне приходилось сталкиваться в проектах.

   Table: Usl, Cols: Usl1..Usl88, далее в приложениях ну очень интересный код типа Usl1+..+Usl88

   Table: DDUContracts, Cols: FirstPay,FirsPayDate, SecondPay, SecondPayDate - ну вы поняли, первой задачей в данном проекте мне было добавить третий платеж :)

   Table: Contragents, Cols: Addr1, Addr2, Phone, MobilePhone - тоже реальный пример, попробуйте добавить третий адрес или новый тип телефона.

   Table: GoodTable, Cols: Fld1,Fld2....Fld300

2. При проектировании схемы хранения, если сложно определиться с уровнем нормализации, лучше использовать третью нормальную форму.

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

4. Все объекты (таблицы, колонки, представления и т.д.) необходимо тщательно комментировать. Если в используемой базе данных предусмотрены комментарии, желательно использовать данные механизмы;  если база данных не поддерживает комментарий, можно разработать собственный механизм хранения комментариев.

5. Старайтесь минимизировать использование вызовы функций в условиях WHERE.  Вызовы функций могут мешать использованию индексов и сильно замедлять получение данных.

6. При написании SQL запросов особое внимание стоит обращать на количество логических чтений. Большое количество логических чтений обычно указывает на недостаточное покрытие запроса индексами (Sargable).

7. В процессе проектирования и разработки базы данных старайтесь полностью изучить механизмы предоставляемые поставщиком базы данных, например, в Microsoft SQL Server последних версии существуют таблицы хранимые в памяти и хранимые вычисляемые колонки.

8. Если проект предусматривает поддержку нескольких баз данных, старайтесь применять ANSI SQL и не используйте слишком специфичные инструменты без сильной необходимости.

9. В современной практике разработки не рекомендуется использовать такой механизм баз данных, как хранимые процедуры, это сильно ограничивает возможность изменения поставщика базы данных.

10. Старайтесь изучать и избегать узкие места, заложенные проектировщиками используемой базы данных, например, функция NVL(a,b) в Oracle интерпретирует оба аргумента. Если аргумент b является подзапросом или вызовом функции, лучше использовать функцию COALESCE.

11. Примите во внимание, что сложные базы данных содержат достаточно много ошибок. Постарайтесь ознакомиться со списком известных ошибок и принять во внимание данный фактор.

12. Весь код исполняемых объектов  (функции, процедуры, триггеры и т.д.) должен содержать подробное описание, желательно с работающими примерами вызовов и результатами.

13. Если в БД существует достаточно большое количество вспомогательных самописных функций и процедур, должен существовать подробный список с описанием. Вместо списка можно использовать отдельную схему или соглашения по именованию, например, вспомогательные функции по работе с датами можно создать в отдельной схеме UtilsDateTime.

14. Названия таблиц в множественном числе помогут избежать использования зарезервированных слов. Их, кстати, удивительно много в базах данных.

Рефакторинг и сопровождение баз данных

15. Настройте и протестируйте механизмы бекапов.

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

17. Для удобства разработки и сопровождения в достаточно больших командах принято использовать следующий набор баз данных (продуктовая, тестовая, стенд, общая или индивидуальная для разработки).  На текущий момент очень удобно разворачивать индивидуальные базы данных для разработчиков с использованием Docker.

18. Запланируйте регулярный аудит схем БД, например, удаляйте неиспользуемые колонки.

19. Поскольку SQL код бывает достаточно плотным и не всегда хорошо читабельным, старайтесь оставлять подробные комментарии в данных случаях.

20. Старайтесь комментировать или давать описательные имена всем магическим константам, также иногда можно выносить константы в простые SQL функции.

21. Для улучшения читабельности рассмотрите возможность использования CTE.

22. В определенных условиях не всегда удается стандартными SQL средствами  получить требуемую производительность. В данном случае можно использовать кэширующие таблицы, вычисляемые хранимые колонки, материализованные представления и прочие механизмы и методы для достижения требуемых параметров производительности.

23. Все колонки в БД по размерности должны быть максимально приближены к хранимым значениям, слишком большие колонки могут негативно повлиять на производительность и место занимаемое таблицами.

24. Если при проектировании таблиц заранее известно про очень большую размерность таблиц, необходимо предусмотреть механизм секционирования таблиц.

25. Все изменения в объектах БД также необходимо хранить в GIT или любой другой используемой на проекте системе контроля версий.

26. Настройте логирование изменений объектов БД, обычно это триггер уровня БД и таблица, в которую триггер записывает все изменения в объектах БД.

Разработка клиентских приложений и сервисов с использованием баз данных

27. Следите за размером строк в байтах, генерируемые запросами на чтение данных. Неоправданно большие размеры строк могут негативно сказаться на производительности, как БД, так и клиентских приложений. В исключительных случаях можно увеличить параметр FetchSize в провайдере данных для ускорения получения данных клиентским приложением.

28. Некоторые базы данных и провайдеры обеспечивают возможности для эффективной отмены SQL запросов, в данном случае в интерфейс можно добавить кнопку для отмены запросов.

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

30. В проектах с большой нагрузкой постарайтесь изучить и правильно использовать ConnectionPool.

31. Для повышения производительности приложений рассмотрите возможность использования асинхронных запросов.

32. Для повышения производительности приложений старайтесь по возможности кешировать данные полученные из базы данных на клиенте.

33. С некоторыми операциями базы данных справляются достаточно плохо, в данном случае рассмотрите вопрос переноса операции на сторону клиента, например, склеивание blob файлов в MS-SQL может быть достаточно медленным.