Connectivity to a Cloud Provider

[Albert D. Kallal]

This is why so many websites have such horridly denormalized
database structures, because the people designing them don't have
the first clue about how to work with normalized structures.

I often thought that most developers "just know" about database design. It
is REALLY amazing to work with some very experienced developers (often with
year of c#, c++) and one just assumes they know about database design (they
don't). We often take this issue granted.

And, yes, when it comes to web sites, I am REALLY amazed how often I have
client show me something that "kind of" close to what they are looking for,
and I can instantly see HORRIBLE un-normalized designs.

And that's how MySQL got popular. It was free, all the web tutorials
on building database-driven websites used it in their examples, and
so its use increased.

How true. On the other hand, dbaseII, dbaseIII clipper, Foxpro etc. really
explored onto the personal computer scene in the late 80's and early 90's.
Many (most) of these systems did not have things like RI, but were still
VERY usefull products. Over time, the products that survived did get RI
features.

That said, as much as I criticize MySQL, I use it on all the
database-driven websites I'm associated with -- I wouldn't even
consider Windows-based hosting because IIS is still simply not ready
for prime time.

I actually stuck to using sql server on web sites since I hooked on using
stored procedures and the ability to have custom functions that can be used
in the sql statements (kind of like using VBA functions in sql in
ms-access). So, this symmetry makes migration of older access designs I have
a good deal easier for me when using Sql server. It been more then 5 years
now since I played with MySql, and I not kept up as to how stored procedures
and functions are built in MySql (when I was using MySql, it did not have
stored procedures).

As mentioned..I am also jumping head strong into SharePoint, and there are
many good reasons for this. A few of which the NDA lifts for me to speak
about in public quite soon...

 

[David W. Fenton]

I often thought that most developers "just know" about database
design. It is REALLY amazing to work with some very experienced
developers (often with year of c#, c++) and one just assumes they
know about database design (they don't). We often take this issue
granted.

One of the great annoyances of being an Access programmer is that we
know more about database design and programming than these code
jockeys, but they look down there noses at us and assume our
knowledge about or area of specialization is inferior because we're
using a to-them "inferior" programming environment.

[]

How true. On the other hand, dbaseII, dbaseIII clipper, Foxpro
etc. really explored onto the personal computer scene in the late
80's and early 90's. Many (most) of these systems did not have
things like RI, but were still VERY usefull products. Over time,
the products that survived did get RI features.

That wasn't really about RI, though, but about the fact that the
development tools for all the xBase variants failed to make the
transition to Windows. On the other hand, Paradox was the first to
make the transition (it was Access before Access existed), but it
lost it's developer community because they replaced their DOS
progamming language (PAL) with a different language with a similar
name (Object PAL). They had to make the transition to event-driven
programming, but they did it by replacing the old language, not by
extending it.

I was a Paradox DOS programmer from 1989 to 1996, and I decided that
I didn't want to make the leap to PdoxWin immediately, simply
because it took awhile for people to adapt to Windows. I first saw
PdoxWin c. 1991 or 92 and decided to sit and wait. By 1996, it was
obvious that since I was going to need to learn an entirely new
programming paradigm (event-driven), why not go with the database
that by then was shipping on every computer with MS Office installed
on it? So, I chose Access (it didn't hurt that the price was easy to
take), and the rest is history.

I was thrilled to have engine-level RI (the versions of PdoxDOS that
I'd used lacked it; I don't know when/if Pdox's engine got
engine-level RI), and eventually figured out event-driven
programming (though I must say the macro-oriented help files in the
Access 2 era were something of an impediment to good application
design).

I actually stuck to using sql server on web sites since I hooked
on using stored procedures and the ability to have custom
functions that can be used in the sql statements (kind of like
using VBA functions in sql in ms-access).

MySQL still doesn't have sprocs, but good website programming
practice would use a database abstraction layer for any database
interaction, and most of those (PearDB, ADODB) provide things like
prepared statements and other aspects of high-level server database
functionality that MySQL itself lacks.

So, this symmetry makes migration of older access designs I have
a good deal easier for me when using Sql server.

Well, none of my MySQL work is with Access -- it's all web-based.

It been more then 5 years
now since I played with MySql, and I not kept up as to how stored
procedures and functions are built in MySql (when I was using
MySql, it did not have stored procedures).

Still doesn't, but the db abstraction layers make that not as much
of a problem as it once was.

As mentioned..I am also jumping head strong into SharePoint, and
there are many good reasons for this. A few of which the NDA lifts
for me to speak about in public quite soon...

Isn't the de facto version 3 due now? I don't the actual version
numbers, but the current version is the second major version I've
been aware of, and the first one that looked useful. The next one
could be the one where MS makes the magic happen.

That said, I worry that MS is designing too much coordination with
SharePoint into their Office apps, thus forcing Office users to
provision a SharePoint server in order to get full value out of
Office apps. I've always felt MS was very unfair to standalone
Outlook users in the way that they were second-class citizens in
comparison to Exchange users. I worry that the more effort MS puts
into SharePoint the more likelihood that there will be this kind of
pressure, and after that, full lockin.

But I'm not paranoid...