Архив форумов ЦИТФорума

[Alex Alexeev]

MSSQL2000
Немного упрощая, ситуация следующая.Существует две таблицы

Master (id int primary key, f1 varchar(50))
и
Blobs (idmaster int foreign key references Master, blob image)

Master достаточно большая, допустим 2 млн записей. Blobs - 5 - 30% от размера Master.

Возникла, вдруг необходимость перенести поле blob из таблицы Blobs в таблицу Master. На лицо избыточность.
Так вот насколько плоха такая избыточность? Сколько занимает значение Null в поле типа Image?

[Sclis]

1 Мне кажется, некорректно используешь термин "избыточность". Это не когда лишние (не нужные) данные хранятся, а когда одни данные хранятся несколько раз. Если бы у тебя этот блоб один ии тот же хранился в обеих таблицах - это избыточность. ну это так... мелочные придирки
2 Создай банальный дбф файл с полем мемо. Кроме него создасться еще один файл - специально для хранения мемо-поля. Вывод: системы довольно давно научились хранить такие данные в отдельном файле.
Вот если ты вторую из твоих таблиц (блоб) создавал специально для того, чтобы не забивать блобами главную таблицу, то делал это зря. Ты строишь вторую таблицу, а система сама прозрачно строит третюю, чтобы не забивать вторую. В итоге вторая - ненужный посредник.
Применительно к МССКЛ термин файл некорректен, но сути это не меняет. Для систем не требующих первичного ключа размер может немного вырасти (за счет того, что в таблице мастер придется хранить ссылку на мемо, а сейчас ты храншь ссылку в таблице блоб, где записей меньше) Если первичный ключ обязателен, то базе достаточно в отдельном файле для мемо хранить ссылку-индекс на него.
То бишь, я думаю, ты только выиграешь от такого преобразования.

[Alex Alexeev]

Для хранения Null в поле Image используется 16 байт.
Далее такой расчет (в Master 2000000 записей, в Blobs - 800000)
(2000000-800000)*16 - 800000*4 = 16000000 (Байт)
16000000 / 1048576 = 15,26 (Мегабайт)

Т.е. таблица Master увеличится на 15,26 Мегабайт. Само по себе это вроде и не страшно, но для хранения информации потребуется больше страниц и теоретически доступ к данным должен замедлиться.
Не прав?

[Sclis]

очень большой файл с произвольным методом доступа будет обробатываться медленней, чем маленький за счет меньшего количества попаданий в кэш но эта такая мелочь, которая только в теории интересна. тут и кэш харда и кэш ОС и страницы базы... а страницы он будет чаще переключать почти пропорционально отношению размеров записи с блобом и без...
главные затраты при работе с базами - позиционирование, поиск нужной записи, а он происходит скачками кратными размеру записи.
вопрос сводится к :
что быстрее вычислит компьютер 100+23*100 или 100+23*116 ?
Одинаково. значит и доступ будет происходить одинаково. А вот в прежнем варианте доступ происходил не с одним, а с двумя поисками.
в таблице блоб и в таблице с блобами(которую ты не видишь).
Должно быстрее работать.
хотя, правильно будет сделать тестовый вариант и попробовать. может практика будет расходится с теорией