??? 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 primary
key should be id, foreign keys should be thing_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 as mysql or psql,
means you have something accessing your database outside of your domain model.
Pages:
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174