Re: foundations of relational theory? - some references for the truly starving

"Ross Ferris" <ross_at_stamina.com.au> wrote in message news:26f6cd63.0311082329.6de24f4b_at_posting.google.com...
> Forgive my lack of formal training, but if you can explain what "PK
> Persistence" is, then I may be able to help. I have no doubt that this

Primary Key Persistence - the concept that the unique identifier for a row remains the same. So conceptually the primary key to an MVed field is RowKey*MVNumber which if you insert a new MV changes. Whilst I'd agree that PK Persistence is an admirable goal the majority of times I'd use MVs I'd be using them to store data I didn't need to treat atomically so I wouldn't need to worry about this. I've said it before and I'll say it again - being forced to store data atomically when you have no requirement to use it so is a limitation of relational architecture. Any attempt to justify it as a desirable side effect is simply post event rationalisation. Funnily enough if all you have is a hammer even screws look like nails.

Simple example - we've had a system in use at a large book vendor for a decade or so where an order for many items can be subdivided between accounts. This is stored in a single row and in all the time the system has been in use it has never restricted the use of the system nor imposed any undesirable side effects. Of course the fact that I can assemble this data for display on screen with a single disk read instead of an index lookup followed by multiple external joins seems (to me at least) to be a desirable side effect.

"Ross Ferris" <ross_at_stamina.com.au> wrote in message news:26f6cd63.0311082329.6de24f4b_at_posting.google.com...
> Forgive my lack of formal training, but if you can explain what "PK
> Persistence" is, then I may be able to help. I have no doubt that this
Received on Sun Nov 09 2003 - 11:38:22 CET