Почему функции, триггеры и представления редко используются?
Несмотря на их потенциал, многие команды разработчиков ПО избегают использования полного спектра возможностей баз данных. Преобладает мнение, что бизнес-логика должна находиться в слое приложения, оставляя базы данных лишь для хранения данных. Этот подход возник из желания поддерживать четкое разделение обязанностей, где приложение обрабатывает бизнес-логику, а база данных просто выполняет запросы.
Однако такой подход может привести к неэффективности, такой как увеличение задержек из-за множества сетевых вызовов и сложности обеспечения согласованности данных в распределенных системах. Используя функции и триггеры базы данных, разработчики могут сократить количество обращений к базе данных, тем самым повышая производительность и упрощая кодовую базу.
Скрытая стоимость переноса логики на уровень приложения
Хотя использование баз данных исключительно как хранилищ имеет свои преимущества, оно также несет скрытые затраты:
- Задержка и использование ресурсов: Каждый запрос от приложения к базе данных добавляет накладные расходы, включая сериализацию, сетевые вызовы и разбор данных. Перенос логики в базу данных может минимизировать эти затраты.
- Потеря атомарности и согласованности: Современные базы данных отлично поддерживают целостность данных благодаря свойствам ACID. Когда логика разделена между приложением и базой данных, обеспечение согласованности становится более сложным.
- Безопасность: Реализация контроля доступа на уровне приложения может ввести уязвимости. Функции безопасности на уровне базы данных, такие как Row-Level Security в PostgreSQL, могут упростить этот процесс и повысить безопасность.
Возрождение программирования для баз данных
В последнее время наблюдается возрождение интереса к программированию для баз данных, обусловленное признанием его преимуществ. Инструменты, такие как Hasura и Supabase, иллюстрируют эту тенденцию, предоставляя разработчикам мощные фреймворки, которые интегрируют расширенные возможности баз данных в приложения без обширного шаблонного кода.
Hasura, например, предлагает реальное время GraphQL API поверх PostgreSQL, в то время как Supabase предоставляет опыт, похожий на Firebase, используя функции PostgreSQL. Оба инструмента демонстрируют эффективность принятия программирования для баз данных, позволяя разработчикам сосредоточиться на создании приложений без ущерба для производительности или безопасности.
Схема базы данных как код: правильные инструменты для кода базы данных
Сдвиг в сторону программирования для баз данных был облегчен появлением инструментов, которые позволяют разработчикам управлять схемами баз данных как кодом. Этот подход позволяет версионировать, тестировать и делиться ресурсами базы данных, аналогично традиционным практикам разработки ПО.
Одним из таких инструментов является Atlas, который предоставляет декларативный API для управления ресурсами базы данных и тестовую среду для проверки логики базы данных. С Atlas разработчики могут применять современные принципы разработки ПО к проектированию баз данных, преодолевая разрыв между логикой приложения и возможностями базы данных.
Игра с базой данных: Камень, ножницы, бумага на вашем PostgreSQL
Чтобы проиллюстрировать применение этих концепций, мы создадим игру «Камень, ножницы, бумага» непосредственно в PostgreSQL. Первый шаг включает настройку локального экземпляра PostgreSQL…