JDO Brings DB Programming into 21st Century Despite Controversy
JDO is a well thought out application programming interface that provides an abstraction layer between the application and data stores of various kinds. So why do relational database vendors and object persistence purists refuse to endorse this open standard?
by Dirk Bartels
July 9, 2003
efore Java Data Objects (JDO), database programming was stuck in the '80s. All programmers had were either highly proprietary programming interfaces or SQL, a powerful but cumbersome declarative database programming language for relational databases that IBM invented in the late '70s. For me, SQL is like programming a Macro Assembler. It requires that I know a lot about the database design (e.g., tables, rows, columns, relationships, indexes, etc.) before I can write my application. That was okay in the '80s, but it's not acceptable for the increasingly complex applications of today.
Developers tried many times to solve the impedance mismatch between the application code (objects) and the data store code (tables, rows, columns, and SQL). However, none of their attempts ever became a widely accepted standard. Examples of these failed solutions include:
Container-based solutions like BMP and CMP that run only within the J2EE space
Simple object streaming, which is available only for flat files
The ill-fated Object Data Management Group (ODMG), which completely ignored the existing relational databases and tried hard to impose a standard for those object databases after the fact (i.e., when the vendors already were offering products with proprietary APIs).
It's quick, easy and you get access to all the articles on DevX.
This registration/login is to allow you to read articles on devx.com. Already a member?
To become a member of DevX.com create your Member Profile by completing the form below. Membership is free!
efore Java Data Objects (JDO), database programming was stuck in the '80s. All programmers had were either highly proprietary programming interfaces or SQL, a powerful but cumbersome declarative database programming language for relational databases that IBM invented in the late '70s. For me, SQL is like programming a Macro Assembler. It requires that I know a lot about the database design (e.g., tables, rows, columns, relationships, indexes, etc.) before I can write my application. That was okay in the '80s, but it's not acceptable for the increasingly complex applications of today.
