Re: Data Constraints Vs Application Constraints

On Fri, 11 Mar 2005 11:34:34 GMT, FrankHamersley <FrankHamersleyZat_at_hotmail.com> wrote:

><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?
>>
>> The most probable reason is: incompetence.
>
>Hmmm ... smells like dogma!

     Not unless he automatically assumes that it is incompetence. A statement of non-certain probability still allows for exceptions.

>>> 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,
>>
>> No. The normal reason is incompentence. Portability is a poor excuse.
>
>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!

     Besides what Mr. Novoa mentioned in his reply, there are other possibilities.

     One possibility is that the desired results are achieved but with much more effort than would be needed were things done better.

     Another possibility is that the users of the system are not aware that it could be better.

     In both of these cases, it can be difficult for someone stuck in the mess to see that it could be better if that person has had no exposure to better.

>>>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?
>>
>> No, that does not mean that they are doing things right.
>
>Dogma now apparently flying in the face of a fat balance sheet.

     No, it may be working with much more effort than needed, or there may be hidden flaws that bite later.

>>>The other hidden reason may be that they did/do not know much about
>>>databases, and you want to tiptoe-tiptoe around that one.
>>
>> That's incompetence :)
>
>But highly unlikely it seems.

     Oh? Why unlikely?

>>>So to sum up, leading with the idea that a working app has been done wrong
>>>is probably a bad idea.
>>
>> It depends on many things. Specially on how smart and educated the
>> managers are.
>>
>> But the honest and professional behavior is to say the truth.
>
>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.

     Yes, but if you were developing a new, different system, would you do it the same way as the old system? If not, then there is something wrong with the first approach.

     I have seen students trying to program by guess. It does not work? Change this statement or that one. Why that statement? It is something to do. Eventually, they may get something that "works". Mr. Novoa is talking about the commercial version of this.

>> 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.

     Yes.

>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.

     Yes.

>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.

      OK.

>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.

     I do not see one either. If anything, the situation may get worse since systems are getting more complex.

></heretic>

     I think you and Mr. Novoa disagree less than you may think you do. Your differences seem to be surfacial.

Sincerely,

Gene Wirchenko Received on Fri Mar 11 2005 - 18:26:08 CET