Скачать: CL | DM;

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

← →
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]

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


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

---

← →
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

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

---

← →
Desdechado ©   (2006-07-09 19:48) [8]

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

---

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

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

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

---

← →
Desdechado ©   (2006-07-10 11:35) [10]

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

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

---

Страницы: 1 вся ветка

Скачать: CL | DM;



Память: 0.48 MB
Время: 0.027 c