Pods lets you create incredibly complex data structures and gives you many tools for working with them. With all these options, a lack of planning can leave you unable to complete your project. Laying out your goals and a path to reach them is the key to success. In this talk, Pods contributing developer Phil Lewis shares the lessons he's learned building Pods-powered sites to show you how to do proper data architecture planning in order to assure yourself of success.

1. Plan Before You Build:
Data Architecture
Planning
Phil Lewis, @pglewis13
Plan Before You Build: Data Architecture Planning // Phil Lewis // PodsCamp 2014

2. Considerations
● Relational database structure
● Performance
● WordPress interoperability
● What you need to do with the data
Plan Before You Build: Data Architecture Planning // Phil Lewis // PodsCamp 2014

3. Database Basics
● Single big flat table (spreadsheet approach)
Plan Before You Build: Data Architecture Planning // Phil Lewis // PodsCamp 2014

4. Database Basics
● Single big flat table (spreadsheet approach)
● Normalization
● Entities and relationships
Plan Before You Build: Data Architecture Planning // Phil Lewis // PodsCamp 2014

5. Performance is Not the Only Consideration
● Otherwise we’d just go for the fastest approach
● Often performance is good enough to allow for
compromise
Plan Before You Build: Data Architecture Planning // Phil Lewis // PodsCamp 2014

6. Why use native WordPress settings pages
○ A Pod without any items in it.
○ Perfect for use in a front-page.php template
○ Way easier than using WordPress Settings API
Plan Before You Build: Data Architecture Planning // Phil Lewis // PodsCamp 2014

7. Why choose native WordPress content types?
● Native custom post types and taxonomies/tags
● Interoperability with well written plugins and themes
● Automatic URL rewriting, archive pages, template
hierarchy friendly
● Leverage existing knowledge of the WordPress codex
functions without a need for the extra learning curve
of a new API
Plan Before You Build: Data Architecture Planning // Phil Lewis // PodsCamp 2014

8. What is meta (EAV)?
● WordPress is used by over 60% of all web sites where the
CMS is known.
● They’ve managed to do this with only 11 database tables
in a basic, non-multisite installation
● Easier to understand therefore easier to adopt
● Posts and users have meta tables; taxonomies do not (yet)
Plan Before You Build: Data Architecture Planning // Phil Lewis // PodsCamp 2014

9. EAV Example
Plan Before You Build: Data Architecture Planning // Phil Lewis // PodsCamp 2014

10. What is EAV good at?
● Flexibility: an item can have no meta attached, or 100
pieces of meta
● Easy to provide interoperability: everything fits in the
same sized box
● Avoids extra tables when using on LARGE setups
(WordPress.com for example, MILLIONS OF TABLES)
Plan Before You Build: Data Architecture Planning // Phil Lewis // PodsCamp 2014

11. What is EAV not so good at?
● Scales very poorly:
# meta fields * number items = # meta rows
● Text field indexes are a lot slower than integers
○ Affects sorting and filtering on meta fields
● SQL complexity with a lot of meta fields can lead to a lot
of joins (tricks here)
Plan Before You Build: Data Architecture Planning // Phil Lewis // PodsCamp 2014