Образовательный блог – всё для учебы

Когда речь идет о 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.

1. OLAP-системы и методика многомерного хранения данных
2. Объектно-ориентированные базы данных
3. Неплотное индексирование – базы данных
4. Языки управления базами данных
5. Основные принципы клиент серверных систем
6. Типы данных SQL
7. Архитектура баз данных
8. Настройка сверхтрудных баз данных
9. Правила для хранилищ данных
10. Система управления базой данных (СУБД). Функции СУБД
11. Кластеризация в базах данных
12. Хеширование в базах данных
13. Проблемы и особенности распределенных баз данных
14. Цепочки указателей в базах данных
15. Пулы соединения с базой данных
16. Общие принципы повышения производительности и доступности
17. Защита данных – параллелизм