andreymx,

В приложении. Совершенно однозначно в приложении, без вариантов.

ИзопропилВ трехзвенном?

При чём тут это?

Shocker.Proтогда если ты будешь раздавать права в приложении, самому приложению будут даны полные права
а это - дырка в безопасности

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

Не говори чепухи.

ИзопропилВ трехзвенном?

А, понял про что ты (и Shocker).

Типа приложение на клиенте напрямую лазит в удалённую базу... Я думал такая схема уже давным-давно изжила себя по +100500 причинам. Не считая наивной простоты реализации. Поэтому даже не рассматриваю.

Изопропила что касается вопроса топикстартера - будь у него трёхзвенка - вопроса бы просто не было

На двух-звенке вопрос сам по себе звучит тупо. И не просто тупо. А очень-очень-очень тупо.

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

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

Если у тебя двух-звенка, то твой вопрос вообще риторический. Всю безопасность надо делать на сервере. А что там у тебя, БД, REST-сервис, апликуха -- к чему у тебя клиент ломится -- вот там. На сервере. Если на сервере есть приложение, то в приложении. Если на сервере нет приложения, то... делать срочно это приложение и отказываться от двух-звенки.

andreymxтам есть некая покупная система, а к ней рядом надо чего-то эдакое влепить, которое из коробки не идёт, совершенно сторонне-постороннее и через отдельную БД. Щаз ищу у заказчика какого-то идеолога.
Пока данные загружаем из экселя через ВБА. А надо чтобы каждый сам себе.

Самый простой путь, сделайте WCF-сервис, и дайте клиентам с ним общаться. На стороне сервиса можно что угодно влепить и клиенты об этом не узнают. Всяко проще чем наколеночные извращения в БД, которые потом ещё как-то придётся поддерживать, а это ад.

Сон Веры Павловны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или ты про пользовательские агрегатные функции?

Именно.

Изопропилнет

Вообще-то, это как раз и есть ORM.

skyANAХм, а что тогда не ORM?

то, что под капотом большинства ORM — ADO.NET

Изопропилчто сказать то хотел?

Да вроде уже всё сказал. Я так и не понял к чему ты ORM вообще приплёл.