OODMS VS RDMS
Vic Cinc
>In article <vicc.74...@extro.ucc.su.OZ.AU>, vi...@extro.ucc.su.OZ.AU (Vic Cinc) writes:
>>
>[stuff deleted]
>> firstly, SQL is the number 1 access method for relational databases and
>> is *virtually* synonymous with "relational model". SQL is
>> rich in keywords and low in functionality. No one could reasonably argue that
>> SQL can outperform anything short of a dog shot in the hind legs.
>> Secondly as to the benefits of the maths model behind the relational paradigm,
>> year of practical first hand use at various organisations, leads me to doubt
>> its long term ability to model real world systems and objects.
>Sure, the real world is complex and difficult to model. However, there is
>nothing that says one has to capture all of that complexity in the structure
>of the database (though capturing as much of it as possible is clearly
>sensible). Inevitably some of the "knowledge" of the real world complexity
>will reside in the application as well. The argument seems to be about
>where this division occurs. OO systems are certainly more ambitious in
A good OODB as well as providing persistance, has no data impedance, ie
the data your program manipulates is the same data the database understands.
To me that alone is worth its weight in gold. Why on earth would you want
to seriously split a program into two possibly differing data representations??
Further good OODBs, have automatic navigation, ie you dont need to
write code the fetch and save your data, it works it out!
Can you imagine how much tedious programming suddenly evaporates.
OODB enforce the object paradigm which addresses the spagetti nature of flat
files and hierarchical DBs. And has been said over and over, you can have
entity relations to your hearts content in an OODB.
Obviously data inside a computer will never exactly match real world
objects/concepts, but why fracture your program and make things harder
with an RDB?
>this respect than relational ones are, but the price that is paid for this
>is in my opinion high - lack of rigour and conceptual simplicity.
You cant be talking from first hand experiences here. rigour is something
not found in commercial RDBMs. let me quietly crucify an RDBMS vendor.
Not to mention any names, but a recent release of Ingres on a Pyramid,
failled to provide the right number of rows, in a join on two btree tables.
huh, whats up doc, the profits slipping out the back door into shareholders
pockets and bypasing the quality control dept?
The mathematical rigour of set theory is about as usefull a being
restricted to legos and asked to build a space shuttle.
As to simplicity, where are you comming from? there is such a thing as
over simplicity. I have suffered for years with RDBs and the real world.
People that continuously stick up for the rigour of the relational
model in my experience have never put it to any serious tests.
Its a bit like boasting about the rigour and simplicity of FORTRAN
if that was the case, why isnt everyone still using it????
The relational model works ok for tiny databases, but for anything serious
its a joke. Its a bit like those noxious 4GLs, you can build a
baby application in no time, but ask them to do some real work and they
have a coronary. Relational should be really called the bondage model.
>> Codd obviously had a big problem with pointers, and invented
>> various 'ab'normal forms to get around the fact you couldnt store pointers
>> in an RDB. well times have changed, pointers are ok now. I cant think of a
>> single application I would recommend the use of an RDB over an OODB.
>> The flexibility of the RDB model is an illusion which has serious
>> performance trade offs. Real flexability is found in pointers not joins
>> and unions. This is why C/C++ has killed COBOL, and why OODBs will kill the
>> relational model.
>Each to their own, but the relational model has proved its power and
>simplicity/flexibility of use in the tremendous explosion of database
>products and applications built using it since its introduction.
Its a marketing driven myth the same way that DOS dominates the PC world.
Its not because its good. Ok there is a modicum of power, and maybe some
trivial flexibility, but take a closer look, behind the glossy promos,
look at the facts, look at what you can do with objects and you will never
want to go back.
vic
--
----------------------------------------------------------------------
Vic Cinc, Krell Labs pty ltd internet: vi...@extro.ucc.su.oz.au
smail: GPO Box 1660 Sydney NSW 2001
Andrew Haisley
big reason for the proliferation of RDBMSs IS do to with their
theoretical neatness: implementing something for which a coherent
mathmatical model exists (and getting it right) is a lot easier than
inventing something entirely new. Of course, just because a model
is neat, doesn't mean to say it is any use. I guess, by the time
you've started adding stored procedure, triggers and the rest, your
average RDMS is just as contorted as any other form of DB.
--
The opinions expressed here are not those of Smallworld Systems Ltd.
Andrew Haisley - and...@smallworld.co.uk or a...@setanta.demon.co.uk
---------------- life is shorter than you think --------------------
Mark Diamond
>>Each to their own, but the relational model has proved its power and
>>simplicity/flexibility of use in the tremendous explosion of database
>>products and applications built using it since its introduction.
>
>Its a marketing driven myth the same way that DOS dominates the PC world.
>Its not because its good. Ok there is a modicum of power, and maybe some
>trivial flexibility, but take a closer look, behind the glossy promos,
>look at the facts, look at what you can do with objects and you will never
>want to go back.
IMO, the best thing relational technology contributed was the CONCEPT
of a high level declarative query language. It is very useful to
get at a database without programming. A useful feature not part
of the model is the stored procedure. Most everything else is suspect:
Normalization (sic): forces designer to mutate his original data model
into a morass of 2 dimensional arrays (tables) losing all structural
semantics of the original model. Also, due to one of to the tenets of
Normalization (single value attributes), there is no inherent support
for large/array objects (these have been tacked on ad-hoc to commercial
systems, but are not directly supported by the database model).
Embeding SQL in a 3GL: using cursors (well known impedance problems).
Referential integrity: left to programmer (although some systems now
have it in their SQL implementations)
Joins are expensive: joins are cross products of tables. As # of
joins increases (ie relationships amongsts tables), performance
decreases exponentially (well not exactly with optimization, but the
point is, it takes a lot of processing to re-glue all data that has
been "normalized")
Limited datatypes: RDBs give you a few datatypes. All other (user-defined)
datatypes must be implemented semantically within an application.
Objectbases address all these limitations and have added features to
support modern applications like versioning and long transactions.
-Mark
----------------
Mark Diamond (ma...@objy.com)
Objectivity, Inc.
KMAN...@bcsc02.gov.bc.ca
ma...@server.uucp (Mark Diamond) writes:
>
>IMO, the best thing relational technology contributed was the CONCEPT
>of a high level declarative query language. It is very useful to
>get at a database without programming.
>
to have a recurring situation with our systems going into molasses
mode during prime shift because some user had signed on to TSS and
formulated a request which the machine was capable of understanding
and executing, without giving any warning of the resource usage involved.
Similar situations with MVS/DB2 came as no surprise to me. DB2 timestamp
mismatches with plans also echo HIS subschema timestamp issues.
My recollection is that the TSS interface was available as soon as the
you had done the subschemas, but my memory may have mutated in the last
14 years.
I recall an instructor at one of our courses making a point of telling
us that if we had a database of any real size we should not assume
that we could load it by having someone sit down at a TSS terminal
and key it in. Apparently at least one of their customers had tried
to this without bothering to work out the entry time arithmetic first.
2-2, 1515 Blanshard St., Victoria, BC, Canada, V8W 3C8
Internet:KMAN...@BCSC02.GOV.BC.CA
Thomas Cox
> Normalization (sic): forces designer to mutate his original data model
> into a morass of 2 dimensional arrays (tables) losing all structural
> semantics of the original model. Also, due to one of to the tenets of
> Normalization (single value attributes), there is no inherent support
> for large/array objects (these have been tacked on ad-hoc to commercial
> systems, but are not directly supported by the database model).
Wrong.
Read "Relation-Valued Attributes", chapter 6 in _Relational Database
Writings: 1989-1991_ by C.J. Date with Hugh Darwen.
There is no reason that _either_ SQL _or_ the relational model would
prohibit you from storing a table, an array, an array of arrays, etc. as
a 'single' (heh) value in a row of a column of a table. Or to use
Darwen-speak (he doesn't talk about 'tables' but rather of 'relations'):
"...relations should be permitted to include other relations nested
inside themselves." [page 76]
> Embeding SQL in a 3GL: using cursors (well known impedance problems).
Oh? Not that I'm aware of. Enlighten me, please.
> Referential integrity: left to programmer (although some systems now
> have it in their SQL implementations)
Indeed, it's in the SQL standard _and_ it's in all the commercial
products I use. Sorry, but not an issue.
> Joins are expensive: joins are cross products of tables. As # of
> joins increases (ie relationships amongsts tables), performance
> decreases exponentially (well not exactly with optimization, but the
> point is, it takes a lot of processing to re-glue all data that has
> been "normalized")
You are no longer discussing relational systems. You are talking about
implementation issues. Because of the separation of logical and
physical constructs, such issues are solvable through judicious use of
such things as disk striping, clustering, hashing, and denormalization.
All such techniques IN NO WAY change the relational nature of the
system.
For an amusing treatment of garbage arguments of the form "relational
systems can't achieve good performance", see "Relational Database:
Further Misconceptions Number Three" in the same volume mentioned above.
> Limited datatypes: RDBs give you a few datatypes. All other (user-defined)
> datatypes must be implemented semantically within an application.
User defined datatypes are certainly allowed by the relational model.
If you're talking about SQL, even that is allowing such datatypes to be
directly defined and addressed in the SQL3 draft (last I saw it anyway).
>Objectbases address all these limitations and have added features to
>support modern applications like versioning and long transactions.
Ah, they have long feature lists! How wonderful. When you can handle
7x24 operation and offer me 400+ third party applications on over a
dozen operating systems, be sure to drop me a note.
Seriously, OODBs are extremely useful today in areas where RDBMSs are
not very good. I've yet to see the OODB that can surpass the usefulness
of an RDBMS in _all_ areas, which you seem to be claiming.
Remember, there is no "best" database or "best" database architecture.
There is only "most appropriate for this task."
-Tom
--
Thomas Cox DoD #1776 '91 CB 750 Nighthawk tc...@qiclab.scn.rain.com
Worldcon: Arkham in '98.
Mark Diamond
>(Mark Diamond) writes:
>
>> Normalization (sic): forces designer to mutate his original data model
>> into a morass of 2 dimensional arrays (tables) losing all structural
>> semantics of the original model. Also, due to one of to the tenets of
>> Normalization (single value attributes), there is no inherent support
>> for large/array objects (these have been tacked on ad-hoc to commercial
>> systems, but are not directly supported by the database model).
>
>Wrong.
>
>Read "Relation-Valued Attributes", chapter 6 in _Relational Database
>Writings: 1989-1991_ by C.J. Date with Hugh Darwen.
>
>There is no reason that _either_ SQL _or_ the relational model would
>prohibit you from storing a table, an array, an array of arrays, etc. as
>a 'single' (heh) value in a row of a column of a table. Or to use
>Darwen-speak (he doesn't talk about 'tables' but rather of 'relations'):
Your referring to nested relations - something that was dreamed up long after
Codd's original paper. Look up the definition of 1st Normal Form in Date's
earlier book (same title, different dates - I think 1985-1989). BTW,
do you know of any implementations of an RDBMS supporting nested
relations?
>
> "...relations should be permitted to include other relations nested
> inside themselves." [page 76]
>
>> Embeding SQL in a 3GL: using cursors (well known impedance problems).
>
>Oh? Not that I'm aware of. Enlighten me, please.
Results of SQL queries are sets of tuples. The impedance mismatch is
when a 3GL like C wants to access each member of the set. That's why
cursors were invented -to allow you to iterate through the set.
>
>> Referential integrity: left to programmer (although some systems now
>> have it in their SQL implementations)
>
>Indeed, it's in the SQL standard _and_ it's in all the commercial
>products I use. Sorry, but not an issue.
Those that don't have it (I think Sybase) forces the programmer to
write a trigger to implement it. Not a huge point - but allows
room for more programmatic errors.
>
>> Joins are expensive: joins are cross products of tables. As # of
>> joins increases (ie relationships amongsts tables), performance
>> decreases exponentially (well not exactly with optimization, but the
>> point is, it takes a lot of processing to re-glue all data that has
>> been "normalized")
>
>You are no longer discussing relational systems. You are talking about
>implementation issues. Because of the separation of logical and
>physical constructs, such issues are solvable through judicious use of
>such things as disk striping, clustering, hashing, and denormalization.
^^^^^^^^^^^^^^^
Isn't this when you start to reverse engineer your relations for performance
reasons (ie you end up undoing all the work you did during normalization)?
My main beef with RDBMSs (let me clarify that I want to refer to
implementations not theory) is that you are forced to funnel your
data model through a two-dimensional model-mutator all in the name
of mathematical purity. This puts a tremendous burdon on the designer
who is forced to think in this two-dimensional straight jacket. Consider
a Many to Many relationship (let use the worn out student <-> courses).
The designer creates the student entity and the course entity. Now
how does he express the many to many cardinality between the two?
He must create a junction table that contains keys from the student
and course table to enable a 1 to Many mapping in each direction. Next
for the sake of efficiency, he needs to define 4 indexes: 1 for student,
1 for course, 1 for stduent key in junction table 1 for course key in
junction table. Thats a lot of low level work for a simple high level concept.
Isn't the goal to ease the burden from data model to implementation?
Another limitation is there is no support for recursively defined
data structures. This was a rude awakening for those trying to
print out a bill of materials. The reason this cant be done is
that there is no recursive join operation, and there is no direct support
for Many to Many cardinality. e.g.
parts are composed of 1 or more other parts.
parts can be part of 1 or more other parts.
This is a many to many relationship from parts to parts.
Please show me how to model this in an RDBMS. That is, give me some
ddl (create table, def keys) and a query that prints out each part and
the parts its composed of.
>
>Remember, there is no "best" database or "best" database architecture.
>There is only "most appropriate for this task."
Thats true. RDBMS marketing was the most successful at attacking that
philosphy.
>
> -Tom
>--
>Thomas Cox DoD #1776 '91 CB 750 Nighthawk tc...@qiclab.scn.rain.com
> Worldcon: Arkham in '98.
-Mark
----------------------------
Ole-Hjalmar Kristensen
<Stuff deleted>
My main beef with RDBMSs (let me clarify that I want to refer to
implementations not theory) is that you are forced to funnel your
data model through a two-dimensional model-mutator all in the name
of mathematical purity. This puts a tremendous burdon on the designer
who is forced to think in this two-dimensional straight jacket. Consider
a Many to Many relationship (let use the worn out student <-> courses).
The designer creates the student entity and the course entity. Now
how does he express the many to many cardinality between the two?
He must create a junction table that contains keys from the student
and course table to enable a 1 to Many mapping in each direction. Next
for the sake of efficiency, he needs to define 4 indexes: 1 for student,
1 for course, 1 for stduent key in junction table 1 for course key in
junction table. Thats a lot of low level work for a simple high level concept.
And how do you represent it in your OODB? A list of courses for each
student, and a list of students for each course? Doesn't seem more
elegant to me.
If you take concrete implementations of RDBS's and OODBMS's, it is not
difficult to find problems which are conveniently expressed in one and
not in the other. (or which cannot be conveniently expressed in any of
them :-)
--
Ole-Hj. Kristensen
"If you are going to shoot, shoot, don't talk."
-- Il Bruto
Mark Stern
>Xref: cc-server4.massey.ac.nz comp.databases.theory:1356 comp.databases.object:794 comp.databases:23732
>Newsgroups: comp.databases.theory,comp.databases.object,comp.databases
>Path: cc-server4.massey.ac.nz!comp.vuw.ac.nz!waikato!decwrl!elroy.jpl.nasa.gov!swrinde!cs.utexas.edu!uunet!pipex!sunic!ugle.unit.no!ole
>From: o...@delab.sintef.no (Ole-Hjalmar Kristensen)
>Subject: Re: Relational Myths (was Re: OODMS VS RDMS)
>In-Reply-To: ma...@server.uucp's message of Fri, 3 Sep 93 17:44:58 GMT
>Message-ID: <OLE.93Se...@delab.sintef.no>
>Sender: ne...@ugle.unit.no (NetNews Administrator)
>Organization: SINTEF DELAB, Trondheim, Norway.
>References: <vicc.74...@extro.ucc.su.OZ.AU> <1993Aug26.1...@objy.com>
> <1993Aug28....@qiclab.scn.rain.com>
> <1993Sep3.1...@objy.com>
>Date: 7 Sep 93 20:52:34
>Lines: 31
>--
>Ole-Hj. Kristensen
Good points.
The way I see it there are places in the world for both technologies. Some
applications/developments/databases will fall naturally into the Relational
Model some will obviously be better handled using OODBMS. The trick is to
identify the appropriate technology for the task at hand.
On the problem of implementing many to many relationships (and other
relationships for that matter) could be solved by the use of a higher level
design tool, in which you describe your relationships and the tool
generates the appropriate schema (be it Relational or OO). You might say this
is all very well but sooner or later you might want to modify the schema etc.
Well the answer to this is that sooner or later you might wish to change the
underlying machine code as well!, but do you? Really you have to decide at
what level of abstraction you wish to work at, then chose a tool that
supports that level and live with the functionality that tool provides.
Lets face it, we all use DBMS technology so we dont have to write and maintain
buckets of 3GL code, it is just another level of abstration giving us the
power to create and destroy large amounts of code with the sweep of a mouse.
Arguing over which is best RDBMS or OODBMS is a bit like the old 3GL arguments
(C or Pascal).
Mark Stern
Massey University
New Zealand
M.W....@massey.ac.nz
Paul Singleton
>> My main beef with RDBMSs (let me clarify that I want to refer to
>> implementations not theory) is that you are forced to funnel your
>> data model through a two-dimensional model-mutator all in the name
>> of mathematical purity. This puts a tremendous burdon on the designer
>> who is forced to think in this two-dimensional straight jacket. Consider
>> a Many to Many relationship (let use the worn out student <-> courses).
>> The designer creates the student entity and the course entity. Now
>> how does he express the many to many cardinality between the two?
>> He must create a junction table that contains keys from the student
>> and course table to enable a 1 to Many mapping in each direction. Next
>> for the sake of efficiency, he needs to define 4 indexes: 1 for student,
>> 1 for course, 1 for stduent key in junction table 1 for course key in
>> junction table. Thats a lot of low level work for a simple high level concept.
> In article <OLE.93Se...@delab.sintef.no> o...@delab.sintef.no (Ole-Hjalmar Kristensen) writes:
....
>>And how do you represent it in your OODB? A list of courses for each
>>student, and a list of students for each course? Doesn't seem more
>>elegant to me.
>
>>If you take concrete implementations of RDBS's and OODBMS's, it is not
>>difficult to find problems which are conveniently expressed in one and
>>not in the other. (or which cannot be conveniently expressed in any of
>>them :-)
From article <M.W.Stern....@massey.ac.nz>, by M.W....@massey.ac.nz (Mark Stern):
> The way I see it there are places in the world for both technologies. Some
> applications/developments/databases will fall naturally into the Relational
> Model some will obviously be better handled using OODBMS. The trick is to
> identify the appropriate technology for the task at hand.
I say:
Indeed, and to "identify the appropriate technology" we surely need a common
language/system with which to model applications, and a formal model of each
technology. We have a clear definition of the relational model, but no
clear definition of the/any OO model (refutations most welcome).
It would be useful if an OODB advocate would give a clear OO representation
of Mark D.'s many-to-many example: surely many-to-many relationships are not
one of Ole-Hj.'s "problems which are conveniently expressed in one and not
in the other" :-)
Down to what level of detail are established systems analysis and data
modelling practices appropriate to both RDBMs and OODBs?
Are there any theorems associated with the OO model? Can we predict the
costs of evaluating an OO query? Can we optimise the schema of an OODB
application to suit certain classes of query? Are the tradeoffs understood?
Are they being studied?
Is it sensible to compare and contrast OODBs and RDBs as if they had
alternative and equally valid theoretical foundations, or is the OODB
little more than a marketing concept?
Please don't assume I'm a RDB apologist. Having used both Prolog and RBDs
for serious applications, I can see that the relational model is a severely
functionally challenged subset of Prolog's logic+terms model, and that many
of the perceived shortcomings of the relational model would be eliminated
by generalising its functionality in the direction shown by Prolog: this
path has the advantage that the theory is already established. The almost
hopelessly impracticable traditional in-core implementation of Prolog is
irelevant here: RDBs need recursion, logical unknowns (misleadingly but
widely called "variables"), and structured data values, while retaining
and generalising their highly engineered indexing, optimisation and smart
secondary storage organisation.
But what we're getting is the "OODB", and no-one can say clearly what it is.
Paul
----
__ __ Paul Singleton (Dr) JANET: pa...@uk.ac.keele.cs
|__) (__ Computer Science Dept. other: pa...@cs.keele.ac.uk
| . __). Keele University, Newcastle, tel: +44 (0)782 583477 << NEW for
Staffs ST5 5BG, ENGLAND fax: +44 (0)782 713082 1993
Vic Cinc
>The way I see it there are places in the world for both technologies. Some
>applications/developments/databases will fall naturally into the Relational
>Model some will obviously be better handled using OODBMS. The trick is to
>identify the appropriate technology for the task at hand.
there is no place in the currnet universe for any RDB, sorry, but these thing
need to be extinguished, and relagated to a museum.
>Lets face it, we all use DBMS technology so we dont have to write and maintain
>buckets of 3GL code, it is just another level of abstration giving us the
>power to create and destroy large amounts of code with the sweep of a mouse.
>Arguing over which is best RDBMS or OODBMS is a bit like the old 3GL arguments
>(C or Pascal).
great use the cruddy 4GL (2.5GL in reality) that most RDBMs provide.
while OODB are still young they are a very promissing technology, just like
COBOL is now a dying art so will RDBMs go away too. and not soon enough.
Thomas J Lohman
distributed transactions across heterogeneous db systems?
thanks,
--tom
--
Thomas Lohman - Research Specialist
MIT Building 36 - Room 297
Cambridge, MA. 02139
e-mail: tho...@mtl.mit.edu, Phone: 617-258-6485
Michael Kifer
: I say:
:
: Indeed, and to "identify the appropriate technology" we surely need a common
: language/system with which to model applications, and a formal model of each
: technology. We have a clear definition of the relational model, but no
: ~~~~~~
: clear definition of the/any OO model (refutations most welcome).
:~~~~~~~~~~~~~ ???!!
: It would be useful if an OODB advocate would give a clear OO representation
: of Mark D.'s many-to-many example: surely many-to-many relationships are not
: one of Ole-Hj.'s "problems which are conveniently expressed in one and not
: in the other" :-)
: ...............
: Paul
: ----
: __ __ Paul Singleton (Dr) JANET: pa...@uk.ac.keele.cs
: |__) (__ Computer Science Dept. other: pa...@cs.keele.ac.uk
: | . __). Keele University, Newcastle, tel: +44 (0)782 583477 << NEW for
: Staffs ST5 5BG, ENGLAND fax: +44 (0)782 713082 1993
Having watched this thread for a while, it seems that many participants of
this discussion have not been following the developments in database theory
in the past 5 or so years.
The Object-Oriented data model is fairly well-understood by now,and it is
clear that there is no tension (in theory, not in politics, of course)
between the two models. Simply said, the relational model is a subset of
the object-oriented model, and you can use the two paradigms in the same
query language.
If you are interested in a somewhat theoretical exposition of these
foundations, you might take a look at my paper on F-logic, to appear in
JACM. It is available via the anonymous FTP from cs.sunysb.edu
(pub/TechReports/kifer/flogic.ps.Z).
In a paper with Won Kim and Shuky Sagiv in SIGMOD-92, we applied these
ideas to the design of an object-oriented extension of SQL, called XSQL. In
XSQL you can use relations and objects on a par (this is not an ad
hoc idea!). Unfortunately, because of space limitation, we had to cut out
the material on relations, but it will be included in a journal paper.
In any case, anyone who understands some classical logic, should be able to see
how relational and object-oriented constructs are combined in one language
after reading a few sections from the aforementioned paper on F-logic.
Michael Kifer
ki...@cs.sunysb.edu
Amitabh Shah
vi...@extro.ucc.su.OZ.AU (Vic Cinc) writes:
> while OODB are still young they are a very promissing technology, just like
> COBOL is now a dying art so will RDBMs go away too. and not soon enough.
Only the most depraved sense of humor would make one use the words "COBOL" and
"art" in the same sentence :-).
-amitabh.
--
Standard Disclaimer: The opinions are my own, and not of my employer's.
----------------------------------------------------------------------------
Amitabh Shah, Digital Equipment Corp., 55 Northeastern Blvd. Nashua NH 03062
Phone/Fax: +1 603 884 1841/0829 Internet: sh...@santur.nuo.dec.com
SRINIVASAN,K
> how does he express the many to many cardinality between the two?
> He must create a junction table that contains keys from the student
> and course table to enable a 1 to Many mapping in each direction.
Though an OO model lets you represent n-n relationships, for
another reason you end up creating classes to represent
relationships anyway. For example, there is a n-n relationship
between vendors and the products they sell. There are certain
attributes like the address of the vendor which are specific
to the vendor alone. Similarly, there are attributes that belong
to the material such as its code. However, certain attributes
such as list-price, discount and lead-time belong to neither
vendor not the product, but characterize the relationship
between the two. I found that in most relationships, there
are certain attributes of the relationship (and not of either
of the participants in the relationship).
--
SRINIVASAN,K
School of Textile Engineering Georgia Tech.
uucp: ...!{allegra,amd,hplabs,seismo,ut-ngp}!gatech!prism!gt4084c
ARPA: gt4...@prism.gatech.edu
Donald Ravey
: there is no place in the currnet universe for any RDB, sorry, but these thing
: need to be extinguished, and relagated to a museum.
Is this person serious? What naivete. But, then, I've seen this impulsive
attitude many times in students. I think such energy and committment can
be a healthy sign of youth, but it surely needs to be channelled to more
useful ends.
+-----------------------------------------------------------------------------+
| Don Ravey dra...@netcom.com OBJECTS IN MIRROR |
| ARE CLOSER THAN THEY APPEAR |
+-----------------------------------------------------------------------------+
Michael Kifer
: there is no place in the currnet universe for any RDB, sorry, but these
: thing need to be extinguished, and relagated to a museum.
This is childish. But also much of the discussion in this thread is
redundant, if not silly.
Some problems are more amenable to relational representation, and some are
better off with the object-oriented data model. What you need is both, and
there is no reason not to have it. The two data models are compatible, as I
mentioned in my previous posting. This idea is slowly getting through to
the industry level. As one example, the object-oriented SQL extension of
UniSQL, Inc. is upward compatible with relational SQL in a very clean
fashion.
That is to say that even a language as bad as SQL does not prevent clean
integration of the two models.
Michael Kifer
ki...@cs.sunysb.edu
Vic Cinc
>I say:
OODB isnt a thing like RDBs are a thing, OO is a methodology for progamming,
and the DB aspect adds persistance/transactions etc. If you are programming
in COBOL or fortran then an OODB isnt for you. If you programming in C++
or smalltalk, then you will save time and money by using a DB which matches
your paradigm. Ideally the database aspects should be transparent,
the database is not the program and isnt anything in its own right, except
a bunch bits on a disk. Having used both I feel that it is the RDBs which
are a marketing concept invented to fill in the void that is missing
from 'structured programming'.
There is a lot a vagueness and waffle about OODB, because they do not have
a foundation like RDBs do. Their real value is in supporting a higher
level paradigm - that of OO. To that end there are many approaches,
persistance via inheritance, mapping via virtual memory addressing, etc.
which is the best approach will prove its self over the next few years.
I program in C++ and having to shoehorn my objects into an RDB is a joke,
even with various state of the art OO-RDB interfaces its so slow as to
be embarrassing.
My first effort in converting a RDB based program to and OODB involved
slashing out nearly 40% of the code. The end system ran over 10 times faster.
I am not going to give any one OODB a free plug but I was extremely
impressed.
There is a lot of hype about the value of queries. My experience is that
ad-hoc queries are a crock. used only to set up or fix a DB.
Users use applications not RDBs, and so shouldnt have direct access to
the DB . We alway provide ad-hoc queries through the application interface
this usually involves having a button with a submenu of '=' < <= > >= etc
the user enter values into a form and presses this find button
which constructs a query and places the output into a tabular form.
One can be selected and is placed back in the original window for editing.
We usually allow an option to limit the search over the output
of the previous search allowing users to build up fairly complicated
queries without knowing a scrap of SQL. How does that differ in an OODB,
well it doesnt, in both systems you still need to construct a dynamic query
and execute it. In both systems you still need to write code to do this.
No one writes serious application where the user has direct access
to raw query facilities, forcing end users to understand SQL syntax.
Thats not an application its an RDB vendors wet dream.
To my way of thinking you dont want to know about the database aspects,
they should be transparent, you only want transactions and a few support
classes, some way of constructing dynamic queries and nothing else
to impeded to design of the program. The Db should not force you
to think about identity via value, it should not force you to think about
normalisation, it should not force you to think about how
on earth am I going to store my pointers in those tables, it should
not force you to think about anything except the application.
DBs should be seen and not heard.
Stephen J Bevan
pa...@cs.keele.ac.uk (Paul Singleton) writes:
> [ lots of good stuff and notes that some sort of extended Prolog
> would solve many of the problems of RDBs ]
... If you programming in C++
or smalltalk, then you will save time and money by using a DB which
matches your paradigm.
Matching the language to your paradigm is IMHO exactly what Paul
describes with his comment about Prolog. I couldn't fathom RDBs until
I discovered Prolog and ever since I've been hoping that someone would
do what Paul suggests. Fortunately, people have, the systems just
aren't "industrial strength" yet. I think it is Ullman who somewhere
says that whilst the deductive database crowd have been busy writing
papers about the theory, the OO crowd have just got on with building
systems.
[ snip snip ]
There is a lot a vagueness and waffle about OODB, because they do
not have a foundation like RDBs do. Their real value is in
supporting a higher level paradigm - that of OO.
Ah yes, OO, the label that many seem to have decided is important but
which for which it is difficult to find two people who can agree on
its meaning. Is it inheritance? Err no, you can use delegation. Is
it classes? Err no, you can have prototypes. Is it dynamic
dispatching? Well maybe, but what about Emerald? Is it class based
encapsulation? Err maybe, but what about Ada9X, CLOS, ModulaIII,
Oberon(-2) or Self? ... etc. Of course the answer is it is any or
all of them; no wonder people don't theorise and just implement
instead :-)
[ snip snip ]
Users use applications not RDBs, and so shouldnt have direct access to
the DB.
There are many types of user, some don't need to see the DB, some do.
If they do need to get at it and they don't want to use your paradigm,
they are just as stuffed as they are now trying to connect C++ to a RDB.
[ snip snip ]
No one writes serious application where the user has direct access
to raw query facilities, forcing end users to understand SQL syntax.
For "users" see above. As to SQL, I don't think many people,
including me, have anything good to say about it. Like many people I'd
prefer if SQL was kept separate from the concept of relations.
To my way of thinking you dont want to know about the database
aspects, they should be transparent, ... it should not force you to
think about anything except the application. DBs should be seen
and not heard.
Agreed, but we ain't there yet.
PS for Paul: glad you finally have a decent account name, was it the
"Dr" that did it?
Geoff Miller
>OODB isnt a thing like RDBs are a thing, OO is a methodology for progamming,
[snip]
Relational Data Modelling is a methodology for modelling and formalising
your understanding of the data with which you're working. The RDBMS
products are attempts (of greater or lesser completeness) to create
a functional application using the data structures of the model. The
data modelling itself has value, irrespective of whether you implement
your final system using that model, and IMHO the biggest criticism of
some of the RDBMS products is that they do not allow you enough leeway
to move away from the detailed model structure, as I guess you've found....
>I program in C++ and having to shoehorn my objects into an RDB is a joke,
>even with various state of the art OO-RDB interfaces its so slow as to
>be embarrassing.
>My first effort in converting a RDB based program to and OODB involved
>slashing out nearly 40% of the code. The end system ran over 10 times faster.
>I am not going to give any one OODB a free plug but I was extremely
>impressed.
However, such improvements are not solely caused by a move to a different
system. We have undertaken some redevelopment of existing systems within
the same product but redesigning the systems to take full advantage of
facilities added to the product since the initial development, and we
have got a similar order of performance improvement.
>There is a lot of hype about the value of queries. My experience is that
>ad-hoc queries are a crock. used only to set up or fix a DB.
If you're going to make blanket statements like this, though, perhaps
you should explain just how much experience that is. In my experience
(since 1980:-) no matter how good a job you do on designing an application
users will always come up with _some_ problem which requires an ad-hoc
query.
>Users use applications not RDBs, and so shouldnt have direct access to
>the DB . We alway provide ad-hoc queries through the application interface
>this usually involves having a button with a submenu of '=' < <= > >= etc
>the user enter values into a form and presses this find button
>which constructs a query and places the output into a tabular form.
>One can be selected and is placed back in the original window for editing.
>We usually allow an option to limit the search over the output
>of the previous search allowing users to build up fairly complicated
>queries without knowing a scrap of SQL.
Yes, well when you start to work in the real world you may also find a
need to do other things like performing several different queries,
sometimes on different databases, and then merging the results.
> How does that differ in an OODB,
>well it doesnt, in both systems you still need to construct a dynamic query
>and execute it. In both systems you still need to write code to do this.
>No one writes serious application where the user has direct access
>to raw query facilities, forcing end users to understand SQL syntax.
>Thats not an application its an RDB vendors wet dream.
No-one writes serious applications where all users have to rely upon
direct access to raw query facilities. Equally, if you deny users
access to such facilities for handling tricky queries then you're
simply creating problems. OK, you may only provide such access for
a few users, but it has to be there. (Anyone who has ever tried to
assist users of an application provided using a run-time version of
a DBMS with no ad-hoc query capability will appreciate already why
this is necessary.)
>To my way of thinking you dont want to know about the database aspects,
>they should be transparent, you only want transactions and a few support
>classes, some way of constructing dynamic queries and nothing else
>to impeded to design of the program. The Db should not force you
>to think about identity via value, it should not force you to think about
>normalisation, it should not force you to think about how
>on earth am I going to store my pointers in those tables, it should
>not force you to think about anything except the application.
>DBs should be seen and not heard.
What I think you're saying is that users shouldn't need to worry about
the structure of their data. In many cases the users _have_ to
understand something about the structure of the data because only
thus can they use the data intelligently. What you're suggesting may
be true in some applications, it's not a general principle.
Geoff (g-mi...@adfa.edu.au)
Piercarlo Antonio Grandi
Some problems are more amenable to relational representation, and some
are better off with the object-oriented data model.
Unfortunately there is no such thing as an OO data model. There is a
thing called a network data model, and a thing called typing/subtyping,
and that's it.
What you need is both, and there is no reason not to have it.
If by *both* you mean adding classes/inheritance/methods to a relational
model DBMS, perhaps one could reluctantly agree, even if I think that is
essentially redundant and betrays the spirit of a relational DBMS.
However let me insist, with dozens of academic writers, that there is no
constest that the network data model on which most OODBs are based is
definitely inferior to the relational one, and for all the well known
reasons.
Just about the only, and big, problem of the relational model is that
the vast majority of current commercial implementations is appallingly
badly designed (as Stonebraker implied long ago, a remark that still
holds true).
Most don't even allow the actually really simple physical
clustering options that are essential to make any DBMS run fast (e.g.
clustering together rows of tables on which a join is expexted, that
would give exactly the same performance on joins as set traversal in
network oriented DBMSes, without however unduly restricing the access
paths like network, and thus usually the OODBs, do).
The above paragraphs slightly rephrased: the strength and weakness of the
network model is that data access paths are prewired, so that the
logical and physical schemas can be essentially identical, and
clustering information is obviously implicit in the logical schema.
Relational DBMSes don't prewire, at the logical level, any access path;
unfortunately most don't then allow for the full freedom to prewire any
"important" access paths and clusterings. Too bad.
I *might*, under duress, admit that perhaps classes/methods/inheritance
can be fitted into a relational database, as I said above, but I
really, really doubt that this is a wise move. It certainly loses the
extensional/value based character of the relational model, which is its
greatest and bestest aspect.
I also think that the benefits of classes/inheritance/methods can
be obtained rather more cleanly and maintainably by suitable data
dictionary design (as far as classes/inheritance go), and by use of
active values (in lieu of methods). Too bad that again most current
commercial relational DBMSes are appalingly bad in this respect too.
Richard Bielak
[...]
>
>If you take concrete implementations of RDBS's and OODBMS's, it is not
>difficult to find problems which are conveniently expressed in one and
>not in the other. (or which cannot be conveniently expressed in any of
>them :-)
>
I disagree.
You can express anything in OODB that you can in RDBMS. Simply start
by creating an class TABLE with operation "join" :-).
On the other hand, how can you define a queue (i.e. an ordered list)
in RDBMS?
--
* Richie Bielak (212)-815-3072 | *
* Internet: ric...@bony.com | "The best way to predict the future *
* Bang {uupsi,uunet}!bony1!richieb | is to invent it." *
* - Strictly my opinions - | - Alan C. Kay - *
Michael Kifer
: On 10 Sep 1993 01:31:21 GMT, Michael Kifer (ki...@cs.sunysb.edu) wrote:
: Some problems are more amenable to relational representation, and some
: are better off with the object-oriented data model.
: Unfortunately there is no such thing as an OO data model. There is a
: thing called a network data model, and a thing called typing/subtyping,
: and that's it.
Are you referring to data models found in undergrad textbooks, or your
statement is about recent research? There is probably no *single*
object-oriented data model, but most of the proposed ones agree on their
major components. Have you been following major database publications?
: What you need is both, and there is no reason not to have it.
: If by *both* you mean adding classes/inheritance/methods to a relational
: model DBMS, perhaps one could reluctantly agree, even if I think that is
: essentially redundant and betrays the spirit of a relational DBMS.
"Both" means that sometimes it is convenient to represent data as relations
and sometimes as objects. What you need is to be able to represent part of
the data using relations and part using objects.
Michael Kifer
ki...@cs.sunysb.edu
Dan Weinreb
However let me insist, with dozens of academic writers, that there is no
constest that the network data model on which most OODBs are based is
definitely inferior to the relational one, and for all the well known
reasons.
I am not sure what you mean when you say "the" network data model.
Chris Date's Introduction to Database Systems presents what I have
always thought of as "the" network model; I know of no OODBMS based on
it. Perhaps you mean "the network model" in a much broader sense?
Just about the only, and big, problem of the relational model is that
the vast majority of current commercial implementations is appallingly
badly designed (as Stonebraker implied long ago, a remark that still
holds true).
I would be very interested in knowing your opinion about how this came
to be. After all, relational database systems have been around for
(depending on how you could, but at the very least) 12 years now.
There is a big and very competitive market for these products. There
is a tremendous amount of literature available. There are very smart
people at Oracle, Ingres, Sybase, IBM Almaden, and IBM Santa Theresa
(among others) working on making good relational database system
products. And yet, you say, just about all of them are appallingly
badly designed. You say that in theory, relational database systems
could be much better than they are. But if that hasn't happened yet,
with all those people and all that competition over all this time, do
you expect it to happen in the next ten years? Or is it that
something else is really going on here?
Ole-Hjalmar Kristensen
Xref: ugle.unit.no comp.databases.theory:1380 comp.databases.object:832 comp.databases:23633
Newsgroups: comp.databases.theory,comp.databases.object,comp.databases
Path: ugle.unit.no!trane.uninett.no!nntp.uio.no!nac.no!news.eunet.no!nuug!news.eunet.fi!news.funet.fi!sunic!mcsun!uunet!psinntp!bony1!richieb
From: ric...@bony1.bony.com (Richard Bielak)
Organization: We don't need no stinkin' Organization!
References: <vicc.74...@extro.ucc.su.OZ.AU> <1993Aug28....@qiclab.scn.rain.com> <1993Sep3.1...@objy.com> <OLE.93Se...@delab.sintef.no>
Date: Mon, 13 Sep 1993 16:33:46 GMT
Lines: 23
In article <OLE.93Se...@delab.sintef.no> o...@delab.sintef.no (Ole-Hjalmar Kristensen) writes:
[...]
>
>If you take concrete implementations of RDBS's and OODBMS's, it is not
>difficult to find problems which are conveniently expressed in one and
>not in the other. (or which cannot be conveniently expressed in any of
>them :-)
>
I disagree.
You can express anything in OODB that you can in RDBMS. Simply start
by creating an class TABLE with operation "join" :-).
I think you will find that this is not so trivial, and remember, you
have to define the other relational operators as well. Besides, that
is cheating, because you are not expressing your problem directly in
your OODB any more, but in a relational form :-)
On the other hand, how can you define a queue (i.e. an ordered list)
in RDBMS?
If you really insist on an ordered list, it will be messy, but an
ordered set is trivial, just make sure you have some unique key to
order by. Of course, there is no provision to associate the relevant
operations with the table and thereby create a new abstract data type
'queue'.
BTW, many (if not most) implementations of RDBMS's keep their tuples
ordered by primary key in a B-tree, which means that if you use the
primary key to implement your queue, there is no extra overhead.
What an RDBMS is notoriously bad at, is problems where some object is
contained in another. It is not difficult to express, but a
straigthforward realization in terms of a table which contains the
keys of the containers and their contents usually results in the RDBMS
joining itself to death.
--
* Richie Bielak (212)-815-3072 | *
* Internet: ric...@bony.com | "The best way to predict the future *
* Bang {uupsi,uunet}!bony1!richieb | is to invent it." *
* - Strictly my opinions - | - Alan C. Kay - *
Vic Cinc
>In article <vicc.74...@extro.ucc.su.OZ.AU>, vi...@extro.ucc.su.OZ.AU
>(Vic Cinc) wrote:
>> while OODB are still young they are a very promissing technology, just like
>> COBOL is now a dying art so will RDBMs go away too. and not soon enough.
> 10) pin point the problem, correct it, and recompile, and continue.
> [ much stuff deleted ]
>So you ask: "Why did I even bother then?" Because I happen to not like
>language bashers. There is nothing wrong with COBOL or FORTRAN or even
>Basic. Except that other languages are felt to be better. I just say
>so what. These languages were built to answer certain needs. They fill
>that need very well. Aristocratic outlooks just don't fit when dealing
>with computer languages any more than to say there is anything wrong
>with speaking Gaelic, Russian, Zulu, or any other language in the world.
>Flame suit now on - IGNITE!
you overlook one small problem of semantics, the language defines what you
can express and at what expense. language like C and C++ kill COBOL
everytime. It hardly the equivalent of comparing Zulu to Gaelic.
Eskimos have over 20 words to descrbie snow, each language has a strength,
which is why you dont see state of the art software written in COBOL unless
there are no options. Its not an aristocratic outlook, you arnt likely
to take a model T out on the formula 1 track are you, certainly not with
any serious intent of winning.
Vic Cinc
>Vic Cinc (vi...@extro.ucc.su.OZ.AU) wrote:
>: there is no place in the currnet universe for any RDB, sorry, but these thing
>: need to be extinguished, and relagated to a museum.
>Is this person serious? What naivete. But, then, I've seen this impulsive
>attitude many times in students. I think such energy and committment can
>be a healthy sign of youth, but it surely needs to be channelled to more
>useful ends.
I am deadly serious I have used these crappy relational things for near
8 years now, and having recently used an OODB, I am not going back.
Its called evolution, maybe you should pay attention to it before you get
left behind and become a fossil.
Vic Cinc
>Vic Cinc (vi...@extro.ucc.su.OZ.AU) wrote:
hmm... may be would should still be riding horses too. Object SQL is an
abortion, suffering the worst features of SQL and few of the strength
of native OODB interfaces. OO is a paradigm shift, relational is dead.
OO totaly superset relational, there is no point wasting new projects
on this old stuff. move on for christ sakes.
Vic Cinc
>vi...@extro.ucc.su.OZ.AU (Vic Cinc) writes:
>>OODB isnt a thing like RDBs are a thing, OO is a methodology for progamming,
>[snip]
>users will always come up with _some_ problem which requires an ad-hoc
>query.
and what are you going to do teach them SQL?
>>Users use applications not RDBs, and so shouldnt have direct access to
>>the DB . We alway provide ad-hoc queries through the application interface
>>this usually involves having a button with a submenu of '=' < <= > >= etc
>>the user enter values into a form and presses this find button
>>which constructs a query and places the output into a tabular form.
>>One can be selected and is placed back in the original window for editing.
>>We usually allow an option to limit the search over the output
>>of the previous search allowing users to build up fairly complicated
>>queries without knowing a scrap of SQL.
>Yes, well when you start to work in the real world you may also find a
>need to do other things like performing several different queries,
>sometimes on different databases, and then merging the results.
I have been working in the real world for 8 years now for everything
from airlines to banks. the above is just an example of how to deal with
ocmputer illiterate users. you can generalise the above for interactive
end users over n databses. If you are talking about batch stuff it gets
written by programers anyway.
I have been involved in a quite a few small and large application
both commercial and in-house, and _never_ have I seen _any_ end user
application which requires the user to learn SQL. hence no end
user ad-hoc queries.
Maybe I should change the thread to 'what they dont teach in computer
science I, II and III.'
What I am saying is too often the database imposes too many restrictions
on the poor programer, which it should not. A database is not an end user
application. Do you think adobe Photo Shop is written on top a commercial
DB, or may the compiler you use? Well I have news for
you there is a compiler built on top an OODB. (free plug for lucid)
try and do that in an RDB.
I get lots of mail from too many students and academics and none from
people who have developed real applications and disagree with me.
Vic Cinc
>On 10 Sep 1993 01:31:21 GMT, Michael Kifer (ki...@cs.sunysb.edu) wrote:
> Some problems are more amenable to relational representation, and some
> are better off with the object-oriented data model.
>Unfortunately there is no such thing as an OO data model. There is a
>thing called a network data model, and a thing called typing/subtyping,
>and that's it.
> What you need is both, and there is no reason not to have it.
>If by *both* you mean adding classes/inheritance/methods to a relational
>model DBMS, perhaps one could reluctantly agree, even if I think that is
>essentially redundant and betrays the spirit of a relational DBMS.
>However let me insist, with dozens of academic writers, that there is no
>constest that the network data model on which most OODBs are based is
>definitely inferior to the relational one, and for all the well known
>reasons.
acedemics again with no application development experience again.
the relational model fails to deal with simple data structures
like trees and graphs. this alone precludes it from dealing with
a large class of problems. As has been pointed out many times the OO
paradign is a super set of the relational model. Its a bit like
quantum theory replacing Newtownian dynamics.
Newtownian physics my be all that is needed to send a man to the moon
but you cant use it to build a microchip.
New things are possible with much greater ease in an OODB.
I dont know what you are blinded by but its certainly not experience.
Eric Hopper
...Stuff deleted...
: Just about the only, and big, problem of the relational model is that
: the vast majority of current commercial implementations is appallingly
: badly designed (as Stonebraker implied long ago, a remark that still
: holds true).
The big problem with relational databases is that mnay people
seem to have a hard time stuffing their data model into a relational
model. They also seem to have problems with efficiency. OODBMS's seem
to be a good, and flexible solution to these problems.
I think you risk getting off track here. The purity of the
underlying mathematical model is not very important. The mathematics and
theory are a useful tool to understand a particular way of doing things,
and to determine if the model is 'complete' in some sense. Other than
that, the overriding concerns are exceedingly practical.
Have fun, (if at all possible)
--Me (Eric Hopper)
Dennis Allard
>dra...@netcom.com (Donald Ravey) writes:
>>Vic Cinc (vi...@extro.ucc.su.OZ.AU) wrote:
>>: there is no place in the currnet universe for any RDB, sorry...
>>Is this person serious? What naivete. But, then, I've seen this impulsive
>>attitude many times in students...
>I am deadly serious I have used these crappy relational things for near
>8 years now, and having recently used an OODB, I am not going back.
>Its called evolution, maybe you should pay attention to it before you get
>left behind and become a fossil.
>vic
What size applications have you developped?
How many mega/giga bytes of data?
How many updates/accesses/searches per second/minute/week/month?
How many users sharing the data? (all at the same time instant)
How many fields/relations/objects/functional relationships/... were
in the data model, using any model of your choice?
Dennis Allard
d...@netcom.com
Dennis Allard
>the relational model fails to deal with simple data structures
>like trees and graphs.
But Vic, neither does the OO 'model'. In both cases, the programmer
must use provided primitives to write code which provides the
semantics of whatever tree or graph structure is being modelled.
In the case of C++ you write some classes and give them some
attributes which define a tree, based upon code which you also
write. You stuff everything into a library, hope its relatively
reusable, and call it a model if you're stubborn. The very same
thing goes for RDB systems such as Ingres or Sybase. You define
a binary relation which maps nodes to nodes and make use of
recursion mechanisms (in the case of Ingres) to provide
search operations, etc. Ditto, you have modelled a tree.
In neither case was a tree part of the language.
Besides, vic, you continue to miss a crucial point. The OO 'paradigm'
as you correctly refer to it, is a *methodology* derived from a
history which includes Simula, Algebraic datatype specifications,
and the English school of structured programming. It is a
*methodology*, not a model. In recent years, some people have
incorporated parts of this methodology directly into programming
languages, giving the allure of a model. But only in the sense
that any given programming language defines a de facto data model.
It could still be argued that this methodology belongs more to
a programming environment than to the language, but that is
a personal opinion which I do not wish to debate here.
>this alone precludes it [the relational model] from dealing with
>a large class of problems.
It is true that the relational model imposes limitations upon the
programmer. But they are limitaitons of convenience, not of
possiblity. In return, for the large class of problems for which
the model is a good fit, you obtain faster implementation time
and improved maintainability, modifiability, and clarity of
specification.
I am not, in any way, defending RDBMS technology, which I
dub 'legacy technology'. However, I do defend what *is* good
about it and defend it from spurious criticism such as yours.
>As has been pointed out many times the OO
>paradign is a super set of the relational model.
Now you are threading on thin ice.
>Its a bit like quantum theory replacing Newtownian dynamics...
Absurd analogy.
>I dont know what you are blinded by but its certainly not experience.
I am not, in any way, an apologist for RDBMS technology, which I
dub 'legacy technology'. However, I do defend what *is* good
about it and defend it from spurious criticism such as yours.
Dennis Allard
d...@netcom.com
Geoff Miller
>g...@sserve.cc.adfa.oz.au (Geoff Miller) writes:
>>users will always come up with _some_ problem which requires an ad-hoc
>>query.
>and what are you going to do teach them SQL?
What do you propose to do--ignore the problem? In my experience the
majority of users are satisfied with the applications, in which
they have access to some fairly flexible but basically pre-defined
reporting options. There are always a few "power" users who have
to use the query language to get what they want. If I worked with
an RDBMS, then yes, I would teach them SQL--fortunately, I work
with something rather easier for them to use:-)
>>Yes, well when you start to work in the real world you may also find a
>>need to do other things like performing several different queries,
>>sometimes on different databases, and then merging the results.
>I have been working in the real world for 8 years now for everything
>from airlines to banks. the above is just an example of how to deal with
>ocmputer illiterate users. you can generalise the above for interactive
>end users over n databses. If you are talking about batch stuff it gets
>written by programers anyway.
(a) I wasn't talking about batch stuff, and (b) you're ignoring the
issue.
>I have been involved in a quite a few small and large application
>both commercial and in-house, and _never_ have I seen _any_ end user
>application which requires the user to learn SQL. hence no end
>user ad-hoc queries.
You're still ignoring the issue. The _average_ user is not
_required_ to learn SQL or any query language. What I have been
attempting to point out is that, no matter how well designed the
application, there will be some once-off, ad-hoc reports which
are most efficiently addressed at the query language level--i.e.
it takes far less time for someone who knows the query language
to use it to address the problem than for a programmer to modify
the application. I would never suggest that all users should have
to rely on a query language, but equally I would expect that the
power users would need access to it and will do their job more
efficiently if they have such access. Very often, too, developments
to the application come from just such users, who find themselves
making a particular query or generating a report often enough to
ask for it to be included in the application.
The kind of situation I'm thinking about is what occurs in our
student administration. The people who handle the routine work
operate happily within the application, but a couple of the more
senior users occasionally need to use the query language when
an odd-ball query ('How many navy cadets coming from Canowindra
are studying economics and play hockey') comes down the line.
>Maybe I should change the thread to 'what they dont teach in computer
>science I, II and III.'
That's OK--I never formally studied computer science anyway:-)
>What I am saying is too often the database imposes too many restrictions
>on the poor programer, which it should not. A database is not an end user
>application.
Now here I agree with you, although some DBMSs come closer than others.
Where I think we differ is that you seem to view all users as being at
a single level (and with banks and airlines this may almost be the
case) whereas the sort of systems that I have worked on have to cater
for users with a wide range of requirements.
[free plug deleted]
>I get lots of mail from too many students and academics and none from
>people who have developed real applications and disagree with me.
Perhaps you're ignoring postings from people who have developed
real applications and disagree with you? BTW--an application with
a dozen users is just as "real" as one with ten thousand.
Geoff (g-mi...@adfa.edu.au)
Rev Dr Phil Herring
g...@sserve.cc.adfa.oz.au writes:
>The kind of situation I'm thinking about is what occurs in our
>student administration. The people who handle the routine work
>operate happily within the application, but a couple of the more
>senior users occasionally need to use the query language when
>an odd-ball query ('How many navy cadets coming from Canowindra
>are studying economics and play hockey') comes down the line.
They'd use a product with a GUI that lets them assemble a query
without recourse to SQL. We have secretary types here who have learned
to this; it's a user-interface issue, and should be handled the same
way regardless of the underlying data model and language.
-- Phil.
-----------------------------------------------------------------------
Rev Dr Phil Herring, University of Wollongong, Australia
Copyright (c) 1993 Phil Herring phil_h...@info-gw.uow.edu.au
"Mmmmmmmm... moanin' moanin' moanin'.... uhh uhh... mmmmm...."
- John Lee Hooker
------------------------------------------------------------------------
Vic Cinc
>In article <CDAwo...@bony1.bony.com> ric...@bony1.bony.com (Richard Bielak) writes:
> In article <OLE.93Se...@delab.sintef.no> o...@delab.sintef.no (Ole-Hjalmar Kristensen) writes:
> [...]
> >
> >If you take concrete implementations of RDBS's and OODBMS's, it is not
> >difficult to find problems which are conveniently expressed in one and
> >not in the other. (or which cannot be conveniently expressed in any of
> >them :-)
> >
> I disagree.
> You can express anything in OODB that you can in RDBMS. Simply start
> by creating an class TABLE with operation "join" :-).
>I think you will find that this is not so trivial, and remember, you
>have to define the other relational operators as well. Besides, that
>is cheating, because you are not expressing your problem directly in
>your OODB any more, but in a relational form :-)
wrong. set operations are especially trivial. you keep forgeting OO is
a superset of relational.
Maybe we should at this point step back and ask some basic questions.
What is a database?
A database is a collection of data probably on a disk. A database
imposes a paradigm: transactions, persistantce of data, recoverability,
consistency, clustering etc.
An ideal DB should allow you to implement whatever programming paradigm
you would like on top of it. ie it just maintains your data for you.
You should be able to model data in whatever data model you like, the latest
OO design methodology or a relational model, or even a heirarchical model.
Imposing really only transactions as the unit of atomicity. Anything is
really beyond the scope of the word database.
Relational databases impose more constraints on its users. Data must be
decomposed into tables and rows. They support limited base data types,
and pointers must be converted to keys. Recomposition of complex
data types must be done via set theoritical operations like union,
intersection, product, cross product etc. Almost all commercial relational
databases provide SQL as the access method, which is either interpreted
or compiled into some intermediate code and then interpreted. Unfortunetly
most people agree, SQL is terrible, even the commercial vendors agree
and provide various 4Gls to compensate for the lack of procedural
abilities in SQL, and its total lack of any speed. You cannot write
an application in pure SQL, or for that matter any pure or semi
pure relational language.
Newer OODBs shouldnt be called Object Oriented Data Bases because
they dont really support any particular OO modeling methodology, In fact
they dont support any particular design methodology. These state of the
art systems are just pure databases, and provide a native language binding
which is usually C++, hence the OO. There is nothing stoping you from
using these new systems in a relational or hierarchical fashion if that is
where you get your jollies. Some provide C binding which has only a spagetti
methodology. The base of these things only provide transactions, versioning,
historical versioning etc. There is no slugish SQL to slow you down,
there is no silly restriction on shape of data, the only restrictions
are you imagination, and whatever design methodology you may choose.
On top of this core most provide a rich set of container classes,
dynamic query composition, and some sort of windowing user interface.
Now which would you choose.
Vic Cinc
>vi...@extro.ucc.su.OZ.AU (Vic Cinc) writes:
>>g...@sserve.cc.adfa.oz.au (Geoff Miller) writes:
>>>users will always come up with _some_ problem which requires an ad-hoc
>>>query.
>>and what are you going to do teach them SQL?
>What do you propose to do--ignore the problem?
no, you provide facilities to manipulate data in the application,
as apart of the application.
>In my experience the
>majority of users are satisfied with the applications, in which
>they have access to some fairly flexible but basically pre-defined
>reporting options.
>There are always a few "power" users who have
>to use the query language to get what they want. If I worked with
>an RDBMS, then yes, I would teach them SQL--fortunately, I work
>with something rather easier for them to use:-)
I certainly wouldnt teach anyone SQL, nor would I let loose
users directly on a database.
You are probably confusing canned reporting features with applications
that can dynamically create subsets of objects based on arbitrary
criteria, and do this recursively. just spiting out reports isnt often
very usefull. You usually want to apply the end result of your qery
back through the original application to get some magic number
or a graph. Query in themselves are only as usefull as where you can funnel
the end result, staring at pages of output is rarely a usefull
end result.
Ole-Hjalmar Kristensen
Xref: ugle.unit.no comp.databases.theory:1396 comp.databases.object:865 comp.databases:23701
Newsgroups: comp.databases.theory,comp.databases.object,comp.databases
Path: ugle.unit.no!trane.uninett.no!sunic!pipex!uunet!usc!sol.ctr.columbia.edu!caen!batcomputer!munnari.oz.au!metro!extro.ucc.su.OZ.AU!vicc
From: vi...@extro.ucc.su.OZ.AU (Vic Cinc)
Sender: ne...@ucc.su.OZ.AU
Nntp-Posting-Host: extro.ucc.su.oz.au
Organization: Information Services, Sydney University, Sydney, NSW, Australia
References: <vicc.74...@extro.ucc.su.OZ.AU> <1993Aug28....@qiclab.scn.rain.com> <1993Sep3.1...@objy.com> <OLE.93Se...@delab.sintef.no> <CDAwo...@bony1.bony.com> <OLE.93Se...@delab.sintef.no>
Date: Wed, 15 Sep 1993 07:27:51 GMT
Lines: 76
o...@delab.sintef.no (Ole-Hjalmar Kristensen) writes:
>In article <CDAwo...@bony1.bony.com> ric...@bony1.bony.com (Richard Bielak) writes:
> In article <OLE.93Se...@delab.sintef.no> o...@delab.sintef.no (Ole-Hjalmar Kristensen) writes:
> [...]
> >
> >If you take concrete implementations of RDBS's and OODBMS's, it is not
> >difficult to find problems which are conveniently expressed in one and
> >not in the other. (or which cannot be conveniently expressed in any of
> >them :-)
> >
> I disagree.
> You can express anything in OODB that you can in RDBMS. Simply start
> by creating an class TABLE with operation "join" :-).
>I think you will find that this is not so trivial, and remember, you
>have to define the other relational operators as well. Besides, that
>is cheating, because you are not expressing your problem directly in
>your OODB any more, but in a relational form :-)
wrong. set operations are especially trivial. you keep forgeting OO is
a superset of relational.
It is obvious that you have never actually tried to implement a
general set of relational operators.
Which definition of the "OO model" are you talking about when you
claim it is a superset of the relational model? Is there any
implementations which qualify? Maybe Postgres, OpenODB or O2 would,
but other implementations remind me more of a CODASYL network DBMS
with its hardwired access paths.
<stuff deleted>
--
----------------------------------------------------------------------
Vic Cinc, Krell Labs pty ltd internet: vi...@extro.ucc.su.oz.au
smail: GPO Box 1660 Sydney NSW 2001
Michele Sherry
->In article <1993Sep13....@aber.ac.uk> p...@decb.aber.ac.uk (Piercarlo Antonio Grandi) writes:
->
-> Just about the only, and big, problem of the relational model is that
-> the vast majority of current commercial implementations is appallingly
-> badly designed (as Stonebraker implied long ago, a remark that still
-> holds true).
->
->I would be very interested in knowing your opinion about how this came
->to be. After all, relational database systems have been around for
->(depending on how you could, but at the very least) 12 years now.
->There is a big and very competitive market for these products. There
->is a tremendous amount of literature available. There are very smart
->people at Oracle, Ingres, Sybase, IBM Almaden, and IBM Santa Theresa
->(among others) working on making good relational database system
->products. And yet, you say, just about all of them are appallingly
->badly designed. You say that in theory, relational database systems
->could be much better than they are. But if that hasn't happened yet,
->with all those people and all that competition over all this time, do
->you expect it to happen in the next ten years? Or is it that
->something else is really going on here?
There's an easy answer to this question:
The "very smart people" who create the server software do not come bundled
with the software they sell. Designing the RDBMS software != implementing
it and using it on site for an application.
I also have seen an unbelievable number of poorly designed databases in
commercial settings. There's at least two reasons for this:
- Few MIS managers realize that database analysis/design/implementation
actually takes some expertise, and that it's not a part-time
job for a single person.
This may seem obvious to you, but there are HUGE development
projects now underway that have decided they need only a
parttime body to handle this task. (I was interviewed by
someone who was supposedly the technical guru on one of these
projects, and he was absolutely flabbergasted that database
design, referential integrity coding, db systems administration,
etc, etc, could possibly be more than 20 person hours a week.)
Also, the mentality is that developing a large mission-critical
system is really just like developing a single-user PC system,
"only bigger". You might be amazed at how often I've seen
"kids" (showing my age here ;->) just out of school, with a
little FoxPro or Dbase III experience handed the job of designing,
tuning, and administrating a large-scale system. They have
little understanding of how to write queries, and tend to
build big "flat file" databases -- "Hey, if I just have one
big table, I never have to do one of those icky joins!!"
- The relatively small amount of effort required up front to
produce and implement a design that will be extremely flexible
yet yield high performance, almost always is seen as too
costly and time-consuming by management. No matter how many
juicy horror stories management is told about the extreme
maintenance nightmares to be encountered down the road, the
short-term cost-cutting (and this year's bonus) is chosen above
long-term benefits.
The result is major long term costs -- not just in
programmer/DBA time, but in _opportunity_ costs --
I've seen business opportunies slip away from companies because
they could not adjust their kludgy system clunkers fast enough
to take advantage of market changes. Few companies recognize that
lost business, because most companies run on pre-war momentum.
It's only recently with the reengineering craze that companies
are beginning to address these issues -- tho most are really
just cutting headcount, rather than reassessing their whole
approach to doing business.
Those of us working in the business arena sometimes fantasize about
working in the rarefied air of a technology vendor or a university
setting, where, in theory(!!), only the best techniques are used, and
politics/self-interest/ignorance do not rule. It might be nice to
be blissfully unaware of these real world constraints I described.
It's sometimes frustrating (not to mention appalling) to see how systems
are really being implemented out here -- on the other hand, the market
for folks equipped to come in and clean up the mess is very lucrative!
Sorry to grab the OODB airwaves for this diatribe, but dollars to
doughnuts, when more OODB systems get established in large traditional
business systems, they'll have all the same headaches, for all of the
above non-technical reasons.
:m
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Michele Sherry | email: ms...@panix.com
KaleidaTech Associates, Inc. | Disclmr: just me, nothing but me
Huntington Station, NY 11746 | Them special effects is FANtastic!
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Dennis Allard
>... [OO programming] is a *methodology* derived from a
>history which includes Simula, Algebraic datatype specifications,
>and the English school of structured programming...
I meant to say the European school of structured programming.
Dennis Allard
d...@netcom.com
Dan Weinreb
There's an easy answer to this question:
The "very smart people" who create the server software do not come bundled
with the software they sell. Designing the RDBMS software != implementing
it and using it on site for an application.
But he said that the "implementations" were badly designed. It
certainly seemed to me that he was talking about the RDBMS software
itself, rather than particular databases at particular sites.
(Otherwise the comment would have been a non sequitur.) So I
don't disagree with what you're saying, but you're discussing a
different topic.
Phil Hystad
>ki...@cs.sunysb.edu (Michael Kifer) writes:
>>Vic Cinc (vi...@extro.ucc.su.OZ.AU) wrote:
>>: there is no place in the currnet universe for any RDB, sorry, but these
>>: thing need to be extinguished, and relagated to a museum.
>>This is childish. But also much of the discussion in this thread is
>>redundant, if not silly.
>>Some problems are more amenable to relational representation, and some are
>>better off with the object-oriented data model. What you need is both, and
>>there is no reason not to have it. The two data models are compatible, as I
>>mentioned in my previous posting. This idea is slowly getting through to
>>the industry level. As one example, the object-oriented SQL extension of
>>UniSQL, Inc. is upward compatible with relational SQL in a very clean
>>fashion.
>>That is to say that even a language as bad as SQL does not prevent clean
>>integration of the two models.
>hmm... may be would should still be riding horses too.
Actually, many people still ride horses, don't they. Even though there
is far superior transport vehicle, horses still have value. Many times
for enjoyment but sometimes out of necessity...after all, most vehicles that
use wheels need roads of some sort...horses don't!!
>Object SQL is an
>abortion, suffering the worst features of SQL and few of the strength
>of native OODB interfaces. OO is a paradigm shift, relational is dead.
>OO totaly superset relational, there is no point wasting new projects
>on this old stuff. move on for christ sakes.
I have been involved in the design and implementation of systems that benefit
from both relational and object-oriented technology for some time. Although
I like OO better in many ways, I still recommend relational for a number of
applications since the model fits very nicely and it is often a cheaper
solution. Today, most OODBMS implementations require code to be written,
but many RDBMS solutions can be written without writing code.
Thus, if the solution fits, use it.
phil
=============================================================================
p...@esca.com || 206-822-6800 || 206-889-1809 x2023 (voice mail)
=============================================================================
Andrew Fullford
in the database from the applications that use it. It seems that
this is the anathema of OODMS which attempt to provide OO
languages with "persistence" that is almost transparently
available.
We run some fairly large databases in Ingres. An individual
database will be in the 1 to 6 GB region. We've found that the
separation of data and applications is quite crucial when dealing
with these sizes. Our schema goes through a state of rapid
change during the design phase of a major release, and then
steady, continuous modification during its production lifetime.
As a major release is put into production, there is phase where
existing data is restructured into the new schema. During the
production period, several minor changes will take place that
cause more localized data restructuring.
The changes are driven by several forces, including requirements
for new features, the need to overcome performance problems, the
need the support a different DBMS feature set, and so on.
It would be almost inconceivable to coordinate a release that
involved the complete restructuring of all data simultaneously
and also completely changed every application at every site.
In our relational environment we can phase such updates: this
does not appear to be the case in the OODMS world. I believe that
this provides some strong justification for the relational
orientation that attempts to separate data and applications.
There are others.
We have moved from one DBMS vendor to another within a version
release (twice). The OODMSs we have examined appear to be
inexorably intertwined with the applications (there being nothing
like a standard query language, as opposed to SQL, which is
something like a standard query language). As I give the "open
systems" movement some credence, I prefer to avoid such
dependency.
We also suffer from a common ailment - dirty data. Typically,
this is poorly controlled data that derives from a legacy system
which often uses some special purpose database of dubious
ancestry. In a relational environment, it is convenient to load
this data into a schema that approximates the legacy system and
then go through a cleaning session using the tools readily at
hand (even SQL) to integrate the data into the primary schema.
This is possible, in part, because the data and the applications
are not tightly coupled.
We are looking closing at OODMS and relational/OO hybrids. OO
has obvious advantages in data structuring, information hiding,
and possibly performance.
So I wonder, how can my concerns be reconciled? Has anybody
implemented a moderate to large system in an OODMS? How do you
manage schema revisions? Has anybody migrated their application
base from one OODMS vendor to another?
I asked (nearly) these questions a couple of weeks ago in
comp.databases.theory and only received a few "tell me what you
find out" mail messages. Maybe the wider, more vocal audience
here will produce some responses!
--
Andrew Fullford a.out computer consultants
a...@august.com +1 214 202 3344
Shneor Sherman
maintained a DB2 database with over 37 million records whose sole purpose was
ad-hoc queries. Was it worth it? I could provide data within an hour, often just5 minutes, at half the cost or less of alternative methods. At the time, it
took wriing an sql statement, not always a trivial exercise. Today, you can
point-and-click to an ad-hoc query, and build a library of those. nformation needs are different in different environments.
Shneor Sherman
Geoff Miller
vi...@extro.ucc.su.OZ.AU (Vic Cinc) writes:
>g...@sserve.cc.adfa.oz.au (Geoff Miller) writes:
>>vi...@extro.ucc.su.OZ.AU (Vic Cinc) writes:
>>>g...@sserve.cc.adfa.oz.au (Geoff Miller) writes:
>>>>users will always come up with _some_ problem which requires an ad-hoc
>>>>query.
>>>and what are you going to do teach them SQL?
>>What do you propose to do--ignore the problem?
>no, you provide facilities to manipulate data in the application,
>as apart of the application.
If that is the most efficient solution, sure. What if it isn't?
What if the most efficient and timely solution is some basic training
in the query language, be it SQL or something else? Let me repeat,
I'm not advocating this as a solution for _all_ users, I am suggesting
that it remains a viable option for meeting the needs of some users.
>>In my experience the
>>majority of users are satisfied with the applications, in which
>>they have access to some fairly flexible but basically pre-defined
>>reporting options.
>>There are always a few "power" users who have
>>to use the query language to get what they want. If I worked with
>>an RDBMS, then yes, I would teach them SQL--fortunately, I work
>>with something rather easier for them to use:-)
>I certainly wouldnt teach anyone SQL, nor would I let loose
>users directly on a database.
Ultimately it is not up to you, as the application developer, to
decide anything of the sort. It is their data. This is the old-
fashioned mainframe-style attitude, "I'm going to tell the users
what they can do". For the user doing routine work, I agree--
all I am suggesting is that there is, for almost any application,
a class (which may only have one member) of user who need an
ad-hoc query facility. Accepting this is not a slight on your
(or my) skills as an application developer. Once you accept that
this class of user exists, then you have to consider how best to
satisfy its requirements. The best solution in your environment
may not be the best in mine.
>You are probably confusing canned reporting features with applications
>that can dynamically create subsets of objects based on arbitrary
>criteria, and do this recursively. just spiting out reports isnt often
>very usefull. You usually want to apply the end result of your qery
>back through the original application to get some magic number
>or a graph. Query in themselves are only as usefull as where you can funnel
>the end result, staring at pages of output is rarely a usefull
>end result.
Thank you for the lesson, but I wasn't confusing anything of the
sort. Some users require detailed reports, others summaries at
varying levels of detail or aggregation and presented in varying
ways. However, you seem to be concentrating solely on queries
which address a progressively smaller subset of the data, and the
problems which I quite often face are best handled by operating on
several subsets simultaneously, creating and combining several
sets of data based on different criteria. This is easily and
efficiently handled within the query language--trying to do this
within the application is not (IMHO) worth the effort. Why
reinvent the wheel?
OK, with 20/20 hindsight some of these problems could be addressed
with a different data structure, but you can never predict everything
the users are going to want to do with the data--and although the OODBMS
products are less confining than the so-called RDBMSs, these problems
will always be with us to some extent.
Geoff (g-mi...@adfa.edu.au)
Geoff Miller
>In article <1993Sep14.2...@sserve.cc.adfa.oz.au> Geoff Miller,
>g...@sserve.cc.adfa.oz.au writes:
>>The kind of situation I'm thinking about is what occurs in our
>>student administration. The people who handle the routine work
>>operate happily within the application, but a couple of the more
>>senior users occasionally need to use the query language when
>>an odd-ball query ('How many navy cadets coming from Canowindra
>>are studying economics and play hockey') comes down the line.
>They'd use a product with a GUI that lets them assemble a query
>without recourse to SQL. We have secretary types here who have learned
>to this; it's a user-interface issue, and should be handled the same
>way regardless of the underlying data model and language.
Putting aside the gratuitous slur on the abilities of the "secretary
types", the systems of this type that I have seen are good as far
as they go, but to use them effectively you still need a reasonable
understanding of the principles of the query if not the detailed
semantics of SQL or whatever. IMHO, the ones I have seen (and I
emphasise that qualification) are a partial rather than a complete
solution--but I'm eager to be convinced that I'm wrong:-)
Geoff (g-mi...@adfa.edu.au)
Piercarlo Antonio Grandi
Piercarlo Antonio Grandi (p...@decb.aber.ac.uk) wrote:
: On 10 Sep 1993 01:31:21 GMT, Michael Kifer (ki...@cs.sunysb.edu) wrote:
: Some problems are more amenable to relational representation, and some
: are better off with the object-oriented data model.
: Unfortunately there is no such thing as an OO data model. There is a
: thing called a network data model, and a thing called typing/subtyping,
: and that's it.
Are you referring to data models found in undergrad textbooks, or your
statement is about recent research? There is probably no *single*
object-oriented data model, but most of the proposed ones agree on their
major components. Have you been following major database publications?
OK, instead of questioning whether I have followed major database
publications, would you please care to teach me as to what is in those models
that is not network+classes/inheritance/methods? I am very curious. So far,
no doubt because of my inherent dumbness, I have not found any author
that managed to enlighten me. Come on, it's your chance for fame and
glory, you have the soapbox.
: What you need is both, and there is no reason not to have it.
: If by *both* you mean adding classes/inheritance/methods to a relational
: model DBMS, perhaps one could reluctantly agree, even if I think that is
: essentially redundant and betrays the spirit of a relational DBMS.
"Both" means that sometimes it is convenient to represent data as relations
and sometimes as objects. What you need is to be able to represent part of
the data using relations and part using objects.
I would strongly disagree with *need*. Surely in a purely data oriented,
extensional sort of model like the relational one can represent the very
same information as tables in a data dictionary, and be the happier
for it. Or are you arguing that it *impossible* or even highly
inconvenient to represent such information in a relational data dictionary?
Piercarlo Antonio Grandi
In article <1993Sep13....@aber.ac.uk> p...@decb.aber.ac.uk (Piercarlo Antonio Grandi) writes:
However let me insist, with dozens of academic writers, that there is no
constest that the network data model on which most OODBs are based is
definitely inferior to the relational one, and for all the well known
reasons.
I am not sure what you mean when you say "the" network data model.
Chris Date's Introduction to Database Systems presents what I have
always thought of as "the" network model; I know of no OODBMS based on
it.
Well, he presents the *CODASYL* network model.
Perhaps you mean "the network model" in a much broader sense?
In almost the same, admittedly extended, sense used in "Database design"
by Wiederhold.
Just about the only, and big, problem of the relational model is that
the vast majority of current commercial implementations is appallingly
badly designed (as Stonebraker implied long ago, a remark that still
holds true).
I would be very interested in knowing your opinion about how this came
to be.
The poor quality of CS education in most Universities, and market realities
that reward poor quality products, as that funny guy from Lucid wrote so
amusingly.
After all, relational database systems have been around for
(depending on how you could, but at the very least) 12 years now.
There is a big and very competitive market for these products. There
is a tremendous amount of literature available. There are very smart
people at Oracle, Ingres, Sybase, IBM Almaden, and IBM Santa Theresa
(among others) working on making good relational database system
products.
Bah, that's what *you* say. I also observe that most current commercial
operating systems have linkers straight out of the fifties, and that
to accomodate them C++ had to be kludged, there are (very few) smart people
at USL, DEC, IBM, ..., a very competitive market for OSes, and yet we are
still stuck with linkers out of the fifties. I also observe that the best
selling OS of all time is DOS/Windows3. Do I need say any more?
And yet, you say, just about all of them are appallingly badly
designed. You say that in theory, relational database systems could
be much better than they are. But if that hasn't happened yet, with
all those people and all that competition over all this time, do you
expect it to happen in the next ten years?
Stated bluntly, I don't. But this does not seem to me reason to throw away
the baby with the water... Perhaps educating users to what they should demand,
such as appropriate clustering facilities in the physical schema, will
make my negative expextation false.
Or is it that something else is really going on here?
Bah, at times, but don't quote me on this, I think that DBMSes are not sold
on the fundamentals, but on how snazzy their form generator is and
similar niceties. Then people discover, when they cannot cluster tuples
along joing columns, that relational DBMSes are slow. Ha! Then they discover
that lin-based DBMSes do automagically cluster onto the hard-wired access
paths, and then they rejoice. Ha! And then they discover that hard-wired
access paths are not as wonderful as they seemes, given that data bases
have to be maintained over time. Ha! And then they discover that having the
data and description of the data in two rather different domains is not so
cool either. Ha! :-)
Thomas J Lohman
>Bah, that's what *you* say. I also observe that most current commercial
>operating systems have linkers straight out of the fifties, and that
>to accomodate them C++ had to be kludged, there are (very few) smart people
>at USL, DEC, IBM, ..., a very competitive market for OSes, and yet we are
>still stuck with linkers out of the fifties. I also observe that the best
>selling OS of all time is DOS/Windows3. Do I need say any more?
You're saying, because linkers come out of the fifties, that there are
very few smart people at DEC, IBM, USL, etc, etc? Fascinating...
Why don't you market your own OS or RDMS? You should be able
to corner the market...:-)
--tom
--
Thomas Lohman - Research Specialist
MIT Building 36 - Room 297
Cambridge, MA. 02139
e-mail: tho...@mtl.mit.edu, Phone: 617-258-6485
Mark Day
RDMS proponents have always pushed the idea of decoupling data
in the database from the applications that use it. It seems that
this is the anathema of OODMS which attempt to provide OO
languages with "persistence" that is almost transparently
available.
Hmm. I see two goals:
Independence: The data should stand on their own, rather than being tangled
up with the specifics of one particular application, so that
it's easy to develop other applications.
Transparency: The data should be accessible from the application in a
straightforward and transparent way.
I don't see any necessary contradiction between these goals.
The mismatch between typical application languages and a relational
data model makes it easier to ensure that you have Independence, but
at the expense of Transparency.
I can see a danger that a system with good Transparency might make it
easier for programmers to violate Independence, but I think that it's
hardly a certainty.
I would think that a model of encapsulated objects ought to do roughly
as well as the relational model at ensuring that the data are
independent of the particular applications using that data.
--Mark Day
Thomas J Lohman
>
>Hmm. I see two goals:
>
>Independence: The data should stand on their own, rather than being tangled
> up with the specifics of one particular application, so that
> it's easy to develop other applications.
>
>Transparency: The data should be accessible from the application in a
> straightforward and transparent way.
Perhaps what was meant Mark was the need to decouple the data from any
particular representation which may be application specific. When you
create a class, you may perceive the attributes differently then someone
else may. If your underlying storage system is forced to model the class
according to your view then another application may have a hard time using it.
I believe some research work has been done in this area through the use of
views upon relational systems. I read a paper a while back (Penguin perhaps?)
but can't recall for sure. Perhaps someone can supply the information.
Dan Weinreb
However let me insist, with dozens of academic writers, that there is no
constest that the network data model on which most OODBs are based is
definitely inferior to the relational one, and for all the well known
reasons.
In almost the same, admittedly extended, sense used in "Database design"
by Wiederhold.
Wiederhold presents a very loose definition at the beginning of this
chapter, which, as far as I can tell, defines a "network" database to
be one that has pointers in it. (Most of the rest of his chapter is
spent on CODASYL specifically.) I'd hardly call that a "data model",
though. Widerhold doesn't call it one.
Well, if you're saying that the preponderance of academics who express
an opinion on data models are advocates of the relational data model,
I would not dispute that. (Just the same, I would not dispute that
there are a lot more relational databases in the world than OO
databases.)
Just about the only, and big, problem of the relational model is that
the vast majority of current commercial implementations is appallingly
badly designed (as Stonebraker implied long ago, a remark that still
holds true).
I would be very interested in knowing your opinion about how this came
to be.
The poor quality of CS education in most Universities,
(Taught by the same academics who you invoked earlier to support your point!)
and market realities
that reward poor quality products, as that funny guy from Lucid wrote so
amusingly.
(Richard Gabriel. In an essay based on an anecdote he heard from me,
in case you like small-world phenomena.)
Bah, that's what *you* say.
OK, so you claim that relational databases could do all these great
things, but in practice none of these abilities emerge in commercial
products. (You don't really say why; you just imply "oh, there's junk
everywhere" without going into the reasons for it. But so be it.) So
your points are all points about theory, and they are of extremely
limited use to anyone who is attempting to buy a product in order to
get a job done.
Perhaps educating users to what they should demand,
such as appropriate clustering facilities in the physical schema, will
make my negative expextation false.
Or at least not relevant to anyone trying to get a job done in the
next couple of years, then.
I agree that a lot of the discussions on this list have been somewhat
confused about differences in data models versus differences in
implementation characteristics. In the current set of commercially
available products, there are quite a lot of differences between the
RDBMS products and the OODBMS products, and only some of them have to
do with "data model" per se. If one is not careful to separate the
different issues, the conversation can get confused.
Vic Cinc
>vi...@extro.ucc.su.OZ.AU (Vic Cinc) writes:
>>dra...@netcom.com (Donald Ravey) writes:
>>>Vic Cinc (vi...@extro.ucc.su.OZ.AU) wrote:
>>>: there is no place in the currnet universe for any RDB, sorry...
>>>Is this person serious? What naivete. But, then, I've seen this impulsive
>>>attitude many times in students...
>>I am deadly serious I have used these crappy relational things for near
>>8 years now, and having recently used an OODB, I am not going back.
>>Its called evolution, maybe you should pay attention to it before you get
>>left behind and become a fossil.
>>vic
>What size applications have you developped?
from small 1 end user to commercial products.
>How many mega/giga bytes of data?
from a few megs, to hundreds of megs. (huge airline central db)
>How many updates/accesses/searches per second/minute/week/month?
one table had 20,000 rows added per day.
no idea, wasnt involved with optimisation much.
>How many fields/relations/objects/functional relationships/... were
> in the data model, using any model of your choice?
not going to count them since I dont have access anymore.
whats the point?
>Dennis Allard
>d...@netcom.com
vic
Vic Cinc
>vi...@extro.ucc.su.OZ.AU (Vic Cinc) writes:
>>the relational model fails to deal with simple data structures
>>like trees and graphs.
>But Vic, neither does the OO 'model'. In both cases, the programmer
>must use provided primitives to write code which provides the
>semantics of whatever tree or graph structure is being modelled.
>In the case of C++ you write some classes and give them some
>attributes which define a tree, based upon code which you also
>write. You stuff everything into a library, hope its relatively
>reusable, and call it a model if you're stubborn. The very same
>thing goes for RDB systems such as Ingres or Sybase. You define
>a binary relation which maps nodes to nodes and make use of
>recursion mechanisms (in the case of Ingres) to provide
>search operations, etc. Ditto, you have modelled a tree.
>In neither case was a tree part of the language.
my point remains, its near as damn impossible
to pick a random RDB and implement trees or graphs.
whereas its 'doable' with the same ease in any OODB.
>Besides, vic, you continue to miss a crucial point. The OO 'paradigm'
>as you correctly refer to it, is a *methodology* derived from a
there are various design methodologies based on the OO paradigm,
just trek along to your nearest computer bookshop. OO doesnt
specify any design or analysis methodologies, its a language
paradigm. In particular it includes strong encapsulation of data
and code through classes, specialisation of that encapsulation
via inheritence, etc. OO design methodologies provide guidelines
for the design and relationships between these classes.
>history which includes Simula, Algebraic datatype specifications,
>and the English school of structured programming. It is a
>*methodology*, not a model. In recent years, some people have
>incorporated parts of this methodology directly into programming
>languages, giving the allure of a model. But only in the sense
>that any given programming language defines a de facto data model.
as a data model Object Orientation isnt ideal, but its an improvement
over the relational data model. personally I favour semantic modeling
via neural nets. which by the way are much easier to implement on top
of an OODB.
>It could still be argued that this methodology belongs more to
>a programming environment than to the language, but that is
>a personal opinion which I do not wish to debate here.
>>this alone precludes it [the relational model] from dealing with
>>a large class of problems.
>It is true that the relational model imposes limitations upon the
>programmer. But they are limitaitons of convenience, not of
>possiblity. In return, for the large class of problems for which
>the model is a good fit, you obtain faster implementation time
>and improved maintainability, modifiability, and clarity of
>specification.
simple point: I as a programmer get paid by the hour, what increases
conveniance is therefor good. what I dont have to write is
money saved. You could use your same argument to justify programming in
assembler. Its precicely this extra level of convenience that make
OO and OODBs worthwhile.
The added level provides extremely important functionality
the most interesting of which is the ability to store pointers
in the database without obscure and twisted pointer/key translations.
In the current code I am working on (which was written nearly 2 years ago),
this accounts for 25% of the system. Having had used an OODB the saving in
man/dollars per year would have more then paid for the cost of having bought
the OODB. The cost of The RDB this code uses could have bought 2 or 3 OODBs.
total saving would have been 3 man months and about AUD50K
I certainly dont believe that relational design improves maintainability,
modifiability or clarity of specifications. One of the strengths of
OO paradigm is maintainability anf modifiability.
This is a well documented trait. This comes from extend code reuse
and code specialisation.
>I am not, in any way, defending RDBMS technology, which I
>dub 'legacy technology'. However, I do defend what *is* good
>about it and defend it from spurious criticism such as yours.
>>As has been pointed out many times the OO
>>paradign is a super set of the relational model.
>Now you are threading on thin ice.
>>Its a bit like quantum theory replacing Newtownian dynamics...
>Absurd analogy.
not at all.
over the last year I have written over 20,000 lines of C++,
the previous RDB system I worked on had over 100,000 lines of SQL/4GL
but had not half the functionality of the 20,000 of C++.
Its a quantum leap in expressability and productivity.
The relational model is a data model and leaves out very important
guidelines (for lack of a better word) for the rest of an application
or program. ie the code. As such languages bases on the relational
data model then to be sadly lacking in terms of expressability
and downright programming grunt and power. witness SQL as the
result of 10 years of dedicated research into this dead end path.
witness the abortive attempts at 4GLs that adorn all commercial RDBMs.
I feel I am being extremely kind towards the relational model.
Vic Cinc
>In article <vicc.74...@extro.ucc.su.OZ.AU> vi...@extro.ucc.su.OZ.AU (Vic Cinc) writes:
> o...@delab.sintef.no (Ole-Hjalmar Kristensen) writes:
> >In article <CDAwo...@bony1.bony.com> ric...@bony1.bony.com (Richard Bielak) writes:
> > In article <OLE.93Se...@delab.sintef.no> o...@delab.sintef.no (Ole-Hjalmar Kristensen) writes:
> > [...]
> > >
> > >If you take concrete implementations of RDBS's and OODBMS's, it is not
> > >difficult to find problems which are conveniently expressed in one and
> > >not in the other. (or which cannot be conveniently expressed in any of
> > >them :-)
> > >
> > I disagree.
> > You can express anything in OODB that you can in RDBMS. Simply start
> > by creating an class TABLE with operation "join" :-).
> >I think you will find that this is not so trivial, and remember, you
> >have to define the other relational operators as well. Besides, that
> >is cheating, because you are not expressing your problem directly in
> >your OODB any more, but in a relational form :-)
> wrong. set operations are especially trivial. you keep forgeting OO is
> a superset of relational.
>It is obvious that you have never actually tried to implement a
>general set of relational operators.
how hard is to implement, union, intersection, product and cross product?
If you are talking about relational operators based on reflectivity,
well again I could that. the hard part is optimisation and distribution.
>Which definition of the "OO model" are you talking about when you
>claim it is a superset of the relational model? Is there any
>implementations which qualify? Maybe Postgres, OpenODB or O2 would,
>but other implementations remind me more of a CODASYL network DBMS
>with its hardwired access paths.
postgres certainly does, point proven, OO is a superset of relational.
pay attention:
the simplest way to imitate a relational system in an OODB is to think
of a table as a class and create persistant class extentent containers with
the constructor methods adding instances to the containers. So each table
you require would have a matching class in the OODB. each table class would
be a sub class of a 'set' container class to which you would provide the usual
set operations: interstion, union etc. You have to add a n-way
join method to the set class. this is just a loop through a list of tables
classes. one of the parameters to the join method is passed a
criteria matching method.
presto the table classes can now be queried just like real 'tables'.
The container class could even be generic 'set' with
a runtime implementation policy of hash, btree, isam etc.
optimising the join method is left as an exercise for the reader.
Dependending on how your OODB provides reflectivity or access to its schema,
you could even then generalise and write a simple parser to imitate SQL
without much sweat being raised. :)
you could replace the hard coded matching method with a recursive dynamic query
class, and pass an instance of the query object to the join method.
you could even add a list of 'linked' containers to the original set class
to simulate indicies and access paths.
then the real fun could begin, you might alter the behaviour by subclassing
to try variations on the theme of data modeling, and invent totaly new
modeling madness. you might add shortcuts like a concatention operator
to your set class, to paste two tables together. or add iterators
on your containers to see if this helps you optimise your join method....
is any light begining to seep through yet?
vic
Vic Cinc
>In article <vicc.74...@extro.ucc.su.OZ.AU>, vi...@extro.ucc.su.OZ.AU
>(Vic Cinc) wrote:
>[Stuff Deleted]
>> you overlook one small problem of semantics, the language defines what you
>> can express and at what expense. language like C and C++ kill COBOL
>> everytime. It hardly the equivalent of comparing Zulu to Gaelic.
>> Eskimos have over 20 words to descrbie snow, each language has a strength,
>> which is why you dont see state of the art software written in COBOL unless
>> there are no options. Its not an aristocratic outlook, you arnt likely
>> to take a model T out on the formula 1 track are you, certainly not with
>> any serious intent of winning.
>>
>> vic
>> --
>> ----------------------------------------------------------------------
>> Vic Cinc, Krell Labs pty ltd internet: vi...@extro.ucc.su.oz.au
>> smail: GPO Box 1660 Sydney NSW 2001
>This is true and not true. After all, I did say "These languages were
>built to answer certain needs" which is the same as saying "the language
>defines what you can express and at what expense." C, and especially C++,
>were never intended to be used as database languages yet that is what they
>are now being used for (as well as a wealth of other things). I have
>nothing against C (we use it extensively here). C++ though is even more
>confusing to people than C (if that is possible). And you do have to
>admit that COBOL, with it's straight forwards, unambiguous language, is
>a lot easier to read than a C program.
>The thing about comparing languages such as Zulu or Gaelic to each other
>is simply to stress that doing so is the same as doing so to C versus
>COBOL versus RDBMS. The Romans thought that everyone who did not speak
>Latin (and who were not a part of the Roman empire) were barbarians. When
>in truth - it is just that they did not speak the same language and did
>not have the same outlook. So it is when you start speaking about CP/M,
>MS-DOS, ProDOS, Unix, or any other operating system. People become locked
>into their own outlook at the world. Anyone who doesn't conform to their
>outlook are barbarians. Some of these people feel it is their god given
>right to force others to believe as they do. I don't. I believe every
>thing has it's part to give and that that is how people should look at
>things.
I agree with all of that. A question I do have, since SQL is god-awfull
and C++ makes a poor database language, what is left?
I feel technology is letting us down here, I feel that we need new
ways for computers to intereact with users. things like the apple newton
being able to read handwriting are a good start. A true DB should be able
to understand plain english, or whatever your native language may be.
Vic Cinc
btw, what was that 'something easier'?
>>I certainly wouldnt teach anyone SQL, nor would I let loose
>>users directly on a database.
[stuff deleted]
>>You are probably confusing canned reporting features with applications
>>that can dynamically create subsets of objects based on arbitrary
>>criteria, and do this recursively. just spiting out reports isnt often
>>very usefull. You usually want to apply the end result of your qery
>>back through the original application to get some magic number
>>or a graph. Query in themselves are only as usefull as where you can funnel
>>the end result, staring at pages of output is rarely a usefull
>>end result.
>Thank you for the lesson, but I wasn't confusing anything of the
>sort. Some users require detailed reports, others summaries at
>varying levels of detail or aggregation and presented in varying
>ways. However, you seem to be concentrating solely on queries
>which address a progressively smaller subset of the data, and the
true, one of my fundamental programing phylosophies is to minimise
paper reports, and make the users think about why they need these reports,
and how they use them. and where ever possible shortcut the data
directly into another application.
ideally I try to make anything more then 1 page (unless required by law)
disapear. this is why my applications are geared towards narrowing and
redirecting user information.
>problems which I quite often face are best handled by operating on
>several subsets simultaneously, creating and combining several
>sets of data based on different criteria. This is easily and
>efficiently handled within the query language--trying to do this
>within the application is not (IMHO) worth the effort. Why
>reinvent the wheel?
I guess here we differ, I beleive self querying applications to
be worth the extra effort. especially since my current boss (a money market
dealer), is a power user, not only does he understand SQL, he is learning
to program in C and C++ (shuder). I know only too well what its like cleaning
up after self educated power users.
>OK, with 20/20 hindsight some of these problems could be addressed
>with a different data structure, but you can never predict everything
>the users are going to want to do with the data--and although the OODBMS
>products are less confining than the so-called RDBMSs, these problems
>will always be with us to some extent.
true.
P. Gainer
>d...@netcom.com (Dennis Allard) writes:
>>What size applications have you developped?
>
>from small 1 end user to commercial products.
>
>>How many mega/giga bytes of data?
>
>from a few megs, to hundreds of megs. (huge airline central db)
Just a point of clarification. A relational database "hundreds of megs"
in size would be considered by relational engines to be verging on
trivially small. A large relational database (today) would be hundreds
of gigs.
Pat Gainer
gai...@almaden.ibm.com
Terry Poot
In article <akf.748138056@awful>, a...@awful.august.com (Andrew Fullford)
writes:
>RDMS proponents have always pushed the idea of decoupling data
>in the database from the applications that use it. It seems that
>this is the anathema of OODMS which attempt to provide OO
>languages with "persistence" that is almost transparently
>available.
But the point of OO is that you take a data-centric view of the
application domain, as the data is much more constant over time than the
applications that use it. From what I've been reading, this is a
constant underlying theme of OO, and it seems to be exactly what you are
talking about.
>We run some fairly large databases in Ingres. An individual
>database will be in the 1 to 6 GB region. We've found that the
>separation of data and applications is quite crucial when dealing
>with these sizes. Our schema goes through a state of rapid
>change during the design phase of a major release, and then
>steady, continuous modification during its production lifetime.
>As a major release is put into production, there is phase where
>existing data is restructured into the new schema. During the
>production period, several minor changes will take place that
>cause more localized data restructuring.
It sounds, then, like your data is highly dependent on the application,
if your data restructuring is tied to application releases rather than
changes in your business. I know in my software, (I use an RDBMS) the
schema is determined by my application requirements, because all my real
data is in BLOBS. Everything not in a BLOB is there because I need to
drive queries from it, and it is a duplicate of some data item within
the blob in the same row. And of course, there are all the numerous
mapping relations to tie all my real data together. (Relational is just
a lousy fit to my applications. My data is all tree structured, and some
of the structures are recursive. We're seriously looking into OODBs.)
>The changes are driven by several forces, including requirements
>for new features, the need to overcome performance problems, the
>need the support a different DBMS feature set, and so on.
>
>It would be almost inconceivable to coordinate a release that
>involved the complete restructuring of all data simultaneously
>and also completely changed every application at every site.
Sounds a lot like what you describe yourself doing today.
>In our relational environment we can phase such updates: this
>does not appear to be the case in the OODMS world. I believe that
>this provides some strong justification for the relational
>orientation that attempts to separate data and applications.
I don't see how your arguments lead to your conclusions.
>We have moved from one DBMS vendor to another within a version
>release (twice). The OODMSs we have examined appear to be
>inexorably intertwined with the applications (there being nothing
>like a standard query language, as opposed to SQL, which is
>something like a standard query language). As I give the "open
>systems" movement some credence, I prefer to avoid such
>dependency.
It is a fact that standards aren't there, and won't be until the
technology is more mature and the dead end approaches die out. This is
typical. Standards generally follow market acceptance. I admit this does
trouble me as well. However, when the choice is between using a
non-standard technology well suited to what I'm doing, vs. a standard
technology that is very ill-suited, it becomes less of a clear-cut
issue. I'm paid to solve the user's problems, and if it comes to that,
I'm paid to rewrite the whole blasted thing later if we have to port.
I'm also paid to avoid doing that if it is avoidable, but in this case,
it isn't yet.
>We also suffer from a common ailment - dirty data. Typically,
>this is poorly controlled data that derives from a legacy system
>which often uses some special purpose database of dubious
>ancestry. In a relational environment, it is convenient to load
>this data into a schema that approximates the legacy system and
>then go through a cleaning session using the tools readily at
>hand (even SQL) to integrate the data into the primary schema.
>This is possible, in part, because the data and the applications
>are not tightly coupled.
Was the data from the legacy application tightly coupled to that
application? How does simply putting it in an RDB break the coupling? Or
by cleaning do you mean complete restructuring? Is the "improvement" you
are seeing due to the fact that you are using an RDB, or just because
you have very good data manipulation tools for your particular RDB?
>We are looking closing at OODMS and relational/OO hybrids. OO
>has obvious advantages in data structuring, information hiding,
>and possibly performance.
>
>So I wonder, how can my concerns be reconciled? Has anybody
>implemented a moderate to large system in an OODMS? How do you
>manage schema revisions?
Many OODB products seem to have very good facilities for schema
modification, and unlike RDBs that I've seen, in many cases they can be
done on-line on a running database.
>Has anybody migrated their application
>base from one OODMS vendor to another?
That would definitely seem to be a harder problem, due to the lack of
standards.
>I asked (nearly) these questions a couple of weeks ago in
>comp.databases.theory and only received a few "tell me what you
>find out" mail messages. Maybe the wider, more vocal audience
>here will produce some responses!
I don't use OODB yet, but I hope to. My understanding of these issues
differs from yours, but I'm no expert. However, if we get a little
debate going on some of these things, hopefully I'll learn a little
more. :-)
--
Terry Poot <t...@mccall.com> The McCall Pattern Company
(uucp: ...!rutgers!depot!mccall!tp) 615 McCall Road
(800)255-2762, in KS (913)776-4041 Manhattan, KS 66502, USA
Anthony L. Kimball
: Just a point of clarification. A relational database "hundreds of megs"
: in size would be considered by relational engines to be verging on
: trivially small. A large relational database (today) would be hundreds
: of gigs.
Some further observations appropriate to the thread:
The raw volume of the database is not representative of
the importance of the application to the enterprise,
the complexity of structure in the database,
the cost of the operations typically performed on the database, or
the cost or complexity of application development.
Relational databases in the terabyte ballpark are still rare, usually the
result of national or international transaction logging, and you'll probably
only see one if you work for a multinational or fortune 500 type corp,
a financial, or a telco. They pose peculiar problems which are in no way
representative of the majority of commercial-style database applications.
People still *buy* mainframes (or, increasingly, parallel supercomputers instead,
hence my interest) to accomodate the IO volume of massive queries on such beasts.
My question:
What's the biggest db anyone has actually run queries on?
I've heard (second hand, from a former telco employee) of a ~10TB tape db
owned by a telco, upon which simple queries were run for toll-fraud detection
purposes. This was all flat file data, with the query ops all hand-coded,
run on multiple mainframes -- in the days before parallel supers, striped
hippi, and RAID-5.
//a...@think.com, a...@msc.edu: Anthony L. Kimball, Thinking Machines Corp.
Disclaimer: My employer has database experts for this stuff, and I'm not one.
If you want an operational Thinking Machines viewpoint, I can put you in touch.
Stephen J Bevan
just trek along to your nearest computer bookshop. OO doesnt
specify any design or analysis methodologies, its a language
paradigm.
Does that mean you don't agree with people like Booch, Berard,
Coad&Youdon, Schlaer&Mellor, ... etc., who all have written
extensively about OOA and OOD and IMHO all seem to be talking about
the same thing?
In particular it includes strong encapsulation of data
and code through classes, specialisation of that encapsulation
via inheritence, etc.
Do you think OO includes the above? What about Ada9X, Beta, CLOS,
Modula III, Oberon(-2), Self and Smalltalk all of which fail one or
more of your criteria?
as a data model Object Orientation isnt ideal, but its an improvement
over the relational data model. personally I favour semantic modeling
via neural nets. which by the way are much easier to implement on top
of an OODB.
I was discussing the gratuitous use of "buzz-words" recently and noted
that thankfully I had yet to see "OO" and "neural net" being used
together. Ah well, it had to end sometime.
simple point: I as a programmer get paid by the hour, what increases
conveniance is therefor good. what I dont have to write is
money saved. You could use your same argument to justify programming in
assembler. Its precicely this extra level of convenience that make
OO and OODBs worthwhile.
The added level provides extremely important functionality
the most interesting of which is the ability to store pointers
in the database without obscure and twisted pointer/key translations.
Generalising your complaint, it seems to be that a relational database
doesn't match the language you want to write your application in
(C++). No argument from me, they don't seem well matched at all.
Your solution is to drop the RDB and use a C++ based OODB . My
preferred solution would be to drop C++ and look for a Deductive-DB
integrated with a decent logic based language. However, we can't
always have what we want :-<
One of the strengths of OO paradigm is maintainability anf modifiability.
This is a well documented trait. This comes from extend code reuse
and code specialisation.
Reuse is a good thing, but as Ed Berard notes "Software reusability is
a topic that is not well understood by the masses. For exampe, many
software reuseability discussions incorrectly limit the definition of
software to source code and object code. Even within the
object-oriented programming community, people seem to focus on the
inheritance mechanisms of various programming languages as a mechanism
for reuse. (...) Although reuse via inheritance is not be dismissed,
there are more powerful reuse mechanisms ... For example analysis and
design techniques have a very large impact on the reusability of
software -- *a greater impact, in fact, than programming (coding)
techniques*."
over the last year I have written over 20,000 lines of C++,
the previous RDB system I worked on had over 100,000 lines of SQL/4GL
but had not half the functionality of the 20,000 of C++.
Its a quantum leap in expressability and productivity.
Are you sure you want to use "quantum" in the above description?
Stephen J Bevan
database language, what is left?
If you mean what can you buy, then not much (though I'd be tempted to
try Eiffel instead of C++, but that is just tinkering). If you mean
what -might- be useable I'd like to think that deductive databases
(with a decent logic based language) will eventually "make it".
However, it has been 10 years and I'm still waiting (I'm optimist
though, I'm also waiting for functional languages to "make it" and
they've been around 30 years :-)
Stephen J Bevan
If you are talking about relational operators based on reflectivity,
well again I could that. the hard part is optimisation and distribution.
Ah, a master of understatement.
[ description of how to "immitate" a relational system in an OODB deleted]
You can "immitate" an OODB using one based on relations (the hard part
is making it efficient :-). Does that "prove" that it is a superset
of an OODB?
Geoff Miller
>true, one of my fundamental programing phylosophies is to minimise
>paper reports, and make the users think about why they need these reports,
>and how they use them. and where ever possible shortcut the data
>directly into another application.
>ideally I try to make anything more then 1 page (unless required by law)
>disapear. this is why my applications are geared towards narrowing and
>redirecting user information.
Yes, I think most of us do that, but my point was that in our current
environment some of the more complex queries are best handled not by
repeated narrowing but by generating and operating on several distinct
subsets to make efficient use of existing indexes. We are not always
working with a subset of the data extracted in the immediately
previous query. Obviously, this can be built into a generalised query
processor, but it's an added level of complexity and its use requires
a good understanding of both the structure of the particular database
and of the nature of the queries being used. By the time the users
have got to that level, they may as well be using the query language
anyway.
>>problems which I quite often face are best handled by operating on
>>several subsets simultaneously, creating and combining several
>>sets of data based on different criteria. This is easily and
>>efficiently handled within the query language--trying to do this
>>within the application is not (IMHO) worth the effort. Why
>>reinvent the wheel?
>I guess here we differ, I beleive self querying applications to
>be worth the extra effort. especially since my current boss (a money market
>dealer), is a power user, not only does he understand SQL, he is learning
>to program in C and C++ (shuder). I know only too well what its like cleaning
>up after self educated power users.
Perhaps it would be easier to train him how to use the system properly?
Geoff (g-mi...@adfa.edu.au)
James Mullens
From Newsgroups: comp.databases.theory,comp.databases.object,comp.databases
Subject: Re: Relational Myths (was Re: OODMS VS RDMS)
Date:
On Thu, 16 Sep 1993 13:39:23 GMT,Thu, p...@decb.aber.ac.uk (Piercarlo Antonio Grandi) wrote:
>OK, instead of questioning whether I have followed major database
>publications, would you please care to teach me as to what is in those models
>that is not network+classes/inheritance/methods? I am very curious. So far,
>no doubt because of my inherent dumbness, I have not found any author
>that managed to enlighten me. Come on, it's your chance for fame and
>glory, you have the soapbox.
OK let me try to answer that by developing a potted history of data
technology:
Generation 0 Flat files. Code must be written to do everything, maintain
all indexes and relationships.
Generation 1 Hierachichial Reduced coding effort due to automatic
maintenance of 1-N relationships, but
data redundancy required to represent N-M.
Code still required to keep redundant data
in sync.
Generation 2 Network Elimination of redundancy required in Hier.
to represent N-M relationships. This also
reduces lines of codes for a given function.
Code required to navigate data structure
Generation 3 Relational Eliminates code required to navigate data,
but there is a residual impedance mismatch
between the set basis of the data storage
model and the record basis of programming
languages.
Aids maintenance and support for evolving
requirements by removing hardwired links.
Also (via Codd's laws) provides a sound basis
for design. (This leads to emergence of a
high priesthood speaking a hypermathematical
language of every increasing obscurity, but's
that another story.)
Generation 4 Object Based Further reduces code required by eliminating
the impedence mismatch between data storage
and programming languages.
Links are hardwired a la Gen 3, but design
techniques are available that provide a sound
guide to development of models matching the
problem domain (unlike many Gen 3 designs which
were driven by performance considerations.)
In addition, the links are based in the
structure of the problem as expressed in the
programming language (unlike Gen 3 where links
were based on the on-disk data structure), and
therefore require no additional coding
overhead.
Now, what's the common theme?
At each step, the new technology has overtaken the previous because
applications where *cheaper* to develop. Each new generation has reduced
the effort required to meet customer requirements.
OODBMS will evolve and replace RDBMS as RDBMS replaced Network simply because
it reduces development costs.
At the moment, as many posters have pointed out, OODBMS products lack the
facilities required to support large scale commercial applications (dba tools,
online backup, separate management of schema and programs, separation of
logical and physical representation, recovery, etc, etc, etc,).
In addition, there are few development tools, such as "4GL" engines, report
writers, adhoc query engines etc.
These are serious deficencies but they arise simply because the products
are immature.
Over time they will be remedied, in the same way that early relational
products suffered these same deficencies and addressed them over time.
Geoff Miller
>The "very smart people" who create the server software do not come bundled
>with the software they sell. Designing the RDBMS software != implementing
>it and using it on site for an application.
If some of these "very smart people" actually had to use some of these
products they might design them somewhat differently. However, ....
>I also have seen an unbelievable number of poorly designed databases in
>commercial settings. There's at least two reasons for this:
[snip]
> - The relatively small amount of effort required up front to
> produce and implement a design that will be extremely flexible
> yet yield high performance, almost always is seen as too
> costly and time-consuming by management. No matter how many
> juicy horror stories management is told about the extreme
> maintenance nightmares to be encountered down the road, the
> short-term cost-cutting (and this year's bonus) is chosen above
> long-term benefits.
I don't excuse the attitude you describe, but it may be worth pointing
out that those of us who maintain database applications prize flexibility
far more than management does. Management knows exactly what it wants
now (forgetting the number of times it has changed its collective mind)
and since it won't change its requirements again (cough, splutter, choke)
why put any effort into building a flexible system. This is where a
good filing system, from which you can extract a full record of the
changed specifications, is highly valuable.
[snip]
>Those of us working in the business arena sometimes fantasize about
>working in the rarefied air of a technology vendor or a university
>setting, where, in theory(!!), only the best techniques are used, and
>politics/self-interest/ignorance do not rule.
You jest. You haven't _seen_ politics, self-interest and ignorance
until you've worked in a university. Technology vendors, too, have
their constraints--imagine going to your management in a software
company and telling them you need to buy a competitor's product
to do your job because their own product doesn't work.
>... It might be nice to
>be blissfully unaware of these real world constraints I described.
>It's sometimes frustrating (not to mention appalling) to see how systems
>are really being implemented out here -- on the other hand, the market
>for folks equipped to come in and clean up the mess is very lucrative!
And will be for the rest of my working life, I hope:-)
Geoff (g-mi...@adfa.edu.au)
Ole-Hjalmar Kristensen
Xref: ugle.unit.no comp.databases.theory:1438 comp.databases.object:923 comp.databases:23847
Path: ugle.unit.no!trane.uninett.no!sunic!mcsun!uunet!munnari.oz.au!sol.ccs.deakin.edu.au!news.cs.uow.edu.au!picasso.cssc-syd.tansu.com.au!rutherford.cssc-melb.tansu.com.au!news-admin
From: jmul...@tansu.com.au (James Mullens)
Newsgroups: comp.databases.theory,comp.databases.object,comp.databases
Date: 19 Sep 1993 23:53:20 GMT
Organization: Telecom Australia - CSSC
Lines: 94
Distribution: world
References: <1993Sep16.1...@aber.ac.uk>
Reply-To: jmul...@tansu.com.au
NNTP-Posting-Host: gauss.cssc-melb.tansu.com.au
Based on the structure of *which* problem? Usually data will be used
in several applications, which may or may not be related in terms of
the problem they solve.
--
Ole-Hj. Kristensen
"If you are going to shoot, shoot, don't talk."
-- Il Bruto
tul...@ptolemy.arc.nasa.gov
on this subject to date (no pun intended). I have been following this thread
for some time and I have been amazed by the highly-charged, emotional nature
of the arguments. Mr. Mullens' descriptions, while clearly among the most
logical and informative I have seen, still leave a couple of unanswered
questions. In his tutorial, speaking of OOD, he states:
>> Links are hardwired a la Gen 3, but design techniques are available
>> that provide a sound guide to development of models matching the
>> problem domain (unlike many Gen 3 designs which were driven by
>> performance considerations.)
>> In addition, the links are based in the structure of the problem as
>> expressed in the programming language (unlike Gen 3 where links were
>> based on the on-disk data structure), and therefore require no
>> additional coding overhead.
As an old CODASYL programmer who has since done some work in both RDBMS and
OODBMS, I was glad to see that someone finally admitted that the links in
OOD are "hardwired" ala CODASYL (network). I believe that this may be one
of the major shortcomings of OOD that must be resolved, because it will cause
difficulties in commercial applications. I suspect that will happen in due
time, but appears to be a disadvantage that some of the OOD proponents are
overlooking in their zealotry for this methodology.
The second part of the statement is somewhat more alarming to me, because
I do not understand why anyone would want the links to be "based on the
structure of the problem as expressed in the programming language". Does that
not represent a loss of "abstraction", which reduces the flexibility of any
system so designed?
It seems to me that in any application, there exist inherent "relationships"
between the various data elements that will exist regardless of the method
of implementation. That is why we normalize (a nasty word?), why we created
sets in CODASYL, relations in RDBMS and however you chose to do it in OOD.
I was under the impression that ER analysis is intended to capture these
relationships and should be universally valid. Any departure from the data
model determined by ER is a "practical" compromise to performance which
represents shortcomings of current technologies (hardware and software)
rather than invalidation of the underlying model.
So where does that leave us? RDBMS appears to be very good at forcing the
designer to think about the underlying data relationships, although it may be
clumsy in its representations of some complex data types, and is sometimes
inefficient in its implementation. OODB on the other hand, gives the designer
much more flexibility in terms of data storage but does it maintain sufficient
abstraction in its representation of the relationships between objects?
Instantiated objects will have relationships to other objects that must be
maintained (probably in both directions). It is one thing for the developer to
understand and hard-wire those relationships while building the system, but
does the OODB model provide sufficient tools to maintain the data integrity of
those relationships in the commercial environment?
I have noted other writers point out that both methodologies have there
place in our "tool box", but have yet to see anyone take a crack at
defining where one or the other are best applied. Would I be correct in
thinking that RDBMS is best used in applications with large collections
of simple data wherein we are primarily concerned with transactions involving
"sets" of data elements. OODBMS, on the other hand may best be applied to
complex data types wherein we are more concerned with individual data
elements (object instantiations). I'm sure that is probably a gross
over-simplification, but I offer it as a basis for futher discussion.
Ultimately, the OOD proponents may be correct in their analysis that this
technology will overtake and replace RDBMS. History continually proves
that there is ALWAYS a better way to do business and RDBMS aficionados must
not cling to the familiar old ways too long. On the other hand, I think
the OOD zealots would do well keep in mind some of the attributes of
RDBMS that has made that methodology successful. I for one, would be
gratified to see continued discussions in this thread based more on fact
(ala James Mullens) and less on emotional appeals.
To change the way you do business, you need two things: brains and guts.
--
} Jim Tulley INTERNET: tul...@ptolemy.arc.nasa.gov {
} Lockheed Space Operations Co. other: jtu...@mcimail.com {
} Kennedy Space Center FL tel: (407) 861-5837 {
} Mail Code LSO-321 fax: (407) 861-6784 {
Ole-Hjalmar Kristensen
> > I disagree.
Yes, but my question was 'which OO?' Seems to me that every man has
his own definition of an OODBMS.
pay attention:
the simplest way to imitate a relational system in an OODB is to think
of a table as a class and create persistant class extentent containers with
the constructor methods adding instances to the containers. So each table
you require would have a matching class in the OODB. each table class would
be a sub class of a 'set' container class to which you would provide the usual
set operations: interstion, union etc. You have to add a n-way
join method to the set class. this is just a loop through a list of tables
classes. one of the parameters to the join method is passed a
criteria matching method.
Can you describe the interface to such a method, expressed in for
example C++ ?
presto the table classes can now be queried just like real
'tables'.
Thank you. You have just conviced me that the amount of work needed to
express relational operations in an OODB is exectly the same as
implementing it on top of a network DBMS, which means that it is not
realistic to do it as part of a project. However, if the DB vendor
includes some scaffolding, it may be feasible. But why would you want
to do such a thing? What you describe is really reimplemting the basic
relational operations over and over again, for each new class you add,
you have to add code to be able to do relational operations, whereas
in a tradional RDBMS, the interpreter/translator does this work for
you by using information from the dictionary.
In case you get me wrong:
I am *not* saying that OODB's are bad, just that there are some good
aspects with relational DB's which I do not want to throw away, and
which you cannot easily add to an arbitrary OODB, but which must be
designed in as a part of the system.
The container class could even be generic 'set' with
a runtime implementation policy of hash, btree, isam etc.
optimising the join method is left as an exercise for the reader.
A fairly large exercise, I would say :-)
Dependending on how your OODB provides reflectivity or access to its schema,
you could even then generalise and write a simple parser to imitate SQL
without much sweat being raised. :)
I look forward to seeing it !
you could replace the hard coded matching method with a recursive dynamic query
class, and pass an instance of the query object to the join method.
you could even add a list of 'linked' containers to the original set class
to simulate indicies and access paths.
then the real fun could begin, you might alter the behaviour by subclassing
to try variations on the theme of data modeling, and invent totaly new
modeling madness. you might add shortcuts like a concatention operator
to your set class, to paste two tables together. or add iterators
on your containers to see if this helps you optimise your join method....
is any light begining to seep through yet?
No.
vic
--
----------------------------------------------------------------------
Vic Cinc, Krell Labs pty ltd internet: vi...@extro.ucc.su.oz.au
smail: GPO Box 1660 Sydney NSW 2001
--
Piercarlo Antonio Grandi
In article <akf.748138056@awful>, a...@awful.august.com (Andrew Fullford)
writes:
>RDMS proponents have always pushed the idea of decoupling data
>in the database from the applications that use it. It seems that
>this is the anathema of OODMS which attempt to provide OO
>languages with "persistence" that is almost transparently
>available.
But the point of OO is that you take a data-centric view of the
application domain, as the data is much more constant over time than
the applications that use it. From what I've been reading, this is a
constant underlying theme of OO, and it seems to be exactly what you
are talking about.
This is a point of hot debate, but IMNHO what characterizes OO is not
at all data centric -- it is entirely procedure centric, in that OO is
defined in terms of procedure structure, not data structure.
The very foundation of OO is a methodology that posits that (most)
programs are optimally decomposed into modules when a module contains
all and only the procedures that know about the representation of one
particular data type, and the definition of that data type.
[Warning: real authorities on the subject, not part-time postgrad
students, have stated that this fixation on decomposition strategy is
nonsense and OO is solely characterized by classes, inheritance and
dynamic messaging, and that *any* program that uses all three is OO
and *any* program that does not use all three is not OO (really! :->,
quotes available on request). Soooo, you should not believe a word of
the preceding paragraph...]
If you agree with the above, the OO decomposition paradigm, at its most
basic, does not say _anything_ on how *data* should be decomposed/modeled.
It only says something on how *procedures/programs* should be decomposed.
[The relational model instead is quite specific: values only (except
for that erroneously named abominations, the various types of null
value), no links, structured as tables, each row in the table with
a fixed number of values, one value per column, each column holding
values of one type only, one column's values forming a set, the others
may be bags; plus various semantic constraints ("normalizations")
to guard against update et al. hazards. Nothing is said as to the
structure of programs that access the data, BTW. Indeed the absence of
links and any prewired access path is motivated by the obervation that
access path are a function of the logic of the programs that do the
accessing.]
On the other hand most OO languages do specify a _data type_ decomposition
strategy, via inheritance, and thus require that the data type model be
hierarchical (single inheritance) or a DAG (multiple inheritance), and
assorted other restrictions. Some uncommon OO languages, e.g. some of
those based on delegation, rather than inheritance, allow for arbitrary
shapes of the data type lattice.
[Please note (e.g. Dave, who seems to enjoy attributing to me caricatures
of what I write, as if it were necessary :->) that I have not said
that common OO languages and OODBs restrict data to trees or DAGs; it
restricts their *types/description* (data dictionary) to a tree or a
DAG. I have also not said whether this is "good" or "bad".]
Piercarlo Antonio Grandi
[ ... ]
Generation 2 Network Elimination of redundancy required in Hier.
to represent N-M relationships. This also
reduces lines of codes for a given function.
Code required to navigate data structure
Generation 3 Relational Eliminates code required to navigate data,
but there is a residual impedance mismatch
between the set basis of the data storage
model and the record basis of programming
languages.
Given that the mismatch is between a low level implementation language,
and a high level database, I think that it is the low level language that
should go. I find the idea of writing user oriented applications in C/C++
or similar languages almost completely ludicrous in most contexts.
Aids maintenance and support for evolving
requirements by removing hardwired links.
Also (via Codd's laws) provides a sound basis
for design. (This leads to emergence of a
high priesthood speaking a hypermathematical
language of every increasing obscurity, but's
that another story.)
Generation 4 Object Based Further reduces code required by eliminating
the impedence mismatch between data storage
and programming languages.
Yes, by reducing everything to the least common denominator. Users and
applications want associative access, low level languages only have
pointers, thus abolish associative access and back to using pointers:
Links are hardwired a la Gen 3, but design
techniques are available that provide a sound
guide to development of models matching the
problem domain
But this is *impossible*, unless in the context of a single application
or application family! Which access path are needed is function of the
application, it is not an intrinsic aspect of the semantics of the data.
And adding new access paths in the *logical* schema is far more trumatic
than adding them in the physical schema, as is possible (but not fully
implemented, amazingly) in relational systems.
(unlike many Gen 3 designs which
were driven by performance considerations.)
In addition, the links are based in the
structure of the problem as expressed
in the programming language (unlike Gen
3 where links were based on the on-disk
data structure), and therefore require
no additional coding overhead.
This is always predicated on the bizarre assumption that we really want
to dump 4GLs and the like and write user level applications in low level
languages... This reminds me tangentially of a nice phrase of an IBM
]researcher some years ago working on a single chip 370 CPU; he wrote that
sooner or later one could put an entire 370 on a desktop, and then added that
perhaps MVS would not then be appropriate... :-)
Now, what's the common theme?
That you seem to be obsessed about lines of code, as if all that mattered
were application sizes. Perhaps then the designers of the relational model
have been wrong to think that aspects such as data integrity, update
hazards, and so on are very important.
At each step, the new technology has overtaken the previous because
applications where *cheaper* to develop.
Ahhhhh, here we understand something crucial -- to you what matters is
applications, not databases. Perhaps you see a database as an extension
of an application, or a set of applications; as in "I have to got to do
a customer address database, let's write an application that stashes
somewhere in a persistent store the addresses, and then handles entry
and query of those'. This is indeed a common mentality, especially for
small businesses and the like.
Unfortunately database people have a completely different outlook;
they care less about application architectures than about data
architectures. For many companies the hugest investment is in the
collection structuring and maintenance of data, applications come and
go, and may be written in many different ways. But the cost of the data
is immense, and its usefulness trascends that of any single application,
or even of any group of applications.
These people are interested in managing data, more than applications,
for the simple reason that's where the money is. And even the people
that start with the belief that all they need is an application to
manager customer addresses, one to manage invoices, one to manage
stocks, one to manage bank accounts, eventually find that all is not
jolly easy as they thought, as redundancies and inconsistencies creep
in.
Each new generation has reduced the effort required to meet customer
requirements.
Only if you add: " where such requirements are that ad hoc, short term
and relatively static application-oriented databases be developed" then
this perhaps applies to OODBs. If you add " where the requirement is
to collect, structure and maintain enterprise-critical data that might
be accessed by a varying and growing set of appplications developed in
many different technologies" then things are not so clear :-).
Dan Weinreb
As an old CODASYL programmer who has since done some work in both RDBMS and
OODBMS, I was glad to see that someone finally admitted that the links in
OOD are "hardwired" ala CODASYL (network).
On the other hand, please keep in mind that in at least some OODBMS's,
there is such a thing as an abstract "set", and there are queries that
can be expressed in a "declarative" way, i.e. queries that do not say
how to traverse the set. The queries are handled by a query
optimizer, which dynamically evaluates the proper method of executing
the query, by seeing whether indexes exist or not, etc. That is,
whether to use the index or not is NOT "wired" into the source code.
This is very much like what relational databases do, and what CODASYL
databases don't do.
Dan Weinreb
I find the idea of writing user oriented applications in C/C++
or similar languages almost completely ludicrous in most contexts.
It is, of course, your prerogative to think so. Back here in the real
world, most of the best-selling software in the Unix and PC and
Macintosh world is written in those languages, whether you like
them or not.
Vic Cinc
>>I guess here we differ, I beleive self querying applications to
>>be worth the extra effort. especially since my current boss (a money market
>>dealer), is a power user, not only does he understand SQL, he is learning
>>to program in C and C++ (shuder). I know only too well what its like cleaning
>>up after self educated power users.
>Perhaps it would be easier to train him how to use the system properly?
you mean like almost droping a table yesterday with autocommit on.
seeing if backups work always gets me excited.
Mark Day
Users and
applications want associative access, low level languages only have
pointers, thus abolish associative access and back to using pointers:
In Thor we think of set[T] as being "just another parameterized type",
albeit one that must be implemented efficiently. A set object has a
query operation that provides associative access to the set, returning
the subset of elements that match the query.
A computation in Thor is made up entirely of operations being invoked
on objects; some of the operations cause navigation along pointers,
some cause more complicated associative accesses to happen. I don't
think that pointers and associative access are mutually exclusive,
although they may be in some data models or systems.
--Mark Day
James Mullens
> Now, what's the common theme?
>
> That you seem to be obsessed about lines of code, as if all that mattered
> were application sizes. Perhaps then the designers of the relational model
> have been wrong to think that aspects such as data integrity, update
> hazards, and so on are very important.
I'm sorry. I'm not belittling these concerns. The context of my posting
was an attempt to explain why OODBMS might have a competitive advantage
in the market place. Unfortunately, given the way software investments
are justified this will almost always involve the cost of application
development over maintenance or the recognition of data as a corporate
resource. Neither do I see data as simply a resource for developers
to "rape and pillage" as they see fit.
Unfortunately this issue, like all non-trivial technical issues, must be
assessed from many viewpoints. I was looking at only one.
Regards
James
Hans Marggraff
writes:
Some good comments. He has been the first in this thread
to give some concrete strongpoints in favour of RDMS.
As I see them they are: Separating data from application,
migration between vendors, legacy systems and data evolution.
As I am in a commercial environment they give me some concern indeed.
I should be able to adress these points in favour of OODBs:
Data Evolution and separating data from application:
|> Our schema goes through a state of rapid
|> change during the design phase of a major release, and then
|> steady, continuous modification during its production lifetime.
|>
|> In our relational environment we can phase such updates: this
|> does not appear to be the case in the OODMS world. I believe that
|> this provides some strong justification for the relational
|> orientation that attempts to separate data and applications.
I believe this is only possible for applications where the internal
representation can be adapted to the changing external data model. If
you have a lot of code that depends on a certain data structure it will
be hard to change it no matter what DB technology you use.
In our area (CAD/CAM) 95% of our code depends heavily on the actual
data structure. So changing the database is the smallest of our
problems. If we change the representation of a line or a body or
whatever we are in deep trouble.
I think this is typical of a lot of applications that use OODBS.
However inheritane gives us some leeway for changes. We have taken care
that all our data structures are designed in a way as to be extendable
through inheritance.
Apart from that most OODBs support schema evolution. We have found
this sufficient in the system we use because the problems lie in the
application not in the I/O.
The problem of changing your DB supplier.
|> [...] We have moved from one DBMS vendor to another within a version
|> release (twice). The OODMSs we have examined appear to be
|> inexorably intertwined with the applications [...]
This is possible
if you can find another system with a similar access paradigm.
Currently I can see only three such paradigms. In one the application
is responsible of knowing which objects are in core and which are
in the database. They need some sort of activate/load instruction.
This group includes POET, Ontos, Objectivity/DB I believe.
The next group uses transparent load through smart pointers (Versant ...)
And at last ObjectStore uses interupt driven load.
I believe changing within one group is manageable even though a dirty job.
I guess, I have not tried it. In the long run ODI should be happy about
other systems using their mode just to strengthen the market in this
area. Currently they are guarding this technology, saying that they have
patented it.
I believe this situation with the evolution of a stable set of OODB
suppliers.
|> We also suffer from a common ailment - dirty data. Typically,
|> this is poorly controlled data that derives from a legacy system
|> which often uses some special purpose database of dubious
|> ancestry. In a relational environment, it is convenient to load
|> this data into a schema that approximates the legacy system and
|> then go through a cleaning session using the tools readily at
|> hand (even SQL) to integrate the data into the primary schema.
|> This is possible, in part, because the data and the applications
|> are not tightly coupled.
First a question: How do you load your data from one database system
into a schema of another, without having access to the internals
or to some neutral format.
I believe the problem of legacy systems is more easily adressed
within an OODB framework where there is the natural neutral
format of C Records or C++ Classes.
In the simple case you have to write a program that assigns every
attribute of some record to some other attribute of some other record.
In the complex case this includes joins and computed attributes.
In our area with some extra number crunching sprinked in.
The overhead of going through a compiled language is not a problem
for us.
Hans
--
Hans Marggraff speaking for myself, but working for:
Straessle Informationssysteme GmbH & Co.
Alte Bahnhofstrasse 10
77933 Lahr, Germany __o
Tel: +49 7821 284 340 -\<,
Fax: +49 7821 284 363 .....O / O
Hans Marggraff
|> in the database from the applications that use it. It seems that
|> this is the anathema of OODMS which attempt to provide OO
|> languages with "persistence" that is almost transparently
|> available.
Yes that is the fundamental misunderstaning why RDMS proponents
and OODB users will continue
to flame each other and discuss completely different issues.
The supposed lack of a mathematical model of OODBs is not an issue
for us because we have to do a lot of number crunching and other complex
computations, so we use books on algorithms and data structures for
our domain as the our preferred data model.
Apart from that most OODB applications I have seen can be modelled
with some sort of extended Entity/Relationship model which includes
inheritance, generalisation and aggregation. These are well established
models, which are also used in RDMS environments. Only I don't have to
map the abstract model into a model of limited expressive power like
relations. Once I have to do this mapping the mathematical soundness
of relations is irrelevant because I have already lost soundness
through mapping.
For people who have to do a lot of simple operations (display,
attribute update, summation, average ...) Data independence is
an advatage. But I still believe that most of these applications
can be done well in an OODB framework using primitive but general structures.
Class table with operator join is NOT hard to implement.
Hans
--
Hans Marggraff speaking for himself but working for:
Straessle Informationssysteme GmbH & Co. __o
Alte Bahnhofstrasse 10;77933 Lahr, Germany -\<,
Tel: +49 7821 284 340 Fax: +49 7821 284 363 .....O / O
email h...@straessle-lahr.de
Hans Marggraff
|>
|> Just a point of clarification. A relational database "hundreds of megs"
|> in size would be considered by relational engines to be verging on
|> trivially small. A large relational database (today) would be hundreds
|> of gigs.
How many of those gigs are there because of overhead? (Indexes, precomputed
joins, extra tables for normalisation etc ?)
How much of these gigs do you actually access (for update or for use in
further computations not just scanning through them) in one transaction?
I doubt that even your largest machines are able to access a significant
subset of this dataset in one chump.
At least your Workstations have problems with speed using databases in the range
below 10 megs using relational technology in a classic relational domain
(document management)
So don't boast. Of course if I add up all data each of my customers store in
their (sub)databases I end up with hundreds of gigs easily, and since they are all
accessible through one major database, yes our application has your size using
OODB technology.
I only count data that has to be accessible during one transaction and that has
to fit into main memory as one database. Here my experience ends with several hundred
megs because my workstation can't really handle more.
But these trivially small datasets are subject to traversals and computations
which are anything but trivial. (geometric reasoning,
constraint solving, non linear equations) The data is higly knitted together
(hardwired access paths implemented as pointers)
In this area OODBs have given us reliable performance.
Hans
--
Hans Marggraff speaking for himself, but working for
Straessle Informationssysteme GmbH & Co.
Alte Bahnhofstrasse 10
77933 Lahr, Germany __o
Tel: +49 7821 284 340 -\<,
Steven Schleimer
(... lots of stuff deleted ...)
>I get lots of mail from too many students and academics and none from
>people who have developed real applications and disagree with me.
>vic
I have been building a commercial application on top of Sybase and
Smalltalk 80 for some years now. It is an enterprise management
application which manages a wide range os systems. The Sybase server
holds both management system configuration information (config) as well
as dynamically acquired enterprise state information (data).
We provide a fairly extensive set of tools to manage both the config and
the data. It is relatively rare that a customer will need to manipulate
the config. However, although we have built an extensive set of tools
for managing the data (acquisition, display, backup, report, removial)
there are MANY cases in which we have not been able to provide EXACTLY
what it is the customer really wants. Generally, customers deal with
this lack by creating their own reports and other manipulatives.
We have learned that SQL is not a the way a customer generally perfers
to access the data. However, SQL does have a number of advantages which
our customers understand (as opposed to forcing us to create customized
reports and manipulatives). Those include:
* generally available understanding in the broader community
* generally available training classes available from third parties
* generally available workers familar with SQL who can be hired
Each of these gives the customer the ability to extend the work we
have done in the provision of our infrastructure.
So, we use OO technology and Relational technology togeather noting that
both are of value and both help us to deliver our product effectively to
our clients :-)
--
--
INTERNET: st...@boole.com (408) 524-3294
USPS: Stephen Schleimer/ Boole & Babbage / 510 Oakmead PKWY / Sunnyvale 94086
Terry Poot
In article <1993Sep20.1...@aber.ac.uk>, p...@aber.ac.uk
(Piercarlo Antonio Grandi) writes:
>On 19 Sep 1993 23:53:20 GMT, James Mullens (jmul...@tansu.com.au)
>wrote:
> but there is a residual impedance mismatch
> between the set basis of the data storage
> model and the record basis of programming
> languages.
>
>Given that the mismatch is between a low level implementation
>language,
>and a high level database, I think that it is the low level language
>that
>should go. I find the idea of writing user oriented applications in
>C/C++
>or similar languages almost completely ludicrous in most contexts.
This is obviously from someone whose needs are well served by simple
data in a rectangular form. My applications use complex data structures,
and from that point of view C is an advanced language and RDBMS is a
primitive data storage facility. If I didn't use blobs, the smallest
useful data item (i.e. the one that it makes no sense to subdivide any
further) would take on the average 1000-3000 rows in the database, and
would require a 4-way join to retrieve. Most of the data retrieved would
be redundant, used mainly to enable the join to work.
I can put this in one row in a BLOB, but fields that I have to have
available for queries have to be duplicated in fields in the row, and I
have to pack and unpack the data anytime I want to access it. And of
course, that doesn't even mention the fact that some of my structures
are recursively defined, and therefore would require an unknown number
of queries to access if they were stored in the usual relational
fashion.
All of this is a hassle imposed by the relational model, with no benefit
whatsoever. Access to sub-parts of this data structure is simply not
useful. In an OODBMS, I could store the data in the same form that
programs will actually use it, and I could query the actual data rather
than duplicate fields.
> Generation 4 Object Based Further reduces code required by eliminating
> the impedence mismatch between data storage
> and programming languages.
>
>Yes, by reducing everything to the least common denominator. Users and
>applications want associative access, low level languages only have
>pointers, thus abolish associative access and back to using pointers:
My users want to call up a printing plate on the screen with decent
response. They don't care at all about pointers OR associative access.
That's my problem. I do need a certain amount of associative access,
which is fully supported by all the OODB systems that I would consider.
Relational has no corner on that market.
>This is always predicated on the bizarre assumption that we really want
>to dump 4GLs and the like and write user level applications in low level
>languages... This reminds me tangentially of a nice phrase of an IBM
>]researcher some years ago working on a single chip 370 CPU; he wrote that
>sooner or later one could put an entire 370 on a desktop, and then added that
>perhaps MVS would not then be appropriate... :-)
Of course, the 4GL has yet to be written that is of any use in an
application domain such as mine, or many, many, others. They are only
useful in a narrow application domain, which, as it happens, is the most
common application domain. OODBs allow application domains that have
NEVER used databases to achieve the benefits that databases provide, and
still actually get the job done. RDBMSs simply have little to offer to
those developers.
The only reason most people think RBDMSs are suitable to most problems
is that most people who have problems not suitable to RDBMSs are smart
enough to avoid them altogether. (I, unfortunately, was not, and I've
regretted it.) OODBMSs allow those people to get the benefits of
database technology using a tool that will actually help them solve
their problems, rather than hinder them.
> Now, what's the common theme?
>
>That you seem to be obsessed about lines of code, as if all that mattered
>were application sizes. Perhaps then the designers of the relational model
>have been wrong to think that aspects such as data integrity, update
>hazards, and so on are very important.
Data is useless if it can not be effectively accessed and manipulated.
OODBs allow one to do that AND address things like data integrity,
concurrency control, etc.
Dan Weinreb
In Thor we think of set[T] as being "just another parameterized type",
albeit one that must be implemented efficiently. A set object has a
query operation that provides associative access to the set, returning
the subset of elements that match the query.
A computation in Thor is made up entirely of operations being invoked
on objects; some of the operations cause navigation along pointers,
some cause more complicated associative accesses to happen. I don't
think that pointers and associative access are mutually exclusive,
although they may be in some data models or systems.
By the way, exactly the same is true in ObjectStore.
Dan Weinreb
In article <akf.748138056@awful>, a...@awful.august.com (Andrew Fullford) writes:
|> RDMS proponents have always pushed the idea of decoupling data
|> in the database from the applications that use it. It seems that
|> this is the anathema of OODMS which attempt to provide OO
|> languages with "persistence" that is almost transparently
|> available.
Yes that is the fundamental misunderstaning why RDMS proponents
and OODB users will continue
to flame each other and discuss completely different issues.
I would go much further than that. There is no "anathema". There is
nothing inherent in OODBMS's that "couples" data to applications. I
will concede that OODBMS's, because of their richer and more complex
data models, give you more rope to hang yourself if you want to do
something wrong. However, there's no problem designing a database
schema that is not particularly "coupled" to any application.
One of the main ideas of how OODBMS technology can be applied to CAD
is that CAD data can be kept in an OODBMS, and many different CAD
applications can all operate on it.
Whenever you design a database schema, it's important to go about it
in a "correct" and "clean" way. I do not have space here to try to
define exactly what that means; it's an extensive topic. Briefly, the
"methodologies" that we have all seen are generally aimed at helping
you make your schema design correct and clean. Having done so, you
can render it in an OODBMS framework or in an RDBMS framework. Please
keep in mind that all real OODBMS's (at least the ones I know about)
provide structures such as bidirectional relationships that are quite
similar to the concepts found in Entity-Relationship diagrams, and you
are quite free to never use unidirectional relationships (pointers) if
you so choose. Conversely, it is possible to do a bad job of schema
design in a relational database (that's one reason that there are
methodologies, CASE tools, etc to help one design relational schemas).
Stephen J Bevan
Which tends to imply that anything that doesn't interface well with
C(++) is by definition bad. This forces compromise solutions to be
used until (if ever) a breakthrough is made and the old ways can be
abandoned. The relational approach was breakthrough (compared to
COBOL, PL/1 and network DBs) but it was not complete, the
implementations never quite lived up to the theory. This has opened
the door for OODBs (son of network, or network part II) as the
compromise solution. Seems to me like an example Gabriel's "New
Jersey vs. MIT" syndrome.
Dan Weinreb
Which tends to imply that anything that doesn't interface well with
C(++) is by definition bad.
No, no, I was trying to make exactly the opposite point, viz. that
there is no single "good" or "bad". There are different market
segments with different requirements. For some programmers who are
doing certain things, C++ is at far too low a level; for other
programmers who are doing different things, C++ is the level they
want.
One of the things that existing OODBMS products are about is providing
a close and natural interface to a programming language. (C++ is
archetypal but many OODBMS's support other languages.) For some
programmers doing some things, this is an important benefit.
Vic Cinc
Vic Cinc
[much stuff deleted]
>Can you describe the interface to such a method, expressed in for
>example C++ ?
have a look at the poet query interface, it does something like this.
> presto the table classes can now be queried just like real
> 'tables'.
>Thank you. You have just conviced me that the amount of work needed to
>express relational operations in an OODB is exectly the same as
>implementing it on top of a network DBMS, which means that it is not
>realistic to do it as part of a project. However, if the DB vendor
>includes some scaffolding, it may be feasible. But why would you want
>to do such a thing? What you describe is really reimplemting the basic
>relational operations over and over again, for each new class you add,
>you have to add code to be able to do relational operations, whereas
>in a tradional RDBMS, the interpreter/translator does this work for
>you by using information from the dictionary.
>In case you get me wrong:
>I am *not* saying that OODB's are bad, just that there are some good
>aspects with relational DB's which I do not want to throw away, and
>which you cannot easily add to an arbitrary OODB, but which must be
>designed in as a part of the system.
well it depends is your intereset is developing applications
or maintaing some data. If all you want to do is perform joins all
day, then dont bother getting an OODB. If you want to write real
systems then you should have a closer look.
dictionary/reflectivity its all the same.
> The container class could even be generic 'set' with
> a runtime implementation policy of hash, btree, isam etc.
> optimising the join method is left as an exercise for the reader.
>A fairly large exercise, I would say :-)
:)
[stuff deleted]
> you could replace the hard coded matching method with a recursive dynamic query
> class, and pass an instance of the query object to the join method.
> you could even add a list of 'linked' containers to the original set class
> to simulate indicies and access paths.
> then the real fun could begin, you might alter the behaviour by subclassing
> to try variations on the theme of data modeling, and invent totaly new
> modeling madness. you might add shortcuts like a concatention operator
> to your set class, to paste two tables together. or add iterators
> on your containers to see if this helps you optimise your join method....
> is any light begining to seep through yet?
>No.
oh well I tried.
out of curiosity?
1) do you program?
a) if so what language(s)?
2) do you use any commercial db?
3) have you tried any new OODBs?
D. J. Pajerek
[snip]
>Apart from that most OODB applications I have seen can be modelled
>with some sort of extended Entity/Relationship model which includes
>inheritance, generalisation and aggregation. These are well established
>models, which are also used in RDMS environments. Only I don't have to
>map the abstract model into a model of limited expressive power like
>relations. Once I have to do this mapping the mathematical soundness
>of relations is irrelevant because I have already lost soundness
>through mapping.
Hear hear! I have found the need to convert all of my data into
tables to be quite annoying, both from the design point of view and
especially from the maintenance perspective. Using an ODB, my data
can go directly from the analysis stage directly into the database,
no 'translation' necessary.
There are almost certainly some types of data that can fit quite
comfortably into the relational model, but there's plenty that doesn't,
and for these situations ODB is a godsend...
>Hans
Don Pajerek
Standard disclaimers apply.
Dennis Allard
>[much stuff deleted]
[much more stuff deleted]
I missed somewhere in the monumental amount of verbage in this
thread where you propose an OODBMS replacement to the RDBMS 4GL.
I am an experienced programmer both in academia and in the real
world. I recently completed a small business application using
Access, a product by Microsoft meant for developing small databases.
The application involves keeping data for about 4000 students, tracking
phone calls to and from them, taking orders for a diverse set of
product types including services, salable merchandise, and courses.
Data is kept about students, courses, special kinds of courses, ads,
advertisers, employees, product line, telephone calls, and orders.
The project took six weeks (240 hours). This involved designing a new
relational model from scratch to replace an existing system which consisted
of a single flat file model for part of the desired funcitonality. The
project included converting preexisting data from the flat model (in Q+A)
over to Access as well as importing DBASE zipcode data for use by Access.
In RDB terms, the size of the system is as follows:
Number of tables: 24
Number of queries (simple to complex joins): 80
Number of forms: 50
Number of reports: 7
Number of lines of code: 1200 approx
By 'code' above, I mean procedural code necessary to fill in semantics or
provide functionality not easily implemented directly as queries or
attached 4GL expressions in forms.
By 'query' above I mean a high level description of a join involving
one or more underlying tables or other joins. Now, don't get too
scared or sarcastic, but an example of one of the more complex joins
in this application is as follows:
PARAMETERS [class number or partial description] Text;
SELECT DISTINCTROW
Class.[class number],
order.orderid,
Student.studentid,
order.timestamp,
<a computed string forming a multi-line address> AS label,
order.[subtotal sum],
order.[amount paid sum],
order.[balance due],
order.[print invoice?]
FROM
[order], Student, [order purchase], Class, [order]
INNER JOIN
Student ON order.studentid = Student.studentid, [order]
INNER JOIN
[order purchase] ON order.orderid = [order purchase].orderid, Class
INNER JOIN
[order purchase] ON Class.classid = [order purchase].classid
WHERE
Class.[class number] Like "*" & [class number or partial description] & "*"
WITH OWNERACCESS OPTION;
This query means the the set of classes which are in any purchase detail for
all orders for all students. For each such class, it contains a tuple
consisting of the class number, student id, order id, order timestamp, etc.
I did not have to write this myself. Rather, I used a GUI tool which comes with
Access to specify which tables to join on which fields, which fields to project
into the final result, etc.
It took me about two minutes to specify and debug this query using the GUI.
I suspect that a good RDBMS hacker could have come up with the raw SQL in not
much longer than that, say five minutes.
It then took me about a half hour to design and build a form based on this
query to display the date and give buttons for various operations such as
moving the focus from a tuple shown in the form to the corresponding Class
form for the given class displayed. Etc.
Now, my point is that to do any of this with an OO language would require
more coding time than it took me with a 4GL. Moreover, the 4GL produces
code which is optimzized depending on which tables are indexed on which
fields. I do not have to think about those optimizations (although I do
have to think about which fields are likely to be useful to the optimizer).
In my professional opinion, I would not have been able to implement this
system in C++ + <any class library of your choice> in six weeks.
Dennis Allard
d...@netcom.com
Peter Moore
|> In article <akf.748138056@awful>, a...@awful.august.com (Andrew Fullford)
|> writes:
|>
|> |> release (twice). The OODMSs we have examined appear to be
|> |> inexorably intertwined with the applications [...]
|>
|> This is possible
|> if you can find another system with a similar access paradigm.
|> Currently I can see only three such paradigms. In one the application
|> is responsible of knowing which objects are in core and which are
|> in the database. They need some sort of activate/load instruction.
|> This group includes POET, Ontos, Objectivity/DB I believe.
|> The next group uses transparent load through smart pointers (Versant ...)
Not to nitpick a quite interesting response, but I would like to make
it clear that Objectivity/DB does NOT require activate/load
instructions (perish the thought). We use smart pointers and
transparently load AND unload data from memory.
Peter Moore
pe...@objy.com
P. Gainer
>In article <27cm6d$h...@juniper.almaden.ibm.com>, gai...@slowmo.almaden.ibm.com (P. Gainer) writes:
>|> A large relational database (today) would be hundreds of gigs.
>
>How many of those gigs are there because of overhead? (Indexes, precomputed
>joins, extra tables for normalisation etc ?)
>How much of these gigs do you actually access (for update or for use in
>further computations not just scanning through them) in one transaction?
>I doubt that even your largest machines are able to access a significant
>subset of this dataset in one chump.
I am not telling you what I believe, nor am I boasting about accomplishing
anything. I am telling you that decision support applications and
transactional applications often access databases *much* bigger than
hundreds of megabytes. This is from customers of RDBMS vendors, not from
me (and not only IBM customers).
>At least your Workstations have problems with speed using databases in the range
>below 10 megs using relational technology in a classic relational domain
I am not bragging about any machines made by IBM or anyone else. All I said
was that databases "hundreds of megs" in size would not be considered big
by a relational engine today. If you wanted to sell an RDBMS to commercial
accounts, it would have to effortlessly handle dozens of gigabytes or you
won't get in the door.
>So don't boast. Of course if I add up all data each of my customers store in
>their (sub)databases I end up with hundreds of gigs easily, and since they are
Who is boasting? Where did I mention anything about myself or about IBM?
>In this area OODBs have given us reliable performance.
Again, I am not slamming anything. I am just attempting to inject some
reality into what a commercial database package must be capable of.
Pat Gainer
gai...@almaden.ibm.com
Marc San Soucie
> Today, most OODBMS implementations require code to be written,
> but many RDBMS solutions can be written without writing code.
This is far less true of OODBMS's today than it was even a year ago.
Marc San Soucie
Servio Corporation
Beaverton, Oregon
ma...@slc.com
David Hansen
>vi...@extro.ucc.su.OZ.AU (Vic Cinc) writes:
>>[much stuff deleted]
>[much more stuff deleted]
>
>I missed somewhere in the monumental amount of verbage in this
>thread where you propose an OODBMS replacement to the RDBMS 4GL.
>
>I am an experienced programmer both in academia and in the real
>world. I recently completed a small business application using
>Access, a product by Microsoft meant for developing small databases.
>
>Now, my point is that to do any of this with an OO language would require
>more coding time than it took me with a 4GL.
Two comments. First, most of the discussion has been addressing
data models, not data manipulation languages. In fact, RDBMS proponents
have gone to great lengths to distance themselves from the limitations
of SQL, correctly arguing that the relational model does not define
a DML.
Second, I'd suggest that you might look at OODBMS products a little
more closely before you assume that a relational 4GL runs circles
around any "OO language." In particular, I've used Ingres, DEC's Rdb,
Oracle, and Sybase extensively, as well as some of the more popular
"4GLs" that work with a number of RDBMS products. Recently I've had
the pleasure of using the GemStone OODBMS (from Servio) and their
application builder GeODE. In my opinion, GeODE wins the "4GL"
competition by a wide margin. The point is, just as realtional != SQL
so OODBMS != C++, there's no reason that powerful "4GL" languages
can't work with an OODBMS, and in my experience, GemStone + GeODE
beats any RDBMS + any 4GL I've used.
- David
--
David M. Hansen | Department of Computer Science and Engineering
| Oregon Graduate Institute of Science & Technology
dha...@cse.ogi.edu | PO Box 91000
(503) 690-1121 7341 | Portland, OR 97291-1000
Dan Weinreb
In my professional opinion, I would not have been able to implement this
system in C++ + <any class library of your choice> in six weeks.
Certainly. For some kinds of applications, such as yours,
application-building tools such as Access, GUI builders, and so on are
very appropriate and helpful. (In contrast, Microsoft Access is
probably not the tool of choice to build an interactive ECAD schematic
capture facility.)
But this isn't essentially (inherently) a question of object-oriented
database systems versus relational database systems. It's really a
question of building applications using various kinds of
application-building tools.
So your position on this depends on whether you are taking a
short-term, what-should-I-buy-now outlook, or a long-term
what-are-the-inherent-and-ultimate-differences point of view.
If you are trying to make a purchase decision right now, you'll find
that in many (though not all) cases, 4GL-style application-building
tools oriented around relational systems are more developed and more
available than those for object-oriented database systems. This is
because the object-oriented systems are generally newer, and so many
desirable tool sets oriented to work around them have not become
available yet.
I want to be fair here. Earlier I countered a statement that
relational database systems could, in theory, do various stuff as fast
as the OO systems; commercial RDBMS's just don't happen to do it now.
I admit that I'm making a sort of a converse statement, that OODBMS's
could have good 4GL tools, but many of them just don't happen to have
them now. In my own defense, (a) some OODBMS's actually do have such
systems, and (b) OODBMS technology is much younger than RDBMS
technology and is still catching up; I think that when RDBMS
technology was this young, Microsoft Access and many other such fine
products did not exist yet.
Also, there are some many GUI builders that are built to work with
with C++. This isn't the same as an integrated 4GL-type system like
Access, but the GUI builders for C++ are useful when you do decide to
use C++, and of course you can make an application that uses any kind
of DBMS and whose GUI is built with one of these tools. So one is not
totally without recourse.
Stephen J Bevan
Which tends to imply that anything that doesn't interface well with
C(++) is by definition bad.
No, no, I was trying to make exactly the opposite point, viz. that
there is no single "good" or "bad". There are different market
segments with different requirements. For some programmers who are
doing certain things, C++ is at far too low a level; for other
programmers who are doing different things, C++ is the level they
want.
Agreed, but that seems like an idealised view to me. Out through my
little window on the Real World (tm), I see C(++) being used almost
exclusively, irrespective of whether it is too high or low level.
This seems to fix in the minds of these users the sentence I wrote above.
D. J. Pajerek
>code which is optimzized depending on which tables are indexed on which
>fields. I do not have to think about those optimizations (although I do
>have to think about which fields are likely to be useful to the optimizer).
>
>system in C++ + <any class library of your choice> in six weeks.
>
>d...@netcom.com
>
There are applications which are quite amenable to solution within
the framework of the relational model. Yours appears to be one of them.
This says nothing, however, about the suitability of the relational
model in other situations.
It's the same old story: use the right tool for the job. For some
jobs, a relational DB is appropriate; for others, it's not. There are
cases where an ODB is clearly the better tool.
Michael Krey
>there is no place in the currnet universe for any RDB, sorry, but these thing
>need to be extinguished, and relagated to a museum.
>
>great use the cruddy 4GL (2.5GL in reality) that most RDBMs provide.
Currenty we're using Windows4gl from Ingres. This has reduced the amount
of code we have had to write, and the time savings are astronomical.
If this is the benefit of a 2.5GL, then I'll take that over a
cumbersome 3GL like 'C' anyday. If you feel that a 4gl equates to
a 2.5GL, then perhaps your use of it needs reforming, or you have
the wrong product.
While I'm not a RDBMS trumpet blower, I think it's time lay the ten-year-old
'RDBMS's will die soon' argumet to rest.
>while OODB are still young they are a very promissing technology, just like
>COBOL is now a dying art so will RDBMs go away too. and not soon enough.
Many of the relational databse vendors are adding Object extensions. While
this will not completely meet the needs of the OO pureists, it nevertheless
allows us silly-billies who purchased 2.5GL RDBMS systems to dabble into
the OO world. At the moment, I sure as hell would not look at investing
in an industrial strength OO database. RDBMS is established in the business
world, with or without OO capabilities. OO is not. Talk to your major
IT directors, and they are not going to stick out their neck at the moment
after they've just justified going the RDBMS route.
It similiar to blowing your IT budget on WINDOWS NT. Who needs the headache.
I for one am will to watch large businesses implement OO, and if they
don't fall on their face, hey, I'm sold. Until then, back to the real world.
Cheerio
Michael Krey
British Aviation Insurance Group
mk...@baig.demon.co.uk
No once ever got their work done by Friday, except Robinson Crusoe.
Vaishali Padhye
>Piercarlo Antonio Grandi (p...@decb.aber.ac.uk) wrote:
>
> ...Stuff deleted...
>
>: Just about the only, and big, problem of the relational model is that
>: the vast majority of current commercial implementations is appallingly
>: badly designed (as Stonebraker implied long ago, a remark that still
>: holds true).
>
> The big problem with relational databases is that mnay people
>seem to have a hard time stuffing their data model into a relational
>model. They also seem to have problems with efficiency. OODBMS's seem
>to be a good, and flexible solution to these problems.
>
> I think you risk getting off track here. The purity of the
>underlying mathematical model is not very important. The mathematics and
>theory are a useful tool to understand a particular way of doing things,
>and to determine if the model is 'complete' in some sense. Other than
>that, the overriding concerns are exceedingly practical.
>
>Have fun, (if at all possible)
>--Me (Eric Hopper)
Newsgroups: comp.periphs,comp.arch.storage,comp.periphs.scsi,comp.databases
Subject: Help: Which database to use
Summary:
Expires:
References:
Sender:
Followup-To:
Distribution:
Organization: Univ. of Florida CIS Dept.
Keywords:
Hello folks,
This is a question to the experts on selecting a databse. I am involved
in a project for simulation of helicopter flights and am faced with
making a choice for a databse to store and retrieve data. Here is what
needs to be done:
1) Put together a model from a wide selection of components
2) For any model , provide a set of inputs
3) Run the simulation on the model and input data using one of a number
of analysis techniques
4) Store the output of the simulation in a database. For any simulation
Some people I know have suggested using an OO database, but I am not sure how
it works and solve my problem . Also is there a public domain OO database?
of outputs can vary between 1 to 300 for a particular set of inputs
5) Change inputs and observe and store outputs for specific model
I am faced with a huge pool of disorganised data to be stored and retrieved.
Can some kind folks out there suggest which way to head?
Thanks in advance.
Please reply directly to this account.
Vaishali Padhye
(v...@beach.cis.ufl.edu)
Marc San Soucie
> A question I do have, since SQL is god-awfull
> and C++ makes a poor database language, what is left?
> I feel technology is letting us down here, I feel that we need new
> ways for computers to intereact with users. things like the apple newton
> being able to read handwriting are a good start. A true DB should be able
> to understand plain english, or whatever your native language may be.
Maybe we should raise future generations to speak Smalltalk...
Sehyo Chang
>Vic Cinc (vi...@extro.ucc.su.OZ.AU) writes:
>
>> A question I do have, since SQL is god-awfull
>> and C++ makes a poor database language, what is left?
>
>> I feel technology is letting us down here, I feel that we need new
>> ways for computers to intereact with users. things like the apple newton
>> being able to read handwriting are a good start. A true DB should be able
>> to understand plain english, or whatever your native language may be.
>
>Maybe we should raise future generations to speak Smalltalk...
>
I second the motion. It is too bad most OODBMS only support C++
interface. By the way, name "Smalltalk" came from idea that
programming language should be easy enough for even children to
how to use immediatly (Alan Kay).
Voice recognition is not too far away. DSP technology and Fast RISC CPU
is getting cheap enough to implement mass produced continous speech
recogniztion. Getting software to understand natural language is another
matter.
Jon F. Rosen
> Voice recognition is not too far away. DSP technology and Fast
> RISC CPU is getting cheap enough to implement mass produced
> continous speech recogniztion. Getting software to understand
> natural language is another matter.
This is nonsense. Good non-trainable continuous speech recognition
is not close. Probably at least a decade or more. Maybe longer.
Has anyone seen the Newton's attempts at handwriting recognition?
Here is a sample of Newton's attempts to recognize hand-written
versions of the Gettysburg address:
> Four score and seven gives ago our fulltime bought turn into
> this continent a new Hanoi concerned in liberty and deduction
> to key proposition that 211 men are created equals
>
> Lori score and seven years ago our retailers brought form onto
> this continue I new notion concerned in liberty and delicate 5
> the proposition that oil men are Osaka equals
And you think we are close to voice recognition? Hardly.
Jon