Mar 4, 2015 at 3:35 PM
Does vita suport GuidComb for guid generation instead of NewGuid?

NewGuid causes a high index fragmentation.

Mar 4, 2015 at 6:18 PM
Auto() attribute actually uses Sequential quids (see Externals.NewSequentialGuid method). the only problem is that the sequences generated are not global and long-running, but within considerable time it is a sequence, so page inserts are rare enough.
As for fragmentation, if you mean bad effect of fragmenting CLUSTERING index, you should either use proper Clustered index (by createdDate), or use HeapTable attribute (no clustered index). The only trouble is MySql (as far as I know), it automatically uses PK as clustering index, this is a source of a lot of criticism. For regular, non-clustered index, guids of any kind are not a problem, as far as I know.
Mar 5, 2015 at 1:42 PM
I have read that if you use GuidComb it causes less index fragmentation a performance benefits.

Here is the NHibernate implementation

private Guid GenerateComb()
        byte[] guidArray = Guid.NewGuid().ToByteArray();

        DateTime baseDate = new DateTime(1900, 1, 1);
        DateTime now = DateTime.Now;

        // Get the days and milliseconds which will be used to build the byte string 
        TimeSpan days = new TimeSpan(now.Ticks - baseDate.Ticks);
        TimeSpan msecs = now.TimeOfDay;

        // Convert to a byte array 
        // Note that SQL Server is accurate to 1/300th of a millisecond so we divide by 3.333333 
        byte[] daysArray = BitConverter.GetBytes(days.Days);
        byte[] msecsArray = BitConverter.GetBytes((long) (msecs.TotalMilliseconds / 3.333333));

        // Reverse the bytes to match SQL Servers ordering 

        // Copy the bytes into the guid 
        Array.Copy(daysArray, daysArray.Length - 2, guidArray, guidArray.Length - 6, 2);
        Array.Copy(msecsArray, msecsArray.Length - 4, guidArray, guidArray.Length - 4, 4);

        return new Guid(guidArray);

Source Code
Mar 5, 2015 at 5:48 PM
oh man this is so wrong! The main point of Guid is that it guarantees (more-less) that there will be no collisions, even if we generated values on different machines at different times. So when we merge two data sets (when syncing databases) we don't worry about same IDs coming from two sources. This comb implementation is based on current time, just a guid like representation of current time. And inevitably will result in values collisions. I don't even understand, why convert to guids, just leave it as big int, and use it as is. I guess converting to Guid it pretends to become more unique, Guid-like, while completely killing the concept of Guids (which are generated in true unique manner, using you computer Id, network IP, and current timestamp)
Mar 5, 2015 at 5:50 PM