1

I am working on a rather large SQL Database project that requires some history tracking. I am aware that SQL has things like Data Capture but I need to have more control than just storing backup copies of the data along with other requirements.

Here is what I am trying to do, I found some similar questions on here like

get-the-smallest-datetime-value-for-each-day-in-sql-database

and

how-can-i-truncate-a-datetime-in-sql-server

What I am trying to avoid is exactly the types of things that are mentioned in these answers, by that I mean that they require some sort of conversion during the Query i.e. truncating the DateTime value, what I would like to do is take the DateTime.Ticks or some other DateTime property, and do a one way conversion to a smaller type to create a "Version" of each record that can be quickly Queried without doing any kind of Conversion after the database update/insert.

The concern that I have about simply storing the long from the DateTime.Ticks as a Version or using something like a Base36 string is the size and the time that is required during queries to compare the fields.

Can anyone point me in the right direction on how to SAFELY convert a DateTime.Ticks or a long into something that can be directly compared during queries? By this I mean I would like to be able to locate the history record using something like:

int versionToFind = GetVersion(DateTime.Now);   

var result = from rec in db.Records
             where rec.version <= versionToFind
             select rec;

or

int versionToFind = record.version; 

var result = from rec in db.Records
             where rec.version >= versionToFind
             select rec;

One thing to mention here is that I am not opposed to using some other method of quickly tracking the History of the data. I just need to end up with the quickest and smallest solution to be able to generate and compare Versions for each record.

Andy Braham
  • 9,594
  • 4
  • 48
  • 56
  • Your example query doesn't make a lot of sense, as presumably it would never return any records (records whose version is *greater* than the most recent version #?). But is the issue that for given date (not time) you simply want to get a unique number (implying at most 1 version per 24h period)? If so, ignoring timezone issues (rarely a good idea), why not just divide DateTime.Ticks by the number of ticks per day? – Dylan Nicholson Nov 27 '17 at 08:56
  • @DylanNicholson Yeah that was a pretty dumb example, I apologize for that, all I was trying to show is how I would like to locate/track the versions. It is not that I need a unique identifier but more a numerical representation of the date that can be used to query the records. – Andy Braham Nov 27 '17 at 09:05
  • I believe this is a case of an [XY](https://meta.stackexchange.com/questions/66377/what-is-the-xy-problem) problem. Please explain your end goal. – Alex Nov 27 '17 at 09:06
  • You didn't answer my question - why not just divide DateTime.Ticks by the number of ticks per day? – Dylan Nicholson Nov 27 '17 at 09:12
  • @Alex The end goal that I am trying to achieve is finding the quickest and smallest way of generating a version from the date that I can then use directly as part of a query. The project I am working on is planned to have a ton of records and I need to be able to work with the history without adding a ton of overhead during the queries. – Andy Braham Nov 27 '17 at 09:12
  • @DylanNicholson Would that be the best approach and give me the smallest possible field? That would decrease the size but does not guarantee that the value generated could be saved in say a int16 would it? – Andy Braham Nov 27 '17 at 09:16
  • Maybe storing dates in [`DATE`](https://learn.microsoft.com/en-us/sql/t-sql/data-types/date-transact-sql) and [`TIME`](https://learn.microsoft.com/en-us/sql/t-sql/data-types/time-transact-sql) columns separately will solve your issues? – Alex Nov 27 '17 at 09:45
  • An int16 is enough to cover about 55 years, so you tell me. With an unsigned int16 you could have over 110. But in either case you'll need to make some adjustment after dividing DateTime.Ticks by ticks-per-day, as that's ticks since Jan 1, 1AD. But I wouldn't assume int16 would get you better performance than int32 - do some testing first. – Dylan Nicholson Nov 27 '17 at 10:42

0 Answers0