Если вы имеете в виду, что его значение рассчитывается по данным из других полей, то согласен, это будет еще одним частным случаем для миграций описанных в статье. Позже добавлю апдейт.
Устаревший ваш подход только в том, что используется целочисленный тип, на замену которого уже давно есть типы "datetime", которые и отображают хорошо при чтении из базы и из дебага, а классы, которые есть в платформах еще и сами всю конверсию умеют делать с помощью утилитных методов.
Не "мой" метод — новый и хороший, это уже давно общая практика. Он по сути говорит о том же, что и вы — что нужно хранить в универсальном времени. Только вы говорите о том, что для этого нужно хранить какое-то там количество секунд, а я говорю о том, что для этого есть готовые типы, которые, более того, умеют еще и смещение таймзоны хранить, если надо. В чем проблема?
Приведенный вами пример не является случаем даты без времени. Если менеджер и вводит только дату, то показываться требуемое время исполнения должно как дата + время, а это уже само по себе противоречит исходному условию. Более того — назначение срока исполнения без конечного времени само по себе выглядит не очень удачным решением. Если я выполню задание в 23:30 1 фераля по московскому времени или 3:30 ночи 2 февраля — может ли так случиться, что для бизнеса по итогу разницы между этими временами нет, хотя дата исполнения стоит 1 февраля?
Не совсем понял — эта информация о смещении для дальнейшего саппорта? Чтобы была возможность потом посмотреть, откуда всязалась ошибка в смещении? Если так — окей, понял.
Если код полностью подконтролен и нет требований, по которым есть надобность хранить часовой пояс клиента — не вижу проблемы сделать на клиенте преобразование в UTC перед отправкой. Тут абсолютно равноценно — что клиент преобразует сам, что перешлет на сервер локальное время + смещение, для того, чтобы сервер сам уже выполнил это преобразование.
Если под неизвестным клиентом подразумевается, что серверное АПИ будет непонятно кто по итогу использовать, то соглашусь. Такое ограничение для "произвольных" клиентов может оказаться неочевидным и неожиданным. Чуть позже обновлю статью.
Там далее в статье написано, что есть требования при которых такой подход не будет работать, и нужно хранить дополнительно смещение часового пояса. Противоречия нет, просто последовательные соображения )
Как уже написали выше — часть описанного в статье скорее не проблемы фреймворка, а нюансы, о которых нужно знать и учитывать при написании кода. Например, все, что связано с AsNoTracking и AutoDetectChangesEnabled — справедливо и для EF7 и так и останется. Очевидно, что трекинг и определение изменений нужны во многих сценариях, и что они вносят дополнительные вычислительные расходы. Просто нужно знать, когда их можно отключить.
Проблемы с перекомпиляцией запроса для Contains, Take и Skip тоже актуальны для EF7, причем в нем пока еще нет перегруженых Take и Skip, принимающих лямбда-выражение. Т.е. на данный момент в нем все запросы, содержащие Take и Skip будут перекомпилироваться при каждом выполнении.
Насчет остального — надо проверять, причем лучше всего уже на релизной версии.
Упомянуть-то можно — просто еще один алгоритм генерации последовательного GUID. Принципиально нового он ничего не вносит. Реализовывать аналог с тем же алгоритмом и размером для того же MS SQL или Oracle может оказаться не оправдывающей себя задачей.
Про преимущества GUID я писал в первой статье, в том числе и про эти. В тех случаях, когда этих преимуществ не требуется, можно обойтись целочисленным ключом.
А что касается безумной оптимизации — то я тут полностью согласен, чаще всего она не нужна )
Алгоритм, который использует UuidCreateSequential() гарантирует непересекаемость (в предыдущей статье описано). Эта же функция используется SQL сервером для получения результата NEWSEQUENTIALID()
Если те же 128, то строго говоря разницы не будет. Что ГУИД, что 128-битовое число — набор байт одинаковой длины. Разница может быть только в порядке сравнения этих байт.
Насчет скорости поиска — я планирую либо сделать вторую часть статьи, либо проапдейтить эту сравнениями производительности выборки. Действительно, это очень нужный в данном случае тест.
Странно, статья как раз в том числе и об этом. Вот эти абзацы например:
Привычная генерация уникальных идентификаторов в том же .NET через Guid.NewGuid() дает множество значений, не связанных друг с другом никакой закономерностью. Если ряд GUID-ов, полученных из этой функции, держать в отсортированном списке, то каждое новое добавляемое значение может «попадать» в любую его часть.
и далее по тексту. Потом:
Над последним пунктом стоит задуматься. Из-за чего может происходить замедление работы при использовании непоследовательных GUID-ов, кроме как частого разделения страниц? Скорее всего — из-за частого чтения «случайных» страниц с диска.
Не "мой" метод — новый и хороший, это уже давно общая практика. Он по сути говорит о том же, что и вы — что нужно хранить в универсальном времени. Только вы говорите о том, что для этого нужно хранить какое-то там количество секунд, а я говорю о том, что для этого есть готовые типы, которые, более того, умеют еще и смещение таймзоны хранить, если надо. В чем проблема?
Проблемы с перекомпиляцией запроса для Contains, Take и Skip тоже актуальны для EF7, причем в нем пока еще нет перегруженых Take и Skip, принимающих лямбда-выражение. Т.е. на данный момент в нем все запросы, содержащие Take и Skip будут перекомпилироваться при каждом выполнении.
Насчет остального — надо проверять, причем лучше всего уже на релизной версии.
А что касается безумной оптимизации — то я тут полностью согласен, чаще всего она не нужна )
Насчет скорости поиска — я планирую либо сделать вторую часть статьи, либо проапдейтить эту сравнениями производительности выборки. Действительно, это очень нужный в данном случае тест.
Время генерации включено во всех случаях (можно посмотреть в коде, который я на гитхабе выложил).
и далее по тексту. Потом:
и далее