Michel,

>As more and more applications are talking with other ones, do you think that more database design will go in favor of a GUID approach for their primary key as some of them will travel across the wire to end up in other applications?

I think so. With GUIDs there's no messing around with PK values when adding records that were created offline (Pocket PC, Palm, etc.). Yes, and they are unique for your record all over the world.

I'm currently doing my first project with GUIDs as PKs. I really like it. We don't have to ask the application server for a valid PK value, we just create a GUID in our BizObjs locally. This saves us one roundtrip to the application and the database server (= more speed and less resources). It also makes prefetching of PK values easy this way. No need to ask the database for a PK value, so this is also easier for simple VFP apps. This might not be the best design from a theoretical point of view, but I see it as a contract between our BizObjs, the rest of the middle tier and the database.

Entering test data directly to the database with Enterprise Manager or other tools is also no problem. We have defined a SQL-Server built-in function that generates GUIDs as a default value for PK columns. So here's no problem as well.

One disadvantage of them is, you can't just say oBizObj.GetClientByID(4711) for testing purposes < g >. It's always something like oBizObj.GetClientByID('2D96013F-B0E6-40B4-B150-085FCDC6598B'). But you can copy and paste the IDs from Enterprise Manager or any other tool, so this is not a real problem.

Another disadvantage of them is their size (16/32 Bytes - MSSQL/VFP), but I don't think that is really an issue. Maybe joins or complex queries might take a little longer, but IMO this isn't a real problem either.

If I can, I will only use GUIDs for PKs and nothing else.

Regards,
Armin