Re: 3vl 2vl and NULL

Frank Hamersley wrote:
> dawn wrote:
> > Frank Hamersley wrote:
> >>dawn wrote:
> >>>Frank Hamersley wrote:
> >>>>dawn wrote:
> >>>>>Frank Hamersley wrote:
> >>>>>>dawn wrote:
> >>>>>>>Frank Hamersley wrote:
> >>>>>>>>dawn wrote:
> >>>>>>>>>Frank Hamersley wrote:
> [....]
> >>>To some extent, perhaps (somewhat similar to XML developers thinking in
> >>>strings), but my reason in this case is that although you might cast to
> >>>another type (even on the way in after testing for compatibility), all
> >>>data input through a UI can be handled as a string, the empty string
> >>>being one such. The string could be seen as the top object for data
> >>>entry, with all other types inheriting from it. A number is string
> >>>input that can be cast to a numeric type, for example. (I realize this
> >>>might be heresy to some)
> >>
> >>OK - my view differs in that the bit is the "top object".
> >
> > All the bits I've seen are single-bit strings ;-) I do make a
> > distinction between binary MIME types and that which can be entered via
> > a standard keyboard (roughly speaking). Query languages, for example,
> > operate quite differently on text than on pictures or songs.
> >
> [..]
> >>>>>>I disagree - there are measurable gains to be had in adopting the RM for
> >>>>>>the storage engine that,
> >>>>>
> >>>>>Can you point me to some emperical data that indicates that? And even
> >>>>>if that were the case, are there corresponding gains to making the RM
> >>>>>the interface between dbms and humans (developers)?
> >>>>
> >>>>I have no empirical data (for or against).
> >>>
> >>>What are these "measurable gains" then? What do they measure? Who has
> >>>done such measuring?
> >>
> >>First, the most obvious gain is a repeatable capability to consistently
> >>disseminate and/or interrogate a large and complex dataset amongst many
> >>people all with varied interests and in so doing avoid the need to
> >>inculcate them with all the various nuances a 2VL programmer might dream
> >>up to persist each item of data.
> >
> > Now that has GOT to be tough to measure.
>
> Perhaps so - the fact that it is feasible at all is reassuring!

How do you know this to be a fact?

>


> >> After factoring in a life cycle and


> >>unavoidable changes in staffing these nuances can become debilitating.

> >

> > I've worked with plenty of systems that are not based on the RM with

> > code > 20 years old and counting.  So, this measurement, too, could be

> > difficult to quantify.  I've looked at possibilities for what might be

> > quantifiable and nothing looks very straight-forward.  I know I don't

> > have emperical data related to bang for the buck or any other metric

> > for non-SQL or non-RDBMS compared to SQL-DBMS's, but I sure have seen a

> > lot of claims about how the RM has been shown to be superior to all

> > other models.  You just claimed that there were measureable gains with

>

This is where there could be some measurement. My hunch is that there are fewer project failures in the MV world than in the SQL-DBMS world. However, then folks will argue that you pay the price down the road in MV (which I do not see to be the case). Measurements would need to measure the total cost of developing and maintaining systems, but also some measure to ensure the systems are effective for the users.

I'll go out on a limb and say that it is unlikely that a development team working with a SQL-DBMS tool would end up writing the same system from the user perspective as a team working with an MV system. The data modelers for the SQL-DBMS tool will work to avoid multivalues so they don't have to form new tables for short lists that don't seem too important, for example. I've seen more FormerNames fields in MV systems, collecting all former names as they become such in cases where it would not be warrented in a SQL-DBMS system -- a single-valued "Maiden Name" attribute (or whatever is deemed politically correct now) is more likely.

> >>The rigour inherent in the RM goes some way to reducing this risk (of
> >>course it is not foolproof).
> >
> > Agreed on both counts.

>

Yes and yes. But the rigour in the SQL-DBMS must come from developers too (even if they go by the title of DBA).

> >>Of course the extant business rules buried in the data itself are an
> >>unavoidable cost of entry to the club - that is a given regardless of
> >>the RM's involvement.
> >>
> >>Secondly, the measured aspect as inferred above is the linear aspect of
> >>continuing to deal with the data, rather than an unquantifiable risk of
> >>non-linear cost/effort in a less rigourous implementation.
> >
> > If all code associated with SQL-DBMS systems were strictly SQL, then
> > perhaps one could argue this. However, it appears to me that SQL-DBMS
> > systems still have stored procedures and other code associated with
> > them for UI's and other processes. So how can you measure this gain
> > and related risks?

>

I have not seen any systems -- complete software packages -- without code in them (whether spec'd and gen'd or hand-coded).

> >>Thirdly I have done the measuring over the last 25 years!
> >
> > Actual measurements you can share or anecdotes like mine? It isn't
> > easy to get beyond anecdotes and we each have different experiences.
> > Can we collect meaningful data with a reproducable experiment?

>

>


> >>There are


> >>other independent sources however - one I find quite humorous (but a sad

> >>comment on IT nonetheless) is visible at http://thedailywtf.com.

> >

> > That's a new one for me--I took a quick peek, will look more later.

> >

> >>In all

> >>my casual viewings of the material on this site, by far and away the

> >>predominant examples are from 2VL exponents or as in todays case 2VL

> >>types trying to railroad an SQL/RM database.

> >>

> >>

> >>>>On anecdotal terms however

> >>>>and relating to some of the commonly held (as far as I believe) precepts

> >>>

> >>>Yes, there are some such that need fixin'

> >>

> >>Which other precepts and what needs fixin' is also eminently debatable!

> >

> > Undoubtedly

> >

> >>>>of good IT such as independence (separation of logical and physical) and

> >>>>simplicity (some will dispute this of course)

> >>>

> >>>I tend to want things simple for me (and those around me) in contrast

> >>>to insisting everything be as simple as possible for the developers of

> >>>my tools or for the tools themselves.

> >>

> >>My view is less self centred - I always look to maximise the long term

> >>corporate benefit even if it is more work for moi at the outset!

> >

> > OK, I'll give you that one.  I happen to be a one man (zero man, to be

> > precise) company right now, but I'm interested in how to improve

> > conditions for software developers in order to maximize the long term

Back in my "darn good programmer" days my manager told me that it looked like a woman month was better than any man month he had seen (rather nice of him). My brain doesn't work the same as it used to, however, so at this point you better up the estimates if I'm coding. That "wo" part might be what keeps the right brain in high gear even when I try to settle it down and lean left. Cheers! --dawn

>
> Cheers, Frank.
Received on Tue Jan 31 2006 - 23:54:06 CET