Are there any repercussions using Negative Primary Keys for tables (Identity Increment -1, Identity Seed -1 in SQL Server 2005)?
The reason for this is we're creating a new database to replace an existing one. There are similar tables between the two databases and we'd like the "source" of the information to be transparent to our applications. The approach is to create views that unions tables from both databases. Negative PKs ensures the identities don't overlap.
Not a problem.
It is slightly un-orthodox, but apart from that, fine.
The default offered by SQL Server is just that - a default, and can be changed to suit needs. Looks like you got a good compromise.
This is perfectly fine from SQL Server's perspective. The real question is going to be your application.
Only problem is you won't be able to add a third data source this way!
It is not an issue. Just make sure your Identity column is of a type that allows negative numbers.
You'll want to review legacy code and look for where developers have sorted on primary key as a lazy/sloppy way of sorting by date (because identity pk's usually are strongly or perfectly correlated to time).
If negative numbers turn out to break something, use even numbers for one and odd numbers for the other.
Like others have said, the database is fine with this.
But it would be a problems for a .NET application that uses DataSet+DataAdapter as they use negative keys as temporaries for new records.
Other data-access layers may use similar tricks.
Another option is to prefix the legacy keys with a string like "OLD_". The ony problem is your key field will be non-numeric.
If you have to have numeric keys, you could introduce a "legacy" indicator column, and the primary key would be a combination of the numeric ID and the legacy indicator (hopefully, that combination should be unique).