Slashdot Mirror

Jim Gray is a SQL advocate. Obviously he'd promote data storage over processing. The sad thing is that he is among those that want to go with the database status quo instead of progressing towards relational nirvana; and without truly relational systems we will never be able of getting full use of all that data.

Jim Gray is a SQL advocate. Obviously he'd promote data storage over processing. The sad thing is that he is among those that want to go with the database status quo instead of progressing towards relational nirvana; and without truly relational systems we will never be able of getting full use of all that data.

The fact that you mention Tutorial D and Dataphor and "true" RDBMS systems suggests to me that you are a fan of Fabian Pascal and Chris Date. I love their site, both for the humour of their fairly extreme and positions and their shear lack of modesty in telling the establishment that "you're wrong." They also know what their talking about and their writings are 100% lucid. Oh well. 'Tis the world we live in.

> HTML is XML, so it obviously is working for the majority of data transfers

HTML is not data transfer, but presentation. XML is not a data format, but text markup. Different tools for different jobs.

> why would anyone give direct access to a DB

That is not what I called for. What I said is that instead of defining a hierarchical, verbose data format, we should have database schemas, possibly ANSI SQL ones if we can't get our act together around a really relational model. Then one can define data exchange formats that will be much faster, logical, than XML-derived ones, and require far less machine processing and programming.

Perhaps you will need some background. I would recomment DBDebunk.

> you can't own up to a simple oversight

I did say I was sorry, and did explain why I didn't care to read into the page referred, and I did correct my negligence. What else do you want, chest thumping?

> you feel it's your place to make judgement calls on the value of words

And why not? Do you think Marketspeak isn't misleading, or that it is useful or beautiful?

> I'm not familiar with "relational prescriptions and proscription"

I would refer you first to Christopher J Date's and Hugh Darwen's The Third Manifesto there isn't much on the site, I point it to you more as a reference to the book. I keep some more links at DMoz, and if you have a tough skin you can try Chris J Date's and Fabian Pascal's Database Debunkings.

Sorry about not doing a write-up, but on one hand I am looking for a job now and on the other I don't think Slashdot is the place to do education (as opposed to discussion).

> What if you could easily generate the SQL from the XML, or vice versa?

Well, assume that the XML schema did convey all the possible information in SQL. SQL is the standard, why create yet another language? Now assume the XML schema can convey even more information than SQL. In this case, I would rather use something terser, clearer, more straightforward such as Tutorial D or D4 or any other declarative D.

> Torque can automatically generate the XML from an existing database, though it's not flawless yet. So you don't have to duplicate your effort, if you started with SQL.

That would be kinda OK, if I can continue keeping my SQL and just regenerate the changes incrementally and transparently.

But I fool myself: I don't actually like OO, I would rather program functionally. The real problem isn't to have something to interface SQL and OO, but something to replace SQL that would be fully relational and thus satisfy OO requirements.

let's not leave out the greats, thanks to dbdebunk.

fact of the matter is, relational theory is mathematically sound, complete, etc. sql is not. it is ... a badly designed interface into a much neater world. having a language that let us do with relational data everything we -should- be able to do would be wonderful. the current obsession with sql (and variants) is actually hurting us.

[snip: rant about wrapping tuple data in objects because it's "cool"]

i would like a good set of OO principles for databases: the link above has a few articles mentioning that domains (datatypes in a database) could be OO, without hurting anything (orthogonality.) i haven't come across anything from Date/Codd/etc. about relations themselves supporting inheritance (derive from 'people' to get 'people-who-can-have-x') and even multiple-inheritance (derive from 'graphs' and 'calendar objects' to build 'interrelated calendar objects') ... it can all be done with FK's, but then, anything can be done manually with pointers, too. the point is to have a structured approach to the whole thing. from what i've seen, C.J. Date and Stroustroup don't quite agree on OO (because of specialization / generalization by constraint: is a circle an ellipse, the other way around, or neither?) it'd be nice to have that from the guys who brought us relational theory in the first place, while not throwing away what we got from smalltalk, c++, etc. (and who thought it was a good idea to remove multiple-inheritance from java?)

For more opinions to make you think:

http://www.dbazine.com/pascal9.html
http://www.dbazine.com/pascal8.html

And here, C.J. Date argues that a truly relational DBMS should be able to support an XML data type:

http://www.dbdebunk.com/lauri1.htm

(PostgreSQL is an example of a DBMS with extensible types)

Aha.

Someone's been reading DBDebunk.com again.

Yes, data integrity is one of the major considerations here. I'm willing to bet that by the time you implemented the equivalent of constraints, triggers, etc... in a system like this, you would be running no faster than a typical SQL DBMS, and you would have thousands of bugs as you reinvent the wheel. But there are even more considerations than integrity. This is language-specific, or application-specific. What do you do when you need to access your data from another application? Even if it is possible, that means you have to implement all your integrity checks again in that application.

Essentially, what this looks like is just another OO method of heirarchical (or perhaps "multi-valued") data storage. This is nothing new. It will suffer all of the historical problems the industry has had with hierarchical storage (there is a reason the relational data model was invented: the problems IBM had with hierarchical data). For example, what happens to existing data when you need to change your logical schema or business rules? The cost of re-ordering or reformatting _every_ single stored object since the beginning of your application would be ridiculous, and in some cases even impossible. How do you track dependencies? In theory, these kinds of systems will work fine, if your application stays exactly as created, and if the nature of the data doesn't change, and if no other applications are involved. In other words, NOT in the real world.

I have a nick-name for hierarchical data storaqe: "headache-ical".

OODBMSes have been thoroughly and handily debunked. For the best opinions on relational database technology, visit these hardcore guys: http://www.dbdebunk.com/

The problems with OODBMSes can be summarized so (OTOMHRN - on top of my head right now):
1) Proper relational technology can model OO-hierarchies, but the other way around is unnatural and cumbersome, if not impossible. Proper relational technology is a step up on the ladder in generalization from OO-technology. It's simply a generation or two ahead, while OODBMS is several steps backwards.

2) Proper relational technology is proven concepts from mathematics and logics, while OODBMSes are just a hack to store application data "quick'n dirty". Everything can be modelled as general relations, while OO-technology lacks the fundamentals to model *ANYTHING* and is limited and impeded by having an obligatory and *meaningless* top-to-bottom hierarchy. (You cannot have *meaning* without relations of differing types to other entities.)

3) Proper relational technology allows you to extract, convert and manipulate data in standardized methods (using query languages like SQL), in ways not thought of at the time of design. OODBMSes can only be used properly in the context of the OO-application layer, often relying on runtime data. If you need flexible solutions, you will have to spend extra time programming a specialized solution, instead of having the benefit of a fully relational query language (which unlike SQL, can express almost any problem to be solved).

4) The future is relational. Current RDBMSes do not implement true relational technology, which if they did, nothing else would be needed. The matemathics in the theories behind it would be at the programmers disposal during programming, reducing time and potential errors. Yes, it requires understanding the theory, but wouldn't you like a true DBA to do that anyways?

Don't buy into the hype, look into true relational technology and educating yourself. As for storing everything in RAM, and "saving it for the night", I wouldn't risk to have my bank-account in such a DB. Such solutions are only usable for storing non-volatile data. For non-commercial game-servers, it maybe perfect.

> What's the problem with SQL

Fuller answer at The Third Manifesto, Database Debunkings and elsewhere.

But to cut a long story short, SQL does not support relational prescriptions as data independence (SQL views are not consistently updateable), nor respect relational proscriptions (undifferentiated NULLs), nor abide by the fundamental relational principles (pointers violate the Information Principle, OO extensions mess the simple domain, attribute, tuple, relation that is central to the relational model).

> on Mysql, precisely?

Its language is not proper SQL at all: it does not support transactions properly, nor has the necessary data types, and has been adding features kinda haphazardly without neither admitting to past mistakes nor presenting a clear roadmap to either SQL or the relational model. It should be called PseudoSQL, or SubSQL, or SimplerThanSQL.

I think many people are confusing Relational databases with SQL database - they are not one and the same. In fact, this site, one of the most vocal proponents of relational databases, states that none of the existing SQL databases is a true relational database. A quote from one of their articles ( "Little Relationship to Relational"):

"Not only do most practitioners think that SQL DBMSs are relational, but they actually blame the problems due to SQL's violations of, or lack of adherence to relational principles on the relational model itself!"

In my opinion, there is no reason that an object-oriented environment cannot implement the relational model, and thus be a true relational database.

A relational database engine would generate relations. Nothing else. Just relations. You could certainly build a SQL Server around a relational database engine, but neither can be the other. The problem here is that what we have is actually two servers - or rather, we should have two. SQL can generate relations, but there is nothing compelling the author to contain himself to relational activities. You can do things like sorting and grouping. A pure relational database engine can only form products, apply theta selections to them, and project relations on this basis, forming projected relations. The direct consequence of limiting its capabilities to product-select-project (PSP) is provable correctness. Not many branches of computer science can boast that. In my less-than-humble opinion, only an idiot would compromise it. Apparently our industry is full of idiots.

Or maybe not. There are very good reasons for wanting to do certain thoroughly non-relational things at the server. Like sorting. If you want to sort and re-sort - we often do, and usually in a hurry - you need indices. At the server you have them. At the client you must either generate them or truck them all the way from the server. Drawing the line

Another good resource is the Database Debunking web page. Browse through the "Content" section to see many discussions on various data models.

Yes, this is absolutely correct. Look into Date & Darwen's "The Third Manifesto" and/or read some of the articles at dbdebunk.com.

> SQL - This example is a straw man. The problem with SQL is not the abstraction it provides, but the complexity of dealing with unknown table sizes when you are trying to write fast generic queries.

Correct conclusion, wrong reasons. The problem with SQL is not the complexity of getting good performance, but the low quality of its abstraction. A truly relational system might even be slow, but it would be uniformally, thus predictably and treatably, slow.

A relational system should never give different performance for different syntax if the result is the same. The optimizer should know the structure and sizes of all objects and always get the same access path if the result of the expression is the same. SQL fails because many SQL constructs are ill-defined or even wrong.

All performance tuning must be done by DBAs at the mapping between the logical and physical schemas, but SQL makes that impossible, specially after SQL:1999. See DBDebunk for more details.

> There's been a trend away from non-leaky abstractions.
[...]
> SQL offers an abstraction for which the underlying database layout is irrelevant except for performance issues.

If you are right, it means we will get a real relational DBMS soon. Wait, it already exists, but no one cares.

Moral: a trend exists when there is awareness not only the problem, but also of possible solutions. Everyone knows SQL is a problem, but most people think the solution is OO, so the real solution is overlooked.

I have found http://www.dbdebunk.com/ very informative. If you insist on cutting down trees, I would recommend any of the books that this site links to.

There are fundamental problems with SQL. You may well be forced to work with it but you should at least know what its limitations are.

Hopefully, once you truly understand the problems with SQL, you will see the light, rebel, tell Oracle et al to go screw, and help develop some nice good Open Source alternative to the crappy SQL language.

If you disagree, you are welcome to touch me lower.

I have found http://www.dbdebunk.com/ very informative. If you insist on cutting down trees, I would recommend any of the books that this site links to.

There are fundamental problems with SQL. You may well be forced to work with it but you should at least know what its limitations are.

Hopefully, once you truly understand the problems with SQL, you will see the light, rebel, tell Oracle et al to go screw, and help develop some nice good Open Source alternative to the crappy SQL language.

If you disagree, you are welcome to touch me lower.

Having FK support does not make one a Relational DBMS. To those who are 'in the know' Oracle, MS SQL Server, even my beloved :) Sybase ASE etc are SQL-Based DBMS. SQL, to put it mildly, butchers most relational tenets and is not how Codd wanted it to work in the first place (enter IBM and SQL language).

But in the least case MySQL supports relations (tables) so it has, to some degree, a relational background. FK support is required according to Codd, but virtually all DBMS also break some of his other rules as well, so it depends on how deviant a product must be before it is declared non-relational.

> Such accusations are not very useful (nor friendly) without something more specific.

Sorry, but database field is too rich to give all the specifics in a Slashdot post. You can go to DB Debunk, Open Directory or Wiki Encyclopaedia for specifics: or better yet, buy An Introduction to Database Systems by Chris J Date.

And no, I was not caring to be much friendly. I believe people should educate themselves before publishing their thoughts to the world, and the database field has suffered much already from people who did not.

But just because you seem interested, a relational database is based on two-valued predicate logic, where predicates are expressed by n-tuples organized on relations, which are time-varying values of relation variables. This is what makes it so simple and powerful. If you break this model, as SQL did, you get something at the same time more complex and less powerful. Programming languages should adapt to it, not the other way round.

> building sets *into* the programming language may make inter-language info sharing harder

I fail to see that. Can you point to somewhere where this is demonstrated? On the contrary, if a programming language gets the relational elements right, they will be the same as in any other programming language that does the same. They would all get the data structures directly from the RDBMS. What that subtracts from tables? It is just higher level, because relations do not have ordering, duplicates, undifferentiated NULLs and all the inconsistencies of SQL.

> it would be interesting to see OO-like classes based on sets rather than trees.

Read The Third Manifesto, and make sure to buy the book too. A class, by definition, is a set. So it maps to data types on the programming language, and domains on the database. Not only maps in the sense of having some relation to, but they are identical. The inheritance thing is orthogonal, and should be done thru Specialisation by Constraint.

> Are you saying that the xBase approach is "flat"?

I said what I said, please read carefully. I said that more distant from relational than xBase would be OO and flat files, but that does not make xBase relational. It is what was called navigational in olden times. But you miss the point, because you have not yet grokked how distant SQL is from the relational model.

> One problem with strong-typing based on fields that come from the database is that if you change the schema type, then it is out of sync with the code.

But this is good! If a data type changes, code around it must change. The same comparisons are not anymore valid, for instance.

The way too keep code stable is to begin with a good data model. Granted, SQL makes this impossible by not supporting domains as required by the relational model: what it calls domains are ridiculous. But if we had real domains, and domain Specialization by Constraint, then they would be stable and precise, and seldom code would need a data type change.

> Relational databases are not going away

I sure hope not, once they arrive indeed. Up to now, we have only Alphora Dataphor, and that is not yet a full-blown DBMS, not to mention being proprietary and MS W32-only. Remember and repeat to yourself: SQL is not relational!

Be sure to read The Third Manifesto and its clear, logic, simple proposal for rich, precise, reusable type hierarchies thru Specialisation by Constraint.

An anonymous-coward poster also mentioned that mysql wouldn't be up to the task...

Uh, actually I (who claimed to be an MIS guy) thought you were trolling with the whole "PHP and MySQL" bit, so I was trolling in response. If you can't disprove every point I made in that post, you ought to visit dbdebunk.com and edjumacate yourself.

Seriously, the reason I couldn't imagine anyone seriously suggesting PHP is that HTML provides such a astoundingly poor UI.

No!

Business rules belong in the database, not in the middle tier! Databases should be application independent. You introduce too many ways to screw up your data when you enforce your rules in some tier outside the database. Think about it, if you have to implement your business rules in every application that talks to the database, what a nightmare. Yes, you could put all that into some middle tier, and make sure that any access to the database goes through that tier, but then you have to enforce that. And often, it's not via triggers or stored procedures, but I'd wager a good chunk of your business rules can be implemented through good relational design, with proper normalization and keys in place.

See www.dbdebunk.com,
Or check out any of the stuff written by C. J. Date or Fabian Pascal.

"I moved to PGSQL because it was a 'real RDBMS.'"

Although my vote would be for Postgresql as well, by some standards (C.J. Date, and Fabian Pascal--see http://www.dbdebunk.com) Postgres isn't a 'real' RDBMS either. By those same standards, Oracle doesn't qualify as well. They fall into the class of database systems known as SQL-DBMSs. SQL wasn't fully relational to start with.

Most of what's on the market today doesn't faithfully implement the relational model--and mainly because of everyone's dependence on SQL.

The Alphora Dataphor DAE is the first relational database management system since IBM BS12 and the QUEL version of Postgres.

It was coded for MS .Net, thus it should be readily portable to Ximian Mono or GNUs & Southern Storms DotGNU Portable.Net.

If such a potentially useful software became publicized and free software, we could have a really innovating no Marketspeak intended , probably killer application the proprietary vendors would have a hard time scrambling after.

And that with unreprochable theoretical foundations attested by the luminars of the field.

The Alphora Dataphor DAE is the first relational database management system since IBM BS12 and the QUEL version of Postgres.

It was coded for MS .Net, thus it should be readily portable to Ximian Mono or GNUs & Southern Storms DotGNU Portable.Net.

If such a potentially useful software became publicized and free software, we could have a really innovating no Marketspeak intended , probably killer application the proprietary vendors would have a hard time scrambling after.

And that with unreprochable theoretical foundations attested by the luminars of the field.

The problem with XML is that it diverges into two dinstict worst cases. One requires and infinite amount of memory, the other and infinite amount of time.

Yeah, yeah, and since it's impossible to tell if a program will halt or run forever, it must be impossible to write a debugger.

Who cares about theoretical worst cases?

What's important is the fact that escaping works, Unicode works and markup works. XML should be used as a glorified ASCII.

It's not just used that way, and that's the real problem. People are trying to turn XML into a database standard. See this article, this one, this one, this one, or this. All are from the excellent dbdebunk.com site.

The one book to have about databases is Christopher J Date’s An Introduction to Database Systems, 7th edition, Addison-Wesley 1.999. The edition is relevant, because it includes recent, fundamental work about type inheritance and other fundaments for relational databases supporting OO programming.

> oop.ismad.com

Hehe... some fun stuff there. I especially agree with your take on the limitations of trees. One of my pet peeves.

If you are into thinking about set mathematics, then you might enjoy reading from the guys at http://www.dbdebunk.com/. They also have some very pointed discussions about OOP and OODBMS.

> You don't even need OO

True enough. Abstracting a database layer in PHP is child's play, with or without OO. In fact, even if you use one of those shiny OO abstraction layers that are so popular in PHP now, you should really be doing some project-specific abstraction anyway. At least, for larger, complex projects.

1. As a desktop database or as a client front-end for an enterprise database, MS Access is an EXCELLENT product. It provides support for all features needed to produce well-normalized databases, has the ability to link to and use many data sources (xbase, jet, oracle, ms sql server, text files, excel, lotus notes, to name a few), a very good report writer, and has an excellent 4GL environment. Access is one of Microsoft's better products. It iss a TALL order for the open source community to even meet, let alone exceed!

MS-Access has had problems when it is misused. This is especially the case when it is adopted as a "poor man's" enterprise database for web sites. If your site has more than a 5 concurrent users, it makes sense to move to something like MS SQL Server.

2. MySQL is limited, especially in its lack of support for stored procedures and referential integrity. The Database Expert Fabian Pascal has made some good points on MySQL's failings at his site DB Debunking http://www.dbdebunk.com/

I followed the link to your home page, and I must say I was impressed.

Nevertheless, I must say you will get only as far as SQL goes, and SQL doesn’t really gives you the full benefits of the relational model. While your ideas are certainly very interesting, they would be potentially even more powerful if they were recast in terms not of SQL tables, but of relations.

> But DB2 is generally *relational*, not OO.

IBM DB2 is SQL. While SQL claims to be relational, it isn’t. There are only two faithful implementations of the relational model, one is obsolete, the other is still a beta.

> can't remember if the proper name for the original mk was Mica or Prism

Microsoft oriented press usually have little regard for jornalistic quality standards, but as far as I remember this article is correct: Prism was the hardware, Mica the OS for Digital’s ‘future system’ that failed, prompting Cutler to go work at Microsoft. Interesting that these ‘future systems’ have a tendency of going seriously wrong: IBM’s gave us SQL instead of relational, and that is worse than Windows!.

1. You didn't do your homework, did you? Ever heard of gnome-apt, console-apt? There are probably others also. Also this is barely relevant at a business desktop environment, where you would want control over the configurations, and do everything from a central location anyway, probably sharing /usr and /home from central file servers at each LAN.

2. You miss the point... obviously RH is not "horrible", after all it's still GNU/Linux. The point is that it is suboptimal: forking, not sending patches to upstream maitainers, relying on proprietary software, calling it just Linux -- not only the base system is the GNU one, there's much more to the kernel there. And the point is that commercial enterprises relying in rpm formats tend to duplicate efforts at the distribution level, while companies relying on Debian -- The Distro Formerly Known As Corel, Progeny, Libranet -- tend to contribute more and avoiding forks. Even forks themselves in Debian are more of "unstable-unstable branches" whose objective is merging back to Debian. Last but not least, Debian is more distributed -- there's a community of individuals, projects and companies doing the distribution itself, companies to support, to burn and/or distribute CDs, and so on.

3. Business friendly all too much often means technically mediocre... witness the Database Debunkings of SQL, and similar comparisions of academic or community initiatives like functional programming against company-sponsored buzzwOOrd-compliant technologies...

Anyway which are the "so many Debian-based distros"? They are much less in number than rpm ones, they are far less divisive, and tend to exist for a shorter time, folding back when their technologies get integrated into the main distro -- witness Progeny and Debian-jp; on the other hand some of them are simply specializations, like Debian-jr and demudi.

You also miss the point that Debian only makes the distribution; support is left to independent companies. In fact Debian welcomes these independent support companies, as well as derived distributions.

4. You must be too young... many billionaire companies have came by and went away in the History of Computing, few remained: basically IBM and HP... Compaq and Microsoft are too young and bad models anyway. Meanwhile since non-profit organizations began in the late sixties ACM, Usenix, the X Consortium (and its son XFree), the FSF all still exist and are in good health (all right, X and the FSF are also younger)... not to mention informal organizations that create and maintain software like TeX and LaTeX, the Linux kernel itself, and so on.

The fear about organizations and reliance on business is mislead, because business are also organizations -- the difference is between profit and non-profit. Non-profit organizations tend to be much better targetted, focusing on specific goals and existing as long as the goal is worthy pursuing -- perhaps less, perhaps longer, but not as erratic as profit organizations. Witness the churches and national states as opposed to the Leagues, the Hansa, the Companies of the Indias, and so on. This fear is due to the irrational fear of the other, and so should be confronted, not regarded.

Finally, you subestimate the complexity of software... the simple fact is that 2.4 still not stable, no matter how much testing.

First, obviously any minimally decent relational-like, even SQL database is better than any non-relational (object, hierarchical) one &ndash& before proceeding please read Database Debunkings. So substituting MS SQL Server for NTFS should be A Good Thing(tm).

Second, SQL isn't a good implementation of the relational model... so it doesn't matter what's the management system behind it (MS SQL, DB/2, Oracle), if it's SQL it's not ideal -- a really relational system should be faster, have less arbitrary restrictions, and do everything a hierarchical or OO database management system could possibly do. But still SQL would be far better than any hierarchical or OO filesystem.

Third, as a SQL implementation MS SQL isn't quite ideal, and Jet (Access, Exchange, the registry) is simply horrible. So while this will probably improve Windows feature-wise, it will make Windows even more bloated, perhaps even less stable and slower. But if they manage to fix the database engine, it could even make Windows faster and more stable.

Fourth, this has already been done. By Oracle. It's called iFS (sorry but I couldn't access Oracle site to get a better page), and exports SMB and other filesystems. As Oracle is too big, proprietary and isn't even SQL compliant, and iFS does not support NFS, I didn't care much about it, but I may have an opportunity to use it as a kind of version control for binaries very shortly.

Last but not least, this idea should be adopted by the Free Software comunity ASAP. We should create a really relational implementation, ideally based on Tutorial D -- there's already a SourceForge project, but nothing has been done up to now. Then this would became a Hurd filesystem (because of Hurd's flexibility) to be ported to Linux. That would blow Longhorn out of water.

If we don't do it better than Microsoft, and if computers continue to get faster and Windows less unreliable, we could have serious competition, say some two or three generations after Longhorn.

SQL is crippling because it doesn't implements the full relational model, as you can read in DBDebunk.
--
Leandro Guimarães Faria Corsetti Dutra
DBA, SysAdmin

Don't throw away the baby with the water. The limitations of SQL are due to it not supporting the full relational model, and to its arbitrary limitations.

We need a properly implemented relational database language -- probably based on Chris J Date's and Hugh Darwen's The Third Manifesto.

Going for any hierarchical model, be it an OODBMS or a filesystem based one, is forfeiting all the relational model advantages because you find SQL, which isn't really relational, lacking... and you get nothing that any proper D wouldn't offer.

Don't throw away the baby with the water. The limitations of SQL are due to it not supporting the full relational model, and to its arbitrary limitations.

We need a properly implemented relational database language -- probably based on Chris J Date's and Hugh Darwen's The Third Manifesto.

Going for any hierarchical model, be it an OODBMS or a filesystem based one, is forfeiting all the relational model advantages because you find SQL, which isn't really relational, lacking... and you get nothing that any proper D wouldn't offer.

> It is interesting to see that a posting with so many wrong statements receives such a high rating here.

It seems that each of us have different ideas about what's right and what's wrong, so let's get over such self-serving statements and go over the issues at hand.

> Reality is object-oriented. We use objects in our modern programming languages.

As far as I know reality may be represented by objects. It makes no sense saying that reality is this or that oriented, since apart from God no one can ever know what He was oriented to when he did create.

Seriously, reality can be represented by objects. It can be represented by relations also. Even if objects are convenient for some programming domains, it isn't for data storage and retrieve, except if your program will never change *and* it is object-oriented. It's surprising to learn how many programming gurus, and specially database gurus, steer clear of object-oriented programming, rather keeping with other models of programming like the functional or the structured ones.

> Why should we flatten these out to tables with unnecessary keys...

Why should we complicate relations with objects, if we can store data-independently?

Please, you are repeating OO jargon without explaining nothing to me. As I never saw much sense in OOness, I will need better teaching than this.

> Relations between objects can be maintained transparently within the database.

This isn't the issue. The issue is that these relationships are maintained physically in the database, thus getting against the Information Principle. In contrast, relational databases have no physical links. All relationships are a result of data kept in common by different relations. I won't explain here what is a relation; you should read Chris J Date's An Introduction to Database Systems for that.

> This is common-sense and there is no need to write scientific papers about it.

It is common sense for uncommon OO programmers, not for DAs, DBAs, functional or other non-OO programmers and common people like me.

The fundamental issue of OO is that is an over-extension of some simple programming rules-of-thumb. When they got the full extension they have today they got much more complicated than the surprisingly simple scientific papers that were published about relational database model theory, like E F Codd's paper.

> You can design data by writing classes in your respective programming language.

Not so fast. I want my data in my database, in a well defined and theoretically sound *data* sublanguage, not only in a programming language.

> [independence of the logical and physical layers of your database]

> Where do you need tables here?
> Class members define properties.
> Methods define behaviour.

If you want to compare relational databases to anything else, it is better to think relations, not tables nor entities or relationships.

Seriously again, relations are a logical representation. With this logical representation of data at users' (and programmers') hands, you can lay your data physically whatever way you want, even by using pointers if you like. This way you can optimise the physical layer for performance or availability or thoroughput or whatever balance of whatever goals, while keeping data logically organized, easily accessible and readily available to access plans created by a good query optimizer.

> [shifting the performance optimization issues to the DBMS' optimizer]

> Object databases also use optimizers to analyze queries.

But your access paths are predefined. The user has little freedom to discover relationships between different data, ad hoc queries will have weird access paths and little possibility of optimization. And if you ever need a schema change, you will have to rewrite lots of queries.

> [any schema change do not only need an application recompilation]

> There are object databases that manage schema versioning automatically.
> Our product simply stores a superset of all used schemas.

This won't fly. This is schema accumulation, not change. You will have data stored in many different ways, and users will find ways of wanting schema changes that can't be efficiently stored anyway.

> Wrong. Our object database is not multi-user as of today

Then you haven't even faced the very issues relational theory was created to solve. First read and understand Codd's paper above, then we can talk. Write me privately by email, or better yet read also The Third Manifesto, then Database Debunkings, and then we can talk.

> By the way: Do you typically have different tables for different users?

Even in quasi-relational SQL each user has its own schema. And this schema can contain base relations, derived relations including named ones (views), and synonyms.

> [rethink the data access path]

> Reengineering is a terrible problem with relational databases.

I've been working for years with weak, quasi-relational SQL and even with this poor tool I've not faced this problem of "reengineering". I now you have a product to sell, so it may be hard to forget marketspeak, even more actually acknowledging some fault, but what do you mean really by reengineering? AFAIK this is a management nineties' regurgitation of Operations and Methods ill digested with some Data Processing thrown in, not a CS word.

> Strings are not typesafe, so you have to parse the entire application

Stop! Stop! You're killing me!

Seriously, strings are strings. If SQL doesn't do all type checking it could, it is no fault of strings per se, much less the relational model. And it has no bearing in relational data independence. When you change a data type, you have a different relation, there's no way of shielding a typesafe language from that. Some data sublanguage may provide some shortcuts to such modifications, and even do some automatic type casting, but this is not a database model issue.

> [which should give us practically all of the advantages of OODBMSs without their cons]

> We are going the other way. We want to provide all the
> relational functionality that you wish with
> our object database. We might finally end up
> with very similar engines.

Not at all, because you haven't yet understood the fundamentals of the field.

> It is interesting to see that a posting with so many wrong statements receives such a high rating here.

It seems that each of us have different ideas about what's right and what's wrong, so let's get over such self-serving statements and go over the issues at hand.

> Reality is object-oriented. We use objects in our modern programming languages.

As far as I know reality may be represented by objects. It makes no sense saying that reality is this or that oriented, since apart from God no one can ever know what He was oriented to when he did create.

Seriously, reality can be represented by objects. It can be represented by relations also. Even if objects are convenient for some programming domains, it isn't for data storage and retrieve, except if your program will never change *and* it is object-oriented. It's surprising to learn how many programming gurus, and specially database gurus, steer clear of object-oriented programming, rather keeping with other models of programming like the functional or the structured ones.

> Why should we flatten these out to tables with unnecessary keys...

Why should we complicate relations with objects, if we can store data-independently?

Please, you are repeating OO jargon without explaining nothing to me. As I never saw much sense in OOness, I will need better teaching than this.

> Relations between objects can be maintained transparently within the database.

This isn't the issue. The issue is that these relationships are maintained physically in the database, thus getting against the Information Principle. In contrast, relational databases have no physical links. All relationships are a result of data kept in common by different relations. I won't explain here what is a relation; you should read Chris J Date's An Introduction to Database Systems for that.

> This is common-sense and there is no need to write scientific papers about it.

It is common sense for uncommon OO programmers, not for DAs, DBAs, functional or other non-OO programmers and common people like me.

The fundamental issue of OO is that is an over-extension of some simple programming rules-of-thumb. When they got the full extension they have today they got much more complicated than the surprisingly simple scientific papers that were published about relational database model theory, like E F Codd's paper.

> You can design data by writing classes in your respective programming language.

Not so fast. I want my data in my database, in a well defined and theoretically sound *data* sublanguage, not only in a programming language.

> [independence of the logical and physical layers of your database]

> Where do you need tables here?
> Class members define properties.
> Methods define behaviour.

If you want to compare relational databases to anything else, it is better to think relations, not tables nor entities or relationships.

Seriously again, relations are a logical representation. With this logical representation of data at users' (and programmers') hands, you can lay your data physically whatever way you want, even by using pointers if you like. This way you can optimise the physical layer for performance or availability or thoroughput or whatever balance of whatever goals, while keeping data logically organized, easily accessible and readily available to access plans created by a good query optimizer.

> [shifting the performance optimization issues to the DBMS' optimizer]

> Object databases also use optimizers to analyze queries.

But your access paths are predefined. The user has little freedom to discover relationships between different data, ad hoc queries will have weird access paths and little possibility of optimization. And if you ever need a schema change, you will have to rewrite lots of queries.

> [any schema change do not only need an application recompilation]

> There are object databases that manage schema versioning automatically.
> Our product simply stores a superset of all used schemas.

This won't fly. This is schema accumulation, not change. You will have data stored in many different ways, and users will find ways of wanting schema changes that can't be efficiently stored anyway.

> Wrong. Our object database is not multi-user as of today

Then you haven't even faced the very issues relational theory was created to solve. First read and understand Codd's paper above, then we can talk. Write me privately by email, or better yet read also The Third Manifesto, then Database Debunkings, and then we can talk.

> By the way: Do you typically have different tables for different users?

Even in quasi-relational SQL each user has its own schema. And this schema can contain base relations, derived relations including named ones (views), and synonyms.

> [rethink the data access path]

> Reengineering is a terrible problem with relational databases.

I've been working for years with weak, quasi-relational SQL and even with this poor tool I've not faced this problem of "reengineering". I now you have a product to sell, so it may be hard to forget marketspeak, even more actually acknowledging some fault, but what do you mean really by reengineering? AFAIK this is a management nineties' regurgitation of Operations and Methods ill digested with some Data Processing thrown in, not a CS word.

> Strings are not typesafe, so you have to parse the entire application

Stop! Stop! You're killing me!

Seriously, strings are strings. If SQL doesn't do all type checking it could, it is no fault of strings per se, much less the relational model. And it has no bearing in relational data independence. When you change a data type, you have a different relation, there's no way of shielding a typesafe language from that. Some data sublanguage may provide some shortcuts to such modifications, and even do some automatic type casting, but this is not a database model issue.

> [which should give us practically all of the advantages of OODBMSs without their cons]

> We are going the other way. We want to provide all the
> relational functionality that you wish with
> our object database. We might finally end up
> with very similar engines.

Not at all, because you haven't yet understood the fundamentals of the field.

> It is interesting to see that a posting with so many wrong statements receives such a high rating here.

It seems that each of us have different ideas about what's right and what's wrong, so let's get over such self-serving statements and go over the issues at hand.

> Reality is object-oriented. We use objects in our modern programming languages.

As far as I know reality may be represented by objects. It makes no sense saying that reality is this or that oriented, since apart from God no one can ever know what He was oriented to when he did create.

Seriously, reality can be represented by objects. It can be represented by relations also. Even if objects are convenient for some programming domains, it isn't for data storage and retrieve, except if your program will never change *and* it is object-oriented. It's surprising to learn how many programming gurus, and specially database gurus, steer clear of object-oriented programming, rather keeping with other models of programming like the functional or the structured ones.

> Why should we flatten these out to tables with unnecessary keys...

Why should we complicate relations with objects, if we can store data-independently?

Please, you are repeating OO jargon without explaining nothing to me. As I never saw much sense in OOness, I will need better teaching than this.

> Relations between objects can be maintained transparently within the database.

This isn't the issue. The issue is that these relationships are maintained physically in the database, thus getting against the Information Principle. In contrast, relational databases have no physical links. All relationships are a result of data kept in common by different relations. I won't explain here what is a relation; you should read Chris J Date's An Introduction to Database Systems for that.

> This is common-sense and there is no need to write scientific papers about it.

It is common sense for uncommon OO programmers, not for DAs, DBAs, functional or other non-OO programmers and common people like me.

The fundamental issue of OO is that is an over-extension of some simple programming rules-of-thumb. When they got the full extension they have today they got much more complicated than the surprisingly simple scientific papers that were published about relational database model theory, like E F Codd's paper.

> You can design data by writing classes in your respective programming language.

Not so fast. I want my data in my database, in a well defined and theoretically sound *data* sublanguage, not only in a programming language.

> [independence of the logical and physical layers of your database]

> Where do you need tables here?
> Class members define properties.
> Methods define behaviour.

If you want to compare relational databases to anything else, it is better to think relations, not tables nor entities or relationships.

Seriously again, relations are a logical representation. With this logical representation of data at users' (and programmers') hands, you can lay your data physically whatever way you want, even by using pointers if you like. This way you can optimise the physical layer for performance or availability or thoroughput or whatever balance of whatever goals, while keeping data logically organized, easily accessible and readily available to access plans created by a good query optimizer.

> [shifting the performance optimization issues to the DBMS' optimizer]

> Object databases also use optimizers to analyze queries.

But your access paths are predefined. The user has little freedom to discover relationships between different data, ad hoc queries will have weird access paths and little possibility of optimization. And if you ever need a schema change, you will have to rewrite lots of queries.

> [any schema change do not only need an application recompilation]

> There are object databases that manage schema versioning automatically.
> Our product simply stores a superset of all used schemas.

This won't fly. This is schema accumulation, not change. You will have data stored in many different ways, and users will find ways of wanting schema changes that can't be efficiently stored anyway.

> Wrong. Our object database is not multi-user as of today

Then you haven't even faced the very issues relational theory was created to solve. First read and understand Codd's paper above, then we can talk. Write me privately by email, or better yet read also The Third Manifesto, then Database Debunkings, and then we can talk.

> By the way: Do you typically have different tables for different users?

Even in quasi-relational SQL each user has its own schema. And this schema can contain base relations, derived relations including named ones (views), and synonyms.

> [rethink the data access path]

> Reengineering is a terrible problem with relational databases.

I've been working for years with weak, quasi-relational SQL and even with this poor tool I've not faced this problem of "reengineering". I now you have a product to sell, so it may be hard to forget marketspeak, even more actually acknowledging some fault, but what do you mean really by reengineering? AFAIK this is a management nineties' regurgitation of Operations and Methods ill digested with some Data Processing thrown in, not a CS word.

> Strings are not typesafe, so you have to parse the entire application

Stop! Stop! You're killing me!

Seriously, strings are strings. If SQL doesn't do all type checking it could, it is no fault of strings per se, much less the relational model. And it has no bearing in relational data independence. When you change a data type, you have a different relation, there's no way of shielding a typesafe language from that. Some data sublanguage may provide some shortcuts to such modifications, and even do some automatic type casting, but this is not a database model issue.

> [which should give us practically all of the advantages of OODBMSs without their cons]

> We are going the other way. We want to provide all the
> relational functionality that you wish with
> our object database. We might finally end up
> with very similar engines.

Not at all, because you haven't yet understood the fundamentals of the field.

> It is interesting to see that a posting with so many wrong statements receives such a high rating here.

It seems that each of us have different ideas about what's right and what's wrong, so let's get over such self-serving statements and go over the issues at hand.

> Reality is object-oriented. We use objects in our modern programming languages.

As far as I know reality may be represented by objects. It makes no sense saying that reality is this or that oriented, since apart from God no one can ever know what He was oriented to when he did create.

Seriously, reality can be represented by objects. It can be represented by relations also. Even if objects are convenient for some programming domains, it isn't for data storage and retrieve, except if your program will never change *and* it is object-oriented. It's surprising to learn how many programming gurus, and specially database gurus, steer clear of object-oriented programming, rather keeping with other models of programming like the functional or the structured ones.

> Why should we flatten these out to tables with unnecessary keys...

Why should we complicate relations with objects, if we can store data-independently?

Please, you are repeating OO jargon without explaining nothing to me. As I never saw much sense in OOness, I will need better teaching than this.

> Relations between objects can be maintained transparently within the database.

This isn't the issue. The issue is that these relationships are maintained physically in the database, thus getting against the Information Principle. In contrast, relational databases have no physical links. All relationships are a result of data kept in common by different relations. I won't explain here what is a relation; you should read Chris J Date's An Introduction to Database Systems for that.

> This is common-sense and there is no need to write scientific papers about it.

It is common sense for uncommon OO programmers, not for DAs, DBAs, functional or other non-OO programmers and common people like me.

The fundamental issue of OO is that is an over-extension of some simple programming rules-of-thumb. When they got the full extension they have today they got much more complicated than the surprisingly simple scientific papers that were published about relational database model theory, like E F Codd's paper.

> You can design data by writing classes in your respective programming language.

Not so fast. I want my data in my database, in a well defined and theoretically sound *data* sublanguage, not only in a programming language.

> [independence of the logical and physical layers of your database]

> Where do you need tables here?
> Class members define properties.
> Methods define behaviour.

If you want to compare relational databases to anything else, it is better to think relations, not tables nor entities or relationships.

Seriously again, relations are a logical representation. With this logical representation of data at users' (and programmers') hands, you can lay your data physically whatever way you want, even by using pointers if you like. This way you can optimise the physical layer for performance or availability or thoroughput or whatever balance of whatever goals, while keeping data logically organized, easily accessible and readily available to access plans created by a good query optimizer.

> [shifting the performance optimization issues to the DBMS' optimizer]

> Object databases also use optimizers to analyze queries.

But your access paths are predefined. The user has little freedom to discover relationships between different data, ad hoc queries will have weird access paths and little possibility of optimization. And if you ever need a schema change, you will have to rewrite lots of queries.

> [any schema change do not only need an application recompilation]

> There are object databases that manage schema versioning automatically.
> Our product simply stores a superset of all used schemas.

This won't fly. This is schema accumulation, not change. You will have data stored in many different ways, and users will find ways of wanting schema changes that can't be efficiently stored anyway.

> Wrong. Our object database is not multi-user as of today

Then you haven't even faced the very issues relational theory was created to solve. First read and understand Codd's paper above, then we can talk. Write me privately by email, or better yet read also The Third Manifesto, then Database Debunkings, and then we can talk.

> By the way: Do you typically have different tables for different users?

Even in quasi-relational SQL each user has its own schema. And this schema can contain base relations, derived relations including named ones (views), and synonyms.

> [rethink the data access path]

> Reengineering is a terrible problem with relational databases.

I've been working for years with weak, quasi-relational SQL and even with this poor tool I've not faced this problem of "reengineering". I now you have a product to sell, so it may be hard to forget marketspeak, even more actually acknowledging some fault, but what do you mean really by reengineering? AFAIK this is a management nineties' regurgitation of Operations and Methods ill digested with some Data Processing thrown in, not a CS word.

> Strings are not typesafe, so you have to parse the entire application

Stop! Stop! You're killing me!

Seriously, strings are strings. If SQL doesn't do all type checking it could, it is no fault of strings per se, much less the relational model. And it has no bearing in relational data independence. When you change a data type, you have a different relation, there's no way of shielding a typesafe language from that. Some data sublanguage may provide some shortcuts to such modifications, and even do some automatic type casting, but this is not a database model issue.

> [which should give us practically all of the advantages of OODBMSs without their cons]

> We are going the other way. We want to provide all the
> relational functionality that you wish with
> our object database. We might finally end up
> with very similar engines.

Not at all, because you haven't yet understood the fundamentals of the field.

The issue is that OODBMSs do not conform neither to current database best practices, nor to theory.

Relating to best practices, you should know already from other, better-rated comments in this thread: you should design your data before your application, OODBMSs make it hard; you should strive for independence of the logical and physical layers of your database, keeping data independence and shifting the performance optimization issues to the DBMS' optimizer; OIDs hinder the designation of candidate keys, of which the primary key is a special case, and thus hinder a lot of data integrity checkings that should be done by referential integrity. And we could go on and on.

As for the practical implications of not conforming to these best practices, any schema change do not only need an application recompilation, but also that you rethink the data access path (also known as a query's access plan); you won't be able to keep several logical schemas to different users, and the identity of the user's view with the physical layout will force you to optimize only for the most common case, instead of leaving it up to the DBMS to create the best access plans.

All this is much better explained in Database Debunkings, a site co-maintained by Chris J Date, author of the best database books I've ever read; you can find a list of his available books also there.

As for theory, there is no real substitute for the relational database model theory. As Linus Torvalds thinks that microkernels were a good idea but misguided, wielding no practical nor theoretical improvements, so OODBMSs sounds nice but offer no real improvements over RDBMSs. This is not to say that everything you will ever need will be handled properly by your SQL DBMS. The point is exactly that people have went for OODBMSs because they thought that SQL was relational, and found it wanting. The problem is that SQL never was truly relational, just an approximation of it. Date has a whole book on it, called The Third Manifesto.

Summing up, what I am really trying to find is some proper implementation of the relational database model ideals, which should give us practically all of the advantages of OODBMSs without their cons. I have just been informed of Suneido, but have not investigated it fully... it's a pity it is Win32, not POSIX.

The issue is that OODBMSs do not conform neither to current database best practices, nor to theory.

Relating to best practices, you should know already from other, better-rated comments in this thread: you should design your data before your application, OODBMSs make it hard; you should strive for independence of the logical and physical layers of your database, keeping data independence and shifting the performance optimization issues to the DBMS' optimizer; OIDs hinder the designation of candidate keys, of which the primary key is a special case, and thus hinder a lot of data integrity checkings that should be done by referential integrity. And we could go on and on.

As for the practical implications of not conforming to these best practices, any schema change do not only need an application recompilation, but also that you rethink the data access path (also known as a query's access plan); you won't be able to keep several logical schemas to different users, and the identity of the user's view with the physical layout will force you to optimize only for the most common case, instead of leaving it up to the DBMS to create the best access plans.

All this is much better explained in Database Debunkings, a site co-maintained by Chris J Date, author of the best database books I've ever read; you can find a list of his available books also there.

As for theory, there is no real substitute for the relational database model theory. As Linus Torvalds thinks that microkernels were a good idea but misguided, wielding no practical nor theoretical improvements, so OODBMSs sounds nice but offer no real improvements over RDBMSs. This is not to say that everything you will ever need will be handled properly by your SQL DBMS. The point is exactly that people have went for OODBMSs because they thought that SQL was relational, and found it wanting. The problem is that SQL never was truly relational, just an approximation of it. Date has a whole book on it, called The Third Manifesto.

Summing up, what I am really trying to find is some proper implementation of the relational database model ideals, which should give us practically all of the advantages of OODBMSs without their cons. I have just been informed of Suneido, but have not investigated it fully... it's a pity it is Win32, not POSIX.

The issue is that OODBMSs do not conform neither to current database best practices, nor to theory.

Relating to best practices, you should know already from other, better-rated comments in this thread: you should design your data before your application, OODBMSs make it hard; you should strive for independence of the logical and physical layers of your database, keeping data independence and shifting the performance optimization issues to the DBMS' optimizer; OIDs hinder the designation of candidate keys, of which the primary key is a special case, and thus hinder a lot of data integrity checkings that should be done by referential integrity. And we could go on and on.

As for the practical implications of not conforming to these best practices, any schema change do not only need an application recompilation, but also that you rethink the data access path (also known as a query's access plan); you won't be able to keep several logical schemas to different users, and the identity of the user's view with the physical layout will force you to optimize only for the most common case, instead of leaving it up to the DBMS to create the best access plans.

All this is much better explained in Database Debunkings, a site co-maintained by Chris J Date, author of the best database books I've ever read; you can find a list of his available books also there.

As for theory, there is no real substitute for the relational database model theory. As Linus Torvalds thinks that microkernels were a good idea but misguided, wielding no practical nor theoretical improvements, so OODBMSs sounds nice but offer no real improvements over RDBMSs. This is not to say that everything you will ever need will be handled properly by your SQL DBMS. The point is exactly that people have went for OODBMSs because they thought that SQL was relational, and found it wanting. The problem is that SQL never was truly relational, just an approximation of it. Date has a whole book on it, called The Third Manifesto.

Summing up, what I am really trying to find is some proper implementation of the relational database model ideals, which should give us practically all of the advantages of OODBMSs without their cons. I have just been informed of Suneido, but have not investigated it fully... it's a pity it is Win32, not POSIX.

The issue is that OODBMSs do not conform neither to current database best practices, nor to theory.

Relating to best practices, you should know already from other, better-rated comments in this thread: you should design your data before your application, OODBMSs make it hard; you should strive for independence of the logical and physical layers of your database, keeping data independence and shifting the performance optimization issues to the DBMS' optimizer; OIDs hinder the designation of candidate keys, of which the primary key is a special case, and thus hinder a lot of data integrity checkings that should be done by referential integrity. And we could go on and on.

As for the practical implications of not conforming to these best practices, any schema change do not only need an application recompilation, but also that you rethink the data access path (also known as a query's access plan); you won't be able to keep several logical schemas to different users, and the identity of the user's view with the physical layout will force you to optimize only for the most common case, instead of leaving it up to the DBMS to create the best access plans.

All this is much better explained in Database Debunkings, a site co-maintained by Chris J Date, author of the best database books I've ever read; you can find a list of his available books also there.

As for theory, there is no real substitute for the relational database model theory. As Linus Torvalds thinks that microkernels were a good idea but misguided, wielding no practical nor theoretical improvements, so OODBMSs sounds nice but offer no real improvements over RDBMSs. This is not to say that everything you will ever need will be handled properly by your SQL DBMS. The point is exactly that people have went for OODBMSs because they thought that SQL was relational, and found it wanting. The problem is that SQL never was truly relational, just an approximation of it. Date has a whole book on it, called The Third Manifesto.

Summing up, what I am really trying to find is some proper implementation of the relational database model ideals, which should give us practically all of the advantages of OODBMSs without their cons. I have just been informed of Suneido, but have not investigated it fully... it's a pity it is Win32, not POSIX.