On Sunday, November 18, 2012 at 01:10, David Johnston wrote:
>
> Can the system be made smart enough to not allow intra-schema
> collisions in addition to same schema ones? That would seem to be the
> area of greatest concern - particularly around the usage of
> truncate/delete/drop.
>
>
My summary FWIW:
1. Potential exists for internally generated names to exceed maxlen; and
2. this maxlen is shorter than the SQL standard specification; but
3. it may not be worth the performance hit to be SQL compliant in this; with
4. potential for (undetected) name collision and unintended consequences.
May I suggest an idea from the days when memory was counted in (tiny int) kB:
represent the over maxlen identifiers "as is" up to maxlen-8 bytes
use those last 8 bytes for a 40bit hash in Base32 for disambiguation
and,
if 1:10^^12 residual collision risk is considered too high
a side list of overlong names would allow for a second hash disambiguation process.
Notes:
1. The choice of Base32 encoding may be a matter of personal preference
<http://en.wikipedia.org/wiki/Base32>, and, if so, I suggest using the
Crockford encoding <http://www.crockford.com/wrmg/base32.html>.
(I am impressed his design is excellent, while also averting some
accidental obscenities. None of the others offer this feature :)
2. Something along these lines, with the side table to track the
(hopefully) occasional overlong identifiers, could give standards
compliance in identifier length while still keeping the working
tables compact.
3. (Wild speculation) There may be a "sweet spot" using even shorter
identifiers than is the case now, with full disambiguation, which
might improve overall performance.
Regards
Gavan Schneider
