On Thu, Jan 8, 2009 at 16:37, Blair Zajac <blair_at_orcaware.com> wrote:
> Hyrum K. Wright wrote:
>> Author: hwright
>> Date: Thu Jan 8 13:25:09 2009
>> New Revision: 35086
>>
>> Log:
>> Followup to r35085: Remove another properties-related table in favor of BLOB
>> column in yet another table.
>
> Is there a reason we're using BLOBs as all in our database? It seems useful to
> have all the data represented in SQL
>
> This is definitely de-normalizing the data :)
>
> I could imaging writing small Python scripts to query the SQL or do other stuff
> in there. If we have BLOBs, that means it's not as straight forward.
If you can show that the performance of selecting N rows from a
properties table and constructing a prop hash is the same or faster
than deserializing a BLOB from the same row as the node... then, sure.
Maybe that makes sense.
Also note that these tables are *private* to the WC. We do not have to
make any concessions for external scripts, which should be using WC
APIs anyways. As such, we are optimizing for overall performance. If
we can get clarity at a small perf cost, then sure... we'd do that.
But for the moment, I believe that a BLOB is going to be significantly
faster than N rows. I'm happy to see somebody demonstrate otherwise
tho...
Cheers,
-g
Received on 2009-01-09 11:49:36 CET