>>
>>Finally, there are trade-offs to be considered. Normalized databases are extremely efficient in terms of the storage space required to hold the information. It is likely that a pure object oriented database will not be as efficient as a normalized database. However, we have already made those trade-offs in our OO code today. No one can argue that the change from structured programming to OOP brought with it less efficient code in terms of instructions and storage space. Those trade-offs are made because OOP is enormously more flexible than structured programming. Are we willing to make similar trade-offs in our databases?
>>
>>- Keith Payne
>
>
>If you look at the history of 'databases', the access methods / knowledge required have, over time, like computing languages in general, distanced themselves from the underlying implementation.
>
>For early data access, you would have to know the file-name, the physical location, the data offset, the data-length, parse it, check physical pointers for linking records. Then, with the next step 'away', you use logical pointers to records, then SQL, with no references to physical location or pointers. At each stage, lower levels of access have been abstracted away or, more correctly, handed over to, and automated by, a lower level system: if you query an Oracle view, for instance, you might have no idea in which country the physical data is stored, let alone the physical data-pointers, and so on.
>
>At the moment, we appear to be 'stuck' at the SQL / Table / Row / Column level which should ideally be regulated to the back-end data-engine, and not be of concern to the programmer - just as you have described. The current OO database implementations appear to be a somewhat messy compromise between the two. I would like to see the situation you have described above, where normalisation and table structure/linkage is generated automatically by the OO system, with no input from the designers whatsoever: I'm not really interested in the machine-code generated by a program, why should I care about the table-structure?. I would love to be freed from the necessity to derive the tables and field definitions from the classes in an analysis and allow the system to do that itself, even moving the data around in tables transparently to me, changing field-types for the most beneficial storage and so on.

Robert;

Codd obviously was not a marketing agent for any database product. His 12 rules prove that as no present day database fits his model of a relational database. Add rule 0 and you have 13 rules from Codd.

If Codd worked for a database manufacturer he would have left out a few rules to fit the product. :)

Imagine all the college courses that would not be required if data was object oriented. The academic world would never be the same. A large number of database experts would not be needed. Perhaps they could join the homeless .COM’ers here in Silicon Valley. Technology moves on and we have to move with it.

About two years ago I read a paper from Codd and he had defined somewhere between 60 and 80 rules for the relational database model. The academic world will probably gear up to the new rules to keep the professors employed.

Five years ago I went to the graduation of a friend who was obtaining his degree in Software Quality Assurance. The invited speaker was the president of AutoDesk (AutoCad, etc.) and a Ph.D. who said something interesting. His words, “I have had seventeen jobs in my working career. Nine of those jobs no longer exist. My advice is to always continuing your education. Technology moves too quickly and we must remain aware of this”!

Well sports fans everywhere, do not get too comfortable. Just when the horse and carriage got to be a way of life along comes this four wheeled monster to replace it and start many new industries. You still see an occasional horse and carriage – but not on the freeway!

Tom