Re: looks like some web developers are getting back into 4GL environment...

 

>But according to the guy who wrote it and is its chief advocate, you explicitly aren't supposed to

>design your database properly.

 

>"We took a pretty radical stand: Stored procedures and all things that make your database

>clever are evil," Hansson said. "If you tell a lot of IT shops that, they'll be majorly offended,

>because that's just the way they do things."

I use all the tricks the database has to secure the data quality of the data in it.  Why?  Because only a darn fool would trust another programmer to (a) properly understand the data model, (b) properly design the application transactions and (c) properly implement their intent. 

 

Shucks, on a bad day, I don't even trust me!

 

>I'm a data bigot. That is I tend to believe that the data that your corporation uses is what has meaning

>and value. The application set that your corporation uses is a set of tools that act on that information to

>automate or improve particular business processes that are subject to change over time. Frequently new

>applications merely represent or reanalyze the same data again. For example over the last 5 years or so

>most data has been made available over the web to other humans. It seems likely to me that over the

>next 5 years or so much the same data will be made available over the web to other computer systems.

>The data however will likely be much the same. Amazon will still sell at retail, Boeing will still make

>planes, the banks will still run financial accounts for their customers and so on. Now making those

>business transactions available as web services (or whatever) to other applications will likely require

>new applications it may not require much new database design.

 

Some years ago I worked for an international shipping company.  I picked up a copy of National Geographic and read with interest the account of a Phoenician trading vessel that had been recovered from the bottom of the sea, some 2200+ years after it sank.  As I read the translations from the baked clay tablets that stored the ship's manifest, I realized that my data model in the 1990's was the same one they used for the same task in 200 BCE!

 

Now, they had a different business process.  They stamped wet clay tablets with the cuneiform script to record the ship's manifest and baked the tablets in an oven to dry them.  Then they put the tablets on board the ship and sailed across the sea.  When they arrived, they showed the tablets to the port officials on the other side.

 

My company, however, was using computers.  The process I inherited was as follows.  The manifest was entered into a computer while the ship started sailing across the sea.  The manifest was compressed and sent via EDI to our computer, where it was loaded into our computer software.  We then printed out the manifest and presented it to customs - almost always after the ship had arrived, often many days afterwards.  At least with the baked clay tablets, when the ship arrived, so did the manifest!

 

Pointing out that our existing business process was inferior to the baked clay tablets from 2200 years ago (plus numerous customs fines) helped me to get the resources to fix the darn system on our end.  Unfortunately, we still had to receive the information before ship arrived, and that was not in our control.

:(