Embed Size (px)
DESCRIPTION
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.
Citation preview
Plan Before You Build: Data Architecture Planning // Phil Lewis // PodsCamp 2014
Plan Before You Build:Data Architecture
PlanningPhil Lewis, @pglewis13
Plan Before You Build: Data Architecture Planning // Phil Lewis // PodsCamp 2014
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
Database Basics
● Single big flat table (spreadsheet approach)
Plan Before You Build: Data Architecture Planning // Phil Lewis // PodsCamp 2014
Database Basics
● Single big flat table (spreadsheet approach)● Normalization● Entities and relationships
Plan Before You Build: Data Architecture Planning // Phil Lewis // PodsCamp 2014
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
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
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
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
EAV Example
Plan Before You Build: Data Architecture Planning // Phil Lewis // PodsCamp 2014
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
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)
![[Architecture ebook] build your own smart home](https://img.dokumen.tips/doc/110x75/541208e48d7f7295728b46a0/architecture-ebook-build-your-own-smart-home.jpg)
