Slashdot Mirror

producing Google SQL to compete with MS Access

Here's hoping they just buy Alphora and package Dataphor with Ajax for portal integration. Thus (or by creating some other D-class database language implementation) they could give us a sanitized SQL to avoid its many pitfalls, while having a much more powerful and simple native database engine and language.

Take a look at Alphora Dataphor. While it is not an end-user tool, it has the potential to lower your development costs so much you will be able to actually serve your users.

Present a working system that really is relational

There are Alphora Dataphor (federated), Duro (library), and Rel (in development). Not to mention former systems like G-Exec and IBM BS/12.

Hans had produced a real advanced working filesystem

But he can't justify it as being better than an RDBMS.

But searching sucks, and I depend on Evolution to do virtual folders. I'd love it even more if my email server was actually a true RDBMS where I could have, besides the traditional IMAP interface, a D (Tutorial D or D4 or something the like) language interface where I could query at will, and save my queries as views that would show up in IMAP as (virtual) folders.

BTW, even non-relational ISO SQL would be so much better than what we have now.

Tutorial D with a truly relational rdbms has already been implemented. The company is Alphora. The product is Dataphor. see http://www.alphora.com/

To see the solution to almost all of the problems identified by Pascal, Date, Darwin and Codd please checkout Dataphor from Alphora. I am a user of their project and it is a marvel. It uses any vendor's DBMS for storage and heavy lifting, but adds untop of it true relational lanaguage and constructs. The system is so highly formalized that Dataphor provides *instant* derived user interfaces for all your tables in your existing database. After taking a few days to supply the missing information about your data that you currently cannot do in your DBMS the instant UI knows how to display all tables and forms in a logical workflow. It also handles all form validation and referencial integrity. If you change your database schema the UI is automatically updated because it is *derived*. It is not the result of some lame MS Access style wizard.

> Can you (or someone else more clueful than I) explain it again in a manner assuming less cluefulness on the part of the reader?

I really haven't the time. About data I'd point you to some reading materials: the books mentioned on The Third Manifesto, DBDebunk, some articles at DMoz and an implementation with documentation; about OSs, the GNU Hurd site seems to be unreachable now.

> This slashdot posting is one of several instances in which Miguel has publicly spread FUD against Portable.Net

Very interesting posting, and an eye-opener. I for one don't care about non-copyleft software, and I had assumed Mono was GNU LGPL.

So the question now becomes, I was planning on a Mono port of Alphora Dataphor, which unfortunately is proprietary, but it is the only package I found capable of doing what I want in the middle term. I haven't started anything yet, but I was under the impression that Mono was the way to go, with their implementations of a PostgreSQL adaptor and ASP.Net. Does DotGNU and Portable.Net could support such a port in, say, one or two years from now?

That said, in the middle of FUD that post has some interesting claims, like impractible goals of DotGNU and you reading Rotor code. And there isn't any specific answer attached to this... would you care to answer in detail now, or provide an URL?

Thanks for the eye-opener.

While I agree with a lot of what you are saying, it sounds like this guy is interested in making use of a card file, not a database. I'm a huge proponent of proper relational design (and keep an close eye on the D4 language's progress, since it corrects several flaws in the SQL language). However, there is a huge population of people who basically need an overblown card file to store some facts. Hypercard had an excellent system for doing so, and I find it odd that there are no semistructured databases similar to that available.

Asking yourself "what is truth" makes sense when you are setting relations in stone. I suspect this guy could get away with a semistructured database that dodges the bullet with flexibility and simplicity. Using a relational database to file recipes is like using a exotic sports car to drive across the street. Perhaps walking makes sense, sometimes.

I also take issue (ah the designer gets loose) that song title had better not be an attribute of a track because of covers. That statement is incomplete. Song titles can be the same, even if they are not covers, so the song title is nothing but a decoration as far as relationships. Even considering it brings peril. However, I doubt any user would be happy if they couldn't *search* upon titles. This common reasoning flaw is why I'm a huge proponent of non significant primary keys: often what appears to be useful in relationships turns out to be unreliable in the longer term.

Also, most MP3 databases only handle tracks. While attempting to handle songs, opus, introductions, etc, it would be best to handle those as a layer on top of the track table: that makes no changes to the track table, howevever. In that light, we have multiple truths, and they can be simultaniously expressed. Similar with albums: they are collections of CDs, meaning two layer, "CD" and "Album".

In regards to artist being an attribute of a track or song, if song is a collection of one or more tracks, I would be careful about not giving the flexability to store it at the track level: if the three sopranos sang three parts of a song, and they broke it into three tracks, I would lean towards relating tracks and artists, and having songs pull the aggrigate artist list from all tracks involved.

Down designer, down....

There is a huge misunderstanding: SQL is corrupted, not derived, from the relational model. Since SQL deviated from it, the relational model has been developed significantly by Hugh Darwen and Chris J Date among and above others.

So MS is not proposing a relational data storage instead of a file system, but a SQL data storage. Or perhaps not even SQL, as MS SQL Server is notoriously almost as little SQL-compliant as Oracle itself, the king of standards deviations, second only to MySQL.

BTW, if anyone tries to tell you SQL is really relational, or quasi-relational, don't belive the Marketspeak. You can't be quasi-Mathematical, and the relational model is really an implementation of set theory and predicate logic. Tables aren't relations, just like 2+2=5 is not Algebra.

Pragmatically, this prevents SQL from being as flexible, simple and performant as a relational system is. There are some examples, unfortunately mostly historical: Ingres QUEL was found to perform consistently better than SQL systems, and much better than pre-SQL systems that had SQL grafted upon; BS12 was much cleaner, as was QUEL, than SQL; nowadays Alphora Dataphor is extensible in a much cleaner way than current OO or SQL OO systems.

In its defense, it may be that Microsoft uses only the data storage engine of MS SQL Server in WinFS, just as it uses it now for Exchange. Getting rid of SQL looses many interesting, powerful capabilities, but also may unleash performance. It even could be perfected as the engine of a future, nice, relational system, if ever Microsoft wakens up to what Alphora and TransRelational are (trying to) do. But I very much doubt; most of the database field, both academic and corporate, is corrupted by SQL money; there simply isn't enough cultural critical mass for a big company as Microsoft to steer its course from SQL to relational.

Even so, this could be the single most important contribution of Microsoft to the Informatics field, on a par with making the x86 computer a commodity. Even a sub-relational system can be so much better than what is around; this, together with Moore's Law making inherent Wintel inefficiencies irrelevant 80% of the cases, could pose a very big threat to the competitive position of free software. Granted the GNU/Hurd, or perhaps even Eros, could implement something even better than WinFS, truly relational and with orthogonal persistence in the physical layer (Eros) and/or a functional language application layer (GNU/Hurd). But there is no talk of doing so yet, and it would take a long time to bring these systems to where GNU/Linux is now.

Chalk up one more person who's missed the point.

This isn't a relational database. Those techs you mention are used to make a denormalised SQL database act like a normalised SQL database; they aren't needed if your relational database is normalised or you're not using a relational database at all.

This is language-specific, or application-specific.

Oh? Which one, then? Language, or application? Have you read the page?

It's NOT intrinsically language specific, although if the languages you're wanting to use together don't have any way of talking to each other you're out of luck (although I don't see how SQL could help you there).

Your other problems are real, of course; but they're also very real for any real database, relational or otherwise.

> 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.

> Things that are more likely to change are things where non-equality comparisons are less likely.

And why non-equality comparisons should be special?

> For example, with CustomerID, you almost never use greater-than or less-than.

Which comparison operator are mostly used is immaterial. The real thing is the domain itself. For example, CustomerID cannot be compared, say, to SaleID. They are different domains. Now, if you map any of this domains to a specific language data type, and you want this language to use dynamic typing, your call. But do not let your language do meaningless cross-domain comparisons.

> Perhaps we should make a distinction between "street relational" and "pure relational".

No, we should make a distinction between relational and non-relational, SQL being non-relational. But if you want, you can call it quasi-relational. But it is not relational, simply because relations are sets, while SQL tables are bags. And bags, by definition, are not sets and do not behave as such.

> Until/if the industry starts to back pure relational, I am not going to assume/wait for it to happen, and try to work with what we have now WRT "relational".

So you only will used something good if everyone does? BTW you do not have to wait, unless you want it free. Go Alphora Dataphor.

> I am all for overhauling SQL.

SQL must be thrown away, not overhauled. It is too inconsistent, illogical and idiosyncratic for overhauling.

> I have kicked around new syntax and structure for such. It tends to resemble functional programming in many ways.

If you do not want to do the right thing and go relational, at least do not wast your efforts by duplication. Go SchemeQL.

> 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.

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 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.

> I meant "street relational", not Codd theory-book relational.

The problem is that street relational is no relational at all, since it violates the basic theoretical principles of the relational model. BTW it’s not only Codd, but also Christopher J Date, Hugh Darwen, Fabian Pascal and now Nathan Allan.

It makes no sense to speak about Codd theory-book relational. There is a post-Euclidian Math with is still Mathematics, and indeed superseeds Euclid; but it evolves from the Euclidian fundamentals to the point of redefining them. SQL, OODBMSs and other database models up to this day are either pre-relational or just plain confusion of mind which seems works just because people never considered they could have something much better &ndash -- that they could have had it for twenty years already.

> 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.

> A valid point, and I may read some more of the articles on the site.

Please do. You may also be interested in some stuff at DMoz Relational Implementations and Model listings... I created these, they have been taken over with no explanations and I could never get back into DMoz, again with now explanations as to why.

> But I'm not likely to buy books merely to understand an argument which appears dubious and impractical.

‘Dubious and impractical’ in which grounds? In fact, it’s hardly dubious because they are the authors and maintainers of the relational model; and it’s not impractical at all because there were already at least two faithful implementations of the relational model already, one currently in beta and other in production usage for twenty years already, not to mention other implementations, partial or not that aren’t perfect but are still more faithful to the model.

> It seems that the core issue is the authors' demand to define 'relational database' in a sense that predates SQL and ignores all recent evolution.

The whole point is that SQL is an involution.

> Has anyone written a true relational database? If not, what are they waiting for? Is such a database vastly harder to write than the pseudo-relational databases being used today?

Yes, as I pointed above. The issue here is that the market has in the eighties taken the ‘safe’ option (IBM SQL/DS) and fell in love with it over the better alternatives, just as it did with MS Windows over Unix and OS/2 in the nineties.

> Sounds like another collision between reality and ideal. In an ideal world, the structure and business model of a company would be known in advance and someone would create a unified data model for the company. In practice, large companies purchase many different software packages that come with their own database schema.

Again that’s a failure in the tools and processes. Even if SQL is fundamentally flawed, if it was really standard integrating all these databases wouldn't be so hard; if it was really distributed it would be a given; if on top of this all these products were properly documented, this job would be almost done already.