Re: The MySQL/PHP pair

"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:
> a) the programming environment (e.g. multivalue (MV) systems'
> integrated environment)
10%

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

> c) empowerment (giving developers control over the database, rather
> than a DBA approving and authorizing)
30%

> d) constraints vs. the lack of them
10%

> e) hierarchies vs. relations
I'll rewrite that as "di-graphs vs relations" and give it 20%

> 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

> g) something about the data model itself (or lack thereof)
yes, but included in the above

> 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. 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 Tue Nov 02 2004 - 23:58:45 CET