I don't have a clash, I was just worried there might be one in the future. Even if it's a remote chance, I'd like to get things as watertight as possible. Easier to change things before going in production than after.
Thanks for your input guys, definitely answered my questions. Henrik On Tue, Mar 25, 2014 at 1:06 PM, Andy Seaborne <[email protected]> wrote: > There are two different layouts - hash style and index style. > > Index may work for you. > > If you have a clash, what is it? > > Andy > > On 25/03/14 10:51, Rob Vesse wrote: > >> Henrik >> >> Išm not familiar with SDB so canšt give you a precise answer but Išll do >> >> my best to address your question, see answer inline: >> >> On 25/03/2014 09:56, "Henrik Alstad" <[email protected]> wrote: >> >> Hi. >>> I'm looking at the SDB indexes for the Nodes table, >>> and I got a very naive question. >>> >>> There is a hash based Nodes table, >>> where there is no ID column, and the primary key of the table is the >>> hash. >>> >>> What happens if two of the lex-values by some insane coincidence get the >>> same hash? >>> >> >> I assume that you do get an error as you suggest. >> >> Regardless of the hash function used there is always a collision >> probability. SDB uses MD5 which has a probability of approximately >> 2^20.96 according to >> http://en.wikipedia.org/wiki/Comparison_of_cryptographic_ >> hash_functions#Cry >> ptanalysis so approximately 1 in 2 million >> >> Is there a built-in handling for this case, or is the hash-function >>> somehow >>> specified to be unique? or is there actually a slight possibility of just >>> getting sdb-errors ("non-unique primary key" or something like that) when >>> using that version? >>> >> >> AFAIK there is no handling for this situation >> >> SDB is not actively supported by the project and is in maintenance mode, >> none of the active developers are familiar with the code or maintaining >> it. It has also been shown to scale poorly compared to native triple >> stores. The project recommends the use of the native TDB triple store >> instead which is actively maintained and developed. >> >> Of course we recognise that there are various reasons why you might want a >> SQL backed solution - IT infrastructure limitations, project requirements, >> better failover support etc - but just be aware that you will be somewhat >> on your own wrt support is you choose to pursue SDB. While the project >> will try and fix bugs we donšt necessarily have the expertise to fix >> >> anything non-trivial. >> >> Rob >> >> -- >>> Cheers, >>> Henrik Kjus Alstad >>> >> >> >> >> >> > -- Henrik Kjus Alstad
