вопрос о БД

[Артэс]

Здравствуйте. Меня интересует, как хранится текст переменной длины в базах данных? К примеру в том же мускуле.

Я догадываюсь что полям отдается заранее определенное кол-во байт, таким образом можно менять данные полей в файле без необходимости целиком перезаписывать файл. Это вполне норм для мелких полей, типа строк, к примеру 256 байт выделил и норм. Но как быть в случае с большим текстом, который скажем на форумах пишут? Если один текст 10 кб весом, а другой 1 кб, не думаю что выгодно создавать поля по 10 кб весом под каждый пост, но тогда если поле имеет переменный размер, то при сохранении текста придется каждый раз перезаписывать файл целиком? Ведь если сообщение решили отредактировать, оно стало длиннее, и надо сдвинуть данные идущие после этого сообщения, а это значит перезаписать файл, вместо изменения только одного поля.

[evg_m]

отдельное хранилище (или специально выделенная область файла) для объектов переменных длин.
в основной ссылка фиксированной длины (смещение { +длина} { + ...} ) на данное хранилище.
изменение атрибута = новая запись в хранилище + изменение ссылки.

[ADSoft]

какой файл? о чем вы
большие тексты в поле формата TEXT
пример хранения текста переменной величины например {"len":100500,"text":"тут 100500 символов текста......"}

[Serge_Bliznykov]

ADSoft, Вы уверены, что ВНУТРИ БД хранится именно так, как Вы указали?!
очень сильно соменваюсь.
в принципе я согласен с мнением evg_m

[ADSoft]

нет конечно.... так для понимания лишь
но похожий принцип записи данных был в давно забытой txtSQL базе

[Артэс]

Т.е. получается большой текст переменной длины хранится в отдельном файле базы данных? Просто что если объем текстов большой, много сообщений, скажем файл с этими сообщениями на 2-3 МБ, и если решили изменить 1 сообщение сделав его длиннее, а оно оказалось в начале файла базы данных.. весь файл 2-3 МБ будет перезаписываться целиком? Это может оказаться довольно затратно и будут небольшие задержки в отклике.. а что если 20-30 МБ

[Аватар]

А есть другой способ? Умозрительно можно два варианта представить перезаписи blob-поля при увеличении его длины. Целиком в новую область в файле, старая помечается как свободная и, возможно, будет использована для записи данных подходящего размера. А может и нет, а только при бэкапе и ресторе такие дырки исчезнут. Или при выполнении какого-то оптимизатора, если таковой есть для СУБД. Второй вариант - на старое место записывается кусок blob-поля со ссылкой на область, в которую запишется остаток. В любом случае полная перезапись blob-поля, даже если его длина и не поменялась. Поэтому и делают ограничения на длину вложений. Второй вариант кстати для чтения хуже

[Артэс]

Хм, довольно интересные варианты, особенно первый, когда берется новая область а старая помечается как пустая, надо будет взять на заметку такое. Просто я задумался о хранении длинных сообщений в файлах, и эти сообщения могут меняться, потому и интересуют варианты их хранения и т.п.

[come-on]

по разному делается