Subject Re: [firebird-support] Re: UUDIs/GUIDs and problem with uuidlib
Author Daniel Albuschat
2006/7/18, lutterot <lutteroth@...>:
> > > I need to use UUDIs/GUIDs as primary keys in my DB...
> > Don't do this. It's fine to have a UUID as a separate, unique field
> > but having it
> > as a primary key is not good, not at all.
> But this is what I need for this project...

Why exactly? Using the UUID as a unique, not null field instead of the
real database's primary key shouldn't be that much of a difference to your
application, imho.
The replication might be more work if you're using foreign keys, though.

> > Why do you use two different UID-techniques in one and the same
> database?
> The UUIDs are said to be optimized for fast indexing and are smaller,
> so that this is the choice for the DB. The GUIDs, however, are the
> standardized representation and have to be used on the application
> level. I don't know enough about uuidlib's UUIDs to convert them to
> GUIDs in the application.

But it'd be easier to convert the UUID within your application than
writing a udf to do this, since it'd basically do the same but would
need to handle the managed vs. unmanaged problem.
It's the same with, for example, integer: Usually, you don't need a
function in the database to convert an integer to it's ASCII-presentation.
That's something that ought to be handled at application-level.

> > Implementing UDFs in .NET would be quite a waste of both,
> programming time and CPU cycles.
> Maybe. But at least I know how to program in C# :-)

It's basically easier to learn the needed stuff of a new language to
do the (quite simple) UUID task than to call a .NET-dll from within
Firebird, AFAIK. Well, I have no experience with .NET personally, but from
what I've heard you have to do quite some magic to call managed code
from unmanaged code. This is without warranty, though.

eat(this); // delicious suicide