15 мая 2023 года "Исходники.РУ" отмечают своё 23-летие!
Поздравляем всех причастных и неравнодушных с этим событием!
И огромное спасибо всем, кто был и остаётся с нами все эти годы!

Главная Форум Журнал Wiki DRKB Discuz!ML Помощь проекту


DAO vs. CRecordset

Dimitri Nikouline -- Dimitri_Nikouline@tscorp.com
Monday, May 20, 1996

Environment: Windows NT 3.51, Visual C++ 4.1
We develop decision support type applications for banks.
We use client/server architecture where server side is some UNIX box running 
Oracle or Teradata.
The databases we are dealing with are substantially large, up to 1 Terabyte.
We are in the process of rewriting our code from Windows 3.1/Borland to Windows 
NT 3.51/VC++.
The big question we have is which database access technology we should use: 
CRecordset or CDAORecordset.
Here is briefly what we learned about both of these technologies:

CRecordset
Pros:
1. Directly wrapped around ODBC.
2. Source code comes as part of MFC.
3. Recommended by Microsoft for use with external data sources.
Cons:
1.  Because we have only level 1 ODBC drivers, scrolling implemented in the 
cursor library by caching all records in the memory.
2. Transactions at the database connection level. 
3. DDX for CTime is not provided.
4. AppWizard maps Numeric fields to CString.


DAO
Pros:
1.  Allows you to store all your queries in one place.
2. Transactions based at the Workspace level.
3. Full control of number of records you want to cache.
4. Caches primary key only.
5. Provides much more functionality than CRecordset.
6. Seems like is going to play a big part in the upcoming OLE-DB thing from 
Microsoft.
Cons:
1. Introduces another file to maintain.
2. Extra layer on top of the ODBC.
3. Source code is not available.

 
We would like to find out about negative/positive experiences with both of 
those technologies in the similar to us environment.
Any advise will be greatly appreciated.


Dimitri






Frederic Steppe -- FredericS@msn.com
Friday, May 24, 1996

[Mini-digest: 2 responses]

>Environment: Windows NT 3.51, Visual C++ 4.1
>We develop decision support type applications for banks.
>We use client/server architecture where server side is some UNIX box running 
>Oracle or Teradata.
>The databases we are dealing with are substantially large, up to 1 Terabyte.
>We are in the process of rewriting our code from Windows 3.1/Borland to 
Windows 
>NT 3.51/VC++.
>The big question we have is which database access technology we should use: 
>CRecordset or CDAORecordset.

This kind of choice is always difficult to make.  Maybe I can give you some 
"personal" feelings about what I would do.

First of all, if I target a specific database, like SQL server, etc I would 
try to avoid both ODBC and DAO by using embedded SQL or something similar (see 
if there is a development kit available for your DB).  C++ wrapping is usually 
easy.

Otherwise, Consider the following points :

The source code for the ODBC classes are provided with MFC, as are the source 
code for the DAO classes.  What you don't get are the source of the DAO 
engine, but you don't have the sources of the ODBC manager either.

DDX for CTime is not provided, but it will take you 30 minutes max to write it 
(see custom data exchange article VC++ help)

As far as I know, DAO uses ODBC to access non-DAO sources.  That should 
implicitly mean that the ODBC transactions are isolated by connection.

Last but not least, remember ODBC is always a little bit slow, with or without 
DAO, if you have to prepare many queries.


Frederic Steppe (frederics@msn.com)
-----From: "Ray Frohnhoefer" 

Dimitri,

We chose DAO after examining these issues and performing a "pseudo" TPC-A
benchmark against both products.  DAO out-performed ODBC by 2-4:1. When
adding 1 million 100 byte records, performance hardly changed (our database
is small, so we didn't look at performance beyond that).  As for your DAO
"cons", the source is in DAOCORE.CPP and  performance would indicate that it
is not a layer above ODBC.  I'm not sure what extra file you are referring
to.  I searched my system and found some JET*.TMP and RMS*.TMP files in
\WINDOWS\TEMP, but they appear to only be created by failed programs
(cleaned up by normal termination).

You might want to take a look at the issue of portability, which should be a
bit easier with ODBC.  It wasn't a big issue for us.

Regards,
Ray F.

           Gott wuerfelt nicht.
                        - Albert Einstein                     
**********************************************************************
*  Ray Frohnhoefer                         email: rayf@datatree.com
*  Software Development Mgr.                      Frohnzie@aol.com          
*  DataTree Corporation                    phone: (619) 231-3300 x131
*  550 West "C" Street, Ste. 2040          fax:   (619) 231-3301 
*  San Diego, CA  92101              
**********************************************************************






| Вернуться в корень Архива |