|
that discourse, and this, alas, attempt to explain why the quote should be "are" not "want to be". and what the bedrock problem is. the book tip-toes around the problem, but doesn't quite explain why the emporer is naked.
so: in addition to the book, read a solid RDBMS theory book, Date comes to mind; and a solid applied RDBMS book, Elmasri/Navathe does come to mind. remember, when you're doing something that hasn't been done before, experience is a poor guide. you'll need theory to tell you what to do.
as i said: the problem with Enterprise java development is that it has been a regression in data thinking. there is *no* Object Model in the way that there is a Relational Model. the latter *guarantees* data integrity/concurrency independent of any code. the so-called Object Model does little more than what COBOL/VSAM did in 1975: define and manage data *only* by specific application code.
the corporate java systems i've seen (more than 1, less 1,000) are just re-writes of COBOL procs with java syntax. this is not progress.
Bob
|
