Database Reference
In-Depth Information
Denormalization
Our follow tables are also the first example we've seen of denormalization , which is the
practice of storing the same data in more than one place. Denormalization is typically
frowned upon in relational database schemas, although from a practical standpoint it's often
a useful optimization even in that scenario. In non-relational databases, denormalization is
often a critical tool in query-driven design.
The downside of denormalization is exemplified by our preceding insert pattern: we have
to make two INSERT statements to fully represent one fundamental fact. From a stand-
point of performance, this is acceptable: Cassandra is optimized for efficient write opera-
tions, so we're happy to make verbose writes in order to allow efficient reads. This does, of
course, add more complexity at the application level: the application is responsible to en-
sure that any modification to the user_outbound_follows table is accompanied by
an equivalent modification to the user_inbound_follows table. If there is a flaw in
the application's logic, the two tables may not contain consistent information.
Search WWH ::




Custom Search