Очень большая БД

← →
Artem K. (2002-08-22 16:51) [0]

Уважаемые мастера!
Я разрабатываю приложение с использованием БД.
Опыта работы с БД мало.
Ответьте пожалуйста на следующие вопросы:
1. Какую БД (Paradox, dBase, FoxPro или др.) лучше использовать (из имеющихся в составе Delphi) для работы (поиск, фильтрация, создание новой БД) с огромным числом записей в таблице БД (>500000000)?
2. Стоит ли использовать SQL (см. вопрос 1)?
3. Имеет ли смысл разбить такую БД (см. вопрос 1) на несколько, и ускорит ли это работу?
4. Я использовал БД Paradox 7. Из одной таблицы (кол-во записей ~7000), путем математических вычислений над ее полями, создавал другую (кол-во зап. должно было быть ~25000000). Но при добавлении записей в районе ~11000000 в таблицу возникла ошибка "Table is full" (Таблица заполнена). Как устранить эту ошибку (может быть ответом на вопрос 1?)?

← →
Anatoly Podgoretsky (2002-08-22 17:01) [1]

1. ни одна не будет работать
2. да и нужен достаточно мощный сервер
3. нет
4. увеличить размер блока

← →
MsGuns (2002-08-22 19:57) [2]

>Anatoly Podgoretsky (п.3)
Смелое заявления, особенно не имея ни малейшего представления о сущности хранимой в такой БД инфы, да еще учитывая, что Artem сообщает в п.4. У меня вообще в голове не укладывается КАК можно в принципе работать с таким кол-вом записей. Может просто дело в неправильной ОРГАНИЗАЦИИ хранения данных (типа декартова ?)

← →
Anatoly Podgoretsky (2002-08-22 20:01) [3]

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

← →
Jeer (2002-08-22 20:01) [4]

>Anatoly Podgoretsky © (22.08.02 17:01)
>3. нет

Могу добавить, что во времена явной нехватки ресурсов на слабеньких по нынешним меркам машинах, совершенно нормальным было разделение некоторых таблиц по фактору МЕСЯЦ, ГОД.
Ускорение было явным.

>MsGuns © (22.08.02 19:57)
>Может просто дело в неправильной ОРГАНИЗАЦИИ

Скорее всего.
Если автор соблаговолит изложить задачу, то могут возникнуть дельные рекомендации.

← →
Jeer (2002-08-22 20:04) [5]

>Anatoly Podgoretsky © (22.08.02 20:01)
>А разбиением я посмотрю как он будет делать выборки.

А это зависит от способа организации выборок.
Например, практикуется и сейчас подведение итогов в конце месяца, т.н. опер-месяц.
Данные далее идут нарастающим относительным итогом

← →
MsGuns (2002-08-22 20:10) [6]

Для очень больших объемов СОВЕРШЕННО ЦЕЛЕСООБРАЗНО использовать архивные БД, физически отделенные от актуальной. Фактор времени (точнее, периода) в таких случаях обычно все решает. А выборка из табла в 1000000 записей будет итти существенно медленнее (в десятки и даже сотни раз) последовательной выборки из 50 таблиц по 20000 записей (для настольных систем, ессно). Опять же на выборку сильно влияет наличие/отсутствие ключей, тип и размер полей и т.д.

← →
Наташа (2002-08-23 10:07) [7]

Для хранения (и нормальной обработки) такого кол-ва записей я бы посоветовала использовать Industrial SQL SERVER совместно с MS SQL Server. Есть его различные версии, расчитанные на различный объем данных (по кол-ву переменных). Например, в In SQL я пишу показания счетчиков с интервалом в 1 сек., а в MS SQL сбрасываются данные по времени операций и суммарному расходу за каждую операцию. Что касается Paradox и ему подобных, то при объеме более 100 000 записей в одной таблице начинается куча разных проблем- индексы валятся, тормозит, много пользователей не пускает...

← →
Anatoly Podgoretsky (2002-08-23 10:13) [8]

Jeer © (22.08.02 20:04)
Я знаю обходные пути, но я в первую очредт говорил об аналитике

← →
Маша (2002-08-23 10:14) [9]

2 Наташа (23.08.02 10:07)
>>Industrial...

Это название фирмы ?

← →
Hro (2002-08-23 10:23) [10]

Ну то что ни одна СУБД (если их таковыми можно обозвать) из перечисленных не подходит это однознаачно. Что касается "СТОИТ ЛИ ..." то скажу не СТОИТ, а НЕБХОДИМО!. Добится ускорения при работе с таким объемом информации зависит от их характера, логики, и вообще самой задачи. Да если это инфа допустим по бухгалтерии то есть понятие месяца тогда разбиваем и все понятно. А если это непрерывные данны то тут стоит серьезно задуматься об организации базы данных. Тут я согласен с мнением Наташи об использовании MS SQL.

Кстати НАТАША ты случайно не энергетикой (АСКУЭ) занимаешся?

← →
Desdechado (2002-08-23 10:42) [11]

> Из одной таблицы (кол-во записей ~7000), путем математических
> вычислений над ее полями, создавал другую (кол-во зап. должно
> было быть ~25000000)
А стоит ли такое делать? Ведь если данные можно вычислить, то зачем их хранить, тем более в таком объеме. Хотя есть и исключения, когда вычисления слишком продолжительные (заметно больше времени выборки из БД).

← →
Tornado (2002-08-23 11:07) [12]

А как будет вести себя БД Access при объеме примерно в 400 000 - 500 000 записей?

← →
Artem K. (2002-08-23 12:58) [13]

Задачи состоят в следующем:
1. Имеется БД (Paradox 7) по звездам (кол-во записей ~7000) с полями: название (alpha), прямое восхождение (number), склонение (number), звездная величина (number). Нужно найти пары звезд, косинус угла между которыми меньше заданной величины. Косинус угла между звездами рассчитывается с использованием полей: прямое восхождение и склонение. По результатам расчетов создается БД (количество записей по моим расчетам ~>25000000)с полями:косинус угла между звездами соответствующий условию (number), название первой и второй звезды в паре (alpha).
2. Есть другая БД (формат пока еще не знаю) по звездам (кол-во записей 50000000). Нужно сделать тоже самое что и в задаче 1.

← →
Shaman_Naydak (2002-08-23 17:18) [14]

Мда, народ, тут кол-во записей не подсократишь :)
Или возможно есть смысл разбивать, если работают всегда отдельно, скажем, с углом 0-45, 45-90 и.т.п.. идея ясна?
Кстати, не вздумай впихивать в таблицу названия звезд, только ссылки.. уж они то просятся вынести их в справочник, как пить дать

← →
Юрий Жуков (2002-08-23 17:35) [15]

500 миллионов записей? Я правильно посчитал нули?
Для таких серверов как Oracle и MSSQL это не проблема.

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

Сдается мне что и Oracle будут по барабану такое количество.

Более того, на сайте ibase.ru вы найдете упоминание о подобной базе на Interbase(люди взлавмывали какой-то алгоритм).

← →
Anatoly Podgoretsky (2002-08-23 17:40) [16]

980 гигабайт

← →
Tornado (2002-08-23 18:42) [17]

>Юрий Жуков © (23.08.02 17:35)

Если Вы об моем сообщении, то не 500 милионов а всего лишь 500 тысяч (математика).... Я саашивал конкетно о MSACCESS

← →
Юрий Жуков (2002-08-24 09:47) [18]

2Tornado
Нет я отвечал на оригинальное сообщение от Artem K.
Загони эти 500 000 записей и посмотри.

← →
Artem K. (2002-08-24 13:35) [19]

Большое спасибо всем за ответы.

Очень большая БД Найти похожие ветки