Re: design question

Mark D Powell wrote:
>
> Dates were another issue as every shop had its own date formatting and
> manipulation routines. We mostly used what was called Julian date
> format, but which was really YYDDD.
>
> Input files were generally all character data likely with over-punches
> for numeric characters but otherwise you still tried to match the data
> to the type.
>

Absolutely true. And sadly, pretty well every shop ended up with non-valid dates in their data; even leaving aside the Y2K problem.

Nowadays we have decent relational databases, which simply reject numbers which aren't, dates which aren't, variable length strings which are longer than expected, child rows without parents, nulls where there shouldn't be, and values not in the allowed list.

And without any coding required, other than some straightforward error handling on the client side.

And can handle row level locking, multi versioning and read consistency without any special code whatsoever.

And that's only Oracle7. We are four more major releases on from there.

Yet some developers want to treat the database as a bit bucket, and forget all the lessons learned over the last 30 years.

Palooka Received on Mon Sep 08 2008 - 15:45:28 CDT