Database Engines with C++

[Reece]

I have a large app using DBF files and an obsolete language (Clipper).
I am looking at re-writing this in C++ but need suggestions about the
database part of the project. Ideally I would like to leave the
database commands alone and rewrite the rest.

Can anyone suggest good datbase engines? -- for example is MySql
better than SQL Server? Also, what about multi-format drivers? It
would be good if the DBF commands [eg GO TOP or DbGoTop()] could
handle SQL tables.

Any suggestions welcome

Reece

 

[Phlip]

I have a large app using DBF files and an obsolete language (Clipper).
I am looking at re-writing this in C++ but need suggestions about the
database part of the project. Ideally I would like to leave the
database commands alone and rewrite the rest.

I would use Rails's ActiveRecord over either MySQL or SQLite3.

C++ is for writing the database engine itself - not for using the engine to
implement business logic.

Also, you can start your project with AR and SQLite3, and then upgrade to a
new database as soon as you need to. AR lets you write migrations that work
on any database, so you can change database at whim.

Also, if you write all this as a Rails site, you have the option to put a
cute web interface on it. And that interface won't get in the way if you
don't need it, but you also get all the migrations, models, unit tests, and
generators stitched together for you, with copious documentation.

 

[Jerry Coffin]

I have a large app using DBF files and an obsolete language (Clipper).
I am looking at re-writing this in C++ but need suggestions about the
database part of the project. Ideally I would like to leave the
database commands alone and rewrite the rest.

Almost anything reasonably modern is likely to require a fairly
substantial rewrite. Clipper uses a basic model that's quite a bit
different from the semi-relational model used by SQL or almost anything
reasonably similar.

Can anyone suggest good datbase engines? -- for example is MySql
better than SQL Server? Also, what about multi-format drivers? It
would be good if the DBF commands [eg GO TOP or DbGoTop()] could
handle SQL tables.

The database engine should be an administrative question rather than a
development one. A decent database library (or even a pretty lousy one)
will insulate you from the specific engine you use. Quite a few will
work, for example, with essentially any engine that has an ODBC driver.

 

[Phlip]

Almost anything reasonably modern is likely to require a fairly

substantial rewrite. Clipper uses a basic model that's quite a bit
different from the semi-relational model used by SQL or almost anything
reasonably similar.

That's why a rewrite should start at characterizing the features and
specifications. A rewrite should not start at reproducing each low-level
function.

 

[Reece]

Philip & Jerry

Thanks for your replies. I will look at Rails’s AR.

Jerry

Maybe I should have asked for a suggested library, not an engine. Can
you suggest a good library?

Reece

 

[Phlip]

Maybe I should have asked for a suggested library, not an engine. Can
you suggest a good library?

http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software

From there I would click into each reference and look for citations into the
ActiveRecord pattern. It simply means...

- Create Read Update Delete are object methods
- comparing objects for equality compares their db IDs
- each record field has a super-easy accessor/mutator
- you can write biz logic as methods in the object class
- the schema itself automatically generates the accessors & CRUD

While I still recommend Ruby for your problem, you may have some other reason to
use C++. I would do that like this:

#include "my_record_.h"

class MyRecord: public MyRecord_ // automatically generated from the schema!
{
public:
void ponderMyRecord();
};

You maintain MyRecord, and the AR system itself maintains MyRecord_. Whenever
you change the database (such as a system like Ruby's AR's migrations), the AR
scripts automatically read the data definitions and generate the C++ statements
required to read and write (access & mutate) all its fields.

Such a system is DRY - Don't Repeat Yourself - because you don't express the
database fields twice, once in your migrations and again in your C++ class. DRY
is good. Further, such a system is super-easy to unit test.

 

[Jerry Coffin]

[ ... ]

Maybe I should have asked for a suggested library, not an engine. Can
you suggest a good library?

I rather like DTL, though I suspect some people are likely to find it
rather foreign (it attempts, and largely succeeds, at making a database
act like an STL container).

 

[James Kanze]

http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software

From what he's said, they haven't fixed on a data base yet. If
this is the case, and he wants something OO, there are a number
of object (oriented) data bases---the Wikipedia article "Object
database" lists quite a few.

Note that I know very little about this subject, other than the
fact that such databases exist, and can't say much more than I
just did. (The proof is that I'm reduced to citing
Wikipedia.)

Otherwise, I was on a project where we used some third party
software (something with the name of Persistence, or
Persistency---a name which makes an effective Google search for
the product almost impossible). I'll admit that I wasn't very
impressed with respect to what it provided. But having worked
on a number of projects using relational databases since then, I
do agree that some sort of automatic generation of code will
usually be necessary in all but the simplest cases. (I did work
on one project where we used OTL directly, but in that case,
there was only one table. Otherwise, I'll often use SQL
directly for some simple---and not so simple---ad hoc select
requests, where I'm only returning a couple of fields.)

From there I would click into each reference and look for
citations into the ActiveRecord pattern. It simply means...

- Create Read Update Delete are object methods
- comparing objects for equality compares their db IDs

Not sure I understand. Records (rows) in a relational DB don't
have id's. Equality and order are specified by the request, and
can vary from one request to the next.

- each record field has a super-easy accessor/mutator

Including the id field?

- you can write biz logic as methods in the object class
- the schema itself automatically generates the accessors &
CRUD

Or some more structured language generates both the code and the
schema? (Just an idea---don't know how it would work out in
practice.) Or a separate language which allows specifying the
column and the table for chaque field in the OO object? (For
more flexibility in interfacing with existing databases---you
don't have to define views in the database if your objects don't
correspond exactly to tables in the base.)

While I still recommend Ruby for your problem, you may have
some other reason to use C++. I would do that like this:

#include "my_record_.h"

class MyRecord: public MyRecord_ // automatically generated from the schema!
{
public:
void ponderMyRecord();
};

You maintain MyRecord, and the AR system itself maintains
MyRecord_. Whenever you change the database (such as a system
like Ruby's AR's migrations), the AR scripts automatically
read the data definitions and generate the C++ statements
required to read and write (access & mutate) all its fields.

Which may cause problems with versionning. (Of course, any time
you allow changes in the schema, you may have problems with
versionning. If you're going to allow it---and you often have
to---this is something you really should consider from the
start.)

Such a system is DRY - Don't Repeat Yourself - because you
don't express the database fields twice, once in your
migrations and again in your C++ class.

Which is normally good. If the database already exists,
however, and its tables don't correspond to what you want for
objects (which will almost always be the case---at best, your
objects will correspond to views), then you may have to do some
additional specification.