Респект автору за такле, ведь OLE это же небезопасно, может утекать память, стабильность сервера под вопросом. Также включать функционал для выполнения таких нестандартных функций это значит поощрять ичпользование sql server не по назначению.
лучше уж оффлоадить такие задачи на SSRS/SSIS, а не хардкодить простыню кода которую никто не разберет потом
расскажите как делают современную геологоразведку золота с помощью карт и анализа и делают ли вообще? хочется узнать как визуализируют рудное тело в 3Д
тест логики процедур делается простыми скриптами sql, но там тяжело что-то зафакапить т.к. один человек отвечает за базу и работаешь уже в терминах бизнес логики (пользователь это запись в dbo.Users, например)
от кода в с# требуется чтобы просто умел обрабатывать http и вызывал правильную хранимую процедуру и с правильными аргументами, т.е. все очень примитивно и трудно зафакапить
а как сообщество шарперов относится к ситуации когда и контролер и сервис являются врапперами и для бизнес логики вызывают хранимые процедуры, которые и содержат всю бизнес логику?
я так и делаю, например, хотя мои проекты небольшие, не хайлоад, но данных много
зависит от системы, forcepoint например блокирует/перехватывает запись на все переносные носители, принтеры, отправку по сети и добавляет метаданные в сам файл, если он openoffice, а также сканирует содержимое регулярками на предмет наличия секретных данных.
если воруете цифровые документы с работы, возможно система предотвращения утечки информации добавляет NTFS поток/метаданные в файл которые вас потом идентифицируют
а можно перечислить продукты или хотя бы вендоров? чтоб если какая-то компания тоже захочет такие же контроли у себя поставить?
Знаем про Cisco IronPort, хотелось бы узнать какие еще альтернативы или дополнительные средства существуют на рынке. Спасибо
модели разграничения доступа бывают разные. Access Control List (ACL) — это когда ручками прописывается кто имеет доступ и на что (см. файловая система в *nix)
более эффективной практикой считается разграничение по ролям RBAC — но тут надо предусмотреть разделение обязанности на разные роли (segregation of duties), например чтобы создавая запись об объекте, он не имел дальнейшего доступа к его функциям, чтобы потенциально не смог злоупотребить.
Например если админ создал учетку юзера, то он не знает пароль к учетке и не может под ней залогиниться. Только отправить ссылку со сбросом пароля на почту юзеру. Также не может удалить запись аудита своих действий (логи о создании учетки и сбросе пароля например)
более продвинутым является ABAC — это расширение RBAC, только используются любые атрибуты, а не только роли. Если вам надоело создавать список ролей и поддерживать отношения субъект->роли и объект->роль->доступ то можете заменить «роль» на аттрибуты и это больше похоже станет на разграничение доступа по бизнес-правилам
почти любой код почти всегда является копированием, т.к. скорее всего описан где-то в документации. Наример вызовите любой метод из майкрософтовской библиотеки, и скорее всего вы копируете из MSDN
какая-то очень сложная система для отбора матросов из кодинг-буткемпов. Самое важное, чтобы они могли копипастить код из стековерфлоу и закрывать тикеты, чтобы галера могла подороже продавать трудочасы.
Чем больше таких людей и чем меньше они просят денег/чем дольше сидят на ровном месте — тем больше прибыли для компании, вот что важно руководству
вы правы, в любом бизнесе есть норма прибыльности. В таких сферах как недвижимость, где цена — это продукт торговли и переговоров и цена высокая, маржа тоже высокая.
Можно спокойно сидеть на попе и заплатить эту маржу бизнесу и получить услугу, а можно побегать, пошустрить по базам и забрать эту маржу себе
присутствуют, но в виде уродливых темплейтов или менее уродливых дженериков.
проблема которую я вижу — в статической типизации — нужно перекомпилировать программу, или активно использовать рефлексию, чтобы добиться чтобы один метод работал с разными типами. А рефлексия это по сути и есть динамическая типизация. Ну и много кода получается, да.
в динамических языках не надо изменять код, там все это встроено. Код проглотит любой тип которые ему дали. Неважно строка вам прилетела, или число, если вы в итоге после всех проверок засовываете это в базу — он просто возьмет и запишет переменную. Что конечно не отменяет что нужн проверять данные на соответствие, но я могу эту задачу переложить на базу данных, если захочу.
просто пример, если мы говорим про примитивные структуры данных типа string, float, int то они не гарантируют корректность бизнес логики. Нужно еще поверх типизации, например кастования к int еще и проверять на корректный диапазон значений (чтобы не было отрицательного кол-ва товаров в корзине например).
Это можно делать как своими классами, так и простыми if/else, но ведь if/else это же не типизация?
динамические языки тем и сильны, что помимо системы типов есть другие вещи которые гарантируют корректность структур данных, например те же регулярные выражения — позволяют выразить сложную грамматику на уровне текстов, которая посложнее чем просто приведение к string.
Мне кажется типизация это не панацея, нужна культура кодинга где все данные проверяются на корректность максимально строго — именно это и дает в итоге правильно и безопасно работающие программы
Респект автору за такле, ведь OLE это же небезопасно, может утекать память, стабильность сервера под вопросом. Также включать функционал для выполнения таких нестандартных функций это значит поощрять ичпользование sql server не по назначению.
лучше уж оффлоадить такие задачи на SSRS/SSIS, а не хардкодить простыню кода которую никто не разберет потом
возможно глупый вопрос, а зачем писать обобщенный isdivisibleBy, если в итоге для вычисления используется стандартный оператор %?
Если у вас есть MS SQL, лучше использовать SSIS он как раз для этих вещей и был создан.
храним модель базы в .DAC файле, которая сама делает миграции базы в ci/cd без потери данных.
https://docs.microsoft.com/en-us/sql/relational-databases/data-tier-applications/data-tier-applications?view=sql-server-ver15
тест логики процедур делается простыми скриптами sql, но там тяжело что-то зафакапить т.к. один человек отвечает за базу и работаешь уже в терминах бизнес логики (пользователь это запись в dbo.Users, например)
от кода в с# требуется чтобы просто умел обрабатывать http и вызывал правильную хранимую процедуру и с правильными аргументами, т.е. все очень примитивно и трудно зафакапить
а как сообщество шарперов относится к ситуации когда и контролер и сервис являются врапперами и для бизнес логики вызывают хранимые процедуры, которые и содержат всю бизнес логику?
я так и делаю, например, хотя мои проекты небольшие, не хайлоад, но данных много
что только не придумают питонисты, лишь бы не использовать SQL. Боюсь меня заминусуют, но ведь эти все задачи решаются простейшим SQL?
матричный принтер! (аж ностальгия нахлынула)
Знаем про Cisco IronPort, хотелось бы узнать какие еще альтернативы или дополнительные средства существуют на рынке. Спасибо
Access Control List (ACL) — это когда ручками прописывается кто имеет доступ и на что (см. файловая система в *nix)
более эффективной практикой считается разграничение по ролям RBAC — но тут надо предусмотреть разделение обязанности на разные роли (segregation of duties), например чтобы создавая запись об объекте, он не имел дальнейшего доступа к его функциям, чтобы потенциально не смог злоупотребить.
Например если админ создал учетку юзера, то он не знает пароль к учетке и не может под ней залогиниться. Только отправить ссылку со сбросом пароля на почту юзеру. Также не может удалить запись аудита своих действий (логи о создании учетки и сбросе пароля например)
более продвинутым является ABAC — это расширение RBAC, только используются любые атрибуты, а не только роли. Если вам надоело создавать список ролей и поддерживать отношения субъект->роли и объект->роль->доступ то можете заменить «роль» на аттрибуты и это больше похоже станет на разграничение доступа по бизнес-правилам
почти любой код почти всегда является копированием, т.к. скорее всего описан где-то в документации. Наример вызовите любой метод из майкрософтовской библиотеки, и скорее всего вы копируете из MSDN
какая-то очень сложная система для отбора матросов из кодинг-буткемпов. Самое важное, чтобы они могли копипастить код из стековерфлоу и закрывать тикеты, чтобы галера могла подороже продавать трудочасы.
Чем больше таких людей и чем меньше они просят денег/чем дольше сидят на ровном месте — тем больше прибыли для компании, вот что важно руководству
Можно спокойно сидеть на попе и заплатить эту маржу бизнесу и получить услугу, а можно побегать, пошустрить по базам и забрать эту маржу себе
проблема которую я вижу — в статической типизации — нужно перекомпилировать программу, или активно использовать рефлексию, чтобы добиться чтобы один метод работал с разными типами. А рефлексия это по сути и есть динамическая типизация. Ну и много кода получается, да.
в динамических языках не надо изменять код, там все это встроено. Код проглотит любой тип которые ему дали. Неважно строка вам прилетела, или число, если вы в итоге после всех проверок засовываете это в базу — он просто возьмет и запишет переменную. Что конечно не отменяет что нужн проверять данные на соответствие, но я могу эту задачу переложить на базу данных, если захочу.
Это можно делать как своими классами, так и простыми if/else, но ведь if/else это же не типизация?
динамические языки тем и сильны, что помимо системы типов есть другие вещи которые гарантируют корректность структур данных, например те же регулярные выражения — позволяют выразить сложную грамматику на уровне текстов, которая посложнее чем просто приведение к string.
Мне кажется типизация это не панацея, нужна культура кодинга где все данные проверяются на корректность максимально строго — именно это и дает в итоге правильно и безопасно работающие программы