Sunday, July 27, 2008

Foreign key cascade on update dangerous?

In relational databases there's a feature called foreign key cascading. Typically, there's an ID associated with each row, or entry, in a database table. Tables may refer to other tables using a foreign key, which typically refers to the IDs of the rows being linked. There are options to "cascade" on two kinds of operations: delete and update. When a table refers to another table, the table pointing to the other table can be configured to take changes in the ID of the original table and integrate them automatically. This is what happens when ON UPDATE CASCADE is set on a foreign key. When ON DELETE CASCADE is set on a foreign key, deleting rows in the original table will also delete rows that are pointing to that row.

So, it's not hard to imagine situations where cascading on delete would be dangerous.

Now a while ago, I was talking to a database specialist about cascading updates on foreign keys. He mentioned that they're dangerous, so I took his word for it. But I've been thinking about it and I still don't see any way they can be dangerous; the only changes being propagated outward will be changes in the values stored in foreign keys; no rows will be deleted.

I've asked around to get second opinions and examples of situations where this would be bad; for now, I'm just going to avoid cascading updates for future projects.

Sunday, July 20, 2008

Truth never changes — or, why we're solving the same problems

"Truth does not change. What was true 2,000 years ago is true today, and will be true 2,000 years from now. New truths may be discovered, but that just means that it was true all along."

The above is paraphrased from a sermon given by Pastor Rick Warren at Saddleback Church. Very few things are really new, which is consistent with my observation of what's going on in the world, and if they are, chances are that there's some catch. What's new and doesn't last probably doesn't work or just isn't true. Such things lack conceptual integrity and fall apart eventually when reality hits.

(I've just started a new job at JibJab, on which I'll write more about later on, but that doesn't mean my mind is completely devoid of all thought dedicated to solving larger problems.)

When I see some new file storage startup, or some new effort to create an operating system, or several companies trying to push their respective next-generation platforms, I think, "Oh, great. Not another file storage startup. Not another operating system. Not another platform."

But I see these things happening again and again — first in Web 1.0, then Web 2.0 — because the problems haven't been solved. The truth in all of these situations is that the problems remain, or have resurfaced due to technological change or heightened consumer expectations.

Having a lot of competitors trying to tackle the same problem shouldn't be seen as, "Hey, there are just a bunch of me-too companies trying to tackle old problems." Instead, it should be seen as, "These are problems that continue to badger us. These are important problems."

The people starting these companies see the importance of addressing these "old" problems, but it's important that rank-and-file employees of these companies, as well as consumers and journalists, recognize the significance of the larger mission.

In order to appreciate these efforts for what they are, it helps to focus on the fact that solving the problem is a formidable task — rather than focusing on the fact that the company is merely another contender in a crowded field.