Re: Three table database - period (?)

Jens wrote:
> Jan Hidders wrote:
>
> > Jens wrote:
 

> > It's very close the a meta data model. The drawbacks are indeed the
> > speed (more joins neccessary, constraint checking is going to be a
> > lot harder and will more often require joins) and space (lots of
> > extra IDs in lots of places) and finally a problem may be the fact
> > that you don't really have a database schema anymore. So you don't
> > really now in advance what attributes of what type an entity is
> > going to have, for example. But in some cases that can also be an
> > advantage.
>
> That's the main reason I was thinking about this. The schema is is in
> the application logic (objects) - I can change the objects
> dynamically without having to change the database.

Ah. I already thought it had an object-oriented smell to it. :-)

> As the attribute table can (and will) get really big I want to avoid
> expensive joins between the tables so I was thinking it might be
> better to make the join in the application where the attributes are
> really needed and I can put in some intelligence in handling them.
> This really is not a join per se. I would just be using the indexes
> to find the right attributes.

Er, let me get this straight. In order to avoid expensive joins you are going to do them yourselves? Most databases are especially optimized to do exactly that sort of thing. Are you smarter then the people who built those databases? :-) Especially if the joins are so big that they won't fit into main memory programming it yourself is going to lead to a lot more disk access.

-- 
  Jan Hidders