Dataphor reborn

Once more, I am ſpurred into action by a comment to my lasſt poſt on DbCG’s Alphora Dataphor. Ðis time ðe delay is not ſo big: five monþs inſtead of two years. Inſignificant as my blog is, I hope ðis is a portent of increaſed awareneß of ðe relational model and implementations’ relevance.

Ðe ſituation now ſeems much brighter: ðere are current efforts, if not yet wiþ a ſet date, for making Dataphor truly free ſoftware — ðere is not yet a GNU build or even inſtruction to build wiþ Mono, much leß a Debian GNU/Linux package, but DbCG is eliminating proprietary dependencies. What is more important, a PoſtgreSQL device driver, neceßary due to the federated nature of Dataphor and to its current reliance on proprietary or deficient DBMSs, is planned for ðe next verſion, and perhaps is already being worked on.

I have no leiſure now to experiment wiþ, much leß contribute to, ðe current ſtate of Dataphor. But once ðere are at leaſt inſtructions to build a PoſtgreSQL and GNU verſion, I will really try to ſet ſome time apart, do a prototype and write about it.

Where Dataphor is

Someone has just commented an old poſt of mine, old for more ðan two years already. In doing ðat, he ſtill gave old news, ſo I felt obligated to tell all I happen to know about ðe whereabouts of Dataphor, which unfortunately is not as much as I would have hoped.

Yes, Dataphor is now free ſoftware, open ſource if you like. But no, all is not well. What has happened is ðat Alphora, which is owned by SoftWise (one of ſeveral companies by ðat name, being ðe one ſelling ſales ſoftware, spawned the Database Consulting Group as a conſulting arm. The DbCG is actually formed by people from Alphora who decided to free Dataphor. They even created a Dataphor webſite as a wiki. But ðere were problems:

• Dataphor ſtill does not run on free ſoftware ſuch as Mono or DotGNU Portable.Net, needing MS .Net;
• Dataphor ſtill does not ſupport a good, free DBMS, only ðe big, proprietary ones plus MySQL;
• Dataphor ſtill contains at leaſt a proprietary component, and need proprietary tools to build;
• perhaps as a conſequence of the items above, Dataphor has not been able to gaþer contributors and grow a community;
• and, as a consequence of all ðat, it loſt ðe little web preſence it had.

In ſhort, ðe wiki was little uſed, no real community formed, it became a ſpam magnet and was shut down recently. What is ðere now is but a template after a ſerver rebuild. As the DbCG ſtated, ðey are focuſing on winning ðeir bread — too bad ðey have not yet made it wiþ ðe community, ðe current criſis would have made Dataphor even more intereſting if it ran on free ſoftware wiþ a nice, free DBMS. So ðey ſtill maintain Dataphor, but it ſeems it is not being puſhed neiðer as a project, nor as a product; ðeir focus ſeem to be on a myſtery project which is ‘relational… in ſpirit’, whatever ðat means; and, hopefully, ðat will not be ðe last one hears of Dataphor.

I do not quite know what to þink about all ðat. Ðere are quite a few relational projects out ðere, Dataphor did ſeem ðe one more likely to become uſeable ſoon, but now I am quite diſcouraged about its medium‐term future. Hopefully ſomeone will ſurpriſe us ſooner ðan later…

MySQL ißues

Ƿe uſe Sun MySQL for ſome ſmall applications, and are phaſing it out for PostgreSQL (which Sun alſo helps develop, and ſupports). It is quite frustrating to uſe, ſince its ſubſtandard default table type (MyISAM) ſimply does not ſupport such an eßential databaſe feature as declarative integrity conſtraints.

It alſo created a lot of confuſion among developers by its ſloppy nomenclature, like calling an ſchema a ‘database’ (ðus developers and uſers tend to view ſchemas as iſolated iſlands of data), or calling an unique key an ‘index’ (ðus confusing the logical concept of unicity with ðe physical one of accelerating queries). Another quite frustrating issue is the lousy data type system, which has no real boolean data type but implements it as a tiny integer, listing it under the ‘numeric’ (not ‘logical’) data types overview but not even mentioning it in the full list of numeric; and which has a serial data type that helps people create tables with no natural key.

Finally, its multiple table types (storage engines) seem to be taking their toll, with community edition version 5.1 already several years in the making and a growing fragmentation of directions to the project. Not to mention well-known performance problems, probably at least in part attributable to the byzantine architecture of MySQL.

Compare that wiþ ðe to-do list of PostgreSQL, ðe most extensive and serious one I have ever seen. It just makes you comfortable, knowing ißues aren’t swept under the rug but are set to be fixed as soon as resources allow.

Oops, Mono’s WinForms are out

Juſt becauſe I complained, Novell has releaſed Mono 1.2 — including an implementation of MS Windows.Forms.

Now I should aſk Alphora about Dataphor on Mono. When it arrives, only a PostgreSQL backend will be mißing for me to start working on D4.

Relational DBMS update

After my poſt on Alphora Dataphor and alternatives, an update.

Dataphor is nearing verſion 2.1, and ðat is good. But Mono’s WinForms ſtill iſn’t available, and ðis means my projects are ſtill on hold.

On the other hand, Hugh Darwen is tutoring ðe development of a Tutorial D wiþ ðe interval type ſyſtem for temporal (and oðers ſuch) operations, MighTyD (ðere is ſome wordplay I couldn’t get in ðe name).

¿Where is Dataphor?

I wonder where is Alphora Dataphor nowadays. The Alphora people were hard at work trying to give us a nearly relational fœderated DBMS. I was expecting for earlier ðis year (perhaps unwarranted) a verſion running on Mono (or DotGNU Portable.Net) and PoſtgreSQL, but heard noþing elſe except ðat ðey were working on ðeir own ſtorage engine.

Ðe þing is, I would like to recommend ðeir tool to ſome people doing web apps, but I can’t in good conſcience recommend MS Windows ſervers.

Ðe only oðer alternative I ſee now, since Alfredo Novoa’s project ſeems dormant, would be Rel maturing faſt, but somehow ðis does not ſeem probable at all, being ſtuck at an α verſion since January.

Trying to get a book fixed

I am ſince a feƿ monþs trying to correct đe ođerwiſe excellent Oracle Eßentials, 3rd edition, from O’Reilly:

Dr. Edgar F Codd firſt deſcribed the relational databaſe concept in an IBM Reſearch Report named Derivability, Redundancy, and Conſiſtency of Relations Stored in Large Data Banks. His 1970 paper was publiſhed in Communications of the ACM, and was called A Relational Model of Data for Large Shared Data Banks. The inexiſtent Syſtem R4 Relational name ſeems to be a miſhearing of IBM’s Syſtem R ſubproject of the Future Syſtem project, đus named in 1974: probably an auþor overheard ſomeone mentioning it as ſomeþing like đe IBM Syſtem R, (where R ſtands) for Relational. Alſo, Oracle was not the firſt relational databaſe. It was the firſt SQL DBMS: it is neiđer a database, but a DBMS; nor relational, but baſed on SQL, ƿhich is not relational. Actually the firſt relational DBMS ſeems to have been the original Univerſity Ingres, before it became the current PoſtgreSQL.

Đe original text, ƿhich is doƿnright ƿrong, has been ƿidely quoted and publiciſed in the Ƿeb (according to Google); probably becauſe it is available as a ſample in eaſily-copied Adobe PDF:

The Evolution of the Relational Database

The relational database concept was described first by Dr. Edgar F. Codd in an IBM research publication entitled “System R4 Relational” appearing in 1970. Initially, it was unclear whether any system based on this concept could achieve commercial success. Nevertheless, […] RSI began in 1977 and released Oracle V.2 as the world’s first relational database within a couple of years. By 1985, Oracle could claim more than 1,000 relational database customer sites. By comparison, IBM would not embrace relational technology in a commercial product until the Query Management Facility in 1983.

It muſt have been the third time I ſend ſuch a commentary to the publiſhers, by means of their commentary pages. Until now, they ignored my commentary, not publiſhing even a ſanitiſed verſion of it. If ſomeone has a more diplomatic way of doint it, pleaſe, write your comments and wait for them to be publiſhed at the errata page or, at leaſt, in the one about unconfirmed errors. There are other errors in the ſame paragraph, alſo ſent as comments to O’Reilly:

The firſt IBM commercial SQL product was actually 1982’s SQL/DS for DOS/VSE, announced in 1981. 1983 ſaw alſo the launch of DB2.

And:

Actually the firſt IBM relational product was BS12.

Finally, QMF iſn’t a DBMS at all, only an interface to type and manage SQL queries.