Rails anti-patterns: how not to design your database

Other

Get Started. It's Free

or sign up with your email address

Rails anti-patterns: how not to design your database by Dominik Plšek Mind Map: Rails anti-patterns: how not to design your database

1. SCALE@PROCORE

2.1.1. Alternatives

2.1.1.1. Closure Trees

2.1.1.1.1. gem 'closure_tree'

2.1.1.2. Materialized Path

2.1.1.2.1. Microsoft uses it in their SQL

2.1.1.2.2. gem 'ancestry'

2.1.1.2.3. Potential for data mistakes

2.1.1.2.4. Fast

2.1.2. hardest to query

2.1.3. joineception

2.1.3.1. joining on every level of tree

2.1.4. N+1 queries

2.1.5. Recursion

2.1.5.1. not very supported in ORM, hard to performance tune

2.1.5.2. not ideal as we have to write recursion to parse the data for displaying them

2.1.6. Simple

2.1.7. Referential Integrity

2.1.8. Efficient on disk space

2.1.9. Use when don't need descendentes

2.2.1. Built-in in Rails

2.2.2. Easy to add more

2.2.3. No foreign keys

2.2.4. No cascading delete

2.2.5. Alternatives

2.2.5.1. Exclusive Arcs

2.2.5.1.1. Foreign key constraints

2.2.5.1.2. Cascading delete

2.2.5.1.3. Possible mistakes

2.2.5.1.4. More migrations

2.2.5.1.5. Many indexes

2.2.5.2. Base Parent Table

2.2.5.2.1. Use when lot of shared fields

or Sign Up