[
Lists Home |
Date Index |
Thread Index
]
On 11/30/05, Michael Kay <mike@saxonica.com> wrote:
> > Surely you're
> > not saying that you are opposed to using RDB's for any real world
> > problems requiring extensive normalization? Or maybe you're saying
> > that if you've got to do extensive normalization you prefer other
> > forms of databases?
>
> Relational databases are a very useful tool, there are some jobs they are
> very good at (mainly the kind of jobs that people used punched cards for 50
> years ago).
>
> But surely you're not saying that they're the only tool, that all persistent
> data should be held in relational databases? How many word processors or
> email servers use an RDB to store their data?
You should ask that question on an AS/400 (whatever it's callled now)
mailing list... :-)
> There have always been some jobs that the relational model was not well
> suited to. Like any tool, you should use it when it suits the task in hand,
> and not otherwise.
>
> The need for extensive normalization is one of the features that suggests an
> RDB might not be the best tool for a particular job. The need for recursive
> query is another.
If you're writing a recursive query in an RDB then your data model is wrong...
> Additional indicators are intrinsic ordering, an
> intrinsic notion of object identity, the absence of a predefined schema, or
> the need for non-boolean queries. You can stretch relational technology to
> tackle some of these problems, but only by making it non-relational.
>
> You seem to be adopting a position where one has to defend a decision not to
> use an RDBMS. That's absurd.
>
No, I believe I understand why you don't think a RDB is always the
solution. I still don't understand exactly what you think is wrong
with Celko's nested set solution for tree management in an RDB. At
this point I'm guessing that you're saying one should have to delve
into the level of schema design that such a model requires and instead
should have a database that is designed specifically for tree
management? I guess I can buy into that with two caveats:
1) some of us have real reasons to be doing low level tool
development. At some point an index is an index is an index and there
are other drivers for making the decisions on the underlying data
store;
2) there's often a need to mix tree models with standard relational
data. In our case 90% of the data fits a relational model very well.
The 10% that doesn't is critical and it can't easily be separated out
into something else.
For the latter case, what kind of approach do you recommend?
--
Peter Hunsberger
|
