В 2011 просто случился разворот бизнеса в сторону маркетплейса. А до этого Озон многие годы был практически монополистом на онлайновом книжном рынке. С сильно развитой логистикой. К 2011 году помимо денег у них был ещё и огромный опыт на схожем рынке, каким мало кто из конкурентов мог похвастаться.
А что в этом плохого? Ну, кроме того, что некоторые библиотеки одной компании не понимают это и кидают ошибку?
отсутствие RETURN с различающимся значением в случае успеха и неуспеха
Ошибки можно и через механизм raiserror передавать. Бонусом будет возможность вернуть не только код ошибки, но и текстовое сообщение. И ещё по severity их отсортировать. Ну и возможность использовать try/catch для всего, а не городить огород с проверкой части ошибок по кодам возврата.
А ответ на заданный вопрос всё ещё можно найти в самом определении ACID. Транзакции друг от друга изолированы. И в данном конкретном случае мы никакого результата не увидим, пока транзакция с апдейтом не завершится. Наша вторая транзакция будет ожидать возможности навесить Shared-lock и будет ждать, пока оттуда первая не снимет Exclusive-lock.
Как-то странно видеть в статье, которая топит за try/catch и прочие новомодные фишки, полное игнорирование того, что изоляция транзакций может быть реализована разными способами. Snapshot isolation когда появился? В 2012? В 2008?
Команда TRUNCATE в MS SQL Server
Скажите, а сколько раз в production code вам доводилось использовать TRUNCATE? Имеет ли смысл спрашивать про нюансы ее работы, если они нужны раз в три года и их всегда можно подсмотреть в справочнике?
И насколько важны именно аспекты работы TRUNCATE в контексте isolation? Мне кажется куда более полезным на практике, что кандидат представляет, что TRUNCATE в сиквел сервере это DML операция, требующая как минимум прав на ALTER TABLE. И ее нельзя, например, применить к таблице, на которую ссылается внешний ключ. И всяких других граблях, из-за которых использование TRUNCATE может оказаться плохой идеей.
Что получим в результате? Но как же так, ведь мы всё откатили! Опять сломался ACID.
А вот раз тебе и бац - табличные переменные вполне себе имеют некоторые особенности.
ACID относится к сохраняемому состоянию данных СУБД, а значения локальных переменных, даже табличных, в него явно не входят. Никого ведь не удивляет, что при откате транзакции какой-нибудь set @answer = 32 не откатывается.
IMHO, на миддла достаточно будет спросить:
Базовый синтаксис SQL, попросить написать какой-нибудь несложный запрос с рекурсией и оконными функциями
Уровни изоляции, какие бывают и какие эффекты можно наблюдать на каждом уровне
Индексы и стратегии джойнов, их алгоритмическую сложность
Планы запросов, как их курить и что делать, если сиквел сервер выбирает хреновый план.
Для РФ не нужно ничего распознавать, у нас все чеки электронные. Достаточно отсканировать QR код на чеке, в нем есть все, что нужно для загрузки данных чека с сайта ФНС. Есть даже официальное приложение для этого, "Проверка чеков".
Для случаев, когда запись редка, особенно конкурентная, а чтений много и объем данных относительно небольшой, SQLite неплохо справляется. Например, для каких-нибудь развесистых конфигов.
Работодателю необходимо понимать, что выгорание (burnout) является сложным состоянием, которое обычно связано с длительным стрессом, перегрузкой на работе и недостатком психологической поддержки.
Меры профилактики очевидны из критериев постановки диагноза. А про витамин D хотелось бы увидеть ссылки на клинические исследования, которые убедительно показывают, как его прием компенсирует бесполезность или отсутствие достижений на рабочем месте. И насколько эффективно "психологическая поддержка" это компенсирует.
Сжечь гимназию и устранить науки. А то иж чо удумали...
Все эти производные, линейная алгебра и прочая непонятная серому мундиру западная фигня, несомненно, часть коварного плана Даллеса по развалу великого и несокрушимого. Запретить!
Развивали-развивали насмотренность, но красный курсив в глазу и не заметили.
Вот изучение языков, кстати, отличный пример, как эта самая насмотренность помогает на практике. Там ее, правда, чаще называют начитанностью, но суть одна.
Во-вторых, шутка про то, что уровень вашего материального достатка определяет ваше положение в обществе. И как-то уважаемых людей в окопах массово не наблюдается, все больше мужики из глухих поселков и прочих низов.
В третьих, когда "надо" план выполнять, то гребут в первую очередь тех, кто меньше ерепенится и права качает. Ибо если с каждым возиться, то план не сделаешь. А чем выше ваше положение, тем больше у вас рычагов, чтобы сопротивляться. Речь даже не про взятки, а банально адвоката нанять или переехать например.
Разделение это просто кривая калька с английского. Shared. Там это слово означает что-то общее. Например, shared kitchen в коммуналке, которую никто не называет "разделяемой".
В отдельных случаях общее можно "разделить", например, судьбу или ответственность. Непонятно, почему кто-то решил "разделять" общий код (что-то, особенно материальное, обычно "делят" и "разделяют" как раз на индивидуальные части), но термин прижился.
За половину подземного гаража выше личное дело будет полвека подпирать ножку вечно шатающегося шкафа в архиве военкомата. А за трёхкомнатную квартиру вы вполне можете оказаться первым человеком, чье личное дело приземлилось на Луне. Пускай и неудачно.
Микросервисы это просто одна из реализаций SOA. Наравне с наносервисами, миллисервмсами, килосервисами, мегасервисами, гигасервисами, супераппами и прочим.
Идеи в основе все те же, просто сериализация сообщений следует моде. XML schema это сложно, давайте использовать JSON Schema. WSDL это сложно, давайте заменим на Swagger/OpenAPI. WS orchestration and choreography это какой-то марсианский, давайте лучше километры ямла для k8s. Шины сообщений что-то вообще непонятное, давайте просто кластер с кафкой и консьюмеры-роутеры.
А если без стеба, то мое личное мнение, что любой архитектор систем на микросервисах просто обязан прочитать хотя бы основные книжки по SOA. Там все основные проблемы сервисной архитектуры разжеваны-пережеваны и пути их решения возведены в ранг индустриальных стандартов. Хорошие художники копируют, великие художники крадут :)
MUMPS это вещь в себе :) В ней есть большинство идей (кроме, разве что, распределенности, хотя, может, уже и появилась), которые лежат в основе большинства NoSQL, но на реляционную БД она точно не похожа.
MUMPS штука очень крутая, на десятилетия опередившая свое время. И даже SQL в современных реализациях как-то использовать можно. Только кому это нужно в 2023 году? Ну, кроме поддержки тонн кода, написанного в 70-х? Мне кажется, VistA за пределами США никем не используется, а больше ничего заметного на MUMPS, кажется, и не осталось.
В 2011 просто случился разворот бизнеса в сторону маркетплейса. А до этого Озон многие годы был практически монополистом на онлайновом книжном рынке. С сильно развитой логистикой. К 2011 году помимо денег у них был ещё и огромный опыт на схожем рынке, каким мало кто из конкурентов мог похвастаться.
Извините, но 9 слоев для начинающего архитектора как-то маловато.
"Жил грешно и умер смешно".
А что в этом плохого? Ну, кроме того, что некоторые библиотеки одной компании не понимают это и кидают ошибку?
Ошибки можно и через механизм raiserror передавать. Бонусом будет возможность вернуть не только код ошибки, но и текстовое сообщение. И ещё по severity их отсортировать. Ну и возможность использовать try/catch для всего, а не городить огород с проверкой части ошибок по кодам возврата.
Как-то странно видеть в статье, которая топит за try/catch и прочие новомодные фишки, полное игнорирование того, что изоляция транзакций может быть реализована разными способами. Snapshot isolation когда появился? В 2012? В 2008?
Скажите, а сколько раз в production code вам доводилось использовать TRUNCATE? Имеет ли смысл спрашивать про нюансы ее работы, если они нужны раз в три года и их всегда можно подсмотреть в справочнике?
И насколько важны именно аспекты работы TRUNCATE в контексте isolation? Мне кажется куда более полезным на практике, что кандидат представляет, что TRUNCATE в сиквел сервере это DML операция, требующая как минимум прав на ALTER TABLE. И ее нельзя, например, применить к таблице, на которую ссылается внешний ключ. И всяких других граблях, из-за которых использование TRUNCATE может оказаться плохой идеей.
ACID относится к сохраняемому состоянию данных СУБД, а значения локальных переменных, даже табличных, в него явно не входят. Никого ведь не удивляет, что при откате транзакции какой-нибудь
set @answer = 32не откатывается.IMHO, на миддла достаточно будет спросить:
Базовый синтаксис SQL, попросить написать какой-нибудь несложный запрос с рекурсией и оконными функциями
Уровни изоляции, какие бывают и какие эффекты можно наблюдать на каждом уровне
Индексы и стратегии джойнов, их алгоритмическую сложность
Планы запросов, как их курить и что делать, если сиквел сервер выбирает хреновый план.
Для РФ не нужно ничего распознавать, у нас все чеки электронные. Достаточно отсканировать QR код на чеке, в нем есть все, что нужно для загрузки данных чека с сайта ФНС. Есть даже официальное приложение для этого, "Проверка чеков".
Ирония в том, что изначально SQLite разрабатывалась для весьма серьезных задач, для управления конфигурацией эскадренных миноносцев.
Для случаев, когда запись редка, особенно конкурентная, а чтений много и объем данных относительно небольшой, SQLite неплохо справляется. Например, для каких-нибудь развесистых конфигов.
Это как OpenJ9 v0.40.0
Как старпер с четвертьвековым стажем скажу: никогда не стоит экономить на газе, рано или поздно вы эпично обосретесь.
Работодатель себе уже кокаин выдал, предвкушая встречу с заказчиком :)
Эка вы ловко перевели increased mental distance from one’s job, or feelings of negativism or cynicism related to one's job; and a sense of ineffectiveness and lack of accomplishment как "недостаток психологической поддержки". Увы, это не лечится ни психологической поддержкой, ни витамином D. Помогает только "а пошло оно нафиг" и "свалить подальше" на пару-тройку лет.
Меры профилактики очевидны из критериев постановки диагноза. А про витамин D хотелось бы увидеть ссылки на клинические исследования, которые убедительно показывают, как его прием компенсирует бесполезность или отсутствие достижений на рабочем месте. И насколько эффективно "психологическая поддержка" это компенсирует.
Сжечь гимназию и устранить науки. А то иж чо удумали...
Все эти производные, линейная алгебра и прочая непонятная серому мундиру западная фигня, несомненно, часть коварного плана Даллеса по развалу великого и несокрушимого. Запретить!
Паленую водку товарищи уже 15 лет успешно маркируют
Развивали-развивали насмотренность, но красный курсив в глазу и не заметили.
Вот изучение языков, кстати, отличный пример, как эта самая насмотренность помогает на практике. Там ее, правда, чаще называют начитанностью, но суть одна.
Ну, во-первых, это шутка.
Во-вторых, шутка про то, что уровень вашего материального достатка определяет ваше положение в обществе. И как-то уважаемых людей в окопах массово не наблюдается, все больше мужики из глухих поселков и прочих низов.
В третьих, когда "надо" план выполнять, то гребут в первую очередь тех, кто меньше ерепенится и права качает. Ибо если с каждым возиться, то план не сделаешь. А чем выше ваше положение, тем больше у вас рычагов, чтобы сопротивляться. Речь даже не про взятки, а банально адвоката нанять или переехать например.
Разделение это просто кривая калька с английского. Shared. Там это слово означает что-то общее. Например, shared kitchen в коммуналке, которую никто не называет "разделяемой".
В отдельных случаях общее можно "разделить", например, судьбу или ответственность. Непонятно, почему кто-то решил "разделять" общий код (что-то, особенно материальное, обычно "делят" и "разделяют" как раз на индивидуальные части), но термин прижился.
Минцифры, а где же ваш хвалёный айти-специалист?
Он улетел, но он обещал вернуться... Милый, милый...
За половину подземного гаража выше личное дело будет полвека подпирать ножку вечно шатающегося шкафа в архиве военкомата. А за трёхкомнатную квартиру вы вполне можете оказаться первым человеком, чье личное дело приземлилось на Луне. Пускай и неудачно.
Микросервисы это просто одна из реализаций SOA. Наравне с наносервисами, миллисервмсами, килосервисами, мегасервисами, гигасервисами,
супераппамии прочим.Идеи в основе все те же, просто сериализация сообщений следует моде. XML schema это сложно, давайте использовать JSON Schema. WSDL это сложно, давайте заменим на Swagger/OpenAPI. WS orchestration and choreography это какой-то марсианский, давайте лучше километры ямла для k8s. Шины сообщений что-то вообще непонятное, давайте просто кластер с кафкой и консьюмеры-роутеры.
А если без стеба, то мое личное мнение, что любой архитектор систем на микросервисах просто обязан прочитать хотя бы основные книжки по SOA. Там все основные проблемы сервисной архитектуры разжеваны-пережеваны и пути их решения возведены в ранг индустриальных стандартов. Хорошие художники копируют, великие художники крадут :)
Я как-то придумал. И лет 5-7 он, действительно, был уникальным в интернете. Но прошло лет 15, и мне стали писать даже компании с таким названием :)
Ничто уникальное не вечно. А в интернете, во времена ChatGPT, и подавно.
MUMPS это вещь в себе :) В ней есть большинство идей (кроме, разве что, распределенности, хотя, может, уже и появилась), которые лежат в основе большинства NoSQL, но на реляционную БД она точно не похожа.
MUMPS штука очень крутая, на десятилетия опередившая свое время. И даже SQL в современных реализациях как-то использовать можно. Только кому это нужно в 2023 году? Ну, кроме поддержки тонн кода, написанного в 70-х? Мне кажется, VistA за пределами США никем не используется, а больше ничего заметного на MUMPS, кажется, и не осталось.