официальной документации - всё просто и замечательно, пока не дойдёшь до момента, когда нужно подключать новые секции, если ограничения старых забиваются. Открыл сторонние источники - там сразу понял, что ничего не понял. Решил снова пересчитать размеры для моей задачи по ограничениями PostgreSQL - получил те самые +- 2/4/8/12 тысяч символов на сообщение и разделения по месяцам. Пошёл искать выходы. Нашёл два - либо триггеры (как в официальной документации в том числе) со склеиванием строк и вычислением, либо ручное изменение функции всего с двумя проверками - на текущий месяц и следующий. Ну в следующем месяце соответственно менять её на тогдашний и следующий месяц. В сторонних источниках написано, что триггеры не очень хорошая идея, да и поскольку дробление у меня предсказуемо - смысла нет. Второй вариант гораздо заманчивей - поскольку все запросы на всех бэках скрыты за представлениями - можно пустить на самотёк через cron и скриптовый язык. Но это относиться только ко вставке. При выборках, нужно искать последнюю таблицу, и, возможно, приклеивать к ней предыдущую. Это, возможно, при представлениях можно тоже без склеивания строк, а очень старых, где уже нужны будут склеивания, уже фиг с производительностью, ибо ну уж очень маловероятно и/или редко будет. Если совсем лень будет - сделаю какую-нибудь "индексную" таблицу/функцию которая за меня будет хранить/склеивать это всё. Я правильно рассуждаю, с учётом что у меня везде есть представления?
вообще не понятно о чем вы рассуждате
Обсуждают сегодня