Is Guid the best identity datatype for Databases?

Question

It is connected to BI and merging of data from different data sources and would make that process more smooth.

And is there an optimal migration strategy from a data

Answer 1

Keep in mind that GUID's (or 'unique_identifier') for PK's is a bad choice, as many PK's have a clustered index (so all rows are stored on disk in the indexed order). As GUID's are random, it's not certain a new row will be appended at the end of the index, but could be inserted in the middle of the index. This causes disk trashing as the rows have to be moved.

IF you consider guid's, at least use sqlserver 2005 or up and NEWSEQUENTIALID() for the PK value, to get sequential guid's which are always bigger than the last one, so are always appended at the end of the index. If you're not using sqlserver (but for example postgresql or you're using oracle and use CHAR(32) or other type), consider COMB's (see: http://www.informit.com/articles/article.aspx?p=25862 )

Answer 2

You will probably need the facility to track back to source for auditing purposes, especially on financial data.

Even if you use synthetic keys in your warehouse system (which you almost certainly want to do if you have multiple data sources) you will still need to support auditing. Put a 'Data Source' and 'Natural Key' column on the tables in your system and populate them with a code for the source and a representation of whatever uniquely identifies the record at source.

If you do this the synthetic keys need only be ints or numerics wide enough to store enough values (ints if <4b rows, numerics if over). This means they will be much more readable than a GUID.