Re: Can relational alegbra perform bulk operations?

Clifford Heath wrote:
> Unfortunately MySQL is still teaching the new generation that the order of
> joins actually matters.
 >
> Now you're singing my song. This is one of the most fundamental problems
> of the industry, going far beyond just the database world.

paul c wrote:
> The sellers know the buyers are ignorant, not unlike many other fields.
> Unlike in most other fields that are so expensive to participate in, the ironic
> aspect in IT is that the "free software" developers usually mimic what the commercial
> developers do (and the bulk of them aspire to be commericlal). For the
> remaining few virtue is the only remaining reward and it's a waste of time to
> complain about what the rest do.

I don't think it's that ironic, paul. The trouble with crowdsourcing is that it's great at showing what *is* the common practice but total crap at showing what *ought* to be the coding practice. Look at OpenOffice and Ubuntu. They amounts to something like Microsoft Me-too! Then contrast with Mac OS X and iWork, which both are closed source though based on open source components, yet they work very well because developers didn't get buried into decision by committee that plauges FOSS at large.

My long-standing song is that it's easy to write a program, but entirely something else to write a program that promote good behaviors on the part of users. Failing to do that just encourages the users to break the rules so they can do it their way, and I think that is somewhat true of any SQL products, commercial or not. Users have little incentive to adopt "good" behavior by letting optimizer doing their job. The blame lies squarely upon the feet of vendors (and to extent the standard committee as well)

On an unrelated matter, I think there is something to be said about MySQL's interesting implementation. Many people recoil in horrors regarding its apparent disregard for transactions and foreign key support (at least for tables not using InnoDB engine), but to me this makes perfect sense: If it's not needed, then the developer should be able to choose to not need it. I'm not going to say that a financial application should choose MyISAM tables to store its essential can't-afford-to-lose-it data, but for applications where we just don't give a hoot if we lose some data or simply don't need transactions, then it makes sense to gain performance in that area.

As a practical example, I worked on a project for a client, having had joined in midway so they already had decided on the specifications. Basically, they used SQL Server as a reporting server, loading data from Oracle DSS. The users just needs to aggregate data upon filters of their choosing and generate reports; no updates except to dump the data and load new dataset from Oracle on a regular interval. Did they really need the transactional feature? Foreign key constraint? No, not really. Did they want their reports fast, fast? Yes. So, They basically paid more money for less performance when they could had use MySQL. (Granted, one could tweak MS SQL server to ease up on various overhead but it can't be turned off entirely and that's more work anyhow whereas MySQL is just that out of the box)

But that's nothing to do with RM itself; it's just one more implementation. From a pragmatic viewpoint, one can see why it may *sometimes* make sense to leave RM/SQL while keeping the interface (e.g. SQL language). Received on Thu Oct 01 2009 - 06:21:20 CEST