Refactoring: Inheritance and Mixins
Since we know our website’s purpose is to
sell movie tickets, it makes sense to add tables to
hold sales data before we begin coding up the front-end. Figure 6-6 shows our first stab
at adding tables to store orders and ticket purchases. The orders table holds each transaction, including
the purchaser’s name, address, and credit card information. The purchased_tickets table is a line item table
for each ticket purchased in the transaction. Rather than simply
providing a column in the orders
table to record the number of tickets purchased, we split up the tables,
foreseeing the need to account for tickets at different prices, such as
student or senior discounted tickets, matinees, and so on.
In adding these extra tables, we find a glaring violation of
the Don’t Repeat Yourself (DRY) principle. The violation of
DRY occurs in the repetition of address data between the theatres table and our new orders table. If we kept the schema as is,
with the data duplicated, we would also end up duplicating a lot of
other code, including validation code and display logic for
addresses.
Figure 6-6. Theatre tickets data model with orders and purchased_tickets table, but with address schema repeated in two tables
Instead of duplicating this structure, we create a separate
addresses table. If mimicking the
previous examples, we would create address_id columns in the ...
Get Enterprise Rails now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
