полное избавление от суррогатного ключа в мускуле не бывает, движок вроде сам создает внутренний "невидимый" ключ и работает с ним.
К счастью, можно особо не париться с типами и для всех переменных указывать тип "s".
Пробовал гуглить, как указывать тип, ничего не нашёл.
сразу бросаются хранение типов и статусов в строках, переделай в числа, должно заметно уменьшить базы данных, уменьшить объем базы и индексов.
лучше всего enum
Скорость выполнения одинаковая
WHERE (task.status, task.type, task.provider, task.cat) = ('active', 'follow_profile', 'insta', 3)к таблице приёмы, паровозиком идут еще несколько: файлы и свойства приёма
Использовать Partitioning для таблицы "приёмы", понятно по годам, а вот для связанных таблиц файлы и свойства приёма, что лучше делать?
подумал сделать Partitioning допустим по годам
есть несколько таблиц, которые занимают 95% места всей БД.
правильно ли я понимаю, что оба диапазона по 16 адресов можно покрыть одной общей маской 194.58.64.0/19 ?
Что-то мне понимание принципа объединения этих адресов трудно дается...
можно как-то колонке добавить свойство, что по умолчанию всегда там значения без пробелов?
Формулу покажите. Ибо в 99% случаев это какая-то тривиальная арифметика, и в этом случае тащить цену на клиента, чтобы пересчитать её и потом отправить обратно - очевидный идиотизм.