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

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

Ездить за рулём, крутить гайки, душнить.

идеальный варинт - яндекс такси!

Just.Doit написал 15 минут назад:

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

Ездить за рулём, крутить гайки, душнить.

идеальный варинт - яндекс такси!

Если ток в майбах, пьяных блядей с отелей увозить

Кстати по поводу такси

@Grohuf сделай уже чтонибудь с этой ебучей рекламой, она везде

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

«Яндекс Маркет» вводит сервисный сбор для пользователей, он будет фиксированным и составит 20 рублей за заказ

найс контора реклама в каждом сервисе на фул ебало надеюсь закроется скоро хуета красная

Тоже хотелось бы чтобы хохлы им всю инфру закриптили с бэкапами вместе

Я не сильно понял.

Яндекс Маркет это Яндекс Еда типа?

Наоборот правильно. Агрегатор и должен брать за покупки какую-то мзду сервисную. Я как покупатель был бы рад это оплачивать из своего кармана, прозрачно.

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

А не проценты, не рекламу, не всю эту поеботу.

Один нюанс, оно наверное в ДОПОЛНЕНИЕ пойдет.

Яндекс Маркет это маркетплейс (как озон, вб, алиэкспресс)
Яндекс Еда это доставка еды из ресторанов (как Delivery Club)

kez написал 1 час назад:

Яндекс Маркет это маркетплейс

яндекс маркет был пиздатой площадкой агрегации отзывов о товарах

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

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

Тут согласен

Охуенный поисковик был. И отзывы, фоточки. Туча фильтров.

Я думал он сдох давно. А оно вон как, кто-то даже пользуется этим.

понабрали людей, решающих только изики на литкоде (с) Гробух

GoldRobot написал 15 часов назад:

Кстати по поводу такси

@Grohuf сделай уже чтонибудь с этой ебучей рекламой, она везде

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

че за реклама?

не думал адблок заюзать? :O

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

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

Есть кто хорошо шарит в 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 стула)

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

Есть кто хорошо шарит в 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 стула)

 

https://www.perplexity.ai/search/est-server-s-vkliuchennoi-snap-EGq2pjpqTN2aEip6RMfH8Q

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

https://www.perplexity.ai/search/est-server-s-vkliuchennoi-snap-EGq2pjpqTN2aEip6RMfH8Q

Ты доверяешь LLM в таких вопросах?

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

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

https://www.perplexity.ai/search/est-server-s-vkliuchennoi-snap-EGq2pjpqTN2aEip6RMfH8Q

Ты доверяешь LLM в таких вопросах?

А какие минусы? 

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

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

Ritsu twit написал 7 минут назад:

https://www.perplexity.ai/search/est-server-s-vkliuchennoi-snap-EGq2pjpqTN2aEip6RMfH8Q

Ты доверяешь LLM в таких вопросах?

А какие минусы? 

Галюцинации и пиздежь. Пользоватся LLM стоит только если ты можешь точно верифицировать их ответ, а я не могу так как сам не уверен

ChatGPT4o выдал такое

 

Цитата

 

Эскалация локов и управление конкурентностью

С точки зрения эскалации локов и конкурентности, ключевым аспектом является использование WITH(READUNCOMMITTED):

WITH(READUNCOMMITTED) минимизирует блокировки, так как данный уровень изоляции не накладывает shared locks и не читает exclusive locks, что снижает вероятность эскалации локов. Однако есть риск чтения "грязных" данных.

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

 

Рекомендация

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

Заключение

Учитывая, что вам необходимо выбирать между двумя вариантами, я бы рекомендовал использовать второй вариант с WITH(READUNCOMMITTED), если данные не критично получать "грязными". Если данные должны быть консистентными, можно рассмотреть использование WITH(READCOMMITTED), но это увеличит вероятность блокировок.

 

как минимум информация относительно WITH(READCOMMITTED)  попахивает пиздежем учитывая входные данные моего запроса

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

Ritsu twit написал 8 минут назад:

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

Ritsu twit написал 13 минут назад:

https://www.perplexity.ai/search/est-server-s-vkliuchennoi-snap-EGq2pjpqTN2aEip6RMfH8Q

Ты доверяешь LLM в таких вопросах?

А какие минусы? 

Галюцинации и пиздежь. Пользоватся LLM стоит только если ты можешь точно верифицировать их ответ, а я не могу так как сам не уверен

ChatGPT4o выдал такое

 

Цитата

 

Эскалация локов и управление конкурентностью

С точки зрения эскалации локов и конкурентности, ключевым аспектом является использование WITH(READUNCOMMITTED):

WITH(READUNCOMMITTED) минимизирует блокировки, так как данный уровень изоляции не накладывает shared locks и не читает exclusive locks, что снижает вероятность эскалации локов. Однако есть риск чтения "грязных" данных.

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

 

Рекомендация

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

Заключение

Учитывая, что вам необходимо выбирать между двумя вариантами, я бы рекомендовал использовать второй вариант с WITH(READUNCOMMITTED), если данные не критично получать "грязными". Если данные должны быть консистентными, можно рассмотреть использование WITH(READCOMMITTED), но это увеличит вероятность блокировок.

 

 

как минимум информация относительно WITH(READCOMMITTED)  попахивает пиздежем учитывая входные данные моего запроса

 

https://www.perplexity.ai/search/est-server-s-vkliuchennoi-snap-EGq2pjpqTN2aEip6RMfH8Q

В целом её надо кормить до талого, я так делаю, можно меня осуждать конечно, но 9 из 10 проблем она мне решает.
 

Ritsu twit написал 48 минут назад:

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

Ritsu twit написал 58 минут назад:

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

Ritsu twit написал 1 час назад:

https://www.perplexity.ai/search/est-server-s-vkliuchennoi-snap-EGq2pjpqTN2aEip6RMfH8Q

Ты доверяешь LLM в таких вопросах?

А какие минусы? 

Галюцинации и пиздежь. Пользоватся LLM стоит только если ты можешь точно верифицировать их ответ, а я не могу так как сам не уверен

ChatGPT4o выдал такое

 

Цитата

 

Эскалация локов и управление конкурентностью

С точки зрения эскалации локов и конкурентности, ключевым аспектом является использование WITH(READUNCOMMITTED):

WITH(READUNCOMMITTED) минимизирует блокировки, так как данный уровень изоляции не накладывает shared locks и не читает exclusive locks, что снижает вероятность эскалации локов. Однако есть риск чтения "грязных" данных.

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

 

Рекомендация

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

Заключение

Учитывая, что вам необходимо выбирать между двумя вариантами, я бы рекомендовал использовать второй вариант с WITH(READUNCOMMITTED), если данные не критично получать "грязными". Если данные должны быть консистентными, можно рассмотреть использование WITH(READCOMMITTED), но это увеличит вероятность блокировок.

 

 

как минимум информация относительно WITH(READCOMMITTED)  попахивает пиздежем учитывая входные данные моего запроса

 

https://www.perplexity.ai/search/est-server-s-vkliuchennoi-snap-EGq2pjpqTN2aEip6RMfH8Q

В целом её надо кормить до талого, я так делаю, можно меня осуждать конечно, но 9 из 10 проблем она мне решает.
 

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

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 стула)

 

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

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