Программирование[11]

Kant написал Только что:

Drakonian написал 2 часа назад:

Есть кто хорошо шарит в Microsoft SQL Server (Azure SQL по факту)?

есть сервер с включенной snapshot isolation https://learn.microsoft.com/en-us/dotnet/framework/data/adonet/sql/snapshot-isolation-in-sql-server
и
Optimized locking https://learn.microsoft.com/en-us/sql/relational-databases/performance/optimized-locking?view=azuresqldb-current&viewFallbackFrom=sql-server-ver16

Допустим есть таблица в которой данные либо есть либо нет

Есть приложение которое общается с таблицей, например читает данные и модифицирует их.

есть два вариант SQL стайтментов (есть ток 2 варианта, по другому и лучше нельзя написать)

Один сначала перед чтением Rows проверяет наличие данных

SELECT TOP 1 NULL  FROM "db_bcprodweu_t34914613_20240527_01042369_b2c1".dbo."SOMETABLE" "36"  WITH(READUNCOMMITTED)  OPTION(OPTIMIZE FOR UNKNOWN)

и только потом выбирает Rows из таблицы для обработки (только если первый запрос найдет что-то)

SELECT *  FROM "db_bcprodweu_t34914613_20240527_01042369_b2c1".dbo.SOMETABLE" "36" WITH(READUNCOMMITTED) ORDER BY "Document Type" ASC,"No_" ASC OPTION(OPTIMIZE FOR UNKNOWN, FAST 50)

Второй сразу ебашит 

SELECT *  FROM "db_bcprodweu_t34914613_20240527_01042369_b2c1".dbo.SOMETABLE" "36" WITH(READUNCOMMITTED) ORDER BY "Document Type" ASC,"No_" ASC OPTION(OPTIMIZE FOR UNKNOWN, FAST 50)

Какой из вариантов лучше с точки зрения производительности и возможной эскалации локов?
Максимум что можно изменить это WITH(READUNCOMMITTED) на WITH(READCOMMITTED)
В таблице может не быть записей, может быть мало или много.

Так же это приложение может в несколько потоков удалять, читать, добавлять, модифицировать, данные в таблице.

 

(почему так по ублюдски? да там по факту интерпрататор генерирует SQL, есть ток 2 стула)

 

не понял зачем вообще там рид анкоммитед, который читает любую парашу на сервере, и при этом снэпшот изоляция, которая принудительно снэпшотит всё что возможно, даже закоммиченные действия

 

поставь рид коммитед снэпшот и не еби себе мозги, ты не лочишь чтениями чтения и записи, не читаешь не закоммиченную парашу и при этом записи работают как обычно

это понятно относительно READCOMMITTED, там просто дефолт READUNCOMMITTED стоит который можно изменить
ты скажи какой вариант лучше 1 или 2
 

Drakonian написал 25 минут назад:

так он разные ответы дает
какой из них верный как узнаешь?))

Есть такая мысль, она существует из моба игр, какой-то образный лол тому пример, если ты не игрок высшей лиги, бери всегда талант, который в меньшей степени зависит от ситуации, а просто работает в 90% случаев. Так и тут скорее нужно выбирать первый вариант, т.к реализация через второй будет создавать лишние запросы или еще какие не желательные события, которые замедлят работу. 

Drakonian написал Только что:

Kant написал 2 минуты назад:

Drakonian написал 2 часа назад:

Есть кто хорошо шарит в Microsoft SQL Server (Azure SQL по факту)?

есть сервер с включенной snapshot isolation https://learn.microsoft.com/en-us/dotnet/framework/data/adonet/sql/snapshot-isolation-in-sql-server
и
Optimized locking https://learn.microsoft.com/en-us/sql/relational-databases/performance/optimized-locking?view=azuresqldb-current&viewFallbackFrom=sql-server-ver16

Допустим есть таблица в которой данные либо есть либо нет

Есть приложение которое общается с таблицей, например читает данные и модифицирует их.

есть два вариант SQL стайтментов (есть ток 2 варианта, по другому и лучше нельзя написать)

Один сначала перед чтением Rows проверяет наличие данных

SELECT TOP 1 NULL  FROM "db_bcprodweu_t34914613_20240527_01042369_b2c1".dbo."SOMETABLE" "36"  WITH(READUNCOMMITTED)  OPTION(OPTIMIZE FOR UNKNOWN)

и только потом выбирает Rows из таблицы для обработки (только если первый запрос найдет что-то)

SELECT *  FROM "db_bcprodweu_t34914613_20240527_01042369_b2c1".dbo.SOMETABLE" "36" WITH(READUNCOMMITTED) ORDER BY "Document Type" ASC,"No_" ASC OPTION(OPTIMIZE FOR UNKNOWN, FAST 50)

Второй сразу ебашит 

SELECT *  FROM "db_bcprodweu_t34914613_20240527_01042369_b2c1".dbo.SOMETABLE" "36" WITH(READUNCOMMITTED) ORDER BY "Document Type" ASC,"No_" ASC OPTION(OPTIMIZE FOR UNKNOWN, FAST 50)

Какой из вариантов лучше с точки зрения производительности и возможной эскалации локов?
Максимум что можно изменить это WITH(READUNCOMMITTED) на WITH(READCOMMITTED)
В таблице может не быть записей, может быть мало или много.

Так же это приложение может в несколько потоков удалять, читать, добавлять, модифицировать, данные в таблице.

 

(почему так по ублюдски? да там по факту интерпрататор генерирует SQL, есть ток 2 стула)

 

не понял зачем вообще там рид анкоммитед, который читает любую парашу на сервере, и при этом снэпшот изоляция, которая принудительно снэпшотит всё что возможно, даже закоммиченные действия

 

поставь рид коммитед снэпшот и не еби себе мозги, ты не лочишь чтениями чтения и записи, не читаешь не закоммиченную парашу и при этом записи работают как обычно

это понятно относительно READCOMMITTED, там просто дефолт READUNCOMMITTED стоит который можно изменить
ты скажи какой вариант лучше 1 или 2
 

поставить ридкоммитед снэпшот на всю базу и никогда в жизни не использовать рид анкоммитед

Kant написал 3 минуты назад:

Drakonian написал 4 минуты назад:

Kant написал 5 минут назад:

Drakonian написал 2 часа назад:

Есть кто хорошо шарит в Microsoft SQL Server (Azure SQL по факту)?

есть сервер с включенной snapshot isolation https://learn.microsoft.com/en-us/dotnet/framework/data/adonet/sql/snapshot-isolation-in-sql-server
и
Optimized locking https://learn.microsoft.com/en-us/sql/relational-databases/performance/optimized-locking?view=azuresqldb-current&viewFallbackFrom=sql-server-ver16

Допустим есть таблица в которой данные либо есть либо нет

Есть приложение которое общается с таблицей, например читает данные и модифицирует их.

есть два вариант SQL стайтментов (есть ток 2 варианта, по другому и лучше нельзя написать)

Один сначала перед чтением Rows проверяет наличие данных

SELECT TOP 1 NULL  FROM "db_bcprodweu_t34914613_20240527_01042369_b2c1".dbo."SOMETABLE" "36"  WITH(READUNCOMMITTED)  OPTION(OPTIMIZE FOR UNKNOWN)

и только потом выбирает Rows из таблицы для обработки (только если первый запрос найдет что-то)

SELECT *  FROM "db_bcprodweu_t34914613_20240527_01042369_b2c1".dbo.SOMETABLE" "36" WITH(READUNCOMMITTED) ORDER BY "Document Type" ASC,"No_" ASC OPTION(OPTIMIZE FOR UNKNOWN, FAST 50)

Второй сразу ебашит 

SELECT *  FROM "db_bcprodweu_t34914613_20240527_01042369_b2c1".dbo.SOMETABLE" "36" WITH(READUNCOMMITTED) ORDER BY "Document Type" ASC,"No_" ASC OPTION(OPTIMIZE FOR UNKNOWN, FAST 50)

Какой из вариантов лучше с точки зрения производительности и возможной эскалации локов?
Максимум что можно изменить это WITH(READUNCOMMITTED) на WITH(READCOMMITTED)
В таблице может не быть записей, может быть мало или много.

Так же это приложение может в несколько потоков удалять, читать, добавлять, модифицировать, данные в таблице.

 

(почему так по ублюдски? да там по факту интерпрататор генерирует SQL, есть ток 2 стула)

 

не понял зачем вообще там рид анкоммитед, который читает любую парашу на сервере, и при этом снэпшот изоляция, которая принудительно снэпшотит всё что возможно, даже закоммиченные действия

 

поставь рид коммитед снэпшот и не еби себе мозги, ты не лочишь чтениями чтения и записи, не читаешь не закоммиченную парашу и при этом записи работают как обычно

это понятно относительно READCOMMITTED, там просто дефолт READUNCOMMITTED стоит который можно изменить
ты скажи какой вариант лучше 1 или 2
 

поставить ридкоммитед снэпшот на всю базу и никогда в жизни не использовать рид анкоммитед

Согласен, ок.


Что насчет изначального вопроса?

SELECT TOP 1 NULL  FROM "db_bcprodweu_t34914613_20240527_01042369_b2c1".dbo."SOMETABLE" "36"  WITH(READCOMMITTED)  OPTION(OPTIMIZE FOR UNKNOWN)

SELECT *  FROM "db_bcprodweu_t34914613_20240527_01042369_b2c1".dbo.SOMETABLE" "36" WITH(READCOMMITTED) ORDER BY "Document Type" ASC,"No_" ASC OPTION(OPTIMIZE FOR UNKNOWN, FAST 50)

VS 

SELECT *  FROM "db_bcprodweu_t34914613_20240527_01042369_b2c1".dbo.SOMETABLE" "36" WITH(READCOMMITTED) ORDER BY "Document Type" ASC,"No_" ASC OPTION(OPTIMIZE FOR UNKNOWN, FAST 50)

ты бы планы скинул для начала, я думал вопрос про локи, а у тебя во всех запросах одно и то же

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

если по неизвестным причинам план без топ1 в говне, зафорсить его чтобы он не был в говне, что в принципе уже сделано через фаст 50

оптимайз фор анноун там вообще не нужен, ведь нет параметров

но я затрудняюсь представить ситуацию, когда селект * из таблицы без фильтров может быть медленным на пустой таблице

да доступа нет...
это по сути ERP имеет свой процедурный ЯП который транслируется в SQL запросы

По сути есть возможность написать код двумя способами
 

If SomeTable.FindSet() then
  repeat
  //Do something with Row In Table
  until SomeTable.Next() = 0;

либо
 

if SomeTable.IsEmpty() then
  exit;

SomeTable.FindSet()
repeat
  //Do something with Row In Table
until SomeTable.Next() = 0;

=======================
Тоесть по сути разница 

SomeTable.FindSet()

vs

if SomeTable.IsEmpty() then
  exit;

SomeTable.FindSet()

============================
где IsEmpty() транслируется в
 

SELECT TOP 1 NULL  FROM "db_bcprodweu_t34914613_20240527_01042369_b2c1".dbo."SOMETABLE" "36"  WITH(READCOMMITTED)  OPTION(OPTIMIZE FOR UNKNOWN)

а FindSet() в
 

SELECT *  FROM "db_bcprodweu_t34914613_20240527_01042369_b2c1".dbo.SOMETABLE" "36" WITH(READCOMMITTED) ORDER BY "Document Type" ASC,"No_" ASC OPTION(OPTIMIZE FOR UNKNOWN, FAST 50)

Откуда знаю как транслируется? Тут есть свой дебагер который показывает последние SQL запросы

А я хочу найти самый оптимальный способ написания этого говна учитывая настройки Azure SQL

Поэтому и вопрос такой кугутский и плана нету

Kant написал 16 минут назад:

 

но я затрудняюсь представить ситуацию, когда селект * из таблицы без фильтров может быть медленным на пустой таблице

А если таблица не пустая, но по фильтрам пусто?

ну в запросе выше у тебя фильтров нет, так что читать ей кластерный индекс придется по любому

а тк это видимо какая-то таблица очереди, то там даже тысяч строк не наберется, так что максимально похуй вообще на запрос

и итого 2 запроса проигрывает 1 просто потому что их 2

Kant написал 3 минуты назад:

ну в запросе выше у тебя фильтров нет, так что читать ей кластерный индекс придется по любому

а тк это видимо какая-то таблица очереди, то там даже тысяч строк не наберется, так что максимально похуй вообще на запрос

и итого 2 запроса проигрывает 1 просто потому что их 2

понял, спасибо

А если фильтра есть? И по этим фильтрам данные могут быть или нет. Ситуация изменится?

плюс записей в тиблце может быть 500к

Почему разные входные данные задаю - хочу понять есть ли в правиле исключения и какие?

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

если там условно ситуация, что проверяет раз в час, и за этот час набежит миллион строк, и присутствовал индекс, который удовлетворяет фильтру,

то тогда запрос с топ 1 нулл будет быстрым, тк ему не надо данные из таблицы, только проверить индекс, а селект * потом уже полезет в кластерный индекс за данными следующим запросом

однако при учете, что ты всё равно собираешься делать селект * следующим же действием, толку от предварительной проверки немного, только если ты в коде можешь передумать и сказать что я нахуй это процессить не буду, либо будешь менять фильтр еще каким-то образом

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

Благодарю, доступно разъяснил

Rooster написал 5 часов назад:

Реально братан ща в приложуху такси адблок зашью

Как говорится just do it

гоям впаривают рекламу прямо внутри уже платного приложения?

лол кек

*******

бтв, тут в очередной раз почитал про новвоведения трудовой миграции в Гермахе

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

так что если кто-то задумывался - велком. могу проконсультировать

Ох уж этот говноскуль из генераторов

Just.Doit написал 1 час назад:

Rooster написал 5 часов назад:

Реально братан ща в приложуху такси адблок зашью

Как говорится just do it

гоям впаривают рекламу прямо внутри уже платного приложения?

лол кек

 

 

*******

бтв, тут в очередной раз почитал про новвоведения трудовой миграции в Гермахе

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

так что если кто-то задумывался - велком. могу проконсультировать

 

 

А че так?

Желающие пакистанцы и индусы с вышкой закончились? Теперь уже рады сирийцам и бангладешцам со школьным образованием

Какая же Евросовку пизда в ближайшие 50 лет

Vova написал 8 часов назад:

Какая же Евросовку пизда в ближайшие 50 лет

жители сша сейчас и представляют адовый микс и как-то со своими проблемами живут норм

без мигрантов некому будет сдавать мусорное жильё по цене полёта в космос, и будет сложно почивать на лаврах гражданам. нужны мигранты, чтобы они копошились у подножия величия граждан по рождению, работая почти 24/7 и отдавая почти все получаемые ресурсы на чужое благополучие

Olololnet написал 34 минуты назад:

Vova написал 9 часов назад:

Какая же Евросовку пизда в ближайшие 50 лет

жители сша сейчас и представляют адовый микс и как-то со своими проблемами живут норм

 

без мигрантов некому будет сдавать мусорное жильё по цене полёта в космос, и будет сложно почивать на лаврах гражданам. нужны мигранты, чтобы они копошились у подножия величия граждан по рождению, работая почти 24/7 и отдавая почти все получаемые ресурсы на чужое благополучие

Спасибо за глубокий анализ

Теперь посмотри че там по требованиям в США и че в Германии

тебе подробнее и не положено

Olololnet написал 1 минуту назад:

тебе подробнее и не положено

Бля ладно

Походу ты даже по русски изъясняться не научился

В германии нерусских дохуя, впадлу жить с обезьянами

В РФ охуенно

А в Германии есть какие-то мб округи/районы, где поменьше мигрантов? 

Vova написал 12 часов назад:

Какая же Евросовку пизда в ближайшие 50 лет

кажется всем пизда в ближайшие 50 лет

тут хотябы работодатели не ебут в жопу

Vova написал 12 часов назад:

А че так?

ту мач бюрокраси

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

сейчас геморрой с визами убрали

в целом и не понятно было нахуя так зажимать рамки

если чел может приехать и работать за хорошую ставку - то почему не дать ему эту возможность

ural1qqq написал 53 минуты назад:

впадлу жить с обезьянами

В РФ охуенно

противоречие на лицо

kez написал 4 минуты назад:

А в Германии есть какие-то мб округи/районы, где поменьше мигрантов? 

все что не берлин/гамбург/франкфурт/итп

а что, боишься что русский ванька мигрант тебе ночью ебало разобьет в подворотне по привычке?

kez написал 5 минут назад:

А в Германии есть какие-то мб округи/районы, где поменьше мигрантов?

ты ж сам мигрант будешь

наоборот лучше с мигрантами - они знают инглишь и имеют такие же как у тебя вопросы/проблемы

а приедешь в чисто немецкую деревню/район и будешь белой вороной которой все сторонятся как сраного мигранта