Re: Is supertyping orthadox?

> > Just to be clear, I think that in your case the generic-table
> > solution is definitely not a good solution and I would describe it as
> > 'sloppy design' at best. As far as you remarks above concern, I agree
> > with you completely. In order to make this design work you really have
> > to know what you are doing because you are taking over some
> > responsibilities that are normally left to the DBMS.
>
> If I had to bet on it, I'd suspect that the consultants are going to be
> using a homegrown set of query-building and/or screen-building tools
> (which they haven't told you about yet :-).
Unfortunately that isn't the case.

My specific situation is that they have done initial analysis and design of a system that is more than just this services structure (and in their defence have done a good job at producing preliminary logical designs of the overall system). The part of the database that would deal with the services however I'm not happy about, due to its complexity and inflexibility. The consultants will not be actually building this system... that's to be done in-house, which is why I'm a little more concerned about it than I would be otherwise.

You've all now got me thinking whether there is *ever* a reason to do what I consider to be 'reinventing the wheel'. Rather than going one level deeper in abstraction, wouldn't it be better to go one level up in abstraction (within the application it is designed for) and deal with the dbms's system tables etc. to do the same thing?

This way you're reducing the chance of error, saving yourself a lot of time and being able to use all the nice tools that you've paid for when you bought the dbms. To do it 'properly' you'd have to redesign all of the things that you get for free normally:

Views
Diagrams
Full SQL interpreter

and maybe even

Table Indexes (!?)
Table Constraints
etc.

The time taken to do all of this I accept would only be one off (not taking into account the maintainance of the code) .. but .. is there any point? You just end up with a dbms inside a dbms.

Actually it may be interesting to pretend that we have all of this functionality and then try to think of a reason why you wouldn't want to go *another* level deeper.. where does it end? :-)

Kind regards
 -=- Brett Received on Thu Mar 22 2001 - 10:56:29 CET