| [Форум] [Помощь] [Поиск] [Выйти] |
Добро пожаловать, ![[info]](userinfo.gif){kind=small} User
|
|
|
| ||
| Delphi. Есть задача - sql-инсертами заполнить базу. Делаю средствами BDE - заполняю в файл 1.db занимает 18 минут, получается файл весом 100 мегов. Делаю через ADO - заполняю 1.mdb - 24 минуты и 6 Mb. А вообще, с чем работать наиболее быстро и удобно (без установки дополнительных субд) ? |
| ||
| Замечательная задача. Вот ее аналог: Какую машину выбрать. Есть задача - топливом заполнить бензобак. Заливаю соляру - занимает 3 минуты и получается 70 литров. Пробую залить АИ95 - занимает 5 минут и 40 литров. А вообще, с чем работать наиболее быстро и удобно (без установки газобалонного оборудования) ? |
| ||
| Поясню. Есть БД на 6 полей. Её нужно долго заполнять и потом селектами работать с ней. Какую технологию предпочтительнее выбирать с точки зрения быстроты работы и неустановки лишнего на компьютер, на котором программа будет работать. |
| ||
| "Есть БД на 6 полей" Таблица на 6-ть полей, ты хотел сказать, одна таблица, без связей с другими и т.п.? Я бы руками код для обслуживания этих данных написал - с учетом всякой специфики было бы наиболее компактно, быстро и автономно. |
| ||
| 6 бензобаков. Это усложняет ТЗ. :) |
| ||
| 6 текстовых полей, селект ищет вхождение подстрок в каждом поле. Хотелось бы перевести разговор в русло скоростей и удобства работ разных систем. |
| ||
| Распарсить данные и сохранить в виде дерева для сверхбыстрого поиска не предлагать? Тогда я бы взял firebird embedded (http://www.ibphoenix.com/) - неплохой встраиваемый sql сервер. |
| ||
| Найтвинг, просили же дополнительное ПО не впаривать)))) Если надо чтоб всё работало быстро и не требовало дополнительного ПО помимо ОС - нужно сделать всё руками. Для работы с шестью полями, имхо, субд можно и не использовать)) Если, конечно, не предвидицца расширения задачи до космических размеров (как очень часто случается) )) |
| ||
| Вот вы говорите руками. Как это себе представить? Последовательно читать весь файл (стометровый) и искать вхождение подстроки? Будет ли это быстрее? Или тот же bde то же самое и делает? Не знаю внутренних алгоритмов, подскажите. |
| ||
| Учи матчасть. (с) |
| ||
| У Кнута было. Про поиск, бинарный и т.п. А так... я бы взял Microsoft SQL Server Desktop Engine (MSDE). Оно есть вместе с Visual Studio (не со всякой), с офисом бывает и т.п. Ну или скачай: http://go.microsoft.com/fwlink/?linkid=13962 (70 метров) |
| ||
| Вот вы говорите руками. Как это себе представить? Последовательно читать весь файл (стометровый) и искать вхождение подстроки? Ежели подстроку искать только в одном поле - сформировать дерево по этой строке с указателями на конкретные записи. Некий аналог кластерного индекса. Думаю, обычная машинка с четвертью гига оперативки вполне потянет такое художество. Будет ли это быстрее? Или тот же bde то же самое и делает? Не знаю внутренних алгоритмов, подскажите. bde суть есмь интерфейс для доступа к БД. Если он работает с dbf, то наверняка сканирует весь файл на предмет наличия подстроки. У Кнута было. Про поиск, бинарный и т.п. Мне кажется, некий вид деревьев был бы оптимальным для поиска подстроки. Не хватает мозгов сказать какое именно. А так... я бы взял Microsoft SQL Server Desktop Engine (MSDE). Оно есть вместе с Visual Studio (не со всякой), с офисом бывает и т.п. Ну или скачай: http://go.microsoft.com/fwlink/?linkid=13962 (70 метров) Да-да, скачайте, разберитесь в установке, попробуйте закачать туда свои данные при том, что инструменты администрирования в msde не входят... |
| ||
| имхо: попробуй с помощью BDE создавать не парадоксовский файл, а тотже dbf, или с помощью ADO тотже dbf, короче поэксперементируй, а то тут дело то может еще и в форматах быть... а не в том что использовать для их создания. Про скорость работы ничего не могу сказать, попробуй поискать в инете. Я сам для своих задач использовал ADO тока из за того чтобы не таскать со своей прогой установку BDE, да и както не ставил целью сравнить эти штуковины. |
| ||
| Ну для администрирования можно пользовать Microsoft SQL Server'а полной версии утилиты. |
| ||
| Ну, знаете.. DBF тоже в себе не содержит инструментов администрирования себя же - и ничего ;) Если прогу просто где-нибудь поставить, чтобы работала - то лучше MSDE сложно придумать. Если прогу нужно дистрибутировать, отдавать клиентам и т.д. - то MSDE будет неудобен, наверное. Но вообще меня очень сильно удивляет такая полученная тобою производительность ADO. Я только что сделал тест для ADO.NET, таблица в MDB-базе, 6 текстовых полей+ключ, вставлял 150 000 записей, объем базы после окончания 137 мегабайт, затрачено 4 минуты с копейками... Я не специалист по Access, я его даже почти не видел и не знаю, как там обстоит дело с индексами, но может быть именно они у тебя так сильно притормозили дело? И попробуй может через ADO работать не с MDB, а, скажем, с той же DBF... Не должно оно 24 минуты 6 мег делать, невероятно это... |
| ||
| Кстати, удивился по поводу сложностей администрирования MSDE... Раз оно позволяет к нему коннектиться, значит оно позволяет делать все, что надо.. все create table, create index, что там еще нужно.. А раз оно позволяет это делать, подумал я, то можно написать для этого морду.. А раз ее можно написать, продолжал размышлять я, то наверняка эта мысль не могла придти мне первому 15 марта на ночь глядя.. И вот, первое, что мне показал Гугл - ASP.NET Enterprise Manager. "ASP Enterprise Manager is a web-based interface for Microsoft SQL Server and MSDE written using ASP.Net, VB.Net and C#.Net." Посмотреть скриншоты можно тут (хотя, кто не видел стандартного Enterprise Manager): http://www.aspenterprisemanager.com/ Скачать можно там же. Учитывая наличие исходного кода можно переделать Enterprise Manager так, как давно хотелось ;) Словом, нет тут нерешаемой проблемы ;) |
| ||
| Насколько я понял, основная задача - не положить данные, а вытаскивать их SQL-запросами, причем критерий отбора записей - вхождение вводимой пользователем подстроки в значение одного или нескольких текстовых полей. Какая тут может быть большая польза от индекса? Конечно, можно сначала поискать в индексном ключе, а потом выдать все записи для найденных ключей, но, если повторяющихся значений немного, то ускорения не будет, и, к тому же, я не слышал, чтобы оптимизаторы запросов так работали. Если я не прав - растолкуйте, плиз. Короче - перебирать все равно придется все записи. Так как по условию задачи требуется не применять какие-либо СУБД (я понял, что имелись в виду SQL-СУБД), то наиболее простым вариантом будет использовать формат dbf. А "ходить" к нему можно, конечно, через BDE, но есть и другой вариант - используй сторонние (с точки зрения Делфи) компоненты доступа к dbf. Я пробовал Apollo, в принципе получалось, SQL-запросы отрабатывали, на машину клиента ничего ставить не надо, только нужно вместе со своим exe-шником таскать одну или две Apollo-вских dll-ки (точно не помню, давно дело было). |
| ||
| Добавлю еще. Если действительно планируется постоянное добавление большого числа записей и выборка по подстроке, то наличие индексов будет даже вредно, т.к. индекс существенно замедляет процесс вставки новых записей. В случае dbf (без использования индексирования) процесс INSERT подразумевает собой тупейшую (с точки зрения операционной системы) операцию по увеличению файла на строго определенное количество байт (длина записи) и внесение в этот кусочек данных, указанных в INSERT. Так что, по-моему, использование dbf в данном случае наиболее оптимально. Есть, конечно, нюансы, но здесь они, как мне кажется, не важны. |
| ||
| Посмотреть скриншоты можно тут (хотя, кто не видел стандартного Enterprise Manager): http://www.aspenterprisemanager.com/ Patrol, я так понял, ты человеку для решения его задачи предлагаешь переустановить ОС (у него наверняка ХР, на неё аспнет не встаёт), поставить IIS, скачать и установить .net framework, разобраться, поставить и настроить рекомендуемый тобою варез и наконец создать таки в MSDE нужный баз? :))) |
| ||
| Спасибо всем за ответы по теме. Искать нужно в нескольких полях, поэтому я решил, что никакого индексирования и ключевых полей не нужно. MSDE неудобно по причином установки дополнительного ПО, что не хочется. Насчет долгой вставки: специально делал тесты на машине, на которой работал winamp и прочая фигня, так сказать в фоновом режиме, памяти там было также максимум 256. ЗЫ. Попробую с dbf форматом, результаты сообщу) |
| ||
| У меня тоже 256 :) И параллельно я пентакор гонял.. :) |
| ||
| у него наверняка ХР, на неё аспнет не встаёт Нормально встает |
| ||
| Ага, напутал я чего-то. |
| ||
| По поводу оперативки - напутал. Оказывается, у меня не 256 а 512 :) По поводу MSDE и тулзы: Винг, я вообще тебе отвечал на высказывание о сложности разобраться/администрировать :) |
| ||
| SQLite рулит |
| ||
| >>ЗЫ. Попробую с dbf форматом, результаты сообщу) Что получилось? На чем остановился? |
| ||
| Сорри, пока нет свободного времени на этот проект. Отложен на неопределенное время. |
| ||
| Рыболовный сезон на носу, SQL обмотан скотчем и убран на антресоли. |
| ||
| Завидуй молча. |
| ||
| А что, InterBase совсем в данном случае не устраивает ? |
| ||
| Она не удовлетворяет требованию "без установки дополнительных субд". |
| ||
| Я что-то слышал про MIDAS, может кто скажет что это за зверь ппдробней? Как раз по теме будет. |
| ||
| как раз наоборот, не по теме. подробности на сайте Borland'а |
| ||
| Без установки СУБД скорее всего подойдет MS Access, я тут прогу писал недавно надо было уйти от BDE, перепотрошил DBF вдоль и поперек, если работать через одбс очень медленно выполняются операции вставки - удаления, если напрямую, используя TDBF, чуть быстрее(на 20 - 30%), если писать прямо в файл не используя TDBF, то скорость правктически не меняется. Пробовал на голом проекте, DBF были локальные. Пробовал парадокс через одбс - скорость побыстрее, но все равно всё это очень медленно(мне надо было вставлять по 600 -1000 записей пакетно). Оракл все кушает на практически мгновенно, так я вообщем оставил мост на Оракл и дополнительно создал мост на MS Access, теперь юзеры могут создавать БД и там и там (по выбору). Ассess имеет мудреный SQL, благо по JET есть справки и файл разбухает от множественных транзакций, но это все мелочи если нужно достичь скорости работы. MS Access обрабатывает множественные транзакции на 60% быстрее DBF, и к тому же это полнофункциональная СУБД со всеми вытекающими. |
Отправил