On Fri, Mar 4, 2011 at 7:18 PM, Enrico Thierbach <e...@open-lab.org> wrote: > On 04.03.2011, at 22:21, Drake Wilson wrote: >> Why do you want to do this? In particular, why would it not work to >> randomize the values from the application side during inserts?
> I am trying to build a solution where two or more databases can synchronize > with each other. As in my problem area > the databases are pretty small (probably less than a 1000 rows), the > collision probability given roughly 64 bit > of randomness would be about 1000 / 2^32. This is less than 10^-6, which is > good enough for me. However, > I am aware that there are better ways to generate IDs that are guaranteed to > be different in different databases. If that's all you want... you could use an LFSR with a sufficiently long period, with the same seed in both DBs but using alternate outputs for each DB, though you'd have to keep LFSR state and serialize access to it. But then you might as well just use odd monotonically incremented rowids in one and even ones in the other, and just forget about the PRNG :) Also, this approach to synchronization only really works if it's OK to synchronize by taking a union and you either guarantee that there are no conflicts or don't care about any conflicts. > To explicitely generate an ID in the application, however, is not a suitable > solution for me. This must work out of the box > (i.e. on a database) with any application that uses this database. Therefore > I am somewhat limited to what SQLite can > give me via SQL (or probably by extending SQLite via its C interface). You could easily use a trigger, as you showed in your original post. In any case, you don't need a PRNG, or any entropy, just a convention by which to allocate non-conflicting IDs (see above). Nico -- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
