⏩Используйте отдельные схемы для разных модулей
Скажем, вам необходимо реализовать систему рассылки пуш-уведомлений на android-устройства клиентов. Вы пишете сервис, который будет работать с FCM. Пишете функции в вашей БД, которые будут выдавать списки token-текст (да там много полей вообще).
Так вот, необходимо, чтобы такие ручки для разных модулей (бэкендов) лежали в отдельных схемах.
⏩Используйте группы ролей и назначайте гранты именно на роли
Предположим, что вы реализовали пункт выше, теперь ваш сервис должен подключаться к БД и крутить свои запросы. Но под каким пользователем? Не будет же он бегать под
postgres или admin?)⏩Используйте расширения
PostgreSQL — это мощная СУБД. Но и она не может быть универсальной. Не надо полагать, что всё делается штатными средствами PostgreSQL. Так-же не надо пробовать писать свои системы чего-либо.
⏩Храните дататайм в timestamptz
Возьмите за привычку в БД всегда хранить
timestampTZ и когда-нибудь Вам скажут большое спасибо за это.⏩Используйте метрики. Пользуйтесь pg_stat_statements
Так-же рекомендую сразу установить расширения для мониторинга запросов (например
pg_stat_statements)⏩В функциях лучше использовать CTE и длинные запросы, чем временные таблицы
PostgreSQL всегда временные таблицы кладёт на диск, это займёт много времени. Используйте табличные выражения. Да и лучше всё писать одним оператором.
⏩Не делайте секции везде, где только можно
Да да, секции — это круто. Но вот их использовать я бы рекомендовал только в некоторых случаях
⏩Не забывайте делать дополнительную статистику
Да, когда планировщик не так представляет выхлоп — у вас могут получиться очень медленные запросы.
⏩Старайтесь не пихать всё в TOAST
Наверное сразу стоит добавить и тот пункт, что не надо хранить в
TOAST ( например json/text с дефолтным параметром хранения ) аналитические данные.📎 Статья
@sqlhub