Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

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

Re: 3vl 2vl and NULL

From: Frank Hamersley <terabitemightbe_at_bigpond.com>
Date: Wed, 15 Feb 2006 02:31:19 GMT
Message-ID: <XnwIf.8329$yK1.2375@news-server.bigpond.net.au>


dawn wrote:
> Frank Hamersley wrote:

>>dawn wrote:
>>>Frank Hamersley wrote:
>>>>dawn wrote:
>>>>>Frank Hamersley wrote:
>>>>>>dawn wrote:

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

>
> Absolutely. I've seen big projects, but have not been on a huge
> building construction site. I definitely design for software solutions
> to scale.

That is as it should be.

However I was referring to a project scale where the quantity of deliverables in the allowed time frame requires a project team of 100 or more developers - not simply the scaling of the application itself.

>>Of course if you are building small apps perhaps the MV toolkit
>>will get bread on your table.

>
> A tour around the MV customer space would adjust your thinking on that.

Unlikely although feasible - as I have already cited before the runs are on the board for the RM/SQL in terms of deployments. I accept there is prolly no reason why the MV tools can not deliver equivalent solutions, but IMO only if the wielders are above average in their kung fu.

This is not a reliable feature of large projects where by implication there will be average (and lower) performers. This bitter reality must be mitigated by every means available and the MV space does not naturally enforce a significant rigour aspect. I don't believe the MV "flexibility" confers anything other than disadvantage - it is akin to shutting the stable door after the horse has bolted.

>>However if you are building enterprise or
>>bigger apps don't simply assume those tools will scale up accordingly.

>
> Now you are preaching my sermons. I definitely care about scalability.

Who doesn't? However you seem to be more significantly more concerned with flexibility. This is strongly evidenced in your writings and has IMO resulted in an incorrect balance derived from inflating the apparent (as you see them) detractions of RM whilst discounting any possible slurs on the MV sphere (which you know and lurve).

[..]

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

>
> Every solution has it problems. You must do risk assessment
> throughout, no matter what tools and techniques you choose. You might
> be mitigating different things, but you are not eliminating risk.

That is not axiomatic at all - it is possible to eliminate risk by deliberate choices. I disagree that you are simply "shuffling deckchairs" although there may still be some on the deck regardless.

>>>"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!

>
> I took that from the "girl tricks book" that says that you are always
> better off quoting a man than using your own words if you want
> agreement from a man ;-)

You then have to ask yourself why that IS axiomatic! :-)

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

>
> I think that many people who employ the RM think they are optimizing
> the cost of ownership over time where I don't think that is the case
> (but I don't know how to prove or disprove it inexpensively).

Perhaps because you would use a MV style of thinking in the analysis. Given its propensity to allow the mind to wander where ever it likes perhaps the analysis would never be convinced it is at a conclusion?

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

>
> Yes. I've heard of IT projects that go way over budget :-)

I was thinking of the case where this is clear at the outset of discussions - i.e. a la la Bob who is sucked in to thinking

"how hard can it be - why I have already knocked up a prototype and I'm not even in IT"

by the instant gratification zone MV and other vendors live in.

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

>
> Yes. Developers will make their own little "business judgments" on
> whether they should cut corners or not. The issue at hand here is that
> of external dependencies. If it costs more to do it right, developers
> will often make the call to assume that additional cost. But if there
> is a need for speed, it is not as likely a developer will take a
> project that they can do themselves and add in an external dependency
> to the project. It adds to much risk to the schedule. So part of the
> problem is the programmer/dba separation.
>
> Gotta run. Cheers! --dawn

Yes - I note you are spread rather thin at the mo - lucky you can TT!

Cheers, Frank. Received on Tue Feb 14 2006 - 20:31:19 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US