DewDrop is an open-source framework that generates source code to support any entity-relationship data model. In practical terms: it generates SQL DDL (Data Definition Language, a.k.a. Database Definition Language) for any database.

DewDrop addresses the need to:

• Define a database generically.
• Support multiple database vendors.
• Simplify database definitions.
• Eliminate numerous vendor-specific files.
• Propagate design changes from a single location.

DewDrop allows you to define your entity-relationship database just once in XML in the form of SQLML, regardless of what database(s) you might want to use. In doing so, you are freed from knowing database-specific DDL for any of these databases. DewDrop provides its own standards-based, easily understandable XML DDL for you, otherwise known as SQLML. No more worrying about "Does rdbms-X support foreign-keys? or What is the syntax that rdbms-Y uses for adding a table constraint?"

All you have to do is define your tables and their relationships in SQLML, and DewDrop takes care of all the nasty details. You tell DewDrop what target database(s) you want to use, and it generates clean, human-readable SQL DDL code for your target. If you like, you don't even have to look at the SQL; you can just have DewDrop install the generated database for you automatically and be on your way developing your application. That's it...no more worrying about how to port (or even worse, completely rewrite) your datamodel to other databases.

Nicely summarized: "One XML Definition. Any Database."

DewDrop is not:

• A complete replacemet for SQL
  
  DewDrop currently only handles definitions of data models via SQLML. That is, it nicely handles the equivalent of all SQL statements for creating tables, columns, table and column constraints, indices, etc. To actually insert/update/retrieve data from these databases, you still need to execute SQL insert/update/select queries. However DewDrop's SQLML provides a <native> target that allows you to embed any sql within the XML document, ensuring all databases are supported, and you still only have one file to deal with.
  
  
• A Data Binding framework (yet)
  
  As DewDrop is fairly new, it cannot yet take your SQLML data model and create Java or C# classes that directly map (or bind) to your definition. However, this feature is of prime concern for the project managers, and this functionality will definately be included in later releases. Other open source projects such as Hibernate, JiBX, Castor or Zeus may be utilized. If functionality requirements deem necessary, we might also create our own binding framework.
  
  
• A persistence layer (yet)
  
  Currently, DewDrop itself does not provide a means of saving data model instances to a RDBMS (Relational DataBase Management System). Since DewDrop does not (yet) generate source code in languages other than SQL (e.g. Java or C# classes), it has no means of persisting data instances of these classes. Again, other means may be used to provide this type of functionality (e.g. Hibernate, EJB, Castor, or OFBiz), or we may create our own persistence layer.

The above features will be reviewed over time, and if the need arises, will likely be implemented in one way or another.

Water vapor in the evening is composed of many independent water molecules, just floating around with no common bond. However, at dawn, after the temperature has dropped, the water molecules condense and gather. Together, they eventually form a single drop of water, or dew.....a dew drop.

DewDrop is the condensation, or consolidation of multiple database definition language implementations into a single point of gathering...essentially a dew drop of SQL DDL.

We know this explanation is somewhat ethereal and overtly metaphorical. But it sounded good, so why not? ;)