Pull to refresh
3
0
Send message

Проскакивала информация и про 7.5млн (она даже гуглится), но это, похоже, какая-то страховая выплата.

Или проще. Через полтора года рубль обвалится так, что выпустят новые рубли и 7.5млн будут равны 7.5 новых рублей, за которые можно будет пойти в магазин и купить буханку хлеба.

Всегда считал, что название РосХхх - это помесь отсутствия воображения и старых советских обычаев образования названий. Неужели в документах по госзаказам фигурирует требование к названию компании? Или просто специально формируют названия, чтобы чиновникам было привычно?

Кстати, для PostgreSQL есть расширение orafce, которое добавляет некоторые фишки оракла, в т.ч. добавляет эмуляцию некоторых специфичных оракловых пакетов.

нередко оракл покупают в т.ч. для более успешного прохождения аудита (когда отдельные очки дают просто за сам факт использования конкретного ПО)

  1. В таких случаях можно сделать рассылку почты в отдельном приложении, которое сами отправляемые письма считывает из таблицы в БД. Обычно хождение СУБД на внешние серваки не приветствуют безопасники, поэтому вынос непосредственно отправки в отдельное приложение обоснован.

Маленькие игроки на рынке либо становятся однодневками, либо вынуждены репутацию поддерживать. А вот крупные считают, что им снижение репутации нипочём. С тем же тиньковым - они довольно неплохо вложились в удобство софта и пока значительный процент людей считает, что к ним по удобству никто не приблизился, они позволяют себе дичь, т.к. считают, что клиенту некуда деваться.

Всё равно могут быть проблемы, если несколько человек начинают делать какую-то длительную доработку в отдельной ветке (когда это действительно нужно). Впрочем, это уже касается любого workflow.

По стандарту SQL, все части предиката будут вычислены. Поэтому обычно в SQL условия типа (N - число) AND (to_number(N) > 5) приведут к ошибке. По опыту, даже оборачивание первого условие внутрь подзапроса не всегда поможет. Хотите жесткой определённости последовательности вычислений? Есть вариант с использованием оператора case, но только, например, в PostgreSQL если аргумент - литерал или входящий параметр (который также может считаться литералом, т.к. первоначально учитывается при планировании), а функция детерминирована вообще (immutable) или в пределах транзакции (stable), то планировщик может попытаться её вычислить даже если она находится в неработающей ветке (просто потому что так работает последовательное упрощение дерева вычислений).

Они только-что потратили на обучение этого сотрудника и своей системы в целом (если не совсем идиоты, то в ПО уже внесена доработка, которая тестирует все варианты конвертаций, чтобы убедиться, что не будет подобной проблемы) почти 2млн (с учетом штрафа и компенсации), будет глупо вот так избавляться от такого ценного сотрудника. Так что единственное разумное решение - записать в непредвиденные потери.

подобные лишние начисления бывают болезненными. Коллеге так начислили, еще и в бухгалтерии подтвердили, что ошибок нет, а в следующем месяце написали, что до этого начислили по ошибке и поэтому аванса не будет. А он на него рассчитывал.

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

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

В итоге, авиакомпания, конечно, заметила его, но мили никто не стал списывать, т.к. репутация дороже. А вот в россии репутация дешевая.

Работа в мастере (без хотя-бы минимального ревью) противопоказана в случае если в команде есть хотя-бы один человек, не разбирающийся по-нормальному, в работе гита (не важно - через консольные команды или через любимую gui-утилиту).

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

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

Вы довольно таки широко трактуете термины, за пределами классического их использования. В такой трактовке, термины теряют свой смысл. Также при этом, PostgreSQL, внезапно, становится настоящей Not only SQL базой, при чём, возможно, в большей степени, чем вышеназванные, ведь она поддерживает настоящий полновесный диалект SQL, выполняя подавляющее большинство стандарта этого языка, а также позволяет использовать её как документоориентированную базу данных за счёт поддержки json/jsonb.

То, что MongoDB может использоваться в качестве rdbms - это всё-таки в некотором роде её развитие (вызванное тем, что людям из соседней экосистемы хочется выполнять знакомые действия привычным способом), однако большинство источников их противопоставляют.

в данном случае работает логика "мы не можем проверить эту строчку, поэтому пропускаем check". Нужно другое поведение? Никто не мешает использовать coalesce.

Ну или другая интерпретация: check constraint проверяет строку на соответствие условию (expr) = false. При выполнении - кидает ошибку.

Вообще, в SQL достаточно странностей (например - работа типов varchar(n)), но едва ли к странностям можно отнести работу NULL-ов в булевых выражениях.

Требовать от SQL поведения аналогичного императивным языкам - очень странно. Например, в SQL неопределён порядок вычисления булевых выражений. Нужно объяснять, почему так сделано?

Давайте я вам помогу: при анализе дампов памяти java в Memory Analyzer'е можно использовать sql-подобный язык для поиска объектов.

Это всё не важно: есть стандарт, которому должны следовать (в меру возможностей) все уважающие себя RDBMS и он общепризнан. Ни монга, ни эластик RDBMS не являются. Давать такие примеры - это всё равно, что говорить, что несущие крылья для самолёта - это концептуальная ошибка, т.к. они занимают много места и вообще, у вертолёта Ми-8 нет таких крыльев и это не мешает ему летать.

Information

Rating
Does not participate
Registered
Activity