SC
big везде
Size: a a a
2020 October 31
И
big везде
Считаешь, что заморачиваться не стоит?
D
А вот такой вопрос. Вы расставляете инкременты в соответствии с потребностями или лупите везде bigincremets? Для категорий подойдет и меньшее значение, но нужна ли такая экономия?
unsigned big int
D
unsigned big int
*это скорее про внешние ключи*
И
Просто начну внешние ключи писать - надо будет подглядывать как там int стоит
И
не сильно большая проблема
И
но все же
И
BIGINT
Диапазон числа со знаком от –9223372036854775808 до 9223372036854775807. Диапазон числа без знака (unsigned) от 0 до 18,446,744,073,709,551,615.
🙊🙈
Диапазон числа со знаком от –9223372036854775808 до 9223372036854775807. Диапазон числа без знака (unsigned) от 0 до 18,446,744,073,709,551,615.
🙊🙈
D
не думаю,что дойдем до лимита даже uns int
И
не думаю,что дойдем до лимита даже uns int
ну и вот зачем такие большие числа для категорий? Если у меня по дефолту категорий штук 100 ожидается.
/преждевременная оптимизация/
/преждевременная оптимизация/
D
ну думаю, логика такая,что лучше бахнуть биг инт
D
чем потом очухаться и попробовать поменять тип у огромной таблицы
D
и о*еть от жизни в проде
D
но биг инт и больше памяти занимает
И
SMALLINT мне тут подойдет как нельзя. На 10 лет вперед
от 0 до 65535
от 0 до 65535
D
на докладах по оптимизациям постгреса, часто советуют "юзайте подходящие типы данных для таблиц"
И
там вопрос лишь занимаемой памяти
D
"не храните всё подряд в базе, храните только то что точно пригодиться"
И
на быстродействие я не знаю как это отразится