Можно ли оценить размер БД

← →
S@shka © (2006-07-08 02:54) [0]

Есть порядка 10 таблиц.
Но именяется (постоянно наполняется) - только одна
вот такой структуры
1 Integer
2 Integer
3 Double
4 TimeStamp

+ висит индекс на поле 1 2 и 4

Можно ли как то оценить размер БД при добавлении скажем 1 000 000 записей в данную таблицу?

Точнее чем просто SizeOf(Table)*1000000

← →
DrPass © (2006-07-08 14:45) [1]

> Можно ли как то оценить размер БД

Точно - нельзя. Выделение страниц в БД зависит от очень многих факторов, куда более сложных, чем SizeOf(...)*1000000. Но в любом случае будет больше, чем этот самый SizeOf(...)*1000000 :) И, судя по всему, размеры индекса к твоей таблице будут едва ли не превышать размеры таблицы

← →
Johnmen © (2006-07-08 14:58) [2]

> Можно ли как то оценить размер БД при добавлении скажем
> 1 000 000 записей в данную таблицу?

Легко.
Делаешь b/r, запоминаешь размер файла, добавляешь свой лимон, смотришь размер файла.

← →
Johnmen © (2006-07-08 15:02) [3]

← →
DrPass © (2006-07-08 16:17) [4]

Т.е. оценить нельзя, но можно добавить и посмотреть, что получится :)
В реальной БД размер будет несколько больше, нежели после добавления записей сразу после бекап/рестор

← →
PEAKTOP © (2006-07-08 16:25) [5]

В IBExperte есть такая функция "Инструменты -> Генератор тестовых данных"

← →
S@shka © (2006-07-08 17:45) [6]

Интересует математически с определенной точностью.
Можн или нет?

Типа Размер = Func (Размер_Страницы,Индексы,Типы_Данных,Количество_Записей)

Мне нужна какая то мера оценки.

← →
DrPass © (2006-07-08 19:10) [7]

Сам же написал:

> SizeOf(...)*1000000

Добавь сюда еще такую же по индексам... и получится математически, с очень низкой точностью. Точнее - никак. В БД образуется масса пустых страниц, временные данные и т.д., заранее определить которые не представляется возможным.

Имхо, только с точностью "плюс-минус два лаптя от солнца".
Поскольку, как уже говорилось, страницы выделяются в зависимости от свойств БД (указанной степени заполнения страниц, размера страниц), свойств данных (сжимаемые или нет), свойств индексов по данным (часто ли данные повторяются, делается ли backup-restore или переиндексация).
Про backup-restore и индексы вообще отдельная песня. При массовых добавлениях индексируемых записей индексы обычно перекашивает (несбалансированные двоичные деревья получаются), а это увеличивает количество служебных данных в индексе. Если индекс перестроить, то он будет занимать меньше места.
Ну, и на последок, не сказано вообще, обязательные ли поля или опциональные. NULL, как известно, в БД не записывается и места не занимает.

← →
Андрей Пазик (2006-07-09 20:38) [9]

> При массовых добавлениях индексируемых записей индексы обычно
> перекашивает (несбалансированные двоичные деревья получаются)
> , а это увеличивает количество служебных данных в индексе.
> Если индекс перестроить, то он будет занимать меньше места.
> Ну, и на последок, не сказано вообще, обязательные ли поля
> или опциональные. NULL, как известно, в БД не записывается
> и места не занимает.

У вас очень устаревшие данные. Ничего не перекашивает, и уже давно.

Андрей Пазик (09.07.06 20:38) [9]
Источник, пожалуйста.

Двоичные деревья, на которых базируются индексы, имеют это нехорошее свойство. Особенно, если новые индексируемые ключи сильно отличаются от ключа точки входа в дерево.

Можно ли оценить размер БД Найти похожие ветки