From: Anjo K. <kr...@lo...> - 2006-06-30 07:01:30
|
Am 30.06.2006 um 08:51 schrieb Guido Neitzer: > Currently I'm working on a project where I really don't know how big > some tables in a database may become (some of them may become really > big), so I'm not sure whether I should go with integer primary keys > (32 Bit) and I'm also not sure whether to go with db created primary > keys (perhaps issues when using a multi master cluster). It is used by the project that I got in January. The main feature is =20 that it does some auto-encoding of entities and hosts, which makes it =20= possible to have multiple DBs and sync them later on. I still don't =20 like it, as it increases the number of PKs with each start of the app =20= by 1000, which is a bit wasteful (granted, with 64 bit you have a lot =20= of room, though) and you need to call it directly, as opposed to =20 simply override the DBC delegate where it would rather belong in. So if I get some time, there=B4s some refactoring due here.... > For now I have chosen to use 24 byte binary primary keys generated by > EOF, but I'm not really happy with them. They are hard to use with > other tools, even when just doing some fetches for one row in the db > tool just to test something. We use these for our main product. Works quite well when you use PG =20 with the hex-encoded keys. A pain when you don't. Also, performance =20 may or may not be impacted. And they are also wasteful as half of =20 these 24 bytes are zero. Cheers, Anjo |