Indeed it may be questionable to use SQLite for stuff like this, but its a
very fast relational db library - and therefore it can be used as any other
relational database to store objects.
What is needed is very simple: you need a object-oriented relation database
wrapper - either as a commercial library or as a home written software.
Be aware, that storing objects in relational database IS not a trivial task
(concerning the fact, that you want to have good speed). Especially
tree structures are always difficult to handle (in an efficient way). Some
databases have special SQL commands extension for that. Tree structures
are often used in the GUI applications.
I've worked with Smalltalk and relational databases and yes it can be
done, but going this way, one has to consider BOTH sides of the
development: the
object oriented side and the relational side and perhaps one should not use
the most hottest feature in the OO world, because mapping can only be
done very badly. Accept the relational side and then you may get happy.
How to map oo structures into databases has been described in the literature
over the last 15 years (starting with Smalltalk, then with Java and now with
C# and all hottest languages) in many online arcticles, in many books etc.
Making a good mapping assumes the knowledge about relational databases,
about the application one has to write and the special needs of this
application.
In general: without tool support, you will get lost.
As an example: I've over the year (in Smalltalk) used a commercial
library, which
allows me to define a oo model (classes, hierarchies, attributes,
associations). Then
it creates a "simple" relational database layout and the Smalltalk base
code for
the model. You may defined searchable attributes (leading to indices)
and several
different kinds of mappings: one class to one table, several classes to
one table etc.
Databases like this are (in newer days) called integrational databases,
because they
look like normal databases and the values can be retrieved from all
other languages.
Other databases are the application oriented databases - databases with
- perhaps -
strange layouts (in the normal sense of relational databases): one
simple example
is a table with two coloumns: one for the object id, the other for a
BLOB column,
holding the binary representation of the object).
Now I go another way: I've written my modeller by myself and also wrote
a code
generator for the languages I wanted to support (in this case C#).
Within the model
each attribut, each association and each class gets a unique number (for
management
purposes). The data types supported are restricted to Integer, String,
Floats, Decimal,
Date, DateTime, Boolean - mainly the basic stuff. Even support for
arrays are possible.
Then I defined a general micro language to create a binary
representation of my object
and changed the modeller to create source code for this representation.
The textual representation of ths language would be like (simplified)
set objectid environment to <objectid>
set attribute 1 to value <12.23>
set attribute 2 to value <false>
set attribute 3 to value <2006/01/20>
add association at attribute 4 with object with <objectid2>
close objectid environment
This representation is pretty compact and can be created automatically
and even the
code to restore the object from that representation can be created
automatically and
pretty fast.
Searchable attributes are (in addition) not only stored in this binary
(BLOB) representation,
but also in special tables: each searchable attribute has its own table
and always the same
layout: column1: object id, column2: attribute value. The name of this
table may be
created automatically using the attribute id of the attribute. (The
drawbacks of this
procedure are quite clear - several insert for ONE object. For a local
database (file
oriented) this may be not that critical, for a networked database this
approach is more
critical).
Associations are handled using additional tables ....
You see: there are standard ways of doing the work and very specialized
ways of
doing it ....
Marten
Jay Sprenkle schrieb:
On 1/14/06, michael munson <[EMAIL PROTECTED]> wrote:
Greetings,
I'm a bit new to SQL and SQLite so pardon me if I ask silly questions but I
have run into a bit of a wall while attempting to design a database for a C++
program I am attempting to write.
The needs of the database are to: represent an object oriented hierarchy of any
number of objects, where each object may have custom properties of several
different datatypes and permission bits.
What about defining a table called 'properties'. It would have a key
to link to the object and 'name' and 'value' column for each object
property. You could have as many properties as desired for each object
and they need not be the same for each object.
I do wonder the same thing as another poster. Is a database really the
tool you want
to be using for this? I can't imagine what you really need with a
database for that
application.
