A couple of articles of interest from Datamation
IT Management Update, May 29, 2001: -
Outsourcing: The Reluctant Bridegroom, By Eva Marer
One third of IT outsourcing contracts signed during a brief 1990s honeymoon
failed, leading CIOs to bring the functions back in-house. But, having
reached a new maturity, outsourcing may be ready for a second chance.
http://itmanagement.earthweb.com/netsys/article/0,,11961_775001,00.html
ASP Will be Dead in a Year, By Peter Slavid
A year from now we won't be talking about application service providers. In
fact, the phrase "ASP" will be as deadly as "dot.com,"
suggests our guest columnist.
http://itmanagement.earthweb.com/entapp/article/0,,11980_772101,00.html
Naming Database Objects.
Most database schemas (or is that schemata?)
are a mess! For example, looking at a leading General Ledger system
we've found a complex database made even less comprehensible because
there's no consistency in table or column names. This makes the
development of queries and maintaining the system much more difficult than
it needs to be.
In contrast, a development project that I've
been involved with for about eighteen months has grown to provide rich
functionality, and the database has three or four times as many tables as
in the initial design, yet when we recently made major changes
(including renaming several of the key tables) these changes occurred
smoothly, with little drama and few errors.
Much of the credit for this goes to the naming
convention followed (originally over my objections - I thought I had a
better idea) by the lead developer, Ian Marshal (imarshall@frl.co.nz).
With Ian's rules:-
1. Every field is prefixed
by an uppercase three-letter code, which identifies the table
containing that field. For example, fields within the JOB table are named
JOBName, JOBid, etc. Fields within the Job-Item table care
named JBIName, JBIQuantity, etc.
2. These three-character
codes are unique to each table, and different to the values used for
working data.
3. ID fields (for almost all
of the tables we use an autonum field as key) are named xxxid. We'd
use xxxNbr for a numeric key with user meaning, and xxxKey for an
alphabetic key - but we have tended to avoid these.
4. Foreign keys are named
like JBIJOBid, ie this is a JOBid carried in the Job Item (JBI) table.
5. Other fields are named
with the prefix followed by the field name in mixed case: for example
JOBName, JOBAddress. There is no particular rule about the
names, apart from striving to be obvious.
This simple convention has made development, maintenance,
and administration easier. Code is more concise -
you never have to prefix the field names with the table name or
use [..] punctuation, fields are easy to find with the
editor, and so on.
On reflection, this convention is so simple
and effective, I don't know why anybody would do anything else.