Последовательный GUID в Linq-to-Sql?

Гребни генерируются следующим образом:

DECLARE @aGuid UNIQUEIDENTIFIER

SET @aGuid = CAST(CAST(NEWID() AS BINARY(10)) + CAST(GETDATE() AS BINARY(6)) AS UNIQUEIDENTIFIER)

Что в переводе на C # будет выглядеть так:

    public static unsafe Guid CombGuid()
    {
        Guid guid = Guid.NewGuid();
        byte[] bytes = guid.ToByteArray();
        long ticks = DateTime.Now.Ticks;
        fixed( byte* pByte = bytes )
        {
            int*    pFirst  = (int *)(pByte + 10);
            short* pNext    = (short*)(pByte + 14);
            *pFirst = (int)(ticks & 0xFFFFFF00);
            *pNext  = (short)ticks;
        }

        return new Guid( bytes );
    }

Код C # (безопасный) (Комплименты генератора гребешков NHibernate)

Guid GenerateComb()
{
    byte[] destinationArray = Guid.NewGuid().ToByteArray();
    DateTime time = new DateTime(0x76c, 1, 1);
    DateTime now = DateTime.Now;
    TimeSpan span = new TimeSpan(now.Ticks - time.Ticks);
    TimeSpan timeOfDay = now.TimeOfDay;
    byte[] bytes = BitConverter.GetBytes(span.Days);
    byte[] array = BitConverter.GetBytes((long) (timeOfDay.TotalMilliseconds / 3.333333));
    Array.Reverse(bytes);
    Array.Reverse(array);
    Array.Copy(bytes, bytes.Length - 2, destinationArray, destinationArray.Length - 6, 2);
    Array.Copy(array, array.Length - 4, destinationArray, destinationArray.Length - 4, 4);
    return new Guid(destinationArray);
}

Ссылка на источник на github: https://github.com/nhibernate/nhibernate-core/blob/master/src/NHibernate/Id/GuidCombGenerator.cs

Ну, вы можете создать Guid вручную. Однако одно из преимуществ Guid состоит в том, что его невозможно угадать, т. Е. Для данной записи 0000-...-0005 обычно мало смысла (со стороны злоумышленника) проверять наличие записи 0000-....-0004 и т. Д.

Также - повторная фрагментация? Пока у вас есть некластеризованный индекс для этих данных, я не уверен, что это проблема. Обычно вы не помещаете кластерный индекс в Guid, поэтому таблица будет кучей (если у вас нет отдельного кластерного индекса, такого как IDENTITY int). В этом случае вы будете добавлять в конец и вставлять новый Guid в некластеризованный индекс. Настоящей боли нет.

(править) Одна из проблем прямого использования времени заключается в том, что вы создаете гораздо больший риск столкновений; вам нужно будет побеспокоиться о создании Guid замкнутого цикла (т. е. о недопущении повторения при создании нескольких последовательно), что означает синхронизацию и т. д. дубликаты.

Вы всегда можете вызвать UuidCreateSequential; это «старый» генератор руководств (до 2000 года, когда MSFT изменила его на более случайные стили, к которым мы привыкли сегодня). Они переименовали старый UuidCreate в UuidCreateSequential и поместили свой новый генератор guid в новую реализацию UuidCreate. UuidCreateSequential - это также то, что SQL Server использует в NewSequentialID (), и он так же уникален, как и обычные руководства, но с тем преимуществом, что они являются последовательными, если вы создаете кучу из них в строке в одном процессе.

using System;
using System.Runtime.InteropServices;

namespace System
{
    public static class GuidEx
    {
        [DllImport("rpcrt4.dll", SetLastError = true)]
        private static extern int UuidCreateSequential(out Guid guid);
        private const int RPC_S_OK = 0;

        /// <summary>
        /// Generate a new sequential GUID. If UuidCreateSequential fails, it will fall back on standard random guids.
        /// </summary>
        /// <returns>A GUID</returns>
        public static Guid NewSeqGuid()
        {
            Guid sequentialGuid;
            int hResult = UuidCreateSequential(out sequentialGuid);
            if (hResult == RPC_S_OK)
            {
                return sequentialGuid;
            }
            else
            {
                //couldn't create sequential guid, fall back on random guid
                return Guid.NewGuid();
            }
        }
    }
}

@arul, @Doug

Почему вы поместили часть времени в конце GUID?

Я думал, что ведущие байты более важны для упорядочивания, и именно благодаря упорядочиванию временная часть была введена в первую очередь для предотвращения фрагментации индекса.

Хорошо, я нашел ответ и этот ответ от Бернхарда Кирхера и сайт Сравнение значений GUID и уникальных идентификаторов ( ADO.NET) он ссылается на.

Таким образом, идентификаторы GUID, созданные таким образом, не будут работать так же в других базах данных, кроме MS SQL-Server, но это не связано с LINQ-to-SQL.

Извините за искаженные URL-адреса, но у меня недостаточно репутации, чтобы размещать больше ссылок.

Сначала мы использовали метод, аналогичный тому, что Дуг опубликовал выше, в модели Entity Framework, поэтому вы также должны иметь возможность делать это с помощью Linq to SQL.

При этом нам понадобился генератор гребенчатых направляющих для тестирования, и в итоге мы создали этот небольшой инструмент для создания гребенчатых направляющих в режиме онлайн.

http://www.webdesigncompany.co.uk/comb-guid/

Надеюсь, это вам тоже поможет.