Rails anti-patterns: how not to design your database

Altro

Iniziamo. È gratuito!

o registrati con il tuo indirizzo email

Rails anti-patterns: how not to design your database da 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

o Registrati