А что еще я должен слышать, если команда загружена на 120% высокоприоритетными задачами?
По факту так и есть - я доку делаю только когда уже память/поиск по почте/конфлюенсу не справляются. И не со зла, а потому что некогда, над пожары тушить.
Ящик отправителя или никогда не существовал, или существовал только очень короткое время. А скорее и весь домен. Так что насладиться пельмешкой будет некому :)
сама идея, что люди сами откажутся от воспроизводства, казалась фантастам абсурдной
– Вы были счастливы в замужестве? – прозвучал следующий вопрос.
– Что вы имеете в виду? – неуверенно отозвалась Гладия.
– Ну как же, – Бейли остановился. А что он действительно имел в виду? И что вообще считалось счастливым браком по солярианским понятиям?
– Ну, скажем, вы часто встречались с вашим мужем?
– К счастью, нет. Мы ведь не животные, не так ли?
Бейли поморщился.
– Да, но ведь вы жили в одном и том же доме, и я подумал…
– Конечно, в одном и том же, – перебила она. – Но у каждого из нас была своя половина. У него была очень важная работа, которая отнимала у него всё время, а у меня были свои дела. Мы вступали в зрительный контакт в тех случаях, когда это было необходимо.
– Но он всё же встречался с вами и реально?
– О таких вещах неприлично говорить, но… иногда он приходил на мою половину.
Мы пытались на SparkSQL сделать распределение платежей по просроченному кредиту на погашение самого кредита и процентов по нему. Так и не получилось. Пришли к выводу, что нужны или иерархические запросы, или переменные, или процедурное расширение, но ничего этого в SparkSQL нет (или мы об этом не знаем).
Но процессы ETL — не аналитические, в норме в них не происходит разбора данных на уровне полей записи для последующей хитрой агрегацией и схлопывания в некий показатель. В них обычно набор данных потребляется целиком, а записи в 99% случаев просто итерируются в духе «возьми всё оттуда, профильтруй, и перебутыль в другое местоположение, сменив формат». То есть, манипуляции, происходящие с данными ещё до их анализа, либо уже после него.
Очень странный тезис. У нас в ETL бывает и "разбор данных на уровне полей записи", и хитрая агрегация, и схлопывание, и еще много чего. А уж стратегий инкремента едва ли не больше, чем источников, потому что каждый источник стремится изобрести свою. И все это прекрасно работает на Spark SQL в Проме. Иногда, конечно, бывает нужна процедурная обвязка, но весьма редко.
Так удобнее. Например, легко вычленять номер источника независимо от того, сколько ему знаков требуется на основную часть, в т.ч. при записи в столбик, т.к. выравнивание чисел обычно вправо. Запись идентификаторов короче и читабельнее.
автоматически увеличивающиеся идентификаторы уникальны только в контексте одной таблицы базы данных
Вообще-то, нет. Часто встречаю, что в последних двух или трех цифрах закодирован источник автоматически увеличивающегося идентификатора. Соответственно, инкремент происходит с шагом 100 или 1000.
А что еще я должен слышать, если команда загружена на 120% высокоприоритетными задачами?
По факту так и есть - я доку делаю только когда уже память/поиск по почте/конфлюенсу не справляются. И не со зла, а потому что некогда, над пожары тушить.
Ящик отправителя или никогда не существовал, или существовал только очень короткое время. А скорее и весь домен. Так что насладиться пельмешкой будет некому :)
"Обзоров на" в русском языке не бывает. Бывают обзоры чего-то, например, "обзор игры".
Пожалуйста, не надо коверкать язык.
"Обнаженное солнце". Айзек Азимов. 1956 г.
Любопытный тариф - 30 ГБ за 250 рублей. Как можно его заполучить?
Мы пытались на SparkSQL сделать распределение платежей по просроченному кредиту на погашение самого кредита и процентов по нему. Так и не получилось. Пришли к выводу, что нужны или иерархические запросы, или переменные, или процедурное расширение, но ничего этого в SparkSQL нет (или мы об этом не знаем).
Любопытно, как именно он это сделает?
Вот пришло письмо с признаками фишинга - и что дальше?
Нет, конечно. Я этого и не утверждал. Но он достаточно массовый, чтобы оспорить исходный тезис.
Очень странный тезис. У нас в ETL бывает и "разбор данных на уровне полей записи", и хитрая агрегация, и схлопывание, и еще много чего. А уж стратегий инкремента едва ли не больше, чем источников, потому что каждый источник стремится изобрести свою. И все это прекрасно работает на Spark SQL в Проме. Иногда, конечно, бывает нужна процедурная обвязка, но весьма редко.
Хм, а зачем?
Мы как-то без замены передаем и ничего, работает...
Это немного не из этой области. С автоинкрементом может быть (и часто бывает) такая же ситуация.
Так удобнее. Например, легко вычленять номер источника независимо от того, сколько ему знаков требуется на основную часть, в т.ч. при записи в столбик, т.к. выравнивание чисел обычно вправо. Запись идентификаторов короче и читабельнее.
И, кстати, один источник автоматически увеличивающихся идентификаторов может использоваться для нескольких таблиц. И не всегда одной базы данных.
Вообще-то, нет. Часто встречаю, что в последних двух или трех цифрах закодирован источник автоматически увеличивающегося идентификатора. Соответственно, инкремент происходит с шагом 100 или 1000.
Подскажите, пожалуйста, подобное устройство с GPIO и USB.
А вы учитываете при этом разные веса работодателей?
У того же Сбера за одной публичной вакансией могут скрываться десятки внутренних.
В заголовке и в тексте упоминается бинарное дерево, так что не так уж и много.
И DISTINCT можно сделать до джойна.
Почему этот Geekom (и в частности Mini Air11) так усиленно пиарят?
Прям постоянно на обзоры натыкаюсь.
Они много денег на рекламу занесли?
В рамках школьной математики можно.
А вот при использовании базовых типов данных (int, double и т.д.) нельзя, ибо они неэквивалентны.
Нашел - https://github.com/WeActStudio/WeActStudio.MiniSTM32F4x1/blob/master/HDK/README.md
Текущая версия V3.1