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