Boost logo

Boost :

From: David B. Held (dheld_at_[hidden])
Date: 2004-03-29 00:28:04


"Tom Brinkman" <reportbase_at_[hidden]> wrote in message
news:20040329042535.5205.qmail_at_web13907.mail.yahoo.com...
> [...]
> I see it, combined with the serialization library , as having the
> potential to eliminate the need for relational databases in c++
> applications.

I disagree entirely. I don't see that IndexedSet + Serialization
can replace JOINs, referential integrity, and a host of other
features that any standard RDB server provides. I especially
don't see how it can match the fast file access you should
expect and demand from an RDBMS. "Serialization" != "random
access". That being said, I do think that IndexedSet is a very
useful library, and my review of it will be forthcoming.

> [...]
> 1) When you add a record to an indexed_set, and it
> violates the index definition in some way, could you
> throw an exception, instead of simply replacing the
> original record?

I agree that at least an option for this behavior is probably
appropriate.

> 2) Is there support for mult-key unique indicies. I read in
> the documenation that you can have more than one unique
> indice in the definition, but they are unique individually.
> Question: Can you combine two or more of those unique
> indice to create a multi-key unique indice.

And this is where you begin to see the difference between
IndexedSet and a full RDBMS. ;) I don't think such a functionality
is necessarily appropriate at the IndexedSet level. I suspect
that this kind of feature might be supported by the RTL (which
acronym I really don't like, because it looks too much like
"RunTime Library"), but those authors will have to speak for it.
Then again, some kind of composite index might indeed be
appropriate at the IndexedSet level. I haven't thought it all
through.

Dave

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.581 / Virus Database: 368 - Release Date: 2/9/2004

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk