iBase.ru Forum

Привет всем.

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

А для чего такое может быть нужно?
Поделись плс, может, и я задумаюсь о таком.

нет. пока нет поддержки tablespace. и когда оно будет, и будет ли - неизвестно. А о каких объемах данных вопрос?

архивные обычно переносят простым копированием, это несложно организовать. Автоматически того что ты просишь, по-моему не бывает нигде.

Это нужно для того, чтобы в БД не хранились записи, которые практически никогда не будут использоваться, но теоретически могут потребоваться, что в свою очередь приведет к уменьшению времени обработки запросов.

Насчет объемов точно сказать не могу, просто начальство поставило задачу и предложила вариант работы с БД как описано выше. Здесь еще проблема в том, что возможно ПО и база будут эксплуатироваться на слабых машинах (типа П1-133), поэтому объем БД видимо будет влиять на скорость обработки запросов.

это все домыслы. нечитаемые записи что в основной базе лежат, что в архивной - все едино. даже если база будет 10 гиг, совсем не обязательно читать из нее все. А вот если разделишь данные, то когда понадобится запрос И по архивным записям сделать - будешь карячиться не просто с двумя запросами из разных таблиц, а с объединением результатов запросов из разных баз.

похоже ты привык к файл-серверным базам....

kdv писал(а):нет. пока нет поддержки tablespace. и когда оно будет, и будет ли - неизвестно. А о каких объемах данных вопрос?

архивные обычно переносят простым копированием, это несложно организовать. Автоматически того что ты просишь, по-моему не бывает нигде.

Кажись в оракле есть возможность разбить большую таблицу на партиции и хранить (кажись) их на отдельных дисках. Попадание при вставке в нужную партицию происходит по заданным условиям. Читал где то...

кажись в оракле, и кажись это даже не tablespace, а table partitioning, в том числе для распараллеливания запросов по разнесенным данным. т.е. это нужная фича когда базы ну очень большие, и железо ну очень быстрое и очень многопроцессорное.

bender писал(а):Привет всем.

Возник такой вопрос: возможно ли разбить БД на несколько...

Разбивать именно на разные базы, имхо, малоэффективно. Эффект-то, может и будет, но только если, скажем, одно приложение только с одним диапазоном (и одной базой) работает, иначе, правильно писали, гетерогенные запрос и т.п. Хотя, конечно, от специфики зависит.

У однизх знакомых было приложение, которое ежедневно породлао какие-то бешенные количества записей. Использовались же они только неделю, через неделю к этим данным уже никто почти не лез. Но все же "почти". У них через неделю записи перемещались в архивную таблицу, а обращение к данным шло через stored proc, которая сама решала, давать данные из короткой оперативной таблицы или из монстроподобной архивной. Но база была одна.
Конечно, классически правильно построенные данные, индексы и т.п. и так обеспечать приемлемое быстродействие, но всегда все хорошо и случаи разные бывают.

Georgi-47 писал(а):и так обеспечать приемлемое быстродействие, но всегда все хорошо и случаи разные бывают.

Тут имелось в виду "НЕ всегда все хорошо"

Сорри за такое количество ошибок, пальцы что-то не гнутся

Georgi-47 писал(а): Использовались же они только неделю, через неделю к этим данным уже никто почти не лез.

Вот об этом и речь, период закончился (скажем год) и в течении следующего периода возможны единичные случаи обращения к данным предыдущего периода.

bender писал(а):

Georgi-47 писал(а): Использовались же они только неделю, через неделю к этим данным уже никто почти не лез.

Вот об этом и речь, период закончился (скажем год) и в течении следующего периода возможны единичные случаи обращения к данным предыдущего периода.

Сколько их там? В гигабайтах. В миллионах записей неинтересно, если индексы нормальные для типовых запросов, то не жмёт.