Post on 31-Oct-2014
description
Defense Against the Dark ArtsProtecting Your Data Against ORMs
Object-Relational Mappers
"An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data.”
Fundamental Perspective Shift => Inevitably, something will be lost
• Enables Rapid Development• Simplifies Application Code• Standardizes Relationships • Standardizes Data Structures• Sometimes Sucks
Defense Against the Dark Arts
Overview
• Relationships
• Inheritance
• Data Types
• Memory Usage
• Data Integrity
• Version Control
• Connections
Relationships
Object Relationships
• Maintained in application code (transparent to developers)
• Simplified Validation (easier for developers to remember)• Cheap, but viable alternative to foreign key constraints
Examples
• 1 : ∞ | one-to-many = A has_many B• 1 : ∞ | one-to-many = A has_many B through A_B• 1 : 1 | one-to-one = A has_one C• ∞ : 1 | many-to-one = B belongs_to A • 1 : 1 | one-to-one = C belongs_to A• ∞ : ∞ | many-to-many = D
has_and_belongs_to_many A
Inheritance
Concrete vs Single Table Inheritance
• Caution: These are TOTALLY DIFFERENT. And confusing.
• Use PG Table Inheritance with Abstract parent class (or Partitioning)– Parent structure allows code reuse and some helpful queries– Child tables are physically separate, so have their own
performance metadata - indexes, keys, etc.
• Use Single Table Inheritance for Small Data sets– All Child classes are physically in Parent table with “type”
attribute– This sucks for a lot of data, and is hard to maintain & extend
Inheritance
Postgres Table Inheritance with Abstract parent class – Parent structure is really for app code reuse, not giant tables– Child tables have their own performance metadata – indexes,
etc.
class Weapon < ActiveRecord::Baseself.abstract_class = true
class Wand < Weapon
CREATE TABLE Weapon(id int, name text);
CREATE TABLE Wand(wood text, length int, core text)
INHERITS (Weapon);
SELECT * FROM Weapons; --wands and other weaponsSELECT * FROM Wands; --only wands
Inheritance
Single Table Inheritance for Small Data sets– All child classes physically in Parent table with “type”
attribute– This sucks for a lot of data, and is hard to maintain &
extend
class Weapon < ActiveRecord::Baseclass Wand < Weapon
CREATE TABLE Weapon(id int, name text, wood text, length int, core text, type text
);
SELECT * FROM Weapons WHERE type = ‘Wand’;
Data Types
Standard Data Types
• Port to new DBMS easily• Developers don’t have to learn new data types• Use tools written for any DBMS without modification
• Miss out on Postgres awesomeness• Waste space & memory• Compromise data integrity
Examples
• Custom Data Types: INTERVAL, smallint, floating point• Size Limitation: Zip code, Phone number, Email Address
Memory Usage
RDBMSs store rows ORMs retrieve objects
Every time you use any piece of that object’s (row’s) data, you get back everything you ever added on to that model (table).
> Accounts.find(2)SELECT * FROM "accounts" WHERE ("accounts"."id" = 2)
> Accounts.find(2).updated_atSELECT * FROM "accounts" WHERE ("accounts"."id" = 2)
• Number and data type of attributes per table DO matter• Watch out for large fields, TOAST data especially
Data Integrity
Safeguards & Dark Arts Trickery
• Foreign Key / Relationship enforcement• Standardized Validation in model (& thus across
application)
• NULL vs Empty String– Defense: Look at data created in all scenarios. The slightest application code difference can mean
different data.Varies by ORM.
• Object–to–row updates can Nullify an entire row– Defense: Add NULL constraints to database
Specify if and how fields can be updated (e.g. keys can’t be set to NULL)
Version Control
Schema Management
• Ideally correlated with application changes• Rails db migrations stay in branch with dependent code• Migration scripts include up & down to reverse effects
Data Migrations
• YMMV - Find the right tool for the job• Iterative or set-based? • How much time do I have at run-time?• How will this impact the production site?
• Small dynamic migrations stay with the schema change logic
• Adding/updating custom data should be separate
Connections
Connection Persistence
• Configuration is only evaluated at deploy time• Expense of creating & dropping connections is
limited
• Every call gets wrapped in a transaction– Very important to remember for migrations and callback-
style background processes sometimes naively launched in parallel
Strategy: Know Your Data
"Trust is for people with poor surveillance” – Col. James R. Trahan, USMC
• Don't be at the mercy of your application code Run Bad Data Checks
Cron job/Rake task to run stored checks & email results
CREATE TABLE data_checks(id int, name text, description text, check_sql text, fix_sql text);
• Don't guess what’s happening, find outMonitor logs with PgFouine to find problem queriesSystem Tables (index usage, pg_stat, pg_stat_io, null fill)
Never Fight Alone