db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: Collation implementation WAS Re: Should COLLATION attribute related code go in BasicDatabase?
Date Thu, 15 Mar 2007 20:52:15 GMT
Somehow this ended up with the odd subject "QL". Here it is with the 
right subject.

Regards,
-Rick

Rick Hillegas wrote:
> Mike Matrigali wrote:
>>
>>
>> Rick Hillegas wrote:
>>>>>
>>>>
>>>> This is where I get confused.  Are multiple collations required in 
>>>> a single database?  With plans for DERBY-1478 it isn't.  With new 
>>>> collations it isn't.
>>>> With collation per-schema it is, but should we pay overhead now for a
>>>> possible future, as long as we have a design that supports an upgrade
>>>> path to it?
>>>> I am not seeing the value in the argument for storing it once per
>>>> table vs. once per database today.
>>>
>>> Hi Mike,
>>>
>>> Can you expand on this? What is the overhead we're avoiding?
>>>
>>> Thanks,
>>> -Rick
>>
>> Pushing an extra argument on every object creation for each member of 
>> a template. Interpreting the extra argument in the object creation call.
>> Storage space in the conglomerate.  Code to read/write the extra 
>> metadata.  The templates in the worst case are created once for each 
>> conglomerate/index accessed in each sql statement.  In best case the 
>> templates are reused across executions of same prepared statement.
>>
>> I admit all this may be small, and if we NEED it then I have no problem
>> it being added.  I just have a problem if there is no need.  I have been
>> burnt in the past adding stuff that I thought might be useful in the 
>> future, so now I tend to lean toward implementing what we need today, 
>> while making sure there is a reasonable upgrade path in the future.  
>> If I thought today's code was making it harder for a future path that 
>> would be a different case.  For
>> example what if whatever way we decide to store the value of the 
>> collation today, turns out not to work for future expansions of the 
>> collation - and we could have gotten away with storing it once per
>> db vs once per table.  Now we have a much bigger upgrade issue.
>>
>> The system catalog implication may make this all a moot discussion, 
>> it may be the reason we need per-schema collations.  Mamta's original
>> design handled system catalog vs non system catalog with format id's so
>> there was no need for per conglomerate collations.  I didn't realize 
>> until my last message that Dan's proposal would need multiple 
>> collations in a single db in 10.3.
> Thanks, Mike. This overhead seems pretty small to me. It's hard for me 
> to predict whether this is useful generality or over-design.
>
> In the SQL standard, collations can be declared per column. That 
> affects index descriptors. In addition, via CASTs, collations can be 
> declared per sortable expression in an ORDER BY clause. That affects 
> the sorter. I'm not the person scratching this initial itch. I just 
> want to register my instinct to design-in the generality up front. I 
> think this has two advantages:
>
> 1) It will remove an upgrade issue later on when someone wants to 
> implement more of the SQL collation support.
>
> 2) It generally lowers the barrier to implementing more of the standard.
>
> Regards,
> -Rick


Mime
View raw message