Vitavonni

Wed, 26 Mar 2008

Measuring code quality by database support...

Do you know why so many (mostly PHP) developers have problems porting their applications to PostgreSQL?

Because PostgreSQL actually enforces constraints on the data.

MySQL, which can even have values that are NULL and NOT NULL at the same time (yes, this is not a joke, Details are found here), is not particularly good at that. And people get used to all kind of stuff they can throw at MySQL and it will try to make the best out of it, instead of forcing the programmer to correctly specify what he intends to do.

That's the reason why I so far have been avoiding any application which only support MySQL: If it only supports MySQL, it probably means they can't get it to work with anything else. And that is a really bad sign.

I was looking for some cheap WebCMS. The big names are Typo3, Joomla, Drupal. Joomla is MySQL only. Plus it doesn't support iCalendar. Typo3, I've had had a look on that one before, it was ugly, used things like line numbers for layouting. And Drupal was pretty much the only one I heard not just negative things about (I was mostly talking to tech guys, not "web designers"). So I thought I'd give it a try. With PostgreSQL, since I want a consistent database.

Drupal (6.1) installation with PostgreSQL worked fine. Then I tried installing the add-on modules I was most interested in: Date and Event; since the web site I'm considering it for will be mostly around organizing events, so I do need some solid calendaring functions.

Apparently, the Date module of Drupal currently does not support PostgreSQL, it failed creating or filling it's timezone table in the database.

How come that pretty much all PHP stuff is broken on so many levels? I figure the Drupal people have spent a lot of time in getting their core working well, and I also believe that the cores of the other systems might all be okay. But when it comes to extension modules, it seems to be as bad as ever before with PHP...

Some people might just say "well, run MySQL, and it would be working".

If a module isn't capable of storing timezone information in other SQL databases, how can it be of good code quality?

(Yes, I know that I'm not being entirely fair. Picking on Drupal or even on the not yet finished Date extension is probably not really fair. But you have to admit that an application which can work with multiple databases probably has received more attention to doing database things the proper way, right?

The Date module is not yet "released". I'm not saying it's worthless, it just does not work for me yet. And it actually backs my first claim: working support for other SQL databases is a sign of code maturity.

And in most (if not all) PHP web applications, extension modules with their varying code quality are known for introducing security issues again and again.)

[category: /en/linux | Permalink]
Menu
[planet.debian]
[planet.xmlhack]
[planet SELinux]
[munichblogs]
[email]
[RSS 2 feed]
[English RSS 2]
Categories
< March 2008 >
SuMoTuWeThFrSa
       1
2 3 4 5 6 7 8
9101112131415
16171819202122
23242526272829
3031     
Archives
2010-Mar
2010-Feb
2010-Jan
2009-Dec
2009-Nov
2009-Oct
2009-Sep
2009-Aug
2009-Jul
2009-Jun
2009-May
2009-Apr
2009-Mar
2009-Feb
2009-Jan
2008-Dec
2008-Nov
2008-Oct
2008-Sep
2008-Aug
2008-Jul
2008-May
2008-Apr
2008-Mar
2008-Feb
2008-Jan
2007-Dec
2007-Nov
2007-Oct
2007-Sep
2007-Aug
2007-Jul
2007-Jun
2007-May
2007-Apr
2007-Mar
2007-Feb
2007-Jan
2006-Dec
2006-Nov
2006-Oct
2006-Sep
2006-Aug
2006-Jul
2006-Jun
2006-May
2006-Apr
2006-Mar
2006-Feb
2006-Jan
2005-Dec
2005-Nov
2005-Oct
2005-Sep
2005-Aug
2005-Jul
2005-Jun
2005-May
2005-Apr
2005-Mar
2005-Feb
2005-Jan
2004-Dec
2004-Nov
2004-Oct
2004-Sep
2004-Aug
2004-Jul
Other links:
Swing and the City - Lindy Hop in Munich