Re: Unknown SQL
Date: Sat, 21 Jul 2001 23:26:51 GMT
Message-ID: <u7wv6zvsxf.fsf_at_sol6.ebi.ac.uk>
On Wed, 30 May 2001 13:56:39 +0200,
"Carl" == Carl Rosenberger <carl_at_db4o.com> wrote:
Carl> It seemed that views where evaluated and retrieved completely before Carl> constraining them by other parts of the query.
which I still find hard to believe; I would consider a database that implements queries on views this way, broken (that is, in the general case; in certain queries it may of course be decided that this is optimal).
Carl> I am not informed about the current state of development. I do know Carl> that MSSQL introduced indexed views some time ago. From reading Carl> newsgroups I get the idea that views still are very slow.
I still disagree with this vehemently, at least for Oracle because that's the only database I have access too. In all cases, views performed as well as fully expanded queries on base tables.
Carl> To circumvent the object-relational mismatch, relational databases will Carl> *have to* introduce the concept of table inheritance. Informix and some Carl> others are already working in this direction. Different approaches that Carl> call themselves "object-relational" are just using marketing Carl> hype. Serialising objects to table columns has nothing to do with Carl> object-relational: - you don't store objects but blobs - objects are Carl> not related Carl> Why are you talking about pointers?Carl> We use Java.
Carl> There are no pointers.
Surely you realize that 'references' ('generalized pointers'), not 'hardware memory addresses' was meant here.
Carl> If relational databases will not learn to disassemble objects and to put Carl> them back together again (= storing references) they will have no future.
Mmmm ... given the current situation, that's a fairly extraordinary claim, which consequently will require fairly extraordinary proof :-)
Carl> No. Declarative queries currently are the strength of relational Carl> databases in comparison to object databases.
Coming from an OO perspective, yes. But as I and others have said before, OO schemas have a habit of being very rigid, i.e. not flexible enough to easily adapt to new situations and requirements.
>> Contemplate the following quotation:
>>
>> "In a relational database, all information is presented to the user
>> explicitly as values in relations."
>>
>> I think it defines the essence of the relational model. It doesn't tell
Carl> the
>> whole story, but it sets the stage for all that follows.
[ agreed ]
Carl> This is where the mismatch comes from. Carl> We are programming with objects not with values.
But the essence of large of amounts of data _is_ those values; they are just a bit more 'raw' than fully composed objects. They have proven to be flexible and adaptable to unforeseen future needs. E.g., they allow more general 'browsing' (such 'mining' is an example of an 'unforeseen way of accessing' to the data)
Carl> Normalization is unnecessary and ugly if you can store objects.
Surely you don't mean to imply that OODBMSs need not be normalized? That would be pretty disastrous (think 'update anomalies'). Date or Celko has said: normalization is Analysis, not Design, and I think there is truth in that.
You may, however, you refer to the need for splicing an object's multi-valued attributes into a different table in order to comply with 1st normal form. If the argument is that relational databases don't distinguish between the storage of entities, weak entities and/or multi-valued attributes: agreed, this is not visible in the table structure (but it would be in the cascading deletes, or, for that matter, an object relational layer). The big argument in favour of it is that this makes the query model uniform, and it makes things more easily extendible in case a weak entity or attribute is promoted to a proper entity. No schema changes! These things are actually a concern with large scale data management. E.g., sometimes a one-to-many relationship is implemented using a link table (ie., as if it were a many-to-many relationship), just to anticipate the relationship changing from a one-to-many into a many-to-many relationship. I don't see how you could achieve this kind of generality and flexibility with OODBMSs.
Carl> Object databases are the best choice to store objects.
If your data model is likely to be very stable, this may be true. Cheers,
Philip
-- If you have a procedure with 10 parameters, you probably missed some. (Kraulis) ----------------------------------------------------------------------------- Philip Lijnzaad, lijnzaad_at_ebi.ac.uk \ European Bioinformatics Institute,rm A2-08 +44 (0)1223 49 4639 / Wellcome Trust Genome Campus, Hinxton +44 (0)1223 49 4468 (fax) \ Cambridgeshire CB10 1SD, GREAT BRITAIN PGP fingerprint: E1 03 BF 80 94 61 B6 FC 50 3D 1F 64 40 75 FB 53Received on Sun Jul 22 2001 - 01:26:51 CEST