Вообще-то, SQL запрос через ADOCommand->Execute() выполнится быстрее чем ADORecordset->Update(). Потому что Update() пробежится по рекордсету лежащему в памяти, для каждой изменной строки сформирует SQL запрос и пошлет его на сервер через Execute().

Но сравнивать скорость этих двух методов все равно бессмысленно. Торомзить в этом месте будет не твоя программа, а сервер БД. Особенно если таблица большая, на ней стоят кривые индексы и "where" для sql запроса в Execute() или описание ключевых полей в рекордсете для Update() сделаны неправильно.

HomosumМеня это интересует чисто теоретически. Я стою перед выбором. Либо самому создавать запрос и отсылать его базе данных через Execute() или воспользоваться Update.Как хочешь... как тебе удобнее, так и делай. Лично я Update() не использую совсем, не доверяю ему :) Не, я знаю что он сделает все что нужно, но лично я предпочитаю всегда контролировать какой sql запрос уходит в базу. Считайте это религиозными воззрениями :)

HomosumЯ так понял Execute быстрее.На исчезающе малую долю миллисекунды...

HomosumНо вот фраза "
Особенно если таблица большая, на ней стоят кривые индексы и "where" для sql запроса в Execute() " мне немного не понятна. Что значит кривые индексы и "where" и как сделать, чтобы они не были кривыми?Это уже тема не для этого форума. Ну ладно, поофтопичу немного :)
Например у тебя есть таблица со списком телефонных звонков, звонок происходит в какой-то день и час. Можно хранить это в одном поле типа datetime, а можно хранить в паре полей типов date и time. Сделаем по этим полям индекс. Теперь если мы хотим получить список всех звонков за определенный день, то надо делать запросы такого вида:
select * from t where date(CallDateTime)=:yesterday // для случая с одним полем
select * from t where CallDate=:yesterday // для случая с двумя полями.
В первом случае индекс созданный по полю CallDateTime не будет использован, потому что в условии стоит функция от поля - это всего лишь обрезка временной части поля, но все равно это функция. Сервер бд будет делать полный скан таблицы, вычисляя функцию для каждой записи и сравнивая результат с константой.
А в случае двух полей и индекса по ним, уже будет использован индекс, потому что константа yesterday сравнивается со значением точно равным значениям внутри индекса.
Вторая засада в неявной конвертации, когда константа не того типа что поле с котором идет сравнение. Например поле типа date, а константа типа varchar. В этом случае сервер попытается привести обе стороны условия (и поле и константу) к общему знаменателю, возможно он догадается превратить константу из varchar в date перед тем как делать запрос, а может и не догадается и будет превращать поле date в varchar чтобы сравнить с varchar константой. В первом случае выборка использует индекс, во втором - появляется неявный вызов формулы и индекс не используется.
Это уже зависит от сервера БД, и большинство современных серверов достаточно умны, но все равно подобные приколы надо всегда учитывать.

HomosumА какие системы кроме Access еще понимают dbf?Да почти все... А если не умеют с dbf, умеют с каким-нибудь другим примитивным форматом работать. CSV, TSV, BCP или даже TXT с полями фиксированой ширины.
Этот подход действительно даст некоторый выигрыш во времени, но не значительный. Серверу БД все равно надо будет найти место в базе под новые записи или найти старую запись для обновления, да обновление индексов... Выигрыш будет за счет того, что данные посылаемые от клиента через нормальный коннект обзательно регестрируются в логе базы, а данные загружаемые сервором из локального файла нет (но это тоже зависит от сервера)..
Но подход с пакетным обновлением из внешнего файла имеет один серьезный недостаток - это может делать только сам сервер. Клиент командует серверу прочитать dbf - сервер читает, да. Но это значит что клиент во первых уже не контролирует процесс чтения. А во вторых, dbf должен быть доступен серверу, то есть либо физически лежать на машине с сервером, либо сервер должен будет по сети подмапировать диск клиентской машины.

А вообще-то, уже давно пора идит в соседний форум "Сравнения БД" или как-то так...

HomosumВедь моя нейронная сеть будет состоять приблизительно из 300-500 ядер (начальный уровень). Каждое ядро это примерно 110 нейронов. Между ними существуют связи. Из 300 ядер на каждом уровне обучения может обновляться до половины, а то и больше. И это будет делаться в автоматическом режиме. Т.е. чем больше будет оптимизация на любом уровне (будь то БД или же сами вычисления) тем быстрее в общем будет работать система.Ну хорошо, начни с того, что формализуй структуру данных. Хранить и модифицировать тебе нужно только связи (в смысле веса синапсов) а ядра сами по себе никаких данных между отдельными запусками не хранят, не должны хранить по идее :) Значит представляем ядра в качестве списка стуркур типа
Потом соединяем ядра при помощи набора синапсов:
И вот уже синапсы надо хранить в базе между запусками. В принципе, можно и текущее состояние ядер хранить в базе, но повторюсь еще раз: база данных это очень медленно. Намного эффективней будет использовать индексированый список с частичной выгрузкой на диск чтобы не хранить все разом в памяти. Но если хранить все в памяти, то будет эффективней :)
Ну а потом, делаешь выборку всех синапсов у которых аксон равен нулю, кидаешь в них какое-то значение. Для всех синапсов обработаных на данном шаге, выбираешь все ядра с номером указаном в дендрите, заменяешь значение в ядре. Потом для всех ядер выбираешь синапсы в которых аксоны равняются номерам обработаных ядер и продолжаешь по кругу, пока на очередном шаге не доберешься до синапсов с нулевыми дендритами.
Собственно говоря, для этой задачи между запусками достаточно хранить всего-лишь список синапсов, а для поиска нужного синпаса или ядра во время работы достаточно индекса (списка ядер сортированного по номерам ядер и списка синапсов сортированого по номерам аксонов и дендритов) в памяти. База данных тут вообще не нужна. Но если хочется взять что-то уже существующее и не изобретать собственную библиотеку работы с сортироваными списками, то Berkeley DB будет практически идеальным решением.