[UPHPU] Using a Database for Object Storage (Sad Times)

MilesTogoe miles.togoe at gmail.com
Wed Jul 1 09:58:21 MDT 2009


On 07/01/2009 09:40 AM, Lonnie Olson wrote:
> On Tue, Jun 30, 2009 at 7:38 PM, Kirk Ouimet<kirk at kirkouimet.com>  wrote:
>    
>> I am currently storing an object in a MySQL database. The object is
>> continually being updated by many (possibly simultaneous) requests. Workflow
>> looks something like this:
>>
>>
>>
>> 1.       Data comes in from one of many sources
>>
>> 2.       PHP reads the object from the database
>>
>> 3.       PHP adds data to the object
>>
>> 4.       PHP writes the object back to the database
>>      
>
> How are you storing your object in the database?  If you are storing
> the whole object in a single column via serialize or some other
> method, you will have this problem.
>
> This problem doesn't really exist if you are using "classic" database
> usage.  You may just need to change how your object is stored.  Each
> data point should have it's own column.
>
> Then your workflow will go something like this:
> 1. Data comes in
> 2. PHP reads current data
> 3. PHP adds data to object
> 4. PHP writes back only the data points that are changed
>
> Depending on what you do with the object, you may be able to skip steps 2 and 3.
> Now, the only concurrency problem is when two requests wish to modify
> the same data point, but that is a whole other problem.
>
> --lonnie
>
>
>    

or for storing objects, you might consider a key:value database such as 
couchdb, mongodb, etc - depends on what exactly your transactions are 
like as to whether speed will compare with a relatonal db.




More information about the UPHPU mailing list