xml to sql generation

I only half-buy that; I don't want to have to design the XML model for my DB. I'm comfortable clicking here and there in phpMyAdmin, or Navicat (or whatever other MySQL GUI). Then, I use MySQLDump to check in the DDL scripts into the source control, works like a charm.

Is there really a need to switch RDBMS engines that often on a project? Even if so, the DDL is vastly compatible between, for example, MySQL and Postgre, so if you use MySQLDump, you can reuse most of your code.

bhazzard, thanks for your input.  And actually, I believe that your post brings to light a much larger / deeper issue within the web-based development community, to the point where I feel there would be a lot of benefit to having a couple of wiki pages up for this (heheh as soon as we get the new qcodo.com with wiki's up there =).

But there's no reason why we shouldn't start the discussion here. =)

I think that the XML vs. DB model approach mostly depends on the way your process is for developing data models.

I know that there are a lot of dev teams (especially within the PHP / MySQL) that work directly with the database in its development process (e.g. via command line tools or something like phpmyadmin)... and because of this more or less lack of formal process, something like propel's XML/YML approach to defining a data model seems a lot more structured.

But in my professional career, I have never seen a development team that, once they've seen ER-diagramming tools used correctly within the software development lifecycle, choose to make ER-diagramming tools a standard within their processes.

I think there is little argument that a visual diagram of a data model as the SOURCE of your data model will beat out any sql dump, web-based admin tool or XML file.

And qcodo's ORM was designed around this philosophy / realization.

By using export-to-sql from your favorite ER diagramming tool (i've got suggestions if you want), then you can switch DB engines whenever you want.

Moreover, by using basic/simple “diff”-based tools from your newly-generated create scripts to existing databases, you can version changes of your database, and thus, keep much better version control of your data model as the application and data model continues to change/modify/grow.

Not sure of what the market looks like for Linux...

Back in the day when I was on the Win32 platform, I was using DeZign for Databases by a company called Datanamic.  It was a slick application back in the 2.0 and 3.0 days... no frills, worked great, and cheap (e.g. it was like $75 or something like that).

Unfortunately, they've gotten considerably more expensive over the years... :-/ -- last time I checked the product, itself, is still good... but for the added $$$ all you get are (IMHO) features that you will never use.

But the ER diagramming market is pretty huge for Win32... so you can easily do as search and look around to see what suits you.

On the Mac OS X side, I highly recommend SQL Editor from a Scotland-based company  Malcolm Hardie <http://www.malcolmhardie.com/>.  It ought to be the standard for ER Diagramming applications.

And avoid MySQL's Open Source WorkBench.  It doesn't work.  Period.