Принципы хранения данных
Когда речь идет о Desktop СУБД, таких как FoxPro, Access, Dbase и другие кортежи хранятся последовательно – запись за записью и обращения к записям при чтении и при записи идет на уровне записи, т.е. работа идет над отдельными кортежами.
В SQL-серверах данные хранятся в виде страниц или блоков, которые обычно бывают в зависимости от СУБД от 1-8 Кб. (2Кб — SQL). Равным кластеру диска. При этом у СУБД есть буфер, который может считывать сразу несколько страниц – по умолчанию в InterBase по умолчанию 75 страниц. Чтение и запись идет сразу по 75 стр. Там, где запись идет редко – можно увеличить это число, следовательно, быстродействие увеличивается. И наоборот, потому что каждый раз приходится перезаписывать все страницы, следовательно, обращение к диску, следовательно, трата времени, т.к. время записи больше времени чтения из-за различных проверок – доменов и проч. (см выше)
Что качается BLOG – полей (Binary Large Object — полей). Поля с картинками, мультимедиа, текстовые поля больших размеров – все поля меньше 4 Гб по определению. Такие поля, как правило, могут иметь размеры от очень маленьких до очень больших и располагать их с основными полями, размер которых постоянен (точно от записи к записи, либо примерно) и можно определить, где какое находится, то из-за BLOG – полей все это нарушается. В десктоп СУБД эти поля хранятся в отдельном файле и из основного файла в дополнительный есть 4-хбайтная ссылка. Что касается SQL – сервера, то тут отдельного файла нет, есть выделенный сегмент, где BLOG-поля сохраняются. Все равно есть указатель на этот сегмент.
В десктоп СУБД картинки хранятся в BMP формате – самом простом формате. Некоторые форматы форматируется самой СУБД в BMP. SQL БД хранят не формат, а байты. Главное суметь записать, а хранить она будет в любом формате, в котором захотим. То есть суметь преобразовать в Jpeg или еще какой-нибудь формат и создать средство записи – программку. В СУБД Oracle есть возможность сегментирования таблиц по значению какого-либо поля, чтобы их можно было хранить на разных дисководах для того, чтобы при считывании можно было брать тот который нужно – приводит к быстродействию. Если таблица огромна – то разбить на 2 части, можно взять сразу тот дисковод, который нужно, а второй оставить. Скорость возрастает вдвое, но ПО усложняется. Большинство SQL – серверов позволяют хранить данные в виде динамических строк, т.е. их длины равна фактическому значению. Т.е. если задали длину текстового поля 50 символов, а записали всего 5 – запишется ровно 5. Но возникает проблема при редактировании данных. Для этого добавляют дополнительное пространство – фактор дополнения Fill Factor – процентов 30-40 пустого места, чтобы при дальнейшей коррекции сервер начинал автоматически строки раздвигать и добавлять туда данные. При работе со страницами это возможно, с кортежами уже нет.
В СУБД Oracle для таких целей отведено ключевое слово pct free.