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-технологию... Или нет?

Довольно интересный спичь и видно, что не голословный.

Моет у кого-то есть опыт и по моей проблемке

Есть прога на аксессе (ОДБС)
Прив выполнении сложных запрсов (связывается 10-12 таблиц одновременнл) ОООЧень тормозит (до 10 мин на выборку 1000-2000записей) (сами таблицы довольно невелеки (500тыс-1000тыс записей - 2-3 основные и по 100-200 остальные)

Может подскажете можно ли это как-то значительно оптимизировать за счет использования других сред разработки??? Или что не делай - серьезных изменений не будет???

Цитата(Lamer @ 10.5.2005, 15:52)

никто не может сказать что-нибудь насчет JDBC?

Да, она использует ODBC-технологию, но по опыту
скажу одно - с dbf работает отвратительно.
Пришлось преписывать прогу с нуля(он на это дело положил год), или прогер оказался не ахти.

Может кто подскажит:
Нужен универсальный доступ к различным БД: MySQL, PostgreSQL (в основном)(Linux/Windows), но возможны и MS SQL (Windows).
Т.е. кросс-платформенные БД (точнее что стоит у заказчика).
Что использовать? Еще бесплатная чтоб была.
Нашел вроде ODBC++, но вы ж говорите что ODBC устаревает?

Ну если нужна кросплатформенность, то почему бы не взять Java + JDBC?

Нельзя, я уже пишу на С++, а переделывать как-то неохото.
Уж больно много времени уже потратил.

Кстати, ADO .NET - тоже довольно универсальное решение. Правда, не кроссплатформенное. С ADO не имеет ничего общего, подходит для любых БД, для которых разработан соответствующий адаптер (OLE DB, ODBC, родная поддержка MSSQL, видел адаптеры для IB и других БД). Напоминает JDBC.

Тут часто упоминают JDBC это разве не ODBC с использованием Java? или я что-то путаю?

Но источник старый, 1997 года (http://www.osp.ru/lan/1997/04/27.htm)
Добавлено @ 21:59
Судя по сановской статье, возможно использование JDBC как через ODBC-bridge, так и без него - http://java.sun.com/products/jdbc/overview.html
Добавлено @ 22:02
И еще:



но, по-моему, ко всем популярным СУБД JDBC-драйвера найти нетрудно.

У Microsoft появился новый проект - DLinq. Это круче всех систем БД, которые я видел. А возможность писать запросы с проверкой типов... Я от него просто балдею . Скачать описание можно тут, скачать preview можно тут. Как только выйду из состояния офигевания, обязательно напишу статью о LINQ, да и о C# 3.0 в целом. Сорри за оффтоп.

Я так понимаю, что DBExpress - платный. Так что лучше использовать для MySQL? ODBC что ли? 

Под Хами тоже есть твой ADO.net!   

Добавлено @ 12:00 
Сам в основном использую ADO.  

Я так понял, что ODBC и ADO разные вещи.

Я не сильно разбираюсь. Я вот утановил MySQL Connector/ODBC  и использую в Билдере ADOQuery. Так как это? Это что я как бы использую ODBC и ADO в паре ? Разъясните пожалуста мне   
 

OLE DB - если мне не изменяет мой склероз, набор COM интерфейсов для доступа к БД. ADO - объектная обертка для этой технологии.  В данном случае используется OLE DB провайдер для ODBC драйверов. И что -то мне подсказывает, что такая связка будет работать неочень быстро.

Кто знает что-нибудь про DOA. Если бы еще знать откуда скачать, то это вообще супер было бы и вообще, стоит ли щас гемороиться и искать DOA, если к Oracle есть провайдер для ADO?

Для доступа к Firebird/Interbase весьма рекомендую компоненты FibPlus, платные, но не дорогие. Уже несколько лет пользуюсь. Хорошая документация с примерами. Хорошая техподдержка. Скорость доступа к данным на много быстрее, чем у стандартных компонент, встроенных в BDS.

А у меня тоже вопрос. Для работы с Postgre вроде есть своя библиотека (libpg или pglib называется - не помню). Через нее работает pgAdmin, если я не путаю. Что лучше - эта библиотека или ODBC? (хотя я догадываюсь, какой будет ответ...) В чем конкретно будут преимущества?

Ты сможешь полностью использовать возможности PostgreSQL: все встроенные типы (геометрические и т.п.), более полный контроль за транзакциями и т.п.

Добрый день! Последнее сообщение было 3 года назад. Что изменилось за это время в способах доступа к данным?? Работаем на Дельфи 7, БД Informix. Собрались перейти с BDE на dbExpress... или может что-то лучше уже придумали?? Тем более что пока что по результатам тестирования побеждает BDE.. с dbExpress работает медленнее

Уже не рекомендую   , по крайней мер покупать не рекомендую.
т.к. техподдержка там стала отвратительная, если она вообще есть. 

Добавлено через 2 минуты и 32 секунды

Вроде UniDAC, AnyDAC неплохие и динамично развивающиеся.

Спасибо, сейчас буду изучать. Их надо покупать и дополнительно ставить? а из того, что в Дельфи идет? или может в новом Дельфи XE2 появится? 
А по поводу dbExpress?? Везде пишут, что он должен быть быстрее BDE.. может его как то специально настраивать надо?? Проход по таблице и набор инсертов-апдейтов явно медленнее идет с dbExpress..

Кажется UniDAC с Информиксом не дружит :(((

Вроде даже есть бесплатные - FreeDAC

Добавлено через 1 минуту и 31 секунду

Посмотри на схему. Там в конце, мне помнится есть что-то вроде Other DataBase VIA ODBC, но производительность..... я бы лучше нашёл и использовать компоненты прямого доступа, БЕЗ ODBC.

Добавлено через 2 минуты и 53 секунды

Судя по схеме, AnyDAC тоже ректально через ODBC/dbExpress

Добавлено через 5 минут и 58 секунд
Поищи Luxena Informix Data Access Components, но вряд ли они до сих пор развиваются

Добавлено через 7 минут и 21 секунду
Мож здесь что-нить найдёшь: http://www.supershareware.com/odbc-informix-free/

Добавлено через 9 минут и 43 секунды
а здесь смотрел?
http://myinformix.narod.ru/

Добавлено через 12 минут и 5 секунд
В общем ещё в 2008 году разработчики сообщили, что Luxena IDAC развивать не планируют.

Судя по всему нормальных прямых компонент для Delphi нету.

Добавлено через 12 минут и 47 секунд
Оставайся на DBE наверное 

эххх...  ну можно еще на dbExpress перейти, хотя пока что по тестам работает медленней :( но dbExpress хоть развивается, в XE2 есть..

ну или сменить базу данных, что-то для этого Информикса особо нет ничего 

ну еще изучаю сейчас SQLdirect - тоже медленней работает пока..

а может вообще ADO????

через ODBC ?