Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Usenet -> comp.databases.theory -> Re: 3vl 2vl and NULL

Re: 3vl 2vl and NULL

From: Frank Hamersley <>
Date: Tue, 14 Feb 2006 07:10:22 GMT
Message-ID: <ynfIf.7756$>

dawn wrote:

> Frank Hamersley wrote:

>>dawn wrote:
>>>Frank Hamersley wrote:
>>>>dawn wrote:
>>>>Personally I don't feel that characterising your approach as
>>>>chaotic under the moniker of agile is unrealistic at all. Feel
>>>>free to prove me wrong but your penchant for "bang for the buck" as
>>>> a prime consideration combined with a dislike of the rigidity of
>>>>the RM is anarchy as I see it.
>>>I just got an e-mail from an IBM U2 customer who said that one of the
>>> senior Pick architects "once said Pick was a 'liberal humanistic'
>>>database as opposed to a 'technocratic fascist' database"
>>Heh, heh - or alternatively perhaps "namby pamby apologists" vs "jack
>>booted brown shirts" - I feel a Godwin event coming' on!
> I reviewed the wording to ensure I didn't hit the mark for that ;-)

>>Of course what is really funny is the wit you quoted freely ascribing
>>fascist behaviours to the RM when in fact the number of "rules" is quite
>>limited as evidenced by the number of times MV proponents will bemoan
>>the myriad ways to create a mess in the RM (see final para though).
>>Methinks it is more about the carbons than the stones!
> You might have lost me on that last statement--you say carbon and
> stones and I think diamonds.  What should I be thinking instead?

Carbons = (aka squishies) the life form pounding the keyboard. Stones = the silicon with impurities responding to the pounding.


>>I would be prepared to bet you have never been on a multi story building
>>site then. The mind boggles at the concept of all mucking in - laying
>>carpet on wet concrete while the desks are being installed and the
>>form work removed while the sparkies are turning on the juice.

> You are right.  I can only use construction analogies related to what
> I've seen on house construction sites.

Hey there grasshopper - you should consider scale as a critical success factor. Of course if you are building small apps perhaps the MV toolkit will get bread on your table. However if you are building enterprise or bigger apps don't simply assume those tools will scale up accordingly.


>>You missed the point - its steel and concrete stressed together that
>>delivers the strength.

> I think I got the point.  So, we need to be sure that what we want to
> vary is not a load-bearing wall, for example.  Maybe I should switch
> out of analogy mode on this one.  I'm not likely to hammer in a nail
> myself.


>>And yes concrete is obstructing if it is in your way - but you can't
>>just put ducts any old where - because you want the building to stay
>>standing. And I'm not talking of the fair weather thinking that MS has
>>(and I suspect MV proponents would) foist on us. You want it to stand
>>through earthquakes and other serious events like fires etc.

> Understood.  But if you upgrade to version n.m then it will be able to
> handle them ;-)

Yikes - Bills get richer quicker secret is out! :-)

>>If you think you can invent the magic substance that delivers your "put
>>back together" result you will make a $bazillion but not on this NG.
> I'm afraid I don't have magic, just finesse.

I have no magic either - but I subscribe to the "don't go there" approach so I can deploy my skills on certain tricks rather than maybes.

>>>With SQL-DBMS's, it does seem a bit like working with a substance
>>>that better be fixed before you start rather than something you can
>>>work with and not end up harming the system (as in your story) if you
>>> make a poor decision up front. With MV, you can shoot yourself in
>>>the foot, remove the bullet and the wound heals (to mix metaphors).
>>If you were only risking your foot you might consider it acceptable
>>risk. The trouble is the average dunce will also point a weapon at some
>>bystander or at their own head and pull the trigger - because it isn't
>>loaded. Believe me as I have witnessed first hand the best soldier in
>>the platoon perform a stupid act like this. Fortunately no one was
>>killed or maimed, except me who got my butt seriously kicked for letting
>>it happen!

> Wow -- no such excitement in my life (knock on wood).

A while back - but instructive nonetheless! However I see so called IT practitioners committing the same style of faux pas repeatedly.


>>>>Not in the IT sphere - our disagreement is primarily your
>>>>sanctioning of an approach that lets the developer construct any
>>>>old domain depending on how they feel today
>>>Unlike some agile methodology folks, I do like to see a pretty clear
>>> statement of requirements up front, even if including a good process
>>> for change from the very start and only requiring low-level design
>>>for the current phase before starting it.
>>That sounds reasonable to me except the design effort. I prefer to see
>>success embedded in foundations rather than a glitzy front door.

> "Form follows function - that has been misunderstood. Form and
> function should be one, joined in a spiritual union."  Frank Lloyd
> Wright

I agree with him! Getting the union is the trick. Where I see the RM playing a part is in assisting in retention of the union even as evolution occurs.

>>>>whereas my insistence that at least a bit of rigour helps ensure
>>>>(but doesn't guarantee sadly) the outcome is viable.
>>>I agree with rigour in the process. I don't want the tools to
>>>constrain developers unnecessarily.
>>Its the "unnecessarily" that is our moot point. In my book a good
>>developer will get the job done regardless of those constraints.

> Sure.  I look at it both from the standpoint of a developer and as
> "Bob, the owner" with the budget.  Obviously people are getting the job
> done with current tools.

Beware of a Bob with eyes bigger than his stomach!

>>And if
>>they are really good and were given your tools of choice I would expect
>>them to still build an outcome much like the SQL tools would deliver.
>>Where the difference come is when the average punter [under skilled,
>>under experienced, under neuroned, take your pick :-) ] joins in. In my
>>view the building stands a much better chance of being built to spec
>>using my hallmarked approach!

> Maybe.  It is a different philosophy, however, where at every move
> during the development, not relying on inspections, developers are
> constrained in an effort to protect the solution against those
> potential evil doers.  Those who set up this protection system are not
> immune to poor construction, however, and can even inadvertantly cause
> the final solution to be worse.  For example, when developers feel they
> have to go to extremes to get a job done because they don't have the
> time/backing or whatever to remove the obstacles.

Often this last case is because of expediences heaped on expediences - just look at the Windows security outcomes for a manifestation!


>>>Ah ha -- good. I agree that in practice the db model influences the
>>> UI. I happen to think the design of most UIs is really, really
>>>important for such things as quality data. The number one cause of
>>>inaccurate data for analysis (for example) is not lack of referential
>>> integrity (again, example).
>>What is the number one cause then?

> There are a lot, but data getting entered wrong (only what is needed
> for a transaction and not for analysis is accurate, for example) or not
> updated when it changes are two.

Overlooked requirements and inadequate integrity rules - prolly expediencies yet again.


>>>>>There are so few established rules in our industry.
>>>>Too true!
>>>>>I suspect you and I could disagree on a number of such "rules."
>>>>>Cheers! --dawn
>>>>Given that there are so few and we disagree at least on some that
>>>>sort of insists we are almost diametrically opposed - does it not?
>>>and on opposite ends of the earth too. I suspect we have some
>>>agreement however, for example, both thinking that good data models
>>>are important? Cheers! --dawn
>>Yes - as I mentioned above you can still make a hash of an SQL database.
>>I suspect thats why the purists insist that SQL isn't RM because if it
>>were the stuff-ups would be impossible. Nirvana I presume.
> I knew there had to be a silver bullet somewhere. Cheers! --dawn

But it shouldn't stop us from trying to ever improve.

Cheers, Frank. Received on Tue Feb 14 2006 - 01:10:22 CST

Original text of this message