1. Accelerating PHP development
Data-tier programming
Brian Rosenthal
Zvi Boshernitzan
Robocommerce
Hi, and welcome to this talk on Accelerating PHP development. My name is Brian Rosenthal, and this is Zvi Boshernitzan, and we both work for Robocommerce, a software company that does exclusively PHP programming.
We believe that mastering the data tier is one of the most important ways of reducing your code size, and thus creating applications that are quicker to develop and easier to manage, so we’ve filled this talk with techniques that we’ve found helpful.
All of them require an understanding of data modeling, so we’re going to start there. If you have *not* programmed with databases before, this talk may be a bit of a reach. Please listen, and see it as a way of gaining exposure. If you have worked with databases before, you’re ready for this talk. Unfortunately, we will not take questions during this talk like what is a database or how do you do an insert statement, but if you listen, you should learn something.

2. Overview: Data modeling
High-level approach to database design.
We will describe
Basic principles of data modeling
PHP Programming techniques
Database abstractions
Stack-based database programming
Inference-based database programming
If you have programmed in databases before, but have not had formal exposure to data modeling, we’ve dedicated the first part of the presentation to a review of basic data modeling concepts. If you’re familiar with these, please stick around and listen to our own take on them.
We’ll go through data modeling, and then go into PHP techniques for abstracting your data layer. Zvi’s going to talk about array and database abstractions. I’m going to talk about Stack-based database programming and inference-based database programming, and that will be it.

3. Basic principles of data modeling
Normalization: “Don’t repeat yourself.”
Entity Relation “ER” diagrams
There are two basic principles of data modeling that I want to talk about: normalization and visualizing relationships. (how many people have had exposure to normalization, ER diagrams)

4. Normalization “Don’t Repeat Yourself”
First approach: store the author information within the book.
Problem: what if there is more than one author. Where do we store the second author?
Normalization is really just a big word for don’t repeat yourself. I’m going to take you through a few examples to show you what it means.
This is a table of books…

5. Normalization “Don’t Repeat Yourself”
Second approach: store up to three authors
Problems: what if there are more, and what about all of the information about the authors (address, etc.)

6. Normalization “Don’t Repeat Yourself”
Third approach: have two tables: books and authors.
Authors have a book id.
“Each book may be written by 0 or more authors.”
Each author must be the writer of a book.

7. Normalization “Don’t Repeat Yourself”
Problem: We still have redundancy
Books id
title 1
Da Vinci Code 2
Angels and Demons
Authors id
book_id
first_name
last_name
phone_number 1
Dan
Brown 2

8. Normalization “Don’t Repeat Yourself”
Fourth approach: have three tables: books, people, authorship.
Each entry in the “authorship” table is a fact. That a particular person participated in an authorship of a book
No information is repeated!

9. ER Diagrams This is an ER diagram.
You read it: “Each product must be sold under a brand”
“Each brand may be the origin of 0 or more products”
ER diagrams are the most underused part of database programming, in my opinion.

10. PHP Database Infrastructure
Zvi: database abstractions.
Brian: stack-based SQL programming
Brian: inference-based SQL programming

11. Database “stack” programming
SQL as a big string versus SQL as a “stack”
SQL is, after all structured.
{‘select’:’firstname,lastname’
, ‘from’:’customers c’
, ‘ijoin’:{‘s’:{‘table’:’sites’, ‘on’:’s.id = c.site_id’}}
, ‘where’:[“c.name like ‘%brian%’”, “c.id > 10”]
, ‘limit’:10
, ‘offset’:5 }
$q->add_where(…)
$q->add_select(…), $q->set_select(…)
$q->add_lojoin(…)
$q->load_dict({‘select’:’c.address_id’, ‘where’:…})
$q->to_sql()
$q->to_dict()

12. SPEC DRIVEN DATABASE PROGRAMMING
db::objects($q->to_sql())
db::assocs($q->to_sql())
db::string($q->to_sql())
db::object($q->to_sql())

13. INFERENCE-BASED DATABASE PROGRAMMING
A lot of information is stored in the database schema
The idea here is to use it where it is possible to do so

14. Inferences from ER diagrams … if you were writing classes to manage these database entities, you might include:
products::mget_by_category(…)
products::mget_by_brand(…)
products::map_keyword(…)
products::mget_by_keyword(…)
keywords::mget_by_product(…)

15. Enter: PHP 5 Call handler override “function __call($m, $args)”
Mysql reflection
Singleton / factory semantics
Autoloads

16. You should really get all of these functions for free:
mg(‘products’)->get($product_id)
mg(‘products’)->create(‘name’, ‘lawnmower’)
mg(‘products’)->mget_by_keyword($keyword_id)
mg(‘products’)->mget_by_category($category_id)
mg(‘products’)->mget_by_brand($brand_id)
mg(‘products’)->get_by_sku($sku)
mg(‘products’)->get_title($product_id)
mg(‘products’)->get_title(‘sku’, $sku)
mg(‘products’)->map_keyword($keyword_id)
mg(‘products’)->colnames()
mg(‘categories’)->get_products($category_id)

17. So, here’s the class: class products extends dbentity {
function references() {
return array('brand_id' => 'brands‘, 'category_id' => 'categories'); }
function mappings() {
return array(
‘keywords' => array(‘product_keywords', 'product_id', ‘keyword_id', ‘keywords‘)
, ‘related_products' => array('product_relations', 'from_product_id', 'to_product_id', 'products')
, 'suppliers' => array('supplier_prices', 'product_id', 'supplier_id', 'suppliers‘
, array('wholesale_price' => 'price', 'sku' => 'sku')) );

18. Customizing the sql: $q = new dbquery(array( ‘select’ => ‘p.name’
, ‘from’ => ‘products p’
, ‘ijoin’ => array(‘c’ => rba::_(‘table’, ‘categories’
, ‘on’, ‘c.id = p.category_id’))
, ‘where’ => “name like ‘%lemon%’ ”
, ‘order_by’ => ‘p.name’
));
$q->add_select(‘p.subname’)
$q->add_ijoin(…)
$q->set_limit(…)
$q->load($q_spec)

19. Customizing the SQL $dbquery = array(
‘select’ => ‘c.name as category_name’
, ‘ijoin’ => array(‘c’ => rba::_(‘table’, ‘categories’
, ‘on’, ‘c.id = p.category_id’)))
mg(‘products’)->get(product_id, compact(‘dbquery’))

20. Zachman Framework Data (What) Activities (How) People (Who)
Timing (When)
Motiva- tion (Why)
Network (Where)
Objectives/ Scope
List of Important Things
Organi- zational Units
Business Events, Cycles
List of Processes
Business Locations
Business Vision and Mission
Business Owner’s View
Business Process Model
Operations by Business Location
Org. Chart, Roles
Master Business Schedule
Business Policies and Rules
Terms, Definitions
Entity/ Relationship Diagram
Data Links, Processing Locations
Roles+Data (Use Cases)
State/ transactions, ELH
Architect’s View*
Essential Functions
Business Rule Model
Designer’s** View
Network Architecture (h/w, s/w types)
User Interface, Security
“Control Flow” diagrams
Tables, Classes
System Design
Rule Design
Data, physical storage design
Detailed Program Design
Screens, Security Design
Builder’s View***
Network Construction
Timing Definitions
Rule Specification
Functioning System
Working System
* John Z calls this the “information designer’s” perspective.
** He calls this the “builder’s” view.
*** This is John Z’s “sub-contractor’s” view.