Re: The MySQL/PHP pair

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

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

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

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

> > 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%, 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?
>
> > 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.

> 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 - 15:59:06 CET