База на >5000000 записей
Вот здесь прочитал про существующие ограничения:
http://www.codenet.ru/progr/delphi/db_024.php
НО!!! Вылетает ошибка, когда заполняю Paradox-таблицу после 655500 записей, а в dBase-таблице после 1100000 записей...
В файловую систему и объем свободного места НУ ЯВНО не упирается...
Скажите мне, пожалуйста… В Delphi 7 есть хоть один работающий тип баз данных, в таблицу которого можно впихнуть около 10 миллионов записей? Paradox, dBase и FoxPro НЕ впитывают такое количество инфы… Вылетает ошибка Table is full…
а ADO не пробовал?
В Delphi 7 есть хоть один работающий тип баз данных
Delphi - среда разработки, никаких баз, тем более не работающих там нет и в принципе быть не может
Paradox, dBase и FoxPro
Почему не MsAccess? А еще на Excel'е можно базу :)
Для таких объемов требуется нормальная СУБД:
MSSQL, MySQL, InterBase, FireBird, Oracle
а ADO не пробовал?
Каким боком к проблеме?
Delphi - среда разработки, никаких баз, тем более не работающих там нет и в принципе быть не может
Почему не MsAccess? А еще на Excel'е можно базу :)
Для таких объемов требуется нормальная СУБД:
MSSQL, MySQL, InterBase, FireBird, Oracle
Каким боком к проблеме?
Вот MySQL точно на полмиллионе заткнётся.
Вот Oracle, MSSQL, IB - да, серьёзные вещи, которым десяток миллионов записей в таблице - раз плюнуть. Но, они денег стоят ;)
Вот MySQL точно на полмиллионе заткнётся.
Вот Oracle, MSSQL, IB - да, серьёзные вещи, которым десяток миллионов записей в таблице - раз плюнуть. Но, они денег стоят ;)
5000000 - не так уж и много :)
из бесплатного, что вытянет такую нагрузку например PostgreSQL, Firebird.
Delphi - среда разработки, никаких баз, тем более не работающих там нет и в принципе быть не может
Почему не MsAccess? А еще на Excel'е можно базу :)
Для таких объемов требуется нормальная СУБД:
MSSQL, MySQL, InterBase, FireBird, Oracle
Каким боком к проблеме?
Дак вот именно, что я в Delphi ее заполняю и спросил про ТИП баз данных, с которым нормально сосуществует Delphi...
Access мне не нравится...
В Excel'е не помещается то, что я хочу...
А до остальных СУБД еще не добрался...
Каким боком к проблеме?
просто думал что мож проблема в компонентах... через ado я без проблем работаю с базами MSAccess и MSSQL.. вопрос правильно задавать надо
Но, они денег стоят
как и винда, как и офис... реально покупается не более 10% этой софты
Дак вот именно, что я в Delphi ее заполняю и спросил про ТИП баз данных, с которым нормально сосуществует Delphi....
Делфи нормально существует с ЛЮБЫМ типом базы данных (хотя нада ещё определить понятие "тип бд") хотябы потому что она никакого отношения к БД не имеет - это всеголишь средство разработки программ, как сказал Dian. Главное, чтобы компоненты правильные были, да и руки из нужного места произрастали.
НО!!! Вылетает ошибка, когда заполняю Paradox-таблицу после 655500 записей, а в dBase-таблице после 1100000 записей...
В файловую систему и объем свободного места НУ ЯВНО не упирается...
ради эксперимента написал прогу, которая добавляет записи в БД dBase... сейчас уже 1850000 запесей и они продолжают добалляться...
ради эксперимента написал прогу, которая добавляет записи в БД dBase... сейчас уже 1850000 запесей и они продолжают добалляться...
А использовал ADO-компоненты?
На счет рук, произрастающих из... Дело в том, что для Paradox и dBase-таблиц РАЗНОЕ максимальное количество записей получается... При чем тут руки???? Если бы прога была кривая, так она бы на одной и том и том же количестве подыхала бы...
И еще... Записи бывают разные... :)
А использовал ADO-компоненты?
да... TADOTable тормозит ужасно.... поэтому использовал TADOQuery совместно с TADOConnection... сейчас уже 2 600 000 записей... (база данных dBase)
И еще... Записи бывают разные... :)
что ты имеешь в виду?
да... TADOTable тормозит ужасно.... поэтому использовал TADOQuery совместно с TADOConnection... сейчас уже 2 600 000 записей... (база данных dBase)
что ты имеешь в виду?
Да то, что можно просто числами забить базу, а можно и строками.
В общем, у меня следующая структура БД. Я конвертирую файлы freedb (кто активно слушает или занимается музыкой, тот, вероятно, знает, что сие есть такое) в свою БД. В виду немного туповатой структуры файлов просто импортировать в тот же Access НЕ получится (необходима определенная обработка). У меня имеется 2 таблицы:
1. Исполнители и альбомы (родительская)
2. Композиции (дочерняя)
Первая состоит из следующих полей:
1. Номер альбома (ключевое поле) (целочисленный тип)
2. Исполнитель (строковый тип)
3. Год альбома (строковый тип)
4. Название альбома (строковый тип)
Вторая таблица состоит из следующих полей:
1. Номер альбома (составной ключ) (целочисленный тип)
2. Номер композиции (составной ключ) (целочисленный тип)
3. Название композиции (строковый тип)
Соответственно, вторая таблица и дорастает до таких объемов, что вылетает ошибка о переполнении.
Что посоветуете?
Так, может, и вправду дело в файловой системе? Файл таблицы до двух гектар вырастает - вот и ошибка...
Это уже недочет СУБД - файловая система поддерживает гораздо большие файлы
Slava_rec
Не волнуйся, плохая база не выдержит этих данных независимо от того, чем её заполнять :)
Так, может, и вправду дело в файловой системе? Файл таблицы до двух гектар вырастает - вот и ошибка...
Ну я же ясно написал, что дело НЕ в файловой системе!!! Или NTFS уже не вмещает файл на пару гигов???
Это уже недочет СУБД - файловая система поддерживает гораздо большие файлы
Slava_rec
Не волнуйся, плохая база не выдержит этих данных независимо от того, чем её заполнять :)
А какая хорошая по твоему?
Ну вот запихнул ее в 41 Excel'овский файл в среднем по 40000 записей в каждом (запись - исполнитель, альбом + как примечание к альбому все композиции)... Возникла другая проблема, но это уже не в этот топик...
А какая хорошая по твоему?
Смотри выше - там целый список, еще и с последующим обсуждением характеристик
Тут вроде о БД говорят.
Юзай Access. Возможностей Jet движка тебе должно хватить. Если что, то с этого движка всегда можно переползти на сиквел сервер.