- Derby: Coding for the Overcrowded Data Center
- Which Is Best: A Tightly Bound or a Loosely Coupled Schema?
- Designing Your Schema and Creating Some Tables
- Updating the Database
- Querying the Database
- Retrieving Data from a ResultSet
- Running the Code
- Derby and Support
- Conclusion
- References
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Which Is Best: A Tightly Bound or a Loosely Coupled Schema?
In general, a schema is almost entirely application-specific in that it relates to the structure of the data in your database. There are tools and a range of tried and tested techniques for schema design.
I’ll use a really simple schema just to show how it can be done within Derby. The traditional approach is to create a script file that is executed once to create the database and the tables within it.
This approach works just fine for most database products (including Derby), but you don’t have to do it this way in Derby. You can instead create the schema inside your Java code. There are pros and cons for each approach.
An external script file is decoupled from your source code and potentially allows the same schema to be shared across a number of programming languages and applications.
It also means that a database programmer need not be too concerned with the complexities of the source code. On the other hand, implementing the schema in Java code makes for a tight coupling between the application and the database.
My own opinion about the traditional separation between database developers and programmers is that in many cases it is artificial and unnecessary. One database developer I worked with even reckoned that there was no need for a database person to understand much about the application domain!
I think this separation possibly dates back to the days of the mainframe—a more natural model is possible with Derby and it’s something that should be embraced.
So, for this reason I’ll be providing a schema that is integrated into a Java program.