Newsequentialid() Is Broken in SQL Server for Linux

Entity Framework Core 1.0 RTM add migration failure

Because you are using version 1.0.0 (and not rc2) your tools should be preview2 and not preview1. You also don't need imports anymore. After you fix your project.json I would recommend cleaning NuGet caches with nuget.exe locals -Clear all
As a side note - you have publish-iis configured to run as a postpublish script but you don't have this tool in your project so you will get an error when publishing since dotnet won't be able to find this tool. You need to add Microsoft.AspNetCore.IISIntegration.Tools to your tools section (again preview2 and no imports)

Sorting on GUID SQL Server 2008

Don't is the best answer.

This explains how SQL Server: How are GUIDs sorted by SQL Server?

You have NEWSEQUENTIALID but this is not guaranteed to sort as you expect. And why use a GUID when you have ranking functions?

What is the difference between Scope_Identity(), Identity(), @@Identity, and Ident_Current()?

• The @@identity function returns the last identity created in the same session.
• The scope_identity() function returns the last identity created in the same session and the same scope.
• The ident_current(name) returns the last identity created for a specific table or view in any session.
• The identity() function is not used to get an identity, it's used to create an identity in a select...into query.

The session is the database connection. The scope is the current query or the current stored procedure.

A situation where the scope_identity() and the @@identity functions differ, is if you have a trigger on the table. If you have a query that inserts a record, causing the trigger to insert another record somewhere, the scope_identity() function will return the identity created by the query, while the @@identity function will return the identity created by the trigger.

So, normally you would use the scope_identity() function.

Should I use UUIDs as primary keys for Rails?

I dislike UUIDs for "primary keys" in general, however, a distributed model is one in which they fit rather well, assuming the UUID is generated appropriately ;-) Depending upon other issues, it still might not be the primary key, but rather another candidate key (think of "an alternate PK" that is backed by a unique index).

The two "issues" I am aware of are:

1. UUIDs are like IPv6. They are long and are thus not the most human-friendly values about. On the other hand, they are very consistent in formatting and are easy to spot. Have your copy'n'paste skills about.

2. Completely random UUIDs tend to fragment indices; if used as PK, which is normally clustered (vs. an index which may just a pointer to the record), this can lead to terrible fragmentation. However;

   1. A good database maintenance plan should solve this: re-index fragmented indices on a schedule.

   2. Special UUID generation schemes, such as NEWSEQUENTIALID in SQL Server, while "more predictable", can also generate monotonically increasing values and thus mitigate index/cluster fragmentation.

Happy coding.

---

Related Topics