В Германии скорее наоборот сложно найти возможность заплатить безналом.
Странно, лет 8 взад не смог заплатить картой только в турецком шиномонтаже (да, не нужно кататься в незнакомых местах на эмоциях), и то они сходили к аптекарю по соседству, которому я и заплатил с переплатой 2% или 3%, ну и таксистам в тот день — кажется, они только нал и принимали, не помню точно, давно все же было. А, да, еще в одной понравившейся кафешке в Потсдаме готовили бумагу. Вроде все, в других магазинчиках/отельчиках нужды в наличности уже тогда не было.
Это все абсолютно логично, и это все документировано. И если кто-то не прочел хотя бы статью msdn перед использованием API и потом удивляется, что размер файла устанавливается равным запрошенному, то это его проблема, а вовсе не причина издавать перлы типа «MapViewOfFile в Windows убог».
Даже если поверить, что это так (а я, уж извините, не поверю уже хотя бы потому, что с таким антивирусом все компьютеры просто не могли бы работать) — так вот, даже если поверить, то как это ваше «MapViewOfFile в Windows вообще убог» появилось?
Ну и заодно и «А MapViewOfFile будет сразу пытаться выделить обьем оперативки равный отмапливаемому участку»?
Linux-овый mmap позволяет спокойно отмапить файл в разы (а то и на порядки) превышающий по размеру оперативную память компьютера, и OS будет грамотно подменять странички по мере доступа
С какой стати? В винде, естественно, то же самое. Достаточно прочесть MSDN, там общая схема расписана.
А MapViewOfFile будет сразу пытаться выделить обьем оперативки равный отмапливаемому участку
Не будет. Кто-то кого-то обманул. Все принципиально везде похоже: выделяется только диапазон виртуальной памяти. При доступе к еще неотображенной странице прозрачно возникает исключение, в результате страница отображается в память, читается из файла и операция доступа перезапускается уже к странице в памяти.
Вы же даже не пытались прочесть хотя бы в таком общем виде, но перлы типа «MapViewOfFile в Windows вообще убог» смело издаете. Не надо так.
А динамичные запросы вы через строки и sp_executesql делаете? В конце концов где-то что-то пропустите и вас нагнут через sql injection.
Нет, конечно, так нет необходимости делать. Динамические запросы нужно строить так, чтоб никакого пользовательского ввода в код запроса просто не попадало. Это всегда можно, кроме редчайших случаев типа построения констант для некоторых вариантов полнотекстового поиска на MS SQL — вот в этих и только этих случаях да, приходится писать обертки, которые не позволят выбраться зловредному пользовательскому вводу за пределы строковых констант. Даже для запросов с 100500 вариантами фильтров, соединений и выражений в том же MS SQL, если не хотите использовать условия запуска подветок, обычно очень неплохо подходит запрос с перекомпиляцией, если вы хорошо понимаете, как написать сколь угодно большой запрос так, чтобы оптимизатор для начала гарантированно отрубил все неиспользуемые ветви, а затем эффективно построил план для оставшейся части — и да, для этого знать про option(recompile) совершенно недостаточно.
Чистый SQL не очень подходит для бизнес логики, кроме совсем простой
Это попросту не так. И да, я видел и некоторое время поучаствовал в разработке такой огромной системы. Там, совершенно как в примере gleb_l, точно такое отношение к безопасности — базовые права гарантирует сам сервер, остальное — процедурной частью, а логика вообще вся на сервере, ни одного запроса мимо интерфейсных объектов, да мимо и невозможно — см. пункт про права на объекты БД. Или же ваше утверждение требует переформулировки или дополнений, например — по факту очень трудно найти специалистов БД, которые способны все это спроектировать, расписать и при необходимости развивать и поддерживать. Например, в сравнением с рынком специалистов по C# — это очень заметно, факт.
код бакенда разрабатывается одним профессионалом
У меня как раз система с горами такого. Спасибо, за двадцать лет там столько «профессионалов» поучавствовало, что волосы встают дыбом, там где их и быть-то не должно.
Видите, у вас ровно обратный хрестоматийный пример — вместо разработки грамотным профессионалам — «столько «профессионалов» поучавствовало» (цитата), с предсказуемыми последствиями. Подход же, озвученный gleb_l, при условии выполнения грамотным специалистом (я понимаю, что специалистом по SQL считает себя чуть менее, чем каждый каждый первый, кто умеет написать простой запрос, но сейчас я именно про грамотных профильных специалистов) очень устойчив при использовании разношерстной командой, уже в одном этом его огромный плюс.
Чистый SQL не очень подходит для бизнес логики, кроме совсем простой. Можно конечно через SQL CLR делать, но тоже так себе удовольствие. На Оракле конечно повеселее, а для SQL server-а это занятие для не слабых духом
Это говорит лишь о том, что с Ораклом вы сколько успели проработать, а с MSSQL — нет. Тут все дело в том, что подходы к ним очень, очень разные. При переходе от одного к другому — неважно, в каком порядке — сначала необходимо полностью перестроить мозги, сломать привычное мышление, совершенно изменить подход. Начинать писать на t/sql и обнаружить, что в нем отсутствуют привычные так необходимые объекты и пайпланы или, наоборот, перейти на Оракл и обескураженно искать, где же тут локальные времянки, без которых жизнь как без воздуха, и непосредственная отдача резалтсета из процедурной части клиенту — поначалу просто апатия, проклятия и ненависть, без преувеличения. Холивары MS SQL vs Oracle потому так и унылы и однообразны, что читаешь аргументы что одной, что другой строны — и видишь только, что аргументаторы привыкли мыслить только одной парадигмой, а противоположная обеим сторонам кажется какой-то инопланетной дикостью, поэтому эффективно мыслить за обе стороны мало кто пытается. В действительности же и у той, и другой стороны есть свои сильные и слабые стороны, опять же хрестоматийный случай.
Ну и да, никто обходиться без CLR не заставляет, даже совершенно не для написания на нем бизнес-логики, а исключительно для базовых вещей, которые почему-то до сих пор не завезли в MS SQL, например, почему-то отсутствующего инструментария для использования регулярок, из-за чего у каждого разработчика есть своя библиотечка на этом CLR для оберток над функционалом для работы с ними. Видите, я использовал аргумент из первой десятки в пользу Оракла, где регулярки давно из коробки :)
Казалось бы, платным троллям-минусаторам и палиться-то так необходимости давно нет, но нет-нет, да проявит кто-то из смены инициативу по способностям :)
Вот не обобщайте на весь Хабр, пожалуйста. Очевидно, что основная доля запросто с вами может быть согласна вполне, но минусуют сначала не они (ну и смена работничков может отметиться), а там и стадное подтягивается. Все как обычно, тысячу раз тут обсасывалось.
А почему вы всегда настолько перевираете мои слова? Опять само так получилось? Я ведь опять ничего подобного не писал. А писал я про ваш пример, который вы срисовали откуда-то, не поняв, что он значит. А значит он, что пока есть хоть одна блокировка, несовместимая по чтению с выбранной на выбранном уровне изоляции (а читать третья сессия хочет всю таблицу, а не диапазон ключей) — читающая на обычном уровне RC будет ждать, именно потому что не закоммичена запись, которую требуется прочитать. Она даже называется Read Committed именно поэтому. Я же вам готовый скрипты дал, просто попробуйте их выполнить. И да, в боевых условиях при этих же вводных будет ровно тот же эффект.
Ну прочтите вы хоть что-то по теме, по которой собрались спорить, чтобы понять хоть этот абзац. Ну хотя бы про RC, что ли. Вы же даже логического смысла блокировок не понимаете, зато смело несете в массы свои определения типа
Это просто определение того, что значит «появиться раньше/позже» с точки зрения наблюдателя системы
Очень интересно. И как же результат txn1, недостигшей еще COMMIT, будет виден другой транзакции с уровнем READ COMMITTED?
У меня вообще-то написано ровно обратное, причем вы еще и окончание предложения снесли. Наверно, случайно так получилось:
Обычный уровень RC и любой выше, как в моем примере, покажет в примере сразу две записи, и только когда завершится вторая сессия
Еще раз: при read committed результат будет виден извне только сразу для двоих записей. Сразу для двоих, т.е. одной записью из первой сессии выхлопа вообще не будет, понимаете? А случится это только тогда, когда обе транзакции из вашего примера зафиксируются.
PS. READ UNCOMMITTED это вообще хак, и далеко не везде он поддерживается
Не знаю, что такое хак в лично вашем определении, но то, что грязное чтение поддерживается не везде, опять же ничего не меняет.
Вы вообще чрезвычайно легко даете определения, категорически противоречащие общепринятым, чего стоит одно это:
Под автоинкрементом обычно подразумевается, что новой транзакции будет выдан номер больший, чем последний, использованный до этого
Для внешнего наблюдателя (txn3) из моего примера сначала появится запись из txn2
Во-первых, абсолютно необязательно. Про уровни изоляции я не просто так обращал внимание. Обычный уровень RC и любой выше, как в моем примере, покажет в примере сразу две записи, и только когда завершится вторая сессия. А Read Uncommitted aka грязное чтение — и вовсе по мере появления незакоммиченных записей. А вот с RCSI действительно будет сначала результат второй транзакции, затем — обеих. С верным порядком ключей — сначала более ранняя вставка и никак иначе, ни при каком варианте!
Во-вторых, опять же, это ровно никакого отношения к порядку ключей относительно порядка вставки не имеет, могу лишь повторить повторить:
Тут чистая видимость транзакции — и, внезапно, никакого нарушения порядка вставки!
Вещь эта, конечно, базовая, но базовая вообще безотносительно автоинкремента, уберите автоинкремент — и абсолютно ничего в примере не изменится.
А вот выше вы утверждали:
Вы же в курсе, да, что автоинкрементальные ID не обязаны появляться в БД в строгом порядке? И запись под номером 9 может появиться после записи под номером 11?
И? Тут чистая видимость транзакции — и, внезапно, никакого нарушения порядка вставки!
Смотрите, ваш пример
-- табличка, создаем сразу
use tempdb;
drop table if exists books;
create table books (id int not null identity primary key, val int not null, dt datetime default sysdatetime());
-- сессия 1
-- вот от этой штуки зависит результат
set transaction isolation level read committed;
begin tran;
insert into books(val) values (1);
waitfor delay '00:00:30';
commit;
-- сессия 2
-- уровень изоляции тот же, что в скрипте 1 для однозначности, например
set transaction isolation level read committed;
begin tran;
insert into books(val) values (2);
commit;
-- сессия 3
-- уровень изоляции тот же, что в скрипте 1 для однозначности, например
set transaction isolation level read committed;
select * from books;
В зависимости от уровней изоляции законно получаем разные эффекты, но всегда, абсолютно всегда сервером гарантируется, что более ранняя вставка имеет меньший identity. Если какие-то записи чтение/вставку не блокируют (например, при read uncommitted/RCSI), то никакого нарушения нет, а есть только в чистом виде эффекты изоляции. С тем же успехом можно было, например, заблокировать запись и делать широкие выводы вида «таракану оторвали ноги — таракан не слышит».
Нет никаких транзакций с номер 10. Есть автоинкрементный ключ вставляемой записи, и он получает значение строго на момент вставки, и при этом строго возрастает. Т.е. ранее вставленная строка всегда имеет значение меньшее, чем вставленная позднее. Это все, что требуется знать для понимания ситуации. Никакие другие факторы, включая время начала транзакции, не меняют вообще ничего. Даже откаченная транзакция просто приведет к пропуску значения, что ничего не меняет в сказанном выше. Так что
Вы же в курсе, да, что автоинкрементальные ID не обязаны появляться в БД в строгом порядке? И запись под номером 9 может появиться после записи под номером 11?
Оба утверждения ложны: автоинкрементные столбцы появляются всегда в строго монотонном порядке (если исключить зацикливание в некоторых СУБД) и запись со значением 9 не может появиться после записи 11 (в случае положительного приращения и с тем же исключением, что и выше). Ну, или вы имели в виду написать совсем не то, что написали, дав свое определение понятия упорядочивания по времени (что, видимо, следует из комментов).
Есть два типа кандидатов: те, про кого я и так все знаю, и код которых видел в миллионах разных мест, и те, про кого я ничего не знаю. С первыми буду общаться за ланчем в кафе
Ну во-первых: нет, не будете вы с ними общаться. Вы ниже сами же и писали:
Команды brainfuck — это кратчайшее описание полной машины Тюринга. Точное соответствие символа — команде можно и подзабыть, но если человек не скажет что-то вроде «меньше, больше, точка, скобки» и не перечислит собственно операции — про синьорство можно перестать разговаривать прямо сразу.
Да, при таком выпедверте разговор будет закончен прямо сразу. И нет, не вами.
или показать завершенный код проекта на гитхабе, или сразу пройти в лес со своими амбициями
Далеко не любой даже разраб может иметь свой пет-проект по своей специализации. Ох как не любой. Я вот, например, sql-разраб. Хорошо хоть, что те, кто ищет sql-разрабов в реале, отлично понимают всю бредовость подобного.
PS. Кого все-таки на хабре не прочтешь, как только разговор на тему рекрутинга заходит. То кандидат, не развеселившийся от тоскливых баянов, должен быть отсеян, то имеющий аккаунт на mailru, то пришедший без галстука, то не показывающий исходников предыдущих работодателей… Сколько из пишущих подобное действительно провели хоть одно собеседование не только как кандидаты? До чего ж нелепое самоутверждение.
Печатаю мало и, главное, редко. MG2400, соответственно, в половине случаев перед перед печатью начинает долго и обильно сморкаться — вроде как сопла чистит. Каждые полгода картридж приходится заменять (сейчас 1600 руб только за черный). В тексте есть табличка с ценами подписки, исходя из нее, мне она обошлась бы ощутимо дешевле. Если есть выбор — в чем вообще проблема?
Были бы частью f, если бы зависели только от количества телевизоров, но мы же подобного утверждать не можем. Они в общем (реальном) случае сами зависят не только еще и от других переменных и их производных (включая зависящие в т.ч. и от этой самой f и ее производных). И там еще спрятано управляющее воздействие системы, само по себе сложным образом зависящее от поведения системы, включая реакцию обалдевшего от происходящего дежурного диспетчера, зависящую вообще черт знает от чего. Причем ни форма, ни знак, ни даже порядок вклада всех этих зависимостей (нам) неизвестна. Так что прав, скорее, Lissov: взяли что-то условно среднепотолочно-линейное, получили оценку 53%-121% сказали, что 87%, ну а там, например, 13% — ну и норм, зритель же доволен, момент яркий, всем запомнился.
Ну и заодно и «А MapViewOfFile будет сразу пытаться выделить обьем оперативки равный отмапливаемому участку»?
Не будет. Кто-то кого-то обманул. Все принципиально везде похоже: выделяется только диапазон виртуальной памяти. При доступе к еще неотображенной странице прозрачно возникает исключение, в результате страница отображается в память, читается из файла и операция доступа перезапускается уже к странице в памяти.
Вы же даже не пытались прочесть хотя бы в таком общем виде, но перлы типа «MapViewOfFile в Windows вообще убог» смело издаете. Не надо так.
Нет, конечно, так нет необходимости делать. Динамические запросы нужно строить так, чтоб никакого пользовательского ввода в код запроса просто не попадало. Это всегда можно, кроме редчайших случаев типа построения констант для некоторых вариантов полнотекстового поиска на MS SQL — вот в этих и только этих случаях да, приходится писать обертки, которые не позволят выбраться зловредному пользовательскому вводу за пределы строковых констант. Даже для запросов с 100500 вариантами фильтров, соединений и выражений в том же MS SQL, если не хотите использовать условия запуска подветок, обычно очень неплохо подходит запрос с перекомпиляцией, если вы хорошо понимаете, как написать сколь угодно большой запрос так, чтобы оптимизатор для начала гарантированно отрубил все неиспользуемые ветви, а затем эффективно построил план для оставшейся части — и да, для этого знать про option(recompile) совершенно недостаточно.
Это попросту не так. И да, я видел и некоторое время поучаствовал в разработке такой огромной системы. Там, совершенно как в примере gleb_l, точно такое отношение к безопасности — базовые права гарантирует сам сервер, остальное — процедурной частью, а логика вообще вся на сервере, ни одного запроса мимо интерфейсных объектов, да мимо и невозможно — см. пункт про права на объекты БД. Или же ваше утверждение требует переформулировки или дополнений, например — по факту очень трудно найти специалистов БД, которые способны все это спроектировать, расписать и при необходимости развивать и поддерживать. Например, в сравнением с рынком специалистов по C# — это очень заметно, факт.
Видите, у вас ровно обратный хрестоматийный пример — вместо разработки грамотным профессионалам — «столько «профессионалов» поучавствовало» (цитата), с предсказуемыми последствиями. Подход же, озвученный gleb_l, при условии выполнения грамотным специалистом (я понимаю, что специалистом по SQL считает себя чуть менее, чем каждый каждый первый, кто умеет написать простой запрос, но сейчас я именно про грамотных профильных специалистов) очень устойчив при использовании разношерстной командой, уже в одном этом его огромный плюс.
Это говорит лишь о том, что с Ораклом вы сколько успели проработать, а с MSSQL — нет. Тут все дело в том, что подходы к ним очень, очень разные. При переходе от одного к другому — неважно, в каком порядке — сначала необходимо полностью перестроить мозги, сломать привычное мышление, совершенно изменить подход. Начинать писать на t/sql и обнаружить, что в нем отсутствуют привычные так необходимые объекты и пайпланы или, наоборот, перейти на Оракл и обескураженно искать, где же тут локальные времянки, без которых жизнь как без воздуха, и непосредственная отдача резалтсета из процедурной части клиенту — поначалу просто апатия, проклятия и ненависть, без преувеличения. Холивары MS SQL vs Oracle потому так и унылы и однообразны, что читаешь аргументы что одной, что другой строны — и видишь только, что аргументаторы привыкли мыслить только одной парадигмой, а противоположная обеим сторонам кажется какой-то инопланетной дикостью, поэтому эффективно мыслить за обе стороны мало кто пытается. В действительности же и у той, и другой стороны есть свои сильные и слабые стороны, опять же хрестоматийный случай.
Ну и да, никто обходиться без CLR не заставляет, даже совершенно не для написания на нем бизнес-логики, а исключительно для базовых вещей, которые почему-то до сих пор не завезли в MS SQL, например, почему-то отсутствующего инструментария для использования регулярок, из-за чего у каждого разработчика есть своя библиотечка на этом CLR для оберток над функционалом для работы с ними. Видите, я использовал аргумент из первой десятки в пользу Оракла, где регулярки давно из коробки :)
Ну прочтите вы хоть что-то по теме, по которой собрались спорить, чтобы понять хоть этот абзац. Ну хотя бы про RC, что ли. Вы же даже логического смысла блокировок не понимаете, зато смело несете в массы свои определения типа
Читайте про изоляцию транзакций — именно там написано, что и почему вышеприведенное значит.
Еще раз: при read committed результат будет виден извне только сразу для двоих записей. Сразу для двоих, т.е. одной записью из первой сессии выхлопа вообще не будет, понимаете? А случится это только тогда, когда обе транзакции из вашего примера зафиксируются.
Не знаю, что такое хак в лично вашем определении, но то, что грязное чтение поддерживается не везде, опять же ничего не меняет.
Вы вообще чрезвычайно легко даете определения, категорически противоречащие общепринятым, чего стоит одно это:
Автоинкремент — это номер транзакции? Да, а номер транзакции — это что такое, вы забыли определить? И выводите из этого дальше сапоги всмятку. На самом деле автоикремент — это значение столбца, автозаполняемого монотонно данными с заданным приращением в порядке вставки. Вот вам, например, по-русски, ознакомьтесь: docs.microsoft.com/ru-ru/sql/t-sql/statements/create-table-transact-sql-identity-property?view=sql-server-ver15
Во-вторых, опять же, это ровно никакого отношения к порядку ключей относительно порядка вставки не имеет, могу лишь повторить повторить:
Вещь эта, конечно, базовая, но базовая вообще безотносительно автоинкремента, уберите автоинкремент — и абсолютно ничего в примере не изменится.
А вот выше вы утверждали:
Это, простите, просто дичь.
В зависимости от уровней изоляции законно получаем разные эффекты, но всегда, абсолютно всегда сервером гарантируется, что более ранняя вставка имеет меньший identity. Если какие-то записи чтение/вставку не блокируют (например, при read uncommitted/RCSI), то никакого нарушения нет, а есть только в чистом виде эффекты изоляции. С тем же успехом можно было, например, заблокировать запись и делать широкие выводы вида «таракану оторвали ноги — таракан не слышит».
Оба утверждения ложны: автоинкрементные столбцы появляются всегда в строго монотонном порядке (если исключить зацикливание в некоторых СУБД) и запись со значением 9 не может появиться после записи 11 (в случае положительного приращения и с тем же исключением, что и выше). Ну, или вы имели в виду написать совсем не то, что написали, дав свое определение понятия упорядочивания по времени (что, видимо, следует из комментов).
Да, при таком выпедверте разговор будет закончен прямо сразу. И нет, не вами.
Далеко не любой даже разраб может иметь свой пет-проект по своей специализации. Ох как не любой. Я вот, например, sql-разраб. Хорошо хоть, что те, кто ищет sql-разрабов в реале, отлично понимают всю бредовость подобного.
PS. Кого все-таки на хабре не прочтешь, как только разговор на тему рекрутинга заходит. То кандидат, не развеселившийся от тоскливых баянов, должен быть отсеян, то имеющий аккаунт на mailru, то пришедший без галстука, то не показывающий исходников предыдущих работодателей… Сколько из пишущих подобное действительно провели хоть одно собеседование не только как кандидаты? До чего ж нелепое самоутверждение.