Read Me

ABOUT the EAV Data Model
++++++++++++++++++++++++
EAV or "Entity Attribute Value" data model, models data by associating a "instances" with
attribute values, usually with an attached schema to describe what the data should look like.

In theory one can build an EAV in a single table, but in practise this becomes a hard to manage.
Typically one uses at least the following tables:
* The attribute definition table (a schema is implemented as an attribute)
* The schema/attribute definition table
* The entity instance management table
* The entity attribute value table

This toolkit will attempt to make EAV's more accessable to programmers by first focussing on the basic
theory of modelling an EAV and then alter extending the model to provide a useful API and UI to play with.
Later we'll look at optimizing the EAV and bringing in vendor specific optimizations.

Wikipedia says: "Entity-attribute-value model (EAV), also known as object-attribute-value model and
open schema is a data model that is used in circumstances where the number of attributes (properties,
parameters) that can be used to describe a thing (an "entity" or "object") is potentially very vast,
but the number that will actually apply to a given entity is relatively modest."
(http://en.wikipedia.org/wiki/Entity-Attribute-Value_model)

THEORY
======

GLOSSARY
--------
Table structure:

== EAV ==

Field    | Type          | Comments
---------+---------------+-------------------------------------------------------
ENTITY   | VARCHAR(250)  | The Entity URI, unique for each instance
ATTRIBUTE| VARCHAR(250)  | The Attribute URI, unique for each field or attribute
VALUE    | VARCHAR(250)  | The value for this object, this attribute

Example:
To model a conventional table user that looks like this:
Field    | Type          | Comments
---------+---------------+-------------------------------------------------------
ID       | INT           | The user's unique ID
NAME     | VARCHAR(250)  | The user's name
LOGIN    | VARCHAR(25)   | The user's login
PASSWORD | VARCHAR(25)   | The user's password

with records:

ID | NAME        | LOGIN  | PASSWORD
---+-------------+--------+--------------------------------
1  | Admin       | admin  | secret
2  | User        | user   | demo


the EAV might look like this:
 ENTITY | ATTRIBUTE | VALUE
--------+-----------+------------------
  1     | ID        | 1
  1     | NAME      | Admin
  1     | LOGIN     | admin
  1     | PASSWORD  | secret
  2     | ID        | 2
  2     | NAME      | User
  2     | LOGIN     | user
  2     | PASSWORD  | demo

One then typically adds a schema definition to better handle the validation and form building.

Storing of values.
------------------
In it's simplest form the EAV values would be converted to varchar and stored like that. For some basic optimization,
I opted to create separate tables for each of the major data types: int, float and varchar.

I also didn't want to implement shared list values at this stage, so list values will have the actual list value(s)
stored in the value table. Since this increases readability and doesn't cost too much in terms of performance, I
decided that shared lists can be implemented later.

Retrieving data
---------------
It should be noted that without sub-query or temporary table support, the system will have to make a quite complex
queries against the database.

Class Diagrams
--------------
eav_persistent
    eav_attribute
        eav_schema_attribute
eav_database


TESTS
-----
I decided to use PHPUnit from http://www.phpunit.de to handle the tests.