So I decided to download Drupal and install it to get a feel for it. I hadn’t looked at it in years, and there is talk of using it for one of the pg sites, so it seemed it might be good to check it out. Unfortunatly it reminded me of all the bad things about a my$ql driven project. The first thing is the noteable prefrence that the drupal maintainers have for my$ql, and the feeling that they only begrudgingly support PostgreSQL. From the first section listing the drupal requirements comes this not so friendly text:
NOTE: the Apache web server and MySQL database are strongly recommended; other web server and database combinations such as IIS and PostgreSQL are possible but tested to a lesser extent.If I’m a postgresql user, that sends up big warning flags all over, and if I don’t have a database preference I’m still likely to pick my$ql. If you keep reading, it doesn’t get any better, as the drupal install file gives you step by step instructions on how to install the system with my$ql, and relegates postgresql to the following helpful text:
If you are using another database, check the database documentation.The problem with this is that it’s a clear signal (to me at least) from the drupal maintainers that they would rather have you just run it on my$ql, when they really either shouldn’t care, or should prefer to get new users in postgresql (there by opening up thier market). But that really wasn’t what bothered me. What bothered me was when I took a look at the database schema. The first thing that tossed me off was the number of varchar(255) fields that were included in the various tables. In most of the cases I have seen, what you really want here are TEXT fields, since you really don’t care if someone puts in a URL that is 256 charectors long, you’re just trying to represent a variable width charector field that can be large in size (a la text). I then noticed that some of the text fields were… silly I guess I would call it, like the menu table, which has two fields called title and description which both have a default value of ”. Yes, thats a blank… which seems to me would not be very good names for menu titles, and yet it’s apparently so good that you might want to have several menus with the same ” title and ” description because there is no unique key on either of these two fields. But even that wasn’t what floored me. What floored me was when I realized that there were no [http://en.wikipedia.org/wiki/Foreign_key foreign keys]! Not only did the whole schema harder to understand (which is why I started looking for them, to figure out wether the fid column in one table belonged to the filters table or the moderation_fileters table (which i gather it is the latter as fid is PK to moderation_filters and filters doesn’t have a [http://en.wikipedia.org/wiki/Primary_key primary key]!)) but it also, and this is key, means there must be a bunch of extra code in the application to make up for this fact, and thats just annoying. Who wants to keep track of dependences within a mess of php code? This is why you use a database, to handle these things that are a pain for you, but I guess [http://sql-info.de/mysql/referential-integrity.html thats what you get] when you build an app around my$ql. Since I don’t use drupal, this is a show stopper for me as a developer, because you know you’re going to have to write more code than you should based on thier myisam driven database design; and looking at the current state of things I’m guessing that they’re not too eager to start rewriting large chunks of thier application against a real database scheme. Too bad they’re not the only one…