Re[75]: The door - .NET

Здравствуйте, vdimas, Вы писали:

V>ОК, пусть даже мы хотим избежать серьёзного изменения в языке C# по историческим причинам.
V>Но в линке-то появилось выражение let x = some_expression.
V>Из этого выражения генерится примерно такое тело делегата:
V>

V>...
V>var x = some_expression(other_variables);
V>...
V>

V>Вопрос:
V>что помешало сделать так:
V>

V>...
V>var x = default;
V>x = some_expression(other_variables);
V>...
V>

V>и разрешить рекурсию прямо в выражениях?
Отсутствие возможности вывести тип. Какого типа у вас тут будет var x?
Несмотря на то, что порождается несколько другой делегат, т.е. x у нас становится не переменной, а мембером transparent identifier-а анонимного типа, проблема сводится к невозможности автовывода типов для частично рекурсивных функций.
Шарповый выводильщик типов умеет выводить тип выражения, если к моменту начала вывода известны типы его аргументов.
Выводить тип выражения, тип аргумента которого зависит от типа результата, он не умеет.
Показываю наглядно:

public static void Sucks<T, R>(T value, Func<T, R> delegate)
{
   Console.WriteLine("({0})=>{1}", typeof(T).Name, typeof(R).Name);
}
public static void Blows<T, R>(T value, Func<T, R, R> semiRecursiveDelegate)
{
   Console.WriteLine("({0}, {1})=>{1}", typeof(T).Name, typeof(R).Name);
}
public static void Main()
{
   Sucks("Hello, World", a=>a.Length); // :)  
   Blows("Hello, World", (a, k)=>a.Length+k); // :( 
   Blows<string, int>("Hello, World", (a, k)=>a.Length+k); // :|
}

Ваша идея разрешить внутри some_expression обращаться к результату этого же expression сводится к этой же проблеме. Если бы мы знали тип x (пусть это будет X), то мы могли бы сварганить для let вот такой делегат:

from t in T
  let x = some_expression(t, x)
=>
T.Select(t => { var _x_ = default(X); return new {t, x=some_expression(t, _x_)}});

Вместо того, что порождается сейчас:

T.Select(t => new {t, x=some_expression(t)}});

Но тип неизвестен. У нас ровно та же ситуация, что и с Blows:

var T = new string[] {"Hello", "World"};
var b = from t in T 
          let x = t.Length + x / 2
        select x

Здравствуйте, Sinclair, Вы писали:

V>>что помешало сделать так:
V>>и разрешить рекурсию прямо в выражениях?
S>Отсутствие возможности вывести тип. Какого типа у вас тут будет var x?

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

S>Несмотря на то, что порождается несколько другой делегат, т.е. x у нас становится не переменной, а мембером transparent identifier-а анонимного типа

Это тонкости реализации, тут x может быть даже ф-ией генерируемого типа-замыкания:
Enumerable<int> x(args) => some_predicate(args) ? 1 : x(some_decrement(args));
К тому же такой код более эффективный, чем рекурсия через делегат.

Более того, не надо ломать голову над "конкретным" типом делегата.

S>проблема сводится к невозможности автовывода типов для частично рекурсивных функций.

Разве?

var y = (int x) => x < 1 ? 1 : x * y(x-1);

Сигнатуру делегата int y(int x) тут вывести легко.
Другое дело, что сигнатуры делегата дотнету мало, ему подавай конкретный тип делегата с этой сигнатурой.
Т.е. опять возвращаемся к моей критики делегатов дотнета. ))

Но, компилятор вполне может подпихивать вездесущие Func<> и Action<>, ведь они не покидают scope, т.е., по большому счёту, пофик, какой конкретно тип делегата.
Почему бы нет?

S>Ваша идея разрешить внутри some_expression обращаться к результату этого же expression сводится к этой же проблеме. Если бы мы знали тип x (пусть это будет X), то мы могли бы сварганить для let вот такой делегат:

С моими предложениями могло быть примерно так:

from t in T
  let IEnumerable<int> x = some_expression(t, x) ...

В автогенерённом коде объекта-замыкания, мембер x может быть ф-ией:

IEnumerable<int> x(int t) => some_expression(t, x(t));

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

Здравствуйте, Serginio1, Вы писали:

S> Ну Anonymous Recursion in C# можно найти за 2007 год. Это старая фича
S>https://blogs.msdn.microsoft.com/wesdyer/2007/02/02/anonymous-recursion-in-c/

По ссылке обычный Y-комбинатор.
Это совсем старая фича. ))
В варианте дотнета к тому же создаёт новый делегат на каждой итерации рекурсии.

Здравствуйте, vdimas, Вы писали:

I>>Рад, что ты прекратил хвастаться пониманием нюансов C# 2.0 и 3.0.
V>А я не рад, что ты не прекратил про меня фантазировать.

Какие же фантазии, если ты две недели ~~изобретал колесо~~ кряду показывал давно известные вещи из C# 2.0 и 3.0.

V>>>Это проблемы SQL-сервака и мои как разработчика.
V>>>Если я пихаю серваку батч, значит мне так надо.
V>>>Извольте исполнять, как грится.
I>>А откуда в твоей такой архитектуре взяться перформасу ?

V>А откуда ты вообще взял такую постановку вопроса?

Это же элементарно — воможности оптимизатора SQL ограничены. Соответсвенно девелоперам надо быть в курсе, как и что писать.

V>И почему батч обязательно означает отсутствие перформанса?

Потому, что SQL оптимизатор такой. Ты придумал себе архитектуру, в которой вместо чистого SQL надо слать на сервер проекцию сознания девелопера, и далее "пусть сервер думает".

I>>Короче, непонятно, что за разработка такая — если надо думать про каждое присваивание, что оно может поломать план запроса.

V>Пусть сервак думает.

То есть, у девелоперов нет ни одного шанса повлиять на это ?

V>Просто надо знать, что он может и каким именно образом.
V>Рекламировать мне тут твой любимый вариант из разряда "разработчик не должен ни о чём думать" не надо.

Этот вариант ты сам же и продвигаешь — "Пусть сервак думает" == "разработчик не должен ни о чём думать"

I>>Сильно вряд ли ты задумываешься о том, в какие команды процессора транслируется код даже в С++

V>Кто не задумывается, тот на С++ не пишет.
V>Кто не задумывается, что происходит на стороне ДБ, тот тоже пусть под ДБ не пишет, какие проблемы?

А если задуматься, что происходит на стороне ДБ, то можно узнать, что оптимизатор SQL выдаёт перформанс не где угодно, а только в запросах определенного вида.

Здравствуйте, Ikemefula, Вы писали:

I>>>Рад, что ты прекратил хвастаться пониманием нюансов C# 2.0 и 3.0.
V>>А я не рад, что ты не прекратил про меня фантазировать.
I>Какие же фантазии, если ты две недели ~~изобретал колесо~~ кряду показывал давно известные вещи из C# 2.0 и 3.0.

Фантазии про локальные ф-ии в C# 2.0 и 3.0, вестимо.

V>>А откуда ты вообще взял такую постановку вопроса?
I>Это же элементарно — воможности оптимизатора SQL ограничены. Соответсвенно девелоперам надо быть в курсе, как и что писать.

Сорри, но это не твоего ума дело, что кому надо.
Девелоперу надо лишь знать, как исходные конструкции линка переводятся в SQL.
А дальше он действует по своей воле.

I>>>Короче, непонятно, что за разработка такая — если надо думать про каждое присваивание, что оно может поломать план запроса.
V>>Пусть сервак думает.
I>То есть, у девелоперов нет ни одного шанса повлиять на это ?

Рука-лицо.

I>>>Сильно вряд ли ты задумываешься о том, в какие команды процессора транслируется код даже в С++
V>>Кто не задумывается, тот на С++ не пишет.
V>>Кто не задумывается, что происходит на стороне ДБ, тот тоже пусть под ДБ не пишет, какие проблемы?
I>А если задуматься, что происходит на стороне ДБ, то можно узнать, что оптимизатор SQL выдаёт перформанс не где угодно, а только в запросах определенного вида.

Т.е. ты продолжаешь отрицать полезность батчей? ))

Твои заблуждения даже похлеще заблуждений Синклера или IB о происходящем под большой нагрузкой:
https://habr.com/company/odnoklassniki/blog/417593/
))

Здравствуйте, vdimas, Вы писали:

I>>>>Рад, что ты прекратил хвастаться пониманием нюансов C# 2.0 и 3.0.
V>>>А я не рад, что ты не прекратил про меня фантазировать.
I>>Какие же фантазии, если ты две недели ~~изобретал колесо~~ кряду показывал давно известные вещи из C# 2.0 и 3.0.

V>Фантазии про локальные ф-ии в C# 2.0 и 3.0, вестимо.

Ну, ок, 2.0, 3.0 и 7.0.

V>>>А откуда ты вообще взял такую постановку вопроса?
I>>Это же элементарно — воможности оптимизатора SQL ограничены. Соответсвенно девелоперам надо быть в курсе, как и что писать.

V>Сорри, но это не твоего ума дело, что кому надо.

Это давно известные вещи — как только появился запрос, следующая таска — сделать его быстрее. Вот девелопер добавил присваивание и обвалил перформанс. Как ему объяснить, какого вида код работает хорошо, а какой- плохо ?
В Linq у нас это заложено в архитектуру — дели запрос на операции, Select, Where и тд. В твоем случае изначально никакого разделения не предусмотрено

V>Девелоперу надо лишь знать, как исходные конструкции линка переводятся в SQL.

А перформанса как добиваться ? Как девелопер узнает, что цикл одного вида работает быстро, а тот же цикл, но другого вида, обвалит перформанс ?
Предлагаешь доку по компиляции C# в SQL заучивать наизусть ?

V>>>Кто не задумывается, что происходит на стороне ДБ, тот тоже пусть под ДБ не пишет, какие проблемы?
I>>А если задуматься, что происходит на стороне ДБ, то можно узнать, что оптимизатор SQL выдаёт перформанс не где угодно, а только в запросах определенного вида.

V>Т.е. ты продолжаешь отрицать полезность батчей? ))

Попробуй переписать обычный SQL в импративное управление курсором. Померяй перформанс.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, Serginio1, Вы писали:

S>> Ну Anonymous Recursion in C# можно найти за 2007 год. Это старая фича
S>>https://blogs.msdn.microsoft.com/wesdyer/2007/02/02/anonymous-recursion-in-c/

V>По ссылке обычный Y-комбинатор.

Func<int, int> fib = null;
fib = n => n > 1 ? fib(n - 1) + fib(n - 2) : n;
Console.WriteLine(fib(6));                        // displays 8

Где здесь Y-комбинатор?

V>Это совсем старая фича. ))
V>В варианте дотнета к тому же создаёт новый делегат на каждой итерации рекурсии.

Я использовал в своей практике

delegate int Recursive(Recursive r, int n);


The delegate can be generalized by parameterizing the type of the first argument and the return type.


delegate R Recursive<A,R>(Recursive<A,R> r, A a);

Now we can use the lambda that we defined.


Recursive<int, int> fib = (f, n) => n > 1 ? f(f,n - 1) + f(f,n - 2) : n;
Console.WriteLine(fib(fib,6));                      // displays 8

Можно ссылочку на то, что создается новый делегат?

Здравствуйте, Serginio1, Вы писали:

S>Где здесь Y-комбинатор?

Дочитай до конца — вся статья ради него.

S>Я использовал в своей практике
S>

S>delegate int Recursive(Recursive r, int n);
...
S>

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

S> Можно ссылочку на то, что создается новый делегат?

Там же по твоей ссылке на каждой итерации Y-комбинатора создаётся новый экземпляр замыкания и для его вызова создаётся экземпляр делегата.
Дочитай до конца.

Здравствуйте, Ikemefula, Вы писали:

I>Это давно известные вещи — как только появился запрос, следующая таска — сделать его быстрее. Вот девелопер добавил присваивание и обвалил перформанс. Как ему объяснить, какого вида код работает хорошо, а какой- плохо ?

Никак. Разработчик замерит сам.
Я же ссылку дал, где чёрным по белому написано, что перформанс обваливают как раз сложные запросы.
А батч из последовательности простых не обваливает.
Т.е. сам батч вроде бы выполняется дольше, чем сложный запрос, но зато сложный запрос лочит пол-базы, а пошаговый батч — лишь отдельные строки таблиц в каждый момент времени, что повышает уровень параллелизма многократно.

I>В Linq у нас это заложено в архитектуру — дели запрос на операции, Select, Where и тд. В твоем случае изначально никакого разделения не предусмотрено

Херня эта архитектура.
РСУБД — тормоза и ненадёжность.
https://habr.com/company/odnoklassniki/blog/417593/

Прелесть РСУБД в том, что они дают достаточную надёжность и богатый функционал подпорок/ограничений прямо изкаробки, что покрывает львиную долю простых сценариев.
Но как только начинаетсячто-то не простое, то сразу туши свет — начинаешь бороться с самой базой, с её ограничениями, тормозами и регулярными отказами.

V>>Т.е. ты продолжаешь отрицать полезность батчей? ))
I>Попробуй переписать обычный SQL в импративное управление курсором. Померяй перформанс.

Батч не равен курсору.
Батч спокойно оперирует множествами.

Здравствуйте, vdimas, Вы писали:

V>Прелесть РСУБД в том, что они дают достаточную надёжность и богатый функционал подпорок/ограничений прямо изкаробки, что покрывает львиную долю простых сценариев.
V>Но как только начинаетсячто-то не простое, то сразу туши свет — начинаешь бороться с самой базой, с её ограничениями, тормозами и регулярными отказами.

Клас, ну вот не знали. Какая база, что потушило ваш свет, сколько лет назад, актуально ли?

V>>>Т.е. ты продолжаешь отрицать полезность батчей? ))
I>>Попробуй переписать обычный SQL в импративное управление курсором. Померяй перформанс.

V>Батч не равен курсору.
V>Батч спокойно оперирует множествами.

Так, реально, кому-то делать нечего и дискутирует над очевидными вещами.
Vdimas, хочется в этом форуме видеть не крутизну, а рельные полезные кейсы. Остальное плиз в войны.

Здравствуйте, Danchik, Вы писали:

V>>Прелесть РСУБД в том, что они дают достаточную надёжность и богатый функционал подпорок/ограничений прямо изкаробки, что покрывает львиную долю простых сценариев.
V>>Но как только начинаетсячто-то не простое, то сразу туши свет — начинаешь бороться с самой базой, с её ограничениями, тормозами и регулярными отказами.
D>Клас, ну вот не знали. Какая база, что потушило ваш свет, сколько лет назад, актуально ли?

Допустим, у вас всего один сервер базы данных, и он отказывает раз в три года. В это время сайт не работает 20 минут, это приемлемо. Если у вас 64 сервера, то сайт не работает уже раз в три недели. А если у вас 200 серверов, то сайт не работает каждую неделю. Это проблема.

Здравствуйте, vdimas, Вы писали:

S>>Отсутствие возможности вывести тип. Какого типа у вас тут будет var x?

V>Для простых случаев тип выводится.
Простые случаи — это и есть "без рекурсии". Рекурсия требует решать уравнения.
V>Для сложных можно было бы позволить в выражении let указать тип переменной.
Да, это могло бы помочь.

V>Это тонкости реализации, тут x может быть даже ф-ией генерируемого типа-замыкания:
V>Enumerable<int> x(args) => some_predicate(args) ? 1 : x(some_decrement(args));
V>К тому же такой код более эффективный, чем рекурсия через делегат.
Я не понимаю этот код. Каким образом мы будем использовать такой x в последующих выражениях?

S>>проблема сводится к невозможности автовывода типов для частично рекурсивных функций.

V>Разве?
V>

V>var y = (int x) => x < 1 ? 1 : x * y(x-1);
V>

V>Сигнатуру делегата int y(int x) тут вывести легко.
Вам — да. Компилятору — нет. Тут же уравнение на типы. Y — это most common type из двух типов: int и тип выражения (int * Y).
Покажите, почему Y не может быть double или long.

V>Другое дело, что сигнатуры делегата дотнету мало, ему подавай конкретный тип делегата с этой сигнатурой.
V>Т.е. опять возвращаемся к моей критики делегатов дотнета. ))
Неправильный ответ.
V>Но, компилятор вполне может подпихивать вездесущие Func<> и Action<>, ведь они не покидают scope, т.е., по большому счёту, пофик, какой конкретно тип делегата.
V>Почему бы нет?
Дело не в этом. В данном месте компилятор ломается потому, что не может сделать выбор между Func<T, R> и Expression<Func<T,R>>.
Рекурсия тут ни при чём. Даже если её убрать, то компиляция не починится. В тех местах, где компилятор знает, что ожидается именно Func<T, R>, он не сможет вывести тип.

V>С моими предложениями могло быть примерно так:
V>

V>from t in T
V>  let IEnumerable<int> x = some_expression(t, x) ...
V>

V>В автогенерённом коде объекта-замыкания, мембер x может быть ф-ией:
V>

V>IEnumerable<int> x(int t) => some_expression(t, x(t));
V>

V>Здесь отсутствует проверка на выход из рекурсии, поэтому она бесконечна, но можно взять какой-нить валидный рекурсивный алгоритм, из показанных мною ранее.
V>(Тип переменной t в этом выражении достоверно известен)
Так не получится. Если посмотреть цепочки методов, в которые превращается query, то там x в разных местах отношения друг к другу не имеет.
Когда мы пишем

from a in A
 let x = expr(a)
select a + x;

то первый и второй x отношения друг к другу не имеют. В том методе, где a+x, нет возможности передать в х какие-либо параметры, которые у нас были в предыдущем вызове.

Здравствуйте, vdimas, Вы писали:

V>>>Но как только начинаетсячто-то не простое, то сразу туши свет — начинаешь бороться с самой базой, с её ограничениями, тормозами и регулярными отказами.
D>>Клас, ну вот не знали. Какая база, что потушило ваш свет, сколько лет назад, актуально ли?

V>

V>Допустим, у вас всего один сервер базы данных, и он отказывает раз в три года. В это время сайт не работает 20 минут, это приемлемо. Если у вас 64 сервера, то сайт не работает уже раз в три недели. А если у вас 200 серверов, то сайт не работает каждую неделю. Это проблема.

А когда ты обвалишь перформанс, то сайт еле-еле дышит и так всё время. Это еще бОльшая проблема. Как ты собираешься получить профит от индексов, если будешь слать оптимизатору проекцию сознания ?
По твоей же ссылке "C помощью ACID нам удалось реализовать индексы «как в SQL». Они обладают согласованностью, могут масштабироваться, быстро работают, могут быть составными и встроены в язык запросов CQL. Для поддержки индексов не нужно вносить изменения в прикладной код. Всё просто, как в SQL."
То есть, индексы все равно остаются. А стало быть эффективный код должен внятно работать с ними. А это значит, что в базу должен уходить качественный запрос, а не абы что.

Здравствуйте, vdimas, Вы писали:

I>>Это давно известные вещи — как только появился запрос, следующая таска — сделать его быстрее. Вот девелопер добавил присваивание и обвалил перформанс. Как ему объяснить, какого вида код работает хорошо, а какой- плохо ?

V>Никак. Разработчик замерит сам.

Я тут паузу возьму. Не вижу смысла дальше обсуждать.

Здравствуйте, Ikemefula, Вы писали:

V>>

V>>Допустим, у вас всего один сервер базы данных, и он отказывает раз в три года. В это время сайт не работает 20 минут, это приемлемо. Если у вас 64 сервера, то сайт не работает уже раз в три недели. А если у вас 200 серверов, то сайт не работает каждую неделю. Это проблема.

I>А когда ты обвалишь перформанс

Твои представления о том, что в SQL сервере быстро, а что нет, практически полностью противоположны наблюдаемой реальности.
Под нагрузкой последовательность простых запросов из батча получается ГОРАЗДО более дешевая, чем один тяжелый запрос.

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

Проекцию сознания я читаю прямо сейчас.
При чём тут индексы и батчи? Они ортогональны.

I>То есть, индексы все равно остаются. А стало быть эффективный код должен внятно работать с ними. А это значит, что в базу должен уходить качественный запрос, а не абы что.

Define "качественный запрос".

Здравствуйте, vdimas, Вы писали:

V>Твои представления о том, что в SQL сервере быстро, а что нет, практически полностью противоположны наблюдаемой реальности.
Наблюдаемая реальность у всех разная. И зависит от степени кривизны рук.

V>Под нагрузкой последовательность простых запросов из батча получается ГОРАЗДО более дешевая, чем один тяжелый запрос.
Это зависит от того какой собственно запрос и какой ответ.

I>>То есть, индексы все равно остаются. А стало быть эффективный код должен внятно работать с ними. А это значит, что в базу должен уходить качественный запрос, а не абы что.
V>Define "качественный запрос".
1) Выдает нужные данные
2) Использует индексы (не читает данные, которые не нужны)
3) Cardinality estimator делает как можно меньше ошибок

Здравствуйте, gandjustas, Вы писали:

V>>Твои представления о том, что в SQL сервере быстро, а что нет, практически полностью противоположны наблюдаемой реальности.
G>Наблюдаемая реальность у всех разная. И зависит от степени кривизны рук.

Т.е. большинство больших промышленных проектов на РСУБД выполнены кривыми руками?
Это ты так решил обидеть РСУБД, что на нём куда ни ткни — везде криворукость?

V>>Под нагрузкой последовательность простых запросов из батча получается ГОРАЗДО более дешевая, чем один тяжелый запрос.
G>Это зависит от того какой собственно запрос и какой ответ.

Это зависит больше от "под нагрузкой" или ты "один в базу стучишься".
Многие вещи, прекрасно работающие в РСУБД в случае одного клиента, резко перестают работать уже при относительно среднем их трафике.
Сотни запросов в секунду для 99.99% наколенных поделок поверх современных РСУБД считается "хорошей нагрузкой".

А чтобы выйти хотя бы на 10 тыс нетривиальных запросов в сек, требуется уже высокая квалификация и целый комплекс мер по избавлению от плюшек РСУБД — избавляемся от внешних ключей, от лишних проверок на уникальность, от проверок на попадание значений в домен, происходит тотальное уничтожение ЛЮБЫХ триггеров, любых пользовательских ф-ий на стороне РСУБД и т.д. и т.п. до бесконечности.

Кароч, вся эта грозная РСУБД превращается в тыкву.

Отсюда возникает правомерный вопрос — а почему бы сразу не взять тыкву? ))

I>>>То есть, индексы все равно остаются. А стало быть эффективный код должен внятно работать с ними. А это значит, что в базу должен уходить качественный запрос, а не абы что.
V>>Define "качественный запрос".
G>1) Выдает нужные данные
G>2) Использует индексы (не читает данные, которые не нужны)
G>3) Cardinality estimator делает как можно меньше ошибок

Я хотел услышать от коллеги, почему в батчах не могут быть "качественные запросы"?

Здравствуйте, vdimas, Вы писали:

V>Я хотел услышать от коллеги, почему в батчах не могут быть "качественные запросы"?

Я тоже хочу услышать объяснение, каким же чудом появится этот качественный запрос в твоем случае. От тебя никакой конкретики нет, только общие слова "сервер сам поймет", "не твоё дело", "девелопер сам замерит" и тд и тд.

Почему в батчах не будет нормальных запросов — потому, что ты собираешься работать с произвольным кодом, который вообще ничем не ограничен.
В текущей реализации транслируется только небольшое подмножество языка и провайдер работает с высокоуровневыми вещами навроде Select, Where и тд. Благодаря этим ограничениям легко построить модель, которая будет генерить более-менее оптимальный запрос как раз под нужды SQL оптимизатора.

Ты же хочешь позволить все стейтменты, какие угодно, в т.ч. присваивания. То есть, linq провайдер должен теперь стать C#->sql компилятором. Скажем, аналог Select можно написать бесконечным количеством вариаций, все зависит от фантазии разработчика.
На самом деле легко компилировать в императивный код. А вот произвольный императивный скомпилировать в функциональный декларативный — это компилятору не под силу, просто потому, что например без подсказки нельзя вывести тип или нельзя выявить паттерн из за отсутствия ссылочной прозрачности.
Это значит, что шансов, что в базу уйдет нормальный код, совсем нет. В базу в твоей архитектуре будет уходить рукопашная работа с курсорами. То есть, та самая проекция сознания девелопера.

Собтсвенно, ты никак не можешь объяснить, откуда же возьмутся нормальные запросы. Ощущение, что ты уже написал свой собтсвенный идеальный C# компилятор, базу данных и провайдер, которые никому не показываешь

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, gandjustas, Вы писали:

V>>>Твои представления о том, что в SQL сервере быстро, а что нет, практически полностью противоположны наблюдаемой реальности.
G>>Наблюдаемая реальность у всех разная. И зависит от степени кривизны рук.

V>Т.е. большинство больших промышленных проектов на РСУБД выполнены кривыми руками?
V>Это ты так решил обидеть РСУБД, что на нём куда ни ткни — везде криворукость?
А с чего ты обобщать начал? У тебя наблюдаемая реальность отличается от моей, твоя кривизна рук отличается от моей.
Учитывая что я достаточно хорошо разбираюсь в СУБД, для тебя плохие новости.

V>>>Под нагрузкой последовательность простых запросов из батча получается ГОРАЗДО более дешевая, чем один тяжелый запрос.
G>>Это зависит от того какой собственно запрос и какой ответ.
V>Это зависит больше от "под нагрузкой" или ты "один в базу стучишься".
Это не зависит от нагрузки от слова совсем.

V>Многие вещи, прекрасно работающие в РСУБД в случае одного клиента, резко перестают работать уже при относительно среднем их трафике.
Например?

V>Сотни запросов в секунду для 99.99% наколенных поделок поверх современных РСУБД считается "хорошей нагрузкой".

Это смотря каких запросов.

V>А чтобы выйти хотя бы на 10 тыс нетривиальных запросов в сек, требуется уже высокая квалификация и целый комплекс мер по избавлению от плюшек РСУБД — избавляемся от внешних ключей, от лишних проверок на уникальность, от проверок на попадание значений в домен, происходит тотальное уничтожение ЛЮБЫХ триггеров, любых пользовательских ф-ий на стороне РСУБД и т.д. и т.п. до бесконечности.

Прости, но такого отборного бреда давно не слышал.

Здравствуйте, gandjustas, Вы писали:

V>>Т.е. большинство больших промышленных проектов на РСУБД выполнены кривыми руками?
V>>Это ты так решил обидеть РСУБД, что на нём куда ни ткни — везде криворукость?
G>А с чего ты обобщать начал? У тебя наблюдаемая реальность отличается от моей, твоя кривизна рук отличается от моей.

Отличаются в первую очередь сценарии.
С твоей кривизной рук мои сценарии не взлетят даже на стадии макета.

V>>Многие вещи, прекрасно работающие в РСУБД в случае одного клиента, резко перестают работать уже при относительно среднем их трафике.
G>Например?

Например хинты блокировок откуда вообще взялись?

V>>Сотни запросов в секунду для 99.99% наколенных поделок поверх современных РСУБД считается "хорошей нагрузкой".

G>Это смотря каких запросов.

Глубокомысленное замечание.

V>>А чтобы выйти хотя бы на 10 тыс нетривиальных запросов в сек, требуется уже высокая квалификация и целый комплекс мер по избавлению от плюшек РСУБД — избавляемся от внешних ключей, от лишних проверок на уникальность, от проверок на попадание значений в домен, происходит тотальное уничтожение ЛЮБЫХ триггеров, любых пользовательских ф-ий на стороне РСУБД и т.д. и т.п. до бесконечности.
G>

G>Прости, но такого отборного бреда давно не слышал.

На сайтах-магазинах с небольшой нагрузкой и не услышишь.

От:	Sinclair	https://github.com/evilguest/
Дата:	24.07.18 04:14
Оценка:

	От:	vdimas
	Дата:	24.07.18 11:38
	Оценка:

	От:	vdimas
	Дата:	24.07.18 11:45
	Оценка:

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	24.07.18 11:58
Оценка:	+1

	От:	vdimas
	Дата:	24.07.18 12:25
	Оценка:

От:	Serginio1	https://habrahabr.ru/users/serginio1/topics/
Дата:	24.07.18 14:24
Оценка:

От:	gandjustas	http://blog.gandjustas.ru/
Дата:	25.07.18 12:29
Оценка:	+1