Greg Stein wrote:
> 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...
Isn't this premature optimization? Do we know how much slower using a BLOB will
be than a separate table? Sure, it will be slower, but how much?
From what I understand when designing schemas, you start off with a normalized
one than denormalize it as necessary for performance.
Blair
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1014091
Received on 2009-01-09 22:32:42 CET