Re: [chiPHPug-discuss] Data Models

[<an...@gm...>]

I wasn't being sarcastic at all Arlo I was giving you a design pattern for working with very large customizeable and extensible data set, sorry if you can't wrap your head around this design.

I gave the example of Elements table so obviously this is one table definition of Many.  The table used partitioning to divide the table into multiple sets of data 7 in our case so only 1 set of data files would be modified in a single day easing the backups of a 7TB database, not to mention 2000 concurrent users in a single monolithic system.  But the key is to group data as it would be likely to have similar sets of data and define your table schema from that approach.  You could probably guess users were in a users table products were in a product table etc.

The concepts involved here are quite advanced and basically turns Oracle/Mysql/Postgres into a system more like big tables.

The key to the data model (which is also similar to big tables) is to abstract the query language from the storage model.  The query API handles resolving column names into field numbers avoiding the scavenger hunt.

Another type of DB layout was asked for and I believe I have answered that.

Alec
Sent via BlackBerry from T-Mobile

-----Original Message-----
From: Arlo Leach <ar...@ar...>
Date: Tue, 20 Apr 2010 12:22:05 
To: Chicago PHP User Group<chi...@li...>
Subject: Re: [chiPHPug-discuss] Data Models

Hello,

> I worked on a very large system that had a wonderful design for some of their tables that is worth investigating.  Perhaps this works best for Oracle but...
> 
> They make a table let's call it element.
> They make the table with 3000 columns let us say.


Just one table for the whole project? That sounds so simple!

In fact, it reminds me of the MacBook Wheel: http://www.youtube.com/watch?v=9BnLbv6QYcA

(You were being sarcastic, right?) 

> I think I'm probably doing to end up with a hybrid model consisting of a 
> class-based data model with hard coded sql for sticky stuff, and a 
> moderately complex CRUD sql generator to handle basic joins across a few 
> tables.

One more thought is that I've used third-party software where the SQL queries were constructed from so many little pieces that it was impossible to understand how the code integrated with the database. When you want to customize something like that, you end up getting frustrated and just wanting to know where a value comes from already! So in my classes most of the queries are "whole," or at least all the pieces are contained in the same method, so if anyone else needs to modify it they don't have to go on a scavenger hunt through the whole project to figure out how the queries are constructed.

Cheers,
-Arlo

_______________________________

Arlo Leach
773.769.6106
http://arlomedia.com

The killer app for the iPad
http://washboardapp.com


------------------------------------------------------------------------------
_______________________________________________
chiPHPug-discuss mailing list
chi...@li...
https://lists.sourceforge.net/lists/listinfo/chiphpug-discuss