Re: Database Engines with C++
On May 9, 6:57 pm, Phlip <phlip2...@gmail.com> wrote:
Reece wrote:
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 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 s=
chema!
{
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.
DRY is good. Further, such a system is super-easy to unit
test.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34