Persistence And Automatic Mapping (A-O/RM)

DDL (Data Definition Language) is the language used to create the database and schema and includes statements like: create, alter, drop, etc. DML (data manipulation language) is the language used to manipulate the data in a database and it includes statements like: select, insert, update, delete, etc. To most of us, it's all SQL, but there actually is a distinction. DDL is about database structure, and DML is about data.

RDB Persistence software (ORMs) quite often generate DDL statements for the database being used. Most of the XML/annotation definition required by persistence software actually exists to support DDL, and to a largely unnecessary extent it exists for the object-relational mapping. Since most shops have database departments and developers who actually design and create the database structures in the database, the DDL that resides in the application software mostly goes unused in that regard. The majority of effort in using persistence software is in the mapping definition itself and this alone is extremely expensive, both for the developers and for the quality of software. Therefore, DDL in the application software is largely a duplication of concerns.

With DDL in the application software, developers are forced to play an annoying game of keeping the object-relational mapping in sync with the changes made to the database and are constantly having to tweak the definitions to mirror the actual schema they are working with. Most of the complaints about today's software development reside around the large amount of configuration developers have to deal with. It has long been known by system administrators that most of the problems they face exist in software configuration, so why would that be any different for developers? It isn't! Projects with large amounts of configuration also have a large number of problems. We should be limiting configuration in software development, but we seem to be increasing it.

Another result and/or side effect of DDL in the application software is the fact that a large part of the database's functionality is made irrelevant and/or is greatly reduced in use, as programmers try to avoid using database functionality that they can't also define in the application's software mapping. The result of all this is inconsistencies between the DDL in the software and the DDL that actually exists in the schema, not to mention the grand extent of effort required to define the object-relational mapping to the application software. Obviously, this causes numerous errors and unexpected results, and is actually completely unnecessary.

So for a typical project, DDL should be defined separately and outside the application, while DML should be soft-coded within the application software. Furthermore, persistence software does not need DDL definitions to handle object-relational mapping. Persistence software can get all the information needed about the structure of an existing database from the database metadata. The ideal situation would have DDL being the concern of the the database experts (data modelers, database developers, and DBAs) and the DML would be the concern of the application developers.

Tags dabuTech