110 | Chapter 4: Database
In this sense, “application” can mean one program or multiple programs within an
application boundary (the same logical application). Usually this distinction refers to
how the schema is organized; in Rails, integration databases are often referred to as
databases with “legacy schemas.” In application databases, integration can still be
performed through messaging at the application layer rather than the database layer.
Rails is opinionated about how your database schemas should be structured: the pri-
mary key should beid, foreign keys should bething_id, and table names should be
plural. This is not database bigotry; Rails has to choose a sensible default for the
“convention over configuration” paradigm to be effective. It is relatively painless to
change almost any of these defaults. Rails plays nice with integration databases.
Many Rails developers shun integration databases as unnecessary; they maintain that
all integration should be done at the application layer. Some take that a step further
and state that data integrity checking belongs in the application only, to keep all
business logic in the same place. Although this might be ideal, the real world is not
always that nice. Even if all integration can be done at the application level, there are
still plenty of valid reasons to use database constraints.
In addition, most databases in the enterprise tend to become integration databases
over time. Databases that are useful for one purpose are often appropriated for
another use. Sometimes you have a database that isn’t under your control, and you
want to use the data without performing a full ETL (extract, transform, load). Even
running a small script against your database without using the ActiveRecord model,
or maintaining the database manually through a console client such asmysqlorpsql,
means you have something accessing your database outside of your domain model. If
the validations in the domain are the only way to ensure that the data is consistent,
this may lead to problems.
Constraints
Database-level constraints provide a way to explicitly specify an application’s
implicit assumptions about its data. There are two types of constraints, which should
not be confused:
Business logic
“A manager may not manage more than five employees.” The key characteristic
of business logic constraints is that they could conceivably change throughout
the lifetime of the database. Business logic constraints should never be in the
database, barring a very good reason to the contrary.
Integrity
“U.S. Social Security numbers, when provided, must contain exactly nine digits.”
Integrity constraints define the nature of the data being represented. Admit-
tedly, “the nature of the data” is a somewhat nebulous concept; the meaning will
differ between databases. Integrity constraints must reside in the database, if for
no other reason than to provide a last-level sanity check on the data.