Re: Is it really that bad?

From: JRStern <JRStern_at_gte.net>
Date: Tue, 06 Mar 2001 17:41:12 GMT
Message-ID: <3aa5201d.6353966_at_news.gte.net>


On Wed, 7 Mar 2001 02:56:50 +1300, "kurt" <out_sp0k1n_at_yahoo.co.nz> wrote:
>I've just spent the last 2 months working like a dog (yep,
>just like everyone else), implementing a database and a few

>associated applications. Unfortunately, my employers main
>designers were busy with other things, so the implementation
>was left to me. Given that there was a fairly tight deadline, I
>bashed out what I thought was a good solution to the problem,
>and which could reasonably be extended or replaced simply
>when revisiting the application for stage 2. However they have
>now decided that this solution wasn't good enough and are
>getting antsy on paying...

If there's a fault, it's their fault, they should pay. Of course.

>My problem is:
>In Java, we mapped every (relational) database table to a class,
>gave every row in each table a unique id, all fairly
>straight-forward,

...

Yes, I've seen this design so often that I guess lots of people call it straight-forward, unfortunately, I think it is also dead wrong. But then, I don't know what your constraints were.

My starting architecture is always a purely relational back-end with an OO front-end. With that architecture, it is a huge, but common, error to start by wrapping every table in a class. The entire point of a relational database is that you query it with joins, and let the back end do all sort of filtering and logic. Front-end objects should map only loosely to tables, even loosely (non-uniquely) to stored procedures, views. Only when your architecture is more complex, and you need to persist objects that draw data from many sources, do you have something on the back-end, that can be simply wrapped by a class on the front-end. And, putting a unique ID on each row for most data, is a common thing that I know Microsoft teaches and recommends, but it is still dubious, at best. Relational theory is based on putting a primary key on each row, which is composed of one or more actual fields of data, not an added ID.

--

Still, if the employer didn't say this up front, or check your work
while in progress, it's far too late after the fact to tell you that
you're wrong.  I'll bet they don't really have any idea how it should
look, not your way, not my way, no idea at all.  Tell me if that's
right or wrong!?!?

Joshua Stern
JRStern_at_gte.net
Received on Tue Mar 06 2001 - 18:41:12 CET

Original text of this message