Marten makes good points. I would go further and suggest that you look
at creating your own API and DB primitives for your application. Often
you will find that trying to shoehorn general purpose tools into tightly
specific applications is as much effort as rigorously defining the
problem and creating a purpose built solution which is tight, fast and
easy to code.
JS
Marten Feldtmann wrote:
Just some additional comments:
The "vertical" approach (described by Teg) leads also to a very
untypical relational
database and if a pure sql administrator would look at it .....
Ok, but it works, but when using a vertical approach you have consider some
points:
* you have to throw away the column (attribute) constraints (contraint,
unique) ...
* accessing the data needs SQL commands, whichs stresses parts of SQL one
normally would not use and perhaps you may find some bugs (group by) ...
* insert speed increases pretty linear (when having ONE table for all
objects -
again different mapping may improve this). queries are not that bad.
* you need tool support - otherwise you are lost.
If you can read Germany - I've described the vertical approach in a
presentation
on page 28:
http://www.schrievkrom.de/uk/tips/nordakademie-2004/Vortrag-Nordakademie-2004.pdf
In this presentation there's also stuff about using/creating database
portable object-ids
and stuff like this.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
The "XML" approach is - more or less - a marketing idea ... XML is now
used for
everything and the main problem of XML is: speed.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
"SQL for Smarties" is a well written book - (by the way: the author is
Joe Celko)
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Another points FOR SQL oriented databases: they are initially open for ALL
programming languages and therefore pretty different from all these
language
centric databases (mainly in the Java world). This is achieved by
introducing
an API - which every language has the same possibilities to get most of the
database - and NOT by using language bindings.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
If you have to consider tree structures you should consider the special SQL
extension some databases offer: (SAP-DB, MaxDB, Firebird). These SQL
extensions (sometimes called recursive sql selects) can improve the
speed of
your application in a DRAMATIC way !!!!!
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.
