[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