ON FLAWED PHILOSOPHY

From: MC

To: Editor

I'm a philosopher at heart, currently working as a computer programmer (technology has long been a hobby of mine). Being informed by both of these perspectives, I have a few comments on your Against The Grain articles (and, by extension, the DATABASE DEBUNKINGS site--although I haven't read DEBUNKINGS very deeply yet).

First, I appreciate your commitment to the theoretical underpinnings of database technology. Among other things, philosophy is responsible for the "theoretical underpinnings" of individual and collective worldviews, and I understand your frustration at practitioners who don't have the theoretical foundation they need to do the work they're doing; I see the same thing all the time.

Second, as far as I can tell from an initial reading, your arguments are quite logically consistent and valid. Thank you! As you so correctly point out in the “Balance” in the Trade Media article, real logic and analysis tends to be rare in IT journalism. This is quite regrettable, not least because the I.T. industry is one where claims are pretty easy to evaluate scientifically/logically. (I've often wished that philosophical arguments about, say, the nature of mind were as easy to benchmark as Quake 3!)

Finally, an observation: technologies that prosper tend to do so because of a perceived need for that technology. I say this specifically in regard to your comments on XML. While I agree with the substance of your arguments--that XML is reincarnating an inferior data model that should have stayed dead--your recommendations don't seem to offer a lot of practical alternatives.

One of the ways XML is being used now is as a run-time data source for Web-based server-side applications. While this does put the burden of managing data on application code--which is bad--a number of developers appear to see this as the lesser of two evils when compared to using one of the current SQL DBMSs (SQL Server, Oracle, etc.) as a data store.

Contemporary SQL DBMSs are much slower than access to an in-memory data store/XML document. These DBMSs are (often correctly) seen as behemoths that eat memory for lunch, with a super-size order of processor cycles on the side. Plus, more and more often the database being connected to is on a separate server than the application server, introducing network transmission time lag.

Personally, I'd love to use an RDBMS as a run-time data store. I'd love to do my data integrity checking on the RDBMS, and have the HTML pages as little more than a UI for users to enter data into the RDBMS. But in order to do that, the RDBMS would need to be fast, lightweight, scalable, and efficient--and I don't know of any current products that fit this mold. Hence the perception of need for XML--which is, I believe, a superior run-time data source for Web-based applications than hidden <form> fields!

However, I'm fully aware that my knowledge is very limited. Do you know of any DBMS that can scratch the itch for a lightweight run-time data source?

Fabian Pascal Responds:

Ø The theory behind relational technology is predicate logic and set mathematics. It would not hurt if practitioners were exposed to these by the education system, and it is sad that they are not. But this does not mean that practitioners must be logicians or math wizards to practice sound database management (I dare anyone to show any trace of predicate logic or math in my writings or lectures). They only need to know the practical implications of theory, and the price of deviations from it, which is what I focus on.

Ø I am afraid the problem is much more profound and goes beyond IT journalism and even beyond the computer industry: it has to do with the character of this society and business.

Ø To the extent that “Technologies that prosper tend to do so because of a perceived need for that technology”, a critical issue is, of course, how the perceptions come about. Last time I looked, efficient markets--where better technologies succeed and worse ones fail – are predicated on perfect information. And since you admit that neither consumers, nor the press are anything near perfectly informed, shouldn’t that make their perceptions suspect? That “a number of developers appear to see XML as the lesser of two evils” is, under the circumstances, hardly a persuasive argument, is it? After all, they had perceived a similar need for SQL too, so why do they need to replace it with XML now? Have you considered why they go from fad to fad, without their “perceived needs” ever being addressed? The fundamentals of their needs have not changed, but erroneous perceptions have, fast and often.

Ø The notion that XML yields better performance is absurd on its face for a variety of reasons (see if you can detect an obvious one in the sample below). And even if it did yield better machine performance, human performance would be a bottleneck, just like with old hierarchic databases. Besides, XML was certainly not invented to resolve performance problems. I have been taken to task for criticizing XML data management, because XML is essentially a data interchange technology. If so, then why bother with a data model at all?? None is required.

<Program_Info>

<Program_Name>XL-Plot</Program_Name>

<Program_Version>2.05</Program_Version>

<Program_Release_Month>03</Program_Release_Month>

<Program_Release_Day>24</Program_Release_Day>

<Program_Release_Year>2002</Program_Release_Year>

<Program_Cost_Dollars>0</Program_Cost_Dollars>

<Program_Cost_Other_Code />

<Program_Cost_Other />

<Program_Type>Freeware</Program_Type>

<Program_Release_Status>Minor Update</Program_Release_Status>

<Program_Install_Support>Install and Uninstall</Program_Install_Support>

<Program_OS_Support>Win95,Win98,WinME,WinNT 4.x,WinXP,Windows2000</Program_OS_Support>

<Program_Language>English</Program_Language>

<File_Info>

<Filename_Versioned>xlplot.zip</Filename_Versioned>

<Filename_Previous>xlplot.zip</Filename_Previous>

<Filename_Generic>xlplot.zip</Filename_Generic>

<Filename_Long />

<File_Size_Bytes>2697970</File_Size_Bytes>

<File_Size_K>2570</File_Size_K>

<File_Size_MB>2.57</File_Size_MB>

</File_Info>

<Expire_Info>

<Has_Expire_Info>N</Has_Expire_Info>

<Expire_Count />

<Expire_Based_On>Days</Expire_Based_On>

<Expire_Other_Info />

<Expire_Month />

<Expire_Day />

<Expire_Year />

</Expire_Info>

<Program_Change_Info>More spreadsheet functions. Now imports bitmaps in drawing sheet.

</Program_Change_Info>

<Program_Specific_Category>Graphics</Program_Specific_Category>

<Program_Categories />

<Program_System_Requirements />

<Includes_JAVA_VM>N</Includes_JAVA_VM>

<Includes_VB_Runtime>N</Includes_VB_Runtime>

<Includes_DirectX>N</Includes_DirectX>

</Program_Info>

Ø In any case, performance cannot possibly, and should not have anything to do with the data model employed, which is purely logical, and everything to do with physical implementation. That is, of course, true of any database technology, including SQL; to the extent that SQL products are slow, that is not because they are relational, but because they are poor implementations. In fact, you say so yourself, without realizing it: you refer to “in-memory” XML documents--what exactly is preventing SQL DBMSs from implementing in-memory tables? And what does this have to do with the data model?

Ø I find the argument that I “don’t offer a practical alternative” nothing short of astounding, and not worthy of a philosopher. For more than 15 years I’ve done nothing but demonstrate that there is only one practical solution, which can be ignored only at peril. And because the industry, users and the trade media have consistently ignored, dismissed, or bastardized the relational model, it is I, of all people, who have not offered a practical alternative??? Really, now.

Ø If the industry has failed so abysmally to implement relational technology, what makes you expect that they will do any better implementing XML, which is inherently much worse?

Posted 10/04/02

[ABOUT] [QUOTES] [LINKS]