Re: Data Constraints Vs Application Constraints

<heretic>
I recognised you toned it down a bit in later posts but as they say first impressions matter ...

Alfredo Novoa wrote:
> On Wed, 09 Mar 2005 08:37:16 -0500, Kenneth Downs
> <knode.wants.this_at_see.sigblock> wrote:
>

>>Do you know why they did it that way?

Hmmm ... smells like dogma!

>> There was definitely a reason and you
>>don't want to ruffle feathers by criticizing it before you know why it was
>>done.  The normal argument is for portability,

Be wary here...incompetents don't actually achieve the desired results (QED) so if this system/solution actually works it might be best to engage brain before selecting mouth!

>>if they code things in the
>>client, their app will run against many databases.  According to you this
>>worked, so I would ask why change it?  Technically it may be "wrong" but
>>technically they somehow got it working and are a big company, so they must
>>be doing something right?

Dogma now apparently flying in the face of a fat balance sheet.

>>The other hidden reason may be that they did/do not know much about
>>databases, and you want to tiptoe-tiptoe around that one.

But highly unlikely it seems.

>>So to sum up, leading with the idea that a working app has been done wrong
>>is probably a bad idea.

I restate my case that IT&T is not yet a profession and the truth rarely is. The next best thing is to consider "if it ain't broke, don't fix it" and IMO its a good guideline to consult the "business" to see if its broken.

> I would not like to work in a company that forces to me to lie and to
> be unprofessional.

Fair call - always a personal decision without a professional bodies documented standards of behaviour to draw on - just remember "believe nothing of what you hear and only half of what you see" before making potentially irrevocable judgements.

Personally, as a bit of a cynic, I am yet to be convinced (but remain open to suggestion) about the benefits of an all encompassing referential and cascading schema etc. I can recognise the apparent desirability of these aims but remain suspicious of the marketing types who glow about this feature or that.

What I have observed in a few cases that very tightly meshed systems become majorly stuffed when the physical side breaks down as computers are want to do. The main issue arises when data fixing is prevented by the rules...of course the more modern DBMS provide improved methods to conduct these out of band activities but for me it's still a hung jury.

Fools rush in and I don't intend to. I note that for all these "advances" there is still not an apparent change in the % of failed IT projects...unless someone can refer me to a well prepared and contrary article on that subject.

</heretic>

Cheers,
Frank. Received on Fri Mar 11 2005 - 12:34:34 CET