Сейчас делаю программу, так вот когда
выбирал бд, то выбирал между DAO и ODBC.
Выбрал DAO.
А вот ADO еще... а в ней чего такого
хорошего? Чем она лучше/хуже, в каких
случаях использовать?
В принципе о преимуществаз ADO много написано в класике.
Это надстройка над OLE DB, технология активно поддерживаемая и развиваемая Microsoft, в отличие от DAO и ODBC. DAO построена на MS Jet, я читал еще года 2 назад, что Microsoft не будет развивать движок Jet, хотя, конечно, будет поддерживать.
DAO ориентирована на MS Access базы данных, хотя поддерживает и другие форматы, но я не знаю примеров удачного использования с MS SQL или чем то еще.
MFCный Wizard, хотя и облегчает первый шаг в работе с базами данными, но дальше начинаются сполшные проблемы с каждой мелочью.
Нет грида. /*я имею ввиду в комплекте*/
Не представляю как можно использовать DAO в многозвенной архитектуре.
Главное, наверно, не зацикливаться на том, что предоставляет для работы с базами данных MFC, я, к примеру, вообще не использую MFCные классы для работы с БД.
Для работы с ADO, коонечно, надо поразбираться немного, COM знать немного. Но лучше день потерять, потом за 5 минут долететь.
Здравствуйте IT, вы писали:
M>>А вот ADO еще... а в ней чего такого M>>хорошего? Чем она лучше/хуже, в каких M>>случаях использовать?
IT>Ispol'zovat' vo vseh sluchajah, osobenno vmesto DAO & ODBC.
IT>Happy coding, IT>Igor
Совсем не убедительно. ADO — надстройка над OLE DB, что отнюдь не добавляет скорости приложению. А если в качестве драйвера используется ODBC-драйвер, то и OLE DB является надстройкой над ним, т.е. еще один уровень. Плюс обязательное подключение COM.
Я не вижу никакой пользы от использования OLE DB (и тем более ADO) в приложениях, которым больше не зачем подсистема COM. Например, ISAPI-extension, работающий только с БД, прекрасно пишется с использованием только ODBC API.
Здравствуйте Alex Ostapenko, вы писали:
AO>Совсем не убедительно. ADO — надстройка над OLE DB, что отнюдь не добавляет скорости приложению. А если в качестве драйвера используется ODBC-драйвер, то и OLE DB является надстройкой над ним, т.е. еще один уровень. Плюс обязательное подключение COM. AO>Я не вижу никакой пользы от использования OLE DB (и тем более ADO) в приложениях, которым больше не зачем подсистема COM. Например, ISAPI-extension, работающий только с БД, прекрасно пишется с использованием только ODBC API.
А как насчет универсализма? Или это уже не ценится?
ADO легок и удобен в использовании.
Практически стольже быстр, как и OLE DB, т.е. в некоторых случаях он очень эффективен (например, провайдеры MS SQL), в некоторых менее эффективен (когда на ODBC), но при этом всегда один и тот же ADO.
Здравствуйте WindJammer, вы писали:
WJ>Здравствуйте Alex Ostapenko, вы писали:
AO>>Совсем не убедительно. ADO — надстройка над OLE DB, что отнюдь не добавляет скорости приложению. А если в качестве драйвера используется ODBC-драйвер, то и OLE DB является надстройкой над ним, т.е. еще один уровень. Плюс обязательное подключение COM. AO>>Я не вижу никакой пользы от использования OLE DB (и тем более ADO) в приложениях, которым больше не зачем подсистема COM. Например, ISAPI-extension, работающий только с БД, прекрасно пишется с использованием только ODBC API.
WJ>А как насчет универсализма? Или это уже не ценится? WJ>ADO легок и удобен в использовании. WJ>Практически стольже быстр, как и OLE DB, т.е. в некоторых случаях он очень эффективен (например, провайдеры MS SQL), в некоторых менее эффективен (когда на ODBC), но при этом всегда один и тот же ADO.
Речь шла про использование ВСЕГДА. Есть задачи, в которых универсальность стоит на последнем месте, а скорость — на первом. В таком случае стоит пару раз подумать, нужно ли навешивать кучу wrapper'ов ради простоты и универсальности. Кстати, ODBC не намного менее универсален, чем OLE DB и ADO, только писать под него несколько сложнее.
Здравствуйте Alex Ostapenko, Вы писали:
AO>Совсем не убедительно. ADO — надстройка над OLE DB, что отнюдь не добавляет скорости приложению.
Ох уж эти аргументы про скорость. Мы используем ADO и из VB и из VC и НИКОГДА не жаловались на скорость, хотя приложения все критичные по скорости. OLE DB не используем в связи с монстроидальностью кода. Опять же ADO в настоящее время документирован в MSDN много лучше чем все остальное.
AO>А если в качестве драйвера используется ODBC-драйвер, то и OLE DB является надстройкой над ним, т.е. еще один уровень.
А не надо использовать ODBC, использовать надо родной провайдер.
AO>Я не вижу никакой пользы от использования OLE DB (и тем более ADO) в приложениях, которым больше не зачем подсистема COM. Например, ISAPI-extension, работающий только с БД, прекрасно пишется с использованием только ODBC API.
Когда-нибудь настанет время, когда MS скажет: "абзац, кто не успел тот опоздал" и все такие проги перестанут работать
Удачи.
тут перечислены подробно все достоинства и недостатки ADO
в двух словах и по русски. ADO это тяжеловесная надстройка над
OLEDB. ADO больше подходит для VB. из C++ рекомендуется
использовать OLEDB через библиотеку шаблонов (ATL consumer templates)
мнение автора статьи, не мое. спорьте, господа :-)
имхо. ADO удобно пользовать из-за поддерживаемого маршалинга рекордсетов
именно поэтому я его юзаю (удобно передавать данные между COM+ и ASP)
как это делать в случае OLEDB не в курсе
ADO's second most important function is simplification of the OLE DB programming model. This benefit is quite welcome by any programmer, including C++ programmers. However, the cost of using ADO is high. Too high perhaps to justify the model simplification benefit, especially if other alternatives exist. Using ADO has these disadvantages:
ADO does not expose the full OLE DB feature set. It does not even come close. Performing certain tasks in ADO is a lot less efficient because the efficient code path is unavailable. And there are some tasks you cannot perform at all in ADO. Period.
The high abstraction delta ADO creates for data access clients results in a rather thick layer of software. ADO is not exactly a lightweight framework. As always, layers of software take their toll on performance. The thicker the layer, the heavier the toll. ADO exacts a measurable performance drain. Whether this matters depends entirely on the particulars of how and where ADO is being used. (Recall the law of task percentages from Chapter 13.) C++ programmers are more likely to be hurt by the performance cost because C++ is the language of choice for writing high-performance COM+ components.
ADO objects, including the recordset, are apartment threaded. High-performance C++ components are often free threaded or thread neutral. The performance penalty for iterating across ADO recordsets, across apartments, is significant and is heaped on top of the penalty levied by the abstraction delta.
Because ADO must present an interface to arbitrary data strictly through COM+ interfaces, ADO is forced to use the VARIANT type copiously. This is just fine for Visual Basic and other environments, but Variants are cumbersome to manipulate in C++, even with the aid of helper classes such as ATL's CComVariant and the _variant_t class made available by #import. Using Variants makes dealing with raw11 ADO unpleasant for C++ programmers. Later in this section, I will show you how to mitigate this problem by layering yet another technology on top of ADO.
I suggest these guidelines: First, recognize that the future of data access on Windows platforms rests firmly on the OLE DB foundation. OLE DB (with the help of the ODBC provider) is by far the most universal and widespread data access interface on Windows today. Expect new types of data sources to appear in the Windows market with OLE DB providers first, and perhaps no other interface at all. Second, make a choice that suits the development environment you use. The following are good combinations:
Use ADO in Visual Basic components.
Use ATL OLE DB consumer templates in Visual C++ components. I will discuss conditions for using ADO in C++ and options for doing so later in this chapter, in the "C++ Data Access" section.
Use ADO through WFC in J++ components. Use JDBC if Java code must be portable.
Consider OO4O in any development environment for access to those data items that are tied to Oracle products.
Здравствуйте Awaken, Вы писали:
A>тут перечислены подробно все достоинства и недостатки ADO
A>в двух словах и по русски. ADO это тяжеловесная надстройка над A>OLEDB. ADO больше подходит для VB. из C++ рекомендуется A>использовать OLEDB через библиотеку шаблонов (ATL consumer templates) A>мнение автора статьи, не мое. спорьте, господа
Ну дык указал бы автора статьи да и ссылку на статью тоже.
TL>Ну дык указал бы автора статьи да и ссылку на статью тоже. :user:
это книжка
Designing Solutions with COM+ Technologies (Brown/Baron/Chadwick)
я ее скачал с FTP одного из участников этого форума, у кого не помню
посмотри в Работе , топик где обсуждали литературу по COM
Если нам не помогут, то мы тоже никого не пощадим.
