Re: [chiPHPug-discuss] Data Models

[Jason R. <ja...@ho...>]

Good comments.  I forgot about the follow on question regarding user 
modified schemas..

Also I just found this because replying to this thread got me curious 
about other data persistence layer approaches.  Dont know how I missed 
it before but it seems interesting:

http://code.google.com/p/torpor-php/

http://paultomlinson.net/tech/torpor



CM Lubinski wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Mudslinging is pointless.
> 
> What Anacreo proposes requires that the "schema" be handled by the
> script rather than the database (a more traditional schema). There's
> certainly cases where that could be useful, in the same way that there
> are cases where Google's file system makes sense. I think we can agree
> that it's not a common design and probably wouldn't be needed for small
> to medium scale projects.
> 
> I do see large similarities with document oriented databases, but
> Anacreo's proposition has the added benefit of proper foreign keys
> (though replication/horizontal scaling is, of course, more difficult).
> In any event, it's just a different, specialized tool and I appreciate
> hearing the thought (though I don't appreciate the derisive comments
> Anacreo's made.)
> 
> Back to junkmail's question about user-created fields:
> I've seen two options:
> 
> First, the PHP serves more or less as a front for ALTER TABLE ADD COLUMN
> x commands (with checks for column name length, uniqueness, etc).
> Whenever such a column is added, an entry in a "field list" table is
> also inserted so that, whenever loading a model of that type, the extra
> fields are also grabbed. With proper caching this query-per-instance can
> be avoided almost all together.
> 
> Second, a table serves as the "custom fields" table, with a column for
> associated model, a column for field name, and a column for value. This
> is used by Trac (ticket management software) for example, and either
> requires a left join for each additional field (obviously taxing), code
> that is smart enough to handle the duplicate data returned by a single
> left join (somewhat complex), or two separate queries (one for the
> model's base data and one for the custom field data). If you go the
> "custom fields" table route, I'd highly suggest you use multiple "value"
> columns, one for each type and/or foreign key (i.e. value_int,
> value_varchar, etc.), otherwise the "value" column has to be the most
> generic of the types you put in to it (often becoming a text field),
> which is highly inefficient, difficult to compare, etc.
> 
> Best of Luck,
> CM Lubinski
> - ---
> http://cmlubinski.info
> 
> 
> matt donohue wrote:
>> I'm missing the simple in your explanation or the reality of 3000 columns (Seriously???).
>> Do you project the schema on the side of buildings? 
>>
>>
>>
>> ________________________________
>> From: Anacreo <an...@gm...>
>> To: Chicago PHP User Group <chi...@li...>
>> Sent: Tue, April 20, 2010 8:40:23 PM
>> Subject: Re: [chiPHPug-discuss] Data Models
>>
>> Yeah I don't have time for this...  I've received similar poo poo
>> responses from this group on similar type discussions.
>>
>> I'll tell you I'm a performance EXPERT and have been designing large
>> scale systems for over 15 years.
>>
>> The general arguments have always been that the approach is too simple
>> or too not what you guys are doing.  Try working on a large scale and
>> you'll realize ruby on rails and PHP with training wheels isn't quite
>> the only answer.
>>
>> As for arbitrary numbers its not so arbitrary your code should meet
>> your demands.  When I signed up I didn't realize this group was PHP
>> for pea-pod size projects with a pea-pod brained Arlo.
>>
>> Alec
>>
>> On 4/20/10, matt donohue <mm_...@ya...> wrote:
>>> I'm resisting the urge to respond to this... or the 3000 columns.
>>>
>>>
>>>
>>> ________________________________
>>> From: Steve Gadlin <sg...@wc...>
>>> To: Chicago PHP User Group <chi...@li...>
>>> Sent: Tue, April 20, 2010 4:40:22 PM
>>> Subject: Re: [chiPHPug-discuss] Data Models
>>>
>>> I'm a big fan of one table design.  When I need a second table, I often
>>> create an entirely separate database for it, just to keep things separate.
>>> I don't like it when my tables "touch."  Viruses spread easier when they do.
>>>
>>> Hi Arlo.
>>>
>>> Steve
>>>
>>>
>>> On 4/20/10 4:37 PM, "Arlo Leach" <ar...@ar...> wrote:
>>>
>>>>> 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.
>>>> Well ... sure, I can wrap my head around it, but all the superlatives like
>>>> "wonderful," "fascinating," "brilliant" and "fun" plus the arbitrary,
>>>> large
>>>> numbers and the generality of your "elements" example made it sound like a
>>>> joke ... my mistake then. The Onion video is still funny, though.
>>>>
>>>> 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
>>> --
>>> Steve Gadlin
>>> Web Development Manager
>>> Weigel Broadcasting
>>> 312.660.8375
>>> sg...@wc...
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> chiPHPug-discuss mailing list
>>> chi...@li...
>>> https://lists.sourceforge.net/lists/listinfo/chiphpug-discuss
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> chiPHPug-discuss mailing list
>>> chi...@li...
>>> https://lists.sourceforge.net/lists/listinfo/chiphpug-discuss
>>>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> 
> iD8DBQFLzn8Afzi1OiZiJLARAjiDAJ0Xxtg2xJOdN/sX7Nkp4wkRivRG3ACdE9H4
> XE+5BWXG/aCmRsRUSLQFgnE=
> =WIIa
> -----END PGP SIGNATURE-----
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> chiPHPug-discuss mailing list
> chi...@li...
> https://lists.sourceforge.net/lists/listinfo/chiphpug-discuss