Если закончился один договор и через несколько лет вы заключили новый (с новым номером и датой). 3млн для импортных 6млн для экспортных контрактов начинают считаться с момента заключения второго договора? или два договора с одним контрагентом считаются одним и тем же договором?
Маленькое замечание. В postgresql для json и jsonb нет синтаксиса, который бы позволил обновить только одно поле (поправьте меня если ошибаюсь). Документ нужно перезаписывать целиком. Поэтому, для исключения состояния гонки, приходится навешивать критические секции на код обновляющий json и jsonb. Для hstore же подобный синтаксис имеется.
На сервере у нас все написано на C#. Предметная область у нас зафиксирована в виде технических заданий с подробно описанными юзер- кейсами. DTO контракты зафиксированы только в коде, но у нас есть строгие правила по разбиению классов по сборкам. Например, контракт обмена между клиентом и сервером описан в отдельной сборке, со строго определенными пространствами имен. Зная правила именования классов найти что-либо в проекте у нас просто.
Добрый день. У нашего приложения есть несколько версий, кастомизированных под различных заказчиков. Там где критична отказоустойчивость у нас поднят балансировщик и несколько IIS. Обновления у нас проводятся руками.
По процессу обновления — в случае глобальных изменений, вроде изменения структуры БД, переносе части данных из одной БД в другую, мы включаем заглушку «профилактические работы» на запросы извне и начинаем процесс обновления — копируем файлы по папкам, мигрируем БД и т.д… После этого мы проверяем с внутреннего адреса что все завелось нормально и снимаем заглушку. Делаем мы это само собой по ночам и не часто. Для мелких изменений проводим процесс обновления «на лету», просто копируя изменившиеся сборки.
Процесс разработки — обычный Continious Integration с тестовыми стендами (у нас их целых пять).
Я немного дополнил статью, вставив картинку с тем как все устроено.
Из очереди сообщение будет удалено только после того, как служба явно сообщит очереди, что обработка этого сообщения завершена. Используется стандартный механизм message acknowledgment в RabbitMQ.
newsequentialid в принципе не плохая штука, но и у него есть проблемы. После перезагрузки сервера метод NEWSEQUENTIALID может начать генерировать GUID с меньшего чем до перезагрузки диапазона. В том же NHibernate есть утилита для генерации uuid в нарастающей последовательности, привязывая ко времени.
В боевых искусствах принято выделять три стадии мастерства: сю, ха, и ри (Shu, Ha, Ri). На первой ступени находится ученик, который лишь повторяет движения за мастером. На второй ступени ученик начинает освобождаться от правил и сам начинает решать, когда им следовать, а когда – нет. На третьей стадии правила пропадают, ученик становится мастером и может сам эти правила создавать.
Понравилось. Но применительно к IT стоит добавить еще одну стадию. Это сю, которые твердо уверены что они уже ри и не считают для себя достойным повторять за мастером. Тем более, что заказчики, в большинстве своем, не способны отличить кунг-фу от мордобоя.
Да, именно это и интересно. Но и чужой опыт по использованию естественных ключей, особенно в условиях масштабируемых шардингом приложений тоже интересен.
Creates a GUID that is greater than any GUID previously generated by this function on a specified computer since Windows was started. After restarting Windows, the GUID can start again from a lower range, but is still globally unique.
Краткий перевод — после перезагрузки сервера метод NEWSEQUENTIALID может начать генерировать GUID с меньшего чем до перезагрузки диапазона.
Еще надо отметить, что метод NEWSEQUENTIALID машинно-зависимый, поэтому, в случае распределенных приложений использующих более чем один сервер, придется выделить специальный сервер-арбитр для создания uuid, к которому уже будут обращаться остальные сервера.
Я считаю, что это не то место, где в реальности стоит что-то оптимизировать.
10% на вставку, лучшая дефрагментация таблиц в БД (соответственно теоретически должен чуть быстрее работать и select) просто заменой Guid.NewGuid() на CombGuid.Generate() не так уж и плохо.
Еще сильно зависит от качества накладки. Некоторые накладки, особенно с длинными шипами, не используются на соревнованиях, поскольку позволяют игнорировать вращение. Вполне возможно, роботу для упрощения алгоритмов, позволят играть нестандартной ракеткой.
В интервью журналисту Championat.com Сергею Гарифуллину пресс-секретарь Федерации настольного тенниса России Алексей Ломаев назвал главную причину успеха китайских спортсменов на международной арене. " Этот вопрос (в чем секрет китайской сборной по настольному теннису) я как-то раз тоже задал одному из тренеров национальной сборной Китая Као Жену. Задал без задней мысли. А поскольку мы беседовали с ним уже не впервые, то он ответил мне достаточно искренне. Посмотрел мне в глаза и говорит, ну, хорошо, скажу тебе. И вот с того момента я знаю секрет китайской сборной, поделюсь им и с читателями «Чемпионат.com». Все дело в том, что в Китае есть государственная программа развития спорта, и настольного тенниса в частности. А ведь это было и у нас в советское время! План развития настольного тенниса, как и любого другого вида спорта, очень прост: надо раскинуть сети по всей стране, и не только настольно-теннисные. Надо охватить все школы, все дворы, парки. Да, нужны и квалифицированные тренерские кадры, которые могли бы увидеть детей, склонных к тому или иному виду спорта", — сказал Ломаев 26 февраля 2012 года.
Тимо Болль никогда не был олимпийским чемпионом. Он выигрывал серебро и бронзу в КОМАНДНЫХ соревнованиях. В личных, за редким исключением, пьедестал оккупируют китайцы.
Жаль на проде еще не 9.5 в моей конторе.
По процессу обновления — в случае глобальных изменений, вроде изменения структуры БД, переносе части данных из одной БД в другую, мы включаем заглушку «профилактические работы» на запросы извне и начинаем процесс обновления — копируем файлы по папкам, мигрируем БД и т.д… После этого мы проверяем с внутреннего адреса что все завелось нормально и снимаем заглушку. Делаем мы это само собой по ночам и не часто. Для мелких изменений проводим процесс обновления «на лету», просто копируя изменившиеся сборки.
Процесс разработки — обычный Continious Integration с тестовыми стендами (у нас их целых пять).
Я немного дополнил статью, вставив картинку с тем как все устроено.
Понравилось. Но применительно к IT стоит добавить еще одну стадию. Это сю, которые твердо уверены что они уже ри и не считают для себя достойным повторять за мастером. Тем более, что заказчики, в большинстве своем, не способны отличить кунг-фу от мордобоя.
Представьте ферму из четырёх iis работающих с несколькими шардами. На каком сервере должен генерироваться uuid методом newsequentialid?
Краткий перевод — после перезагрузки сервера метод NEWSEQUENTIALID может начать генерировать GUID с меньшего чем до перезагрузки диапазона.
Еще надо отметить, что метод NEWSEQUENTIALID машинно-зависимый, поэтому, в случае распределенных приложений использующих более чем один сервер, придется выделить специальный сервер-арбитр для создания uuid, к которому уже будут обращаться остальные сервера.
Для примера, как генерируют Id в инстаграмме. Они кроме времени кодируют внутри идентификатора еще и шарду, к которой должна относиться запись.
instagram-engineering.tumblr.com/post/10853187575/sharding-ids-at-instagram
10% на вставку, лучшая дефрагментация таблиц в БД (соответственно теоретически должен чуть быстрее работать и select) просто заменой Guid.NewGuid() на CombGuid.Generate() не так уж и плохо.