Re: The MySQL/PHP pair

"Laconic2" <laconic2_at_comcast.net> wrote in message news:me6dnRN17rbdCBbcRVn-hA_at_comcast.com...
>
> "Dawn M. Wolthuis" <dwolt_at_tincat-group.comREMOVE> wrote in message
> news:cm93fd$g11$1_at_news.netins.net...
> > "erk" <eric.kaun_at_pnc.com> wrote in message
> > news:1099431388.630616.174500_at_f14g2000cwb.googlegroups.com...
> > > > It almost looks like the more we remove from an RDBMS, the more
> > > productive
> > > > our development environment becomes.
> > >
> > > I realize it's been addressed before in fits and starts, but this
might
> > > be worth a deeper go-round. I've never understood the RDBMS as a
> > > barrier, and am wondering which of the following, and in what
> > > proportions, this idea is influenced by:
>
> I really liked erk's precis of the issues surrounding database management,
> data architecture, and data modeling.
>
> I also appreciate your attempt to quantify your responses. There were
some
> real surprises for me.

> > > a) the programming environment (e.g. multivalue (MV) systems'
> > > integrated environment)
> > 10%
>
> Integration between SQL (as a data sublanguage) and the programming
> language is very different, depending on which programming language and
> which dialect you deal with.
>
> For instance, there is "dynamic SQL" where the SQL is just a character
> string until it's parsed and aceted on by the server at run time.
Sometimes
> the dynamic nature is inherent in the requirements. Sometimes it's just
> lazy design. It's very dynamic, but almost completely unintegrated.
>
> Then there's "precompiled SQL" where the SQL is parsed and validated
> (including data dictionary lookups) at precompile time. The precompiler
> expresses the SQL in some form that captures the intent, but not
necessarily
> the expression.
>
> A variant of the above is the "SQL module language". In this variant,
there
> is an "SQL compiler" that creates what looks like
> callable procedures from the point of view of the host language, but is
> actually queries referred to the server. It's predigested like the above,
> but it has the advantage (?) that the callers of the procedures don't have
> to learn any SQL.
>
> Further integration is acheivable, but I haven't become familiar with
tools
> that do it.
>
> Dawn, I was surprised at how low a percentage you gave this. Maybe there's
> more discussion in here.

There were too many 80%'s for me to assign and I sort-a wanted it to add up to 100.

> >
> > > b) expressiveness (the "language-based" aspect of MV - Dawn focuses
> > > here, but I'm still fuzzy on what, as the locus of expression, is most
> > > important)
> > 30%
>
> I agree that this is quite important. This is one of the principal
> difficulties with SQL. It's supposed to be a query language, but it isn't
> easy for the people who haven't been educated in it. It's supposed to be
a
> data exchange sublanguage, but it isn't formal enough for that purpose.
> And it's supposed to be the only programming language you'll ever need,
for
> a certain subset of data processing functions (routine updates).
>
> It makes me think of a boat that's supposed to be able to be used as a
> sailboat, or a speedboat, or a tugboat, depending on the circumstances.
> It might be better to have three different boats.
>
> >
> > > c) empowerment (giving developers control over the database, rather
> > > than a DBA approving and authorizing)
> > 30%
> >
>
> This is the heart of the matter, IMO. We really need to discuss this in
> depth. How do the developers (plural) exercise control over the data
> architecture, without damaging each other? What contract do the
developers
> have with future users of the data with regard to forward compatibility?
> How do people who invest in the data protect their investment.
>
> I don't think the answers here are simple or easy at all.

Very much agreed.

>
> > > d) constraints vs. the lack of them
> > 10%
> >
>
> I think you underestimate both the costs of declaring constraints, and
the
> cost of not declaring constraints.
>
> I'm going to start a new thread about constraints. I want to explore it
> from a different point of view.

I've beat on constraints many times before and I like your different perspective in the new thread. I definitely appreciate this issue and the costs of declaring and not declaring constraints. I could give this one an 80% too ;-)

>
> > > e) hierarchies vs. relations
> > I'll rewrite that as "di-graphs vs relations" and give it
> > 20%
> >
> This is the major justification originally given for proposing the
> relational model, in contrast to what existed in 1970.
>
> Given the low percentage that you give it, it seems to me that your beef
is
> with DBA's or more properly Data Architects,
> and not so much with the relational model as such.

20 is not a low percentage when given such a list -- I'll up it to 95%, OK?

> > > f) sheer cost of commercial RDBMSs making the cost:benefit ratio bloat
> > 0% (90% in other contexts, but my gripes with the relational model are
> that
> > and not about cost
>
> I'm amazed that you give this 0%,

I had to make it out-of-scope else it would have had to have been another 90% or so.

> given the amount of posting you did a few
> months back on the question of "total cost of ownership". Is "cost" in
the
> above limited to actual licensing costs, and not "total cost"? Have you
> changed you mind?
> Or what?

Total cost of ownership and big bang for the buck are all wrapped up in software developer productivity, ease of maintenance and such. Yes, this is really, really important to me, but I added up the previous percentages and had already reached 100. Heigh ho.

> > > g) something about the data model itself (or lack thereof)
> > yes, but included in the above
>
> I think it's worth separating out.
> >
> > > h) (ominous music) Other
> > whatever is left ;-)
> >
> > >
> > > Sorry to bring this up again - feel free to shout me down (is that a
> > > thumbs-up or a thumbs-down, then?).
> >
> > It makes sense to bring it up since I have yet to PROVE all of my
> concerns.
>
> Attention, Dan:
> Dawn says that she has yet to PROVE all her concerns. That is why I give
> her the benefit of the doubt. I do not share all of Dawn's concerns.
> Perhaps she will learn something from us in the course of dialogue.
Perhaps
> we will learn something from her. Perhaps c.d.t. is just the sounds of
> silence. Whatever will be, will be.

smiles. --dawn

>
> > I have proven, I think, that 1NF as currently implemented by most
software
> > developers (the old version of 1NF) has no mathematical basis. Since
> others
> > have already ditched it, or redefined it to the point where every
relation
> > is necessarily in 1NF, that is just a start. We also have some
agreement
> > (at least I know you agree with me on this one) that we need a means of
> > encoding constraints once for the front-end and back-end "services" to
use
> > the same constraint specifications, or even the same constraint
"engine".
> >
> > I do think you have a point in the list above that there can be a
problem
> in
> > the process whenever the developer is not permitted to do some aspects
of
> a
> > software development job. With all of the aspects of software
development
> > today, it is likely that the developer will need to rely on graphic
> > designers, writers, QA professionals and others to write software, but
> when
> > the developer has no choice but to convince another person to make a
> change
> > to the database and wait for the change, that is a way not only to slow
> > things down, but sometimes get a lesser product. It is potentially a
way
> to
> > water down the vision of the overall designer of an application if they
> need
> > to yield to the overall designer of a database, for example.
> >
> > Just musing. Cheers! --dawn
> >
> > > - erk
Received on Fri Nov 05 2004 - 21:08:40 CET