A
Size: a a a
2020 September 30
キG
Типичный размер блока - 8k, если нужны "резиновые" строки - есть CLOB, который в блоке данных таблицы хранит только LOB locator, а данные как раз отдельно в LOB segment
первые 4к хранятся в строке
а все что сверх того уже в лоб-сегменте
а все что сверх того уже в лоб-сегменте
У
первые 4к хранятся в строке
а все что сверх того уже в лоб-сегменте
а все что сверх того уже в лоб-сегменте
Не всегда
キG
Не всегда
если явно указать только при конструировании столбца
キG
по умолчанию имено так работает
DC
И так зачем же нужно указывать максимальную длинну если по факту длинна один хер какая получится
Без ограничения по длине varchar превращается в CLOB, а для LOB-ов у Оракла целый ряд ограничений
DC
Часть из них завязаны на размер блока - если данные одной строки занимают больше, чем блок данных, то такой блок данных уже неоптимален для их хранения, аналогично индексы по таким данным потеряют эффективность
DC
Даже не блок данных, а меньше, т.к. часть занимают метаданные, ITL и т.п.
Отсюда ограничения на хранение Inline до 4k, про которое выше писали, отсюда ограничение на размер primary key и т.д.
Отсюда ограничения на хранение Inline до 4k, про которое выше писали, отсюда ограничение на размер primary key и т.д.
DC
Да и организовать работу с типом данных в коде СУБД тем проще, чем больше у него ограничений
DC
SQLite же не про оптимальность
DC
А в табличке на пару сотен GB и выше любое лишнее раздутое поле выльется в перерасход ресурсов, в первую очередь ввода/вывода который обычно в оракловых БД основное узкое место
DC
Ну и варианты a la "исторически сложилось" влияют, продукт же начинался в конце 70-х, в таком что-то кардинально поменять - слишком дорого
DC
Даже увеличенный varchar2 начиная с 12-й версии сделали на базе LOB Storage