DAO - объектная модель - надстройка над ODBC.
ODBC - набор функций API - надежная, широко распространенная, но устаревающая технология доступа только к реляционным данным.
ADO - объектная модель - удобоваримая, с интуитивно понятной структурой надстройка над технологией OLE DB.
OLE DB - технология (в принципе, тоже объектная модель - набор объектов и интерфейсов для управления этими объектами), постепенно приходящая на смену ODBC. Позволяет обращаться к данным различной структуры (не только реляционным), поддерживает службы анализа данных OLAP.
Вот упрощенная, сокращенная, обобщенная, IMHO характеристика, так сказать, в общих чертах.
Думаю, найдутся желающие высказаться более подробно по отднльным темам.

P.S. Еще пару комментариев ( тоже IMHO ) :
ODBC и OLE DB - низкоуровневые интерфесы для доступа к данным (интерфесы в общем, не СОМ-, смысле). С ними, как правило (но не всегда), работают на C/C++. DAO и ADO - их обертки для упрощенного доступа к данным из языков более высоклго уровня VB, VBA, DELPHI и т.д. (опять же как правило, но бывают и исключения).

Это сообщение отредактировал(а) vickr - 4.7.2003, 12:30

Чисто с практической точки зрения:

ODBC - наиболее универсальная, тормознутая, стандартная, старая система. Используй там где нет ничего лучшего

DAO - даёт максимальные возможности при работе с MS Access/MS Excel (есть куча опций которые просто недоступны через другие системы). С MS Access работает очень быстро, но в основном за счёт очень сильного кэширования записи данных( если кэш сбрасывать после каждой транзакции, то скорость будет не быстрее чем ADO).

ADO - новая система от MS - претендует на стандарт доступа. Проста и удобна, не самая быстрая, но является "родной" для MS SQL Server. Если работаете с MS SQL Server то использовать надо только ADO, если с MS Access то только если скорость не очень критична. Для остальных баз данных можно задуматься об альтернативе

BDE - старая система от Borland. "Родная" для парадокса, очень хорошо работает так же с dbf самых разных мастей. Для коннекта с серверами баз данных хоть и можно использовать, но лучше подумать о чём-то более продвинутом.

DB Express - новая система от Borland. "Родная" для IB. Работает так же с DB/2, Oracle, Informix, MySQL. Очень компактна и проста в использовании, кросплатформенна (поддержка и в Windows и в Linux), но могут быть проблемы при дизайне очень навороченных multi-tier архитектур, более ориентированная на проекты малого и среднего размера.

Есть ещё куча систем доступа, специализированных для определённой базы данных (DOA, MySQL API и т.д.)- они обычно работают быстрее и дают больше возможностей, но в них нет универсальности, кросплатформенности, переносимости. Программирование их может быть подчас весьма трудоёмким, громоздким, сложным.


При выборе надо учитывать такие факторы:
1) Насколько критична скорость работы
2) Насколько критична универсальность
3) Насколько критичен доступ к тонким функциям настройки и опциям
4) Какая система является более "родной" для базы данных
5) Насколько критична сложность установки и настройки системы баз данных

При прочих равных обстоятельствах надо отдавать преимущества более новым системам, т.е. в первую очередь ADO и DBExpress, в последнюю ODBC и DAO.

При важности скорости работы что выбрать лучше
ADO или BDE???

ADO, однозначно. BDE и скорость - это антонимы.

Цитата(RAN @ 17.9.2003, 10:21)

ADO, однозначно. BDE и скорость - это антонимы.

Это несовсем так, точнее совсем не так! По результатам моих тестов BDE на локальных базах данных (Paradox, MS Access) работает более чем на порядок быстрее, а вот для серверных баз данных ситуация прямо противоположная. Следует учесть что родная система доступа практически всегда работает быстрее, т.е.

для Paradox - BDE
для MS Access - DAO
для MS SQL Server - ADO


Следует также отметить ещё один важный момент, сколько клиентов одновременно будет работать с базой данных. Если больше 3-5ти то предпочтение надо отдавать ADO, так как BDE/DAO оптимизированны под одного клиента, а ADO под clien-server архитектуру. Из этого следует так же какой делать дизайн программы, если с BDE/DAO быстрее будут таботать компоненты типа TTable, и притормаживать квери, то в ADO при работе с таблицами будут явные тормоза, и наоборот квери будут выполняться очень быстро...

Vit, с тобой спорить бесполезно. Буду знать. Просто мне приходилось работать с BDE + IB. База была большая и, IMHO, плохо нормализована. Впечатления отвратительные. Всё работало очень медленно. Клиентов было около 10. Из них 3-4 использовали базу очень активно.

В данном случае совершенно с тобой согласен! Во перавых IB это серверная база данных, во-вторых BDE не родная система доступа к IB, в-третьих у тебя было много клиентов и клиент-серверная архитектура. Именно в данной ситуации BDE - самый плохой выбор (нет, всё же самый плохой это ODBC). Как раз твой случай - это та классика, когда применять BDE категорически противопоказано... У меня самого был очень негативный опыт работы с BDE когда я пытался через него работать с большой и сильно нагруженной базой в MS SQL Server, но это ничуть не умаляет удобств и скорости работы BDE с локальными базами данных. Собственно, я именно к этому и веду - если ты внимательно читал мой топик, то я НИГДЕ НЕ ГОВОРЮ что какая-то система хороша, а другая плохая - просто они оптимизированны под разные задачи, разные базы, разные архитектуры. Нельзя всё под одну гребёнку, вот пара примеров из моей практики:

1) Случай первый: Локальные таблицы, один пользователь:

BDE+Paradox - выполнение Insert квери - больше 2000 кверей в минуту
ADO+MS Access - выполнение той же самой Insert квери - около 35 кверей в минуту

На том же самом компьютере, на тех же данных, в той же среде программирования...

2) Случай второй: Большая серверная база данных на MS SQL (около 50 гигабайт), больше сотни одновременных подключений, частота запросов к таблицам 20-30 кверей в секунду (вперемешку Select, Update, Insert квери)

BDE+SQL Link - в каждый момент минимум 1-2 клиента получают сообщения о Deadlock, timeout и т.п. Среднее время прохождения квери зачастую превышает 1 минуту... Четырёхпроцессорный MS SQL Server - загрузка всех процессоров - 100%

ADO - на той же самой системе, ни одна квери ни изменена, не оптимизирована, т.е. изменён только драйвер - Deadlock - нет, timeout - нет, время прохождения квери лишь изредко превышает 100 милисекунд, обычно где-то в районе 30-50 милисекунд. Загрузка процессоров на сервере колеблется в пределах 20-30%.


Вот они и преимущества...

Для DB Express есть драйвер и для MS SQL. Имеется специфакация для создания таких драйверов, так что в принипе возможно написание под любую БД

Цитата(Vit @ 17.9.2003, 22:35)

ADO - на той же самой системе, ни одна квери ни изменена, не оптимизирована, т.е. изменён только драйвер - Deadlock - нет, timeout - нет, время прохождения квери лишь изредко превышает 100 милисекунд, обычно где-то в районе  30-50 милисекунд. Загрузка процессоров на сервере колеблется в пределах 20-30%.

Небольшой вопрос. А величина результирующего запроса учитывалась?
Например я столкнулся с такой проблемой. При большой выборке выдача информации клиенту произволится на порядок быстрее, поскольку BDE перебрасывает данные по требованию (т.е откроет информацию, перебросив 10-15 записей), а ADO всегда полностью. При получении отчетов это не ииеет значение, а если клиент работает с БД в интерактиве, то большой недостаток.
А тесты вещь весьма относительная. Мы тоже в свое время проводили тесты и таких удручающих эффектов не видели. А тесты проводились, что бы уличить отдного товарища в некомпетентности, который утверждал что BDE + MS SQL быстрее. Мы же ( мы - потому что я был не один, нас была группа разработчиов) же пребывали в полной уверенности, что ADO + MS SQL будет вне конкуренции. После тестов, мы были вынуждены признать собственную некомпетентность. Хотя от ADO не отказались: много пришлось бы переделывать, да и технология умирающая. Сервер SuperMicro тоже 4-x процессорный на Xeon'ах. Вот так то.

Ещё раз подтверждает - кажлая система имеет что-то реализованное лучще или хуже.

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

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

из личного опыта....

Разве ADO построена не на ODBC?
Как же тогда программировать в MFC?
В MFC нашел примеры DAO и ODBC причем отдельно друг от друга.
Никаких примеров MFC с ADO нет.
Неужели для ADO нужно использовать какие-то другие классы?

Цитата

Разве ADO построена не на ODBC?

Нет, но имеет возможность использования ODBC драйверов

Цитата

Как же тогда программировать в MFC?

Как обычно. ADO основано на OLE DB, а OLE DB имеет совершенно стандартный OLE интерфейс, создавайте OLE объекты и работайте

Цитата

В MFC нашел примеры DAO и ODBC причем отдельно друг от друга. Никаких примеров MFC с ADO нет.

Есть тысячи серверов OLE для которых нет примеров работы, но в том то и дело что они стандартные, ибо суть - OLE. Разбирайтесь...

Цитата

Неужели для ADO нужно использовать какие-то другие классы?

А что в MFC работа с чужими интерфейсами такая проблема?

А никто не может сказать что-нибудь насчет JDBC? Она, кажется, тоже как-то использует ODBC-технологию... Или нет?