Defense Against the Dark Arts: Protecting Your Data from ORMs

Defense Against the Dark Arts Protecting 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::Base
self.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 weapons
SELECT * 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::Base
class 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_at
SELECT * 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 out Monitor logs with PgFouine to find problem queries
System Tables (index usage, pg_stat, pg_stat_io, null fill)

Never Fight Alone

http://vanessahurst.com	888
http://posterous.com	40
http://www.slideshare.net	18
https://posterous.com	9
https://twimg0-a.akamaihd.net	5
url_unknown	3
https://si0.twimg.com	2

Defense Against the Dark Arts: Protecting Your Data from ORMs

by Vanessa Hurst on Mar 23, 2011

Accessibility

Categories

Tags

Upload Details

Usage Rights

7 Embeds 965

Statistics

Defense Against the Dark Arts: Protecting Your Data from ORMs — Presentation Transcript