Сон Веры ПавловныhVosttВсяко проще чем наколеночные извращения в БД, которые потом ещё как-то придётся поддерживать, а это ад.
Ад/не ад - зависит исключительно от навыка работы с SQL.

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

Конечно, если навыки работы с SQL -- это всё, что есть, то.. лучше выгнать эскюэльщика и взять вменяемого разработчика.

ИзопропилПолагаешь , что без ORM жизни нет?

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

Сон Веры ПавловныАналогия некорректна, поскольку подразумевает одинаковую функциональность с разной реализацией, что в обсуждаемом вопросе далеко не так.

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

SQL используется, но для разработки приложений лучше взять более подходящие инструменты (c#, java, python.....).

Сон Веры ПавловныПеревод гипотетической ситации в крайность для подтверждения своей позиции? А если не всё, что есть, и в равной степени наличествует и навык работы с SQL, и с C#?

Выгнать упоротого эскюэльщика не крайность, а зачастую здравое и мудрое решение. Если наличествнует навык C# и SQL, надо писать приложение на C#, а сложные запросы на SQL. Даже не понял, с чем ты тут не согласен.

Cat2У каждой строки есть свой маркер и база выясняет, имеет ли пользователь что-то делать с помеченной данным маркером строкой.

Сегодня достаточно маркера. А завтра нужно будет учитывать контекст и кучу обстоятельств.

Cat2А вот в этом и заключается профессионализм. Заранее предусмотреть кучу обстоятельств

Я тоже так раньше думал.

Изопропилесли писать на c# это конечно же учитывать не придётся - само всё напишется ))))

У тебя всё будет под рукой, потому что это именно то место, где всё происходит. А база данных это изначально хранилище. Не надо лепить из неё что-то там другое.

ИзопропилhVosttА база данных это изначально хранилище. Не надо лепить из неё что-то там другое.Оракл и Майкрософт до сих пор не в курсе. Вот и пилят кто PL/SQL, кто T-SQL

Авторитетом компаний решил задавить? Тем более PL/SQL и T-SQL уже как бы в самом названии намекает, что это про обработку запросов. Существуют задачи, где надо много и массированно колбасить данные, пережёвывать их много и в большом количестве. Но это слишком узкоспециализированные задачи. Да и внешним программированием они порой всё же эффективней решаются. Если уж говорить о T-SQL, то даже свою агрегатную функцию МС рекомендует писать на .NET-е и приделывать DLL.

andreymxто есть чтобы подсчитать количество активных ОС, я должен их всех затянуть на клиента?

А что, с клиента уже SQL-запросы не делаются?

Изопропилда ты шо

Так я и не понимаю чего вы хотите доказать тут мне. Раскидывать куски логики между БД и приложением? Или вообще пилить приложуху на T-SQL? Я понимаю, что это возможно, но нафиг не упало такой хернёй заниматься.

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

Изопропилвесьма вероятно, что среднее звено в этой задаче - как корове седло.

Надо с чего-то начинать. Не постоянно же «в говне» сидеть.
Если бы я руководствовался логикой «херак-херак» и в продакшен, то вряд ли вырос до уровня текущих проектов. Так бы и занимался низкопрофильным мудизмом до пенсии. Поэтому топикастеру и всем другим желаю только лучшего. Даже если это выглядит непросто.

andreymxили ты про пользовательские агрегатные функции?

Именно.