Database Reference
In-Depth Information
The problems that 2PC introduces for application developers include loss of availability and
higher latency during partial failures. Neither of these is desirable. So once you've had the good
fortune of being successful enough to necessitate scaling your database past a single machine,
you now have to figure out how to handle transactions across multiple machines and still make
the ACID properties apply. Whether you have 10 or 100 or 1,000 database machines, atomicity
is still required in transactions as if you were working on a single node. But it's now a much,
much bigger pill to swallow.
Schema
One often-lauded feature of relational database systems is the rich schemas they afford. You can
represent your domain objects in a relational model. A whole industry has sprung up around (ex-
pensive) tools such as the CA ERWin Data Modeler to support this effort. In order to create a
properly normalized schema, however, you are forced to create tables that don't exist as business
objects in your domain. For example, a schema for a university database might require a Student
table and a Course table. But because of the “many-to-many” relationship here (one student can
take many courses at the same time, and one course has many students at the same time), you
have to create a join table. This pollutes a pristine data model, where we'd prefer to just have stu-
dents and courses. It also forces us to create more complex SQL statements to join these tables
together. The join statements, in turn, can be slow.
Again, in a system of modest size, this isn't much of a problem. But complex queries and multiple
joins can become burdensomely slow once you have a large number of rows in many tables to
handle.
Finally, not all schemas map well to the relational model. One type of system that has risen
in popularity in the last decade is the complex event processing system, which represents state
changes in a very fast stream. It's often useful to contextualize events at runtime against other
events that might be related in order to infer some conclusion to support business decision mak-
ing. Although event streams could be represented in terms of a relational database, it is an un-
comfortable stretch.
And if you're an application developer, you'll no doubt be familiar with the many object-rela-
tional mapping (ORM) frameworks that have sprung up in recent years to help ease the difficulty
in mapping application objects to a relational model. Again, for small systems, ORM can be a
relief. But it also introduces new problems of its own, such as extended memory requirements,
and it often pollutes the application code with increasingly unwieldy mapping code. Here's an
example of a Java method using Hibernate to “ease the burden” of having to write the SQL code:
@CollectionOfElements
@JoinTable(name="store_description",
joinColumns = @JoinColumn(name="store_code"))
@MapKey(columns={@Column(name="for_store",length=3)})
