Re: By The Dawn's Normal Light

"Paul" <paul_at_test.com> wrote in message news:418fe1dd$0$43592$ed2e19e4_at_ptn-nntp-reader04.plus.net...
> Marshall Spight wrote:
> > This conversations takes as a given that there's a
> > "relation engine" and a *separate* entity, the "type
> > engine." I've not heard this terminology outside
> > of this list. Can someone explain what the value of
> > separating these two entities is?
>
> I think it might be some terminology that I've made up. It's often said
> that "types and relations are orthogonal" (google this newsgroup for
> example) and this is just expressing that idea.
>
> It seems neatest to me to consider the part that does the relational
> stuff as a separate system to the part that does the type/domain stuff.
> It's like they are encapsulated from each other and interact only
> through well-defined interfaces.
>
> I think it's crucial when considering what is meant by "first normal
> form" and "atomic", for example.
>
> I've not written a DBMS so I'm only guessing, but I'd imagine the
> relational implementation would divide quite naturally from the
> implementation of the types/domains.
>
> But it makes sense to me to think about it from both a logical and
> physical point of view.
>
> The idea is that people should be able to write their own type
> implementations and add them to a relational core. How easy this is I'm
> not sure and I think it's difficulty might be underestimated, but it
> would fit with the idea of separating out the two.
>
> Paul.

I think you've got it, Paul.

I haven't written a DBMS either, but I've "read one", meaning I've studied the internals. The division into multiple "layers" of that DBMS was a large factor in its adaptability. The "logical/physical" layering of design was just the tip of the iceberg.

There were multiple layers within the parts that were not visible to the transaction clients. There was a type layer, a relational layer, an optimization layer, an indexing layer, a placement layer, a space management layer, and an operating system interface layer. Or something like that. My memory is hazy, and I'm too lazy to go look it up.

Anyway, to get back to the current theme, you should be able to go back and add some new type without having to rework the relational engine.

Let's say you've implemented with some kind of proprietary format for floating point numbers (this goes back a few years), and now you want to add IEEE floating point numbers as a new datatype. Well, gee, that shouldn't require any reworking of the lower layers, at all! If you've done your work carefully, it won't. If the whole system is spaghetti, it might.

If I were building a DBMS today, I would definitely learn OOP, and learn it well, first. I would then use OOP to prevent "the ripple effect" from paralyzing future evolution. This would probably result in something at least vaguely analogous to the "layers" I've described above. Received on Tue Nov 09 2004 - 14:00:32 CET