Re: ID field as logical address
Date: Sat, 30 May 2009 19:12:42 GMT
"paul c" <toledobythesea_at_oohay.ac> wrote in message
> Walter Mitty wrote:
>> I think the process by which 714 comes to be associated with Joe Friday
>> is actually somewhat mysterious. Googling "Badge 714" confirmed this
>> opinion. BTW, I an NOT using "mysterious" as a code word for "mystical".
>> The one thing I can say is that it's not a consequence of the data. It's
>> either part of the data as given, or it's part of some fairly arbitrary
> There will always be 'mysteries' that machines don't deal with. I'd say
> requirements should always trump any notion of some data being innately
> different from other data. Requirements are arbitrary, to say they aren't
> is to say any system will suit any purpose. For me if it's a requirement
> that a system generate badge numbers, that's pretty much the same thing as
> a requirement that it generate invoice numbers. If it's a requirement
> that a clerk generate the numbers instead, so be it. Whether the numbers
> are calculated or sequential or reversible might be another requirement.
I agree, in general. But I still think it might be worthwhile to distinguish between application requirements and database requirements. I think that associating a new instance of any entity with an abitrary "next" element of some sequence that's suitable for identification, is an application requirement.
There's one aspect of autogeneration that ought to be persistent. Remembering where the sequence generator was in its sequence so that it can resume at some later time where it left off last time, is a legitimate database function.
All of this raises yet another question. Should application development swallow database development? (Whee! Now we can fire all the DBAs!) Or, alternatively, should database development swallow up applications development? (Whee! Now we can fire all the programmers!). Or should they remain collaborators neither of which fully controls the other. Received on Sat May 30 2009 - 21:12:42 CEST