MySQL preps business upgrade

TalkBack 13 of 19:

Next »

« Previous

• Thread View
• Flat View

Reply to jcg

"You are so far away from the real world that you're looking through a straw, making up grand disaster theories about what you can see with your little view."

No I am a database designer involved with every day tasks for the most part.

"The world runs on databases that speak SQL, with every other data retreival technology (object-oriented, object-relational, hierarchical, etc.) lagging far behind. Saying that you find SQL "logically absurd" is just another way of saying you don't like. Who cares?"

Yes, the vast majority of DBMS are SQL and it is better than object-orientated or hierarchical approaches. However row duplication is logically absurd and in clear violation of the relational model. (What do the duplicated rows mean?). By and large row duplication is just a bug generator (and probably a drain on performance too). This is why I say it is absurd.

"You can implement your solution on your vaporware DBMS, or you can use a real RDBMS which speaks, yep!, SQL. Because that, my friend, is what everyone else in the room will understand as a relational database."

Yes, at present I have to use SQL. Does this mean I am not allowed to critisise it? Surely not. Yes, colloquially SQL DBMSs are relational but in reality (if you actually take the trouble to understand the theory) they are definitely not as I have already demonstrated above.

"If you think the majority or even a large minority of failures in productions systems are because SQL doesn't provide a "pure" relational query language, you've just got your head in the sand (or somewhere less attractive). It might be convienent to blame a bad design, lack of analysis, or insufficient testing on the tool, but we all know that's just a diversion."

Errors happen for all sorts of reasons but why defend a language that allows you to shoot yourself in the foot as easily as SQL does. We could start with duplicates and nulls as very bad design faults in SQL. Also the very weak support for constraints in all implementations of SQL makes it very difficult to implement the necessary validation, thus leading to bugs. I am not saying that all errors are due to faults in SQL but SQL is error prone.

"Maybe DBMS's aren't pure relational because the nature of the hardware that implements them isn't well aliged with their requirements, and therefore gives horrid performance - did that ever cross your mind?"

No, you are incorrect here. A lot of the performance problems are due to the very literal mapping of the logical to physical layers that exists in all SQL implementations. There are ways to address these problems and this could (and I believe will) lead to truly relational DBMS with good performance.

"I recall how object oriented databases were going to upset the relational dbms's in the 1990's, and how I spent 2 years as a Versant OODB DBA when my firm jumped too quickly. Today, OODB's are no more in route to upsetting RDBMS's than they were then."

You're right, OODBs are a mistake. Identifying classes with relations is a fundamental logical failure.

"What I think is innovative in DB's right now are hybrid approaches, generally referred to as "post-relational" db's, like InterSystem's "Cache" (www.intersystems.com/cache/), or Matisse (http://www.matisse.com/). Also hot among academics who have something to do with their time except obcess on realtional theory are XML query languages."

I don't know about Cache but all of the "hybrid" systems I have seen seem to be repeating all of the mistakes of OODB. As for XML isn't this just an anachronistic throwback to hierarchical methods?

"Real transactional and data warehouse database professionals are more concerned right now with performance on large volumes of data, and have no interest in the hairs you're splitting. Terra-data, for example, has solutions for "trickle feeding" your data warehouse, and solving the indexing problem on large data stores by massive parallelism."

Hopefully they worry about keeping the data consistent first and then about performance. I am not sure anyone is interested in crap, no matter how fast you can generate it. Also maybe indexing isn't the right way to solve performance problems, but you have to look at ideas that are outside the box a little bit to understand that.

"Is there anyone actually developing solutions that get deployed in the real world who is the least bit concerned about your outrage with SQL? Not that I'm aware of. I think you're a vocal member of a very small group."

I am developing solutions that get deployed in the real world and I know I am not alone in holding these opinions.

Posted by: jorwell   Posted on: 10/19/05 You are currently: a Guest | Members login | Terms of Use

Alert moderator to an offensive message

Subscribe to this discussion via Email or RSS

SponsoredWhite Papers, Webcasts, and Downloads

• Virtualization: Architectural Considerations And Other Evaluation Criteria VMware Of the many approaches to x86 systems virtualization available in the ... Download Now
• Five Steps to Determine When to Virtualize YourServers VMware Server virtualization isn't just for big companies. Entry-level ... Download Now
• The Impact of Virtualization Software on Operating Environments VMware Today's use of virtualization technology allows IT professionals to ... Download Now