Здравствуйте, gandjustas, Вы писали:
A>>Я на этот очень правильный подход уже насмотрелся — он хорош в теории и, быть может, в лабе. На практике от него одни проблемы. G>И какие проблемы?
Сложная и слабо контролируемая система прав доступа, в которой практически всегда у кого-то есть права больше, чем должны быть.
G>>>Неверно. Для этого надо включить пользователя в другую группу. A>>Нельзя, он тогда должен быть сразу в двух группах-филиалах. G>В RBS членство в нескольких группах — нормальное явление.
Нет ничего нормального в том, чтобы за счёт введения дополнительных групп пользователей, по группе на операцию, обходить бедность системы прав доступа.
A>>А ты всё никак не приведёшь контрпримеры. А ошибки не мои, это Microsoft Dynamics NAV, например. Часто бывало что операцию запретишь, а её всё равно можно через другое окно сделать. G>Отсуствие тестирования и кривость рук разработчиков теперь будем лечить введением row-level security?
О да, все в дерьме и только ты в белом. Недостаточное тестирование и кривость рук это факторы существующие в любом проекте.
G>Кроме всего прочего RBS позволяет описывать гораздо больше сценариев, чем row-level security. G>Пример Синклера: "Младший менеджер не имеет права отгружать заявку дороже 50000р без подтверждения старшего менеджера" отлично описывается в RBS, и нифига не работает в варианте row-level security.
А и не должен работать, row-level security решает другие задачи.
Здравствуйте, gandjustas, Вы писали:
L>>Расскажи, как мне сделать в EF маппинг полей сущности на xml-колонку. С удовольствие послушаю. G>В ssdl можно указать запрос, который получает для получения сущностей (Defining query кажись).
Значение колонки вряд ли можно отнести к сущностям.
G>Кроме того в MS SQL 2008 есть sparse columns, которые делают тоже самое, но на уровне БД. G>Вообще говоря инкапсуляция на уровне БД гораздо эффективнее и удобнее.
Поднимись выше по ветке и посмотри, по каким причинам понадобилась xml-колонка.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
A>>>Кеш может жить не дольше самого приложения. G>>С чего бы? G>>Вот Янус и почта так работает. A>Может в смысле may, а не can.
И что? Сам придумал сограничения, а тереь сам придумываешь оправдания.
A>>>А чёго это я должен доказывать? Это ты покажи пример где наступает рассогласование. А у меня всё хорошо. G>>Еще раз. Я (и не только) говорю что сохранить согласованность данных между двумя запросами в общем случае можно только используя транзакционные методы (блокировки). G>>Ты так и не смог доказать обратного. Частные случаи, вероятности и отстраненные размышения мало интересуют. A>Ты (и не только) говорите глупость. Нельзя обеспечить актуальность и согласованность. Согласованность обеспечить можно.
Решение в студию
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
A>>>Я на этот очень правильный подход уже насмотрелся — он хорош в теории и, быть может, в лабе. На практике от него одни проблемы. G>>И какие проблемы? A>Сложная и слабо контролируемая система прав доступа, в которой практически всегда у кого-то есть права больше, чем должны быть.
RBS для операций гораздо проще в создании, поддержке и управлении, чем RLS.
Только чтобы сделать RBS правильно думать надо. А вариант с RLS позволяет сказать "у меня все настраивается разрешениями, а дальше е****сь сами".
G>>>>Неверно. Для этого надо включить пользователя в другую группу. A>>>Нельзя, он тогда должен быть сразу в двух группах-филиалах. G>>В RBS членство в нескольких группах — нормальное явление. A>Нет ничего нормального в том, чтобы за счёт введения дополнительных групп пользователей, по группе на операцию, обходить бедность системы прав доступа.
А что значит "дополнительных"? В RBS группы (в смысле роли) создаются как раз для разделения групп разрешений.
A>>>А ты всё никак не приведёшь контрпримеры. А ошибки не мои, это Microsoft Dynamics NAV, например. Часто бывало что операцию запретишь, а её всё равно можно через другое окно сделать. G>>Отсуствие тестирования и кривость рук разработчиков теперь будем лечить введением row-level security? A>О да, все в дерьме и только ты в белом. Недостаточное тестирование и кривость рук это факторы существующие в любом проекте.
И что? Затыкать проблемы разработчиков кривыми архитектурными решениями, пороздая только новые проблемы?
Надо разработчиков учить, а не оберегать ((с) не помню кто)
G>>Кроме всего прочего RBS позволяет описывать гораздо больше сценариев, чем row-level security. G>>Пример Синклера: "Младший менеджер не имеет права отгружать заявку дороже 50000р без подтверждения старшего менеджера" отлично описывается в RBS, и нифига не работает в варианте row-level security. A>А и не должен работать, row-level security решает другие задачи.
Какие? И как решать задачу описанную выше?
Здравствуйте, gandjustas, Вы писали:
A>>>>Кеш может жить не дольше самого приложения. G>>>С чего бы? G>>>Вот Янус и почта так работает. A>>Может в смысле may, а не can. G>И что? Сам придумал сограничения, а тереь сам придумываешь оправдания.
Не говори чушь, нет никаких ограничений, просто ты не удосужился правильно прочитать предыдущее сообщение. Если ты не видишь разницы между фразами "Кеш может жить не дольше приложения" и "Кеш не может жить дольше приложения", то советую подучить русский язык.
A>>>>А чёго это я должен доказывать? Это ты покажи пример где наступает рассогласование. А у меня всё хорошо. G>>>Еще раз. Я (и не только) говорю что сохранить согласованность данных между двумя запросами в общем случае можно только используя транзакционные методы (блокировки). G>>>Ты так и не смог доказать обратного. Частные случаи, вероятности и отстраненные размышения мало интересуют. A>>Ты (и не только) говорите глупость. Нельзя обеспечить актуальность и согласованность. Согласованность обеспечить можно. G>Решение в студию
gandjustas ты сперва заявляешь что локальная реплика это самое простое, что можно сделать, потом просишь меня показать решение. Ты уж как-нибудь определись с тем что ты знаешь, а что нет.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
A>>>>>Кеш может жить не дольше самого приложения. G>>>>С чего бы? G>>>>Вот Янус и почта так работает. A>>>Может в смысле may, а не can. G>>И что? Сам придумал сограничения, а тереь сам придумываешь оправдания.
A>Не говори чушь, нет никаких ограничений, просто ты не удосужился правильно прочитать предыдущее сообщение. Если ты не видишь разницы между фразами "Кеш может жить не дольше приложения" и "Кеш не может жить дольше приложения", то советую подучить русский язык.
Причем тут язык?
Я не вижу причин по которым согласованный слепок данных не может жить дольше приложения.
A>>>>>А чёго это я должен доказывать? Это ты покажи пример где наступает рассогласование. А у меня всё хорошо. G>>>>Еще раз. Я (и не только) говорю что сохранить согласованность данных между двумя запросами в общем случае можно только используя транзакционные методы (блокировки). G>>>>Ты так и не смог доказать обратного. Частные случаи, вероятности и отстраненные размышения мало интересуют. A>>>Ты (и не только) говорите глупость. Нельзя обеспечить актуальность и согласованность. Согласованность обеспечить можно. G>>Решение в студию A>gandjustas ты сперва заявляешь что локальная реплика это самое простое, что можно сделать, потом просишь меня показать решение. Ты уж как-нибудь определись с тем что ты знаешь, а что нет.
Локальная реплика предлагается как решение?
А чтобы получить согласованную реплику её не надо читать в одной транзакции? Может у тебя есть способы магического согласования данных в режиме read uncommited?
Ты путаешь способ получения согласованных данных со способом их использования.
Здравствуйте, gandjustas, Вы писали:
G>RBS для операций гораздо проще в создании, поддержке и управлении, чем RLS. G>Только чтобы сделать RBS правильно думать надо. А вариант с RLS позволяет сказать "у меня все настраивается разрешениями, а дальше е****сь сами".
Это всё только в теории. Практика показывает что управляемыми являются права доступа на элементарные операции над объектами, а не сложные бизнес-процессы.
A>>Нет ничего нормального в том, чтобы за счёт введения дополнительных групп пользователей, по группе на операцию, обходить бедность системы прав доступа. G>А что значит "дополнительных"? В RBS группы (в смысле роли) создаются как раз для разделения групп разрешений.
Да-да-да, это и есть убогость. Подобная ситуация наблюдается в файловой системе старых Линуксов и Юниксов, где невозможно тонко раздать разрешения на объект и в итоге создаётся куча дополнительных групп пользователей, потом появляются всякие sudo, запись в файл через нарошный пайп и прочие извращения. Ты глубоко уверен что говоришь о чём-то прогрессивном, то твоим ошибкам уже лет 30. Сейчас у нас есть seLinux, HP-UX в которые сие исправили, потому что ошибка. Подожду 30 лет пока и ты эволюционируешь.
A>>О да, все в дерьме и только ты в белом. Недостаточное тестирование и кривость рук это факторы существующие в любом проекте. G>И что? Затыкать проблемы разработчиков кривыми архитектурными решениями, пороздая только новые проблемы? G>Надо разработчиков учить, а не оберегать ((с) не помню кто)
О нет, fine grained access rights это как раз правильная архитектура.
G>>>Кроме всего прочего RBS позволяет описывать гораздо больше сценариев, чем row-level security. G>>>Пример Синклера: "Младший менеджер не имеет права отгружать заявку дороже 50000р без подтверждения старшего менеджера" отлично описывается в RBS, и нифига не работает в варианте row-level security. A>>А и не должен работать, row-level security решает другие задачи. G> G>Какие? И как решать задачу описанную выше?
Я в последний раз пытаюсь до тебя донести элементарную истину. Row level security решает задачи доступа не требующие анализа объектов. Это настолько часто встречающаяся задача, что её крайне выгодно выделить в отдельную универсальную подсистему. Есть задачи которые в RLS не укладываются и их надо решать отдельно, но это не значит что универсальная система RLS перестала быть выгодной или раздавать права на объекты стало ошибкой.
Здравствуйте, VladD2, Вы писали: VD>Дык операторы и методы сравнения можно переопределить как надо. Для тех же кортежей в немерле так и сделано.
Операторы биндятся в компайл-тайме на основе статически известного типа аргументов. Поэтому нужно убедиться, что ни в одном из сценариев компилятор не потеряет тип.
VD>Я могу сказать как разработчик (фактический) того же Nemerle. Я не стал возиться с анонимным типами по двум причинам. VD>1. Не хочется вводить в язык неполноценное решение. VD>2. Есть кортежи которые и так позволяют решать проблему и при этом являются полноценным решением. VD>Однако я с удовольствием сделал бы поддержку полноценных анонимных типов а-ка записей если бы их поддерживал CLR.
VD>OK. Тогда поставим вопрос по другому. Ты же не говоришь, что проблема анонимных типов заключается в отсутствии наследования. Тебе не нравится, то что их нельзя возвращать из метода. Так?
Ну да.
VD>Дык надо всего лишь позволить рассматривать два типа как один если у них одинакова структура.
Дык надо понять, что такое "структура". Набор полей? Набор свойств? VD>Пусть будут запрещено наследование. Это не помеха. Тогда останется придумать и реализовать синтаксис для описания анонимного типа.
VD>И главное понять, то этот не имеет никакого отношения к ООП. По этому не стоит рассуждать об инкапсуляции, полиморфизме и прочем (хотя последнее как раз весьма возможно).
Согласен.
VD>Реально толковых ссылок там не так. Много я если тебе действительно интересен вопрос, то я бы все же начал с вопроса в Декларативном программировании. Там есть народ который такие работы вместо газет на за завтраком читал . Ок, посмотрим, как время будет.
VD>А вот это должен скрывать рантайм. Для меня все должно быть прозрачно. Семантика должна быть как у типов-значений, но при этом сами типы могут быть просто не изменяемыми.
Ну да, вот Nullable пришлось специальным образом хардкодить в рантайме, чтобы гарантировать корректные результаты при анбоксинге null и прочие весёлости.
Я nen подумал о том, что для неизменяемых типов нужна специальный Property pattern.
В CLR встроена возможность обозвать пропертью пару методов с сигнатурами void SetXXX(T value), T GetXXX().
Для immutable-типов void SetXXX не подходит. Зато подойдет метод SetXXX, который возвращает новый экземпляр, который отличается от старого только значением свойства.
Ну, и собственно сами проперти должны иметь тот же смысл.
То есть мы пишем как-то так:
var newDate = GetDate().Days += 1;
VD>Это все проверено сто раз в функциональных языках. Даже нехилая теория под это дело подведена.
Ну так в этих языках нет проблемы интероперабельности с CLR.
VD>К тому же в реальных языках такие типы будут скрываться за интерфейсом каких-нить анонимных типов или записей.
Вот это поинтереснее.
VD>Так что на эти типы априори будут наложены более строгие ограничения. Например, для записей операторы сравнения будут генерироваться самим компилятором. Сравнение будет просто по полям (вызов Equals() для каждого члена). Просто соответствия структуры будет достаточно чтобы все работало как надо.
VD>Ну, вот пусть они приведут воркэраунд позволяющий возвращать IQueryble<анонимный тип или список значений>.
VD>Это же действительно бред получается. Люди не могут вынести навороченный составной запрос в отдельную функцию только потому, что авторы языка и дотнета требуют каких-то убедительных довыдов, а совершенно очевидные недоработки попросту игнорируют.
VD>Кстати, интересно о чем они там говорят? Что их интересует? Почему-то подозреваю, что разная мелочевка.
Да, мелочевка — в том числе и поддержка туплов. Но в основном люди страдают ерундой. Например, некоторые C# MVP из Калифорнии искренне полагают, что switch("test") порождает словарь строк при каждом проходе.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, IT, Вы писали: IT>Смотрел, мне семантика == тоже не нравится по тем же причинам — перекладывание большинства проверок на рантайм.
Каких проверок?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Lloyd, Вы писали: L>Меня смущает то, что со временем эта куча превращается в помойку, т.к. никакой внятной схемы именования подобных классов мне придумать не удалось.
Ну, идеально было бы их вообще не именовать.
L>Был бы аналог удобного глобального вывода типов для анонимных классов, было бы удобно. А так приходится созерцать эти унылые CustomerInfo...
Называй класс по имени View.
L>PE = Presentation Entity
L>Удобно, если ID и Name. Но если полей становится больше 2-3-х, то получаем кучу унылого говно-кода.
Откуда взялся говнокод?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, adontz, Вы писали:
A>Я пришёл к выводу, что система безопасности должна обеспечивать ссылочную целостность — я не могу читать объект, который ссылается на объекты, которые я читать не могу.
Это ошибка. Ты не обратил внимание на то, что в большинстве СУБД права на REFERENCE отделены от прав на SELECT?
A>Вот это-то и есть ошибка, котрую я уже много раз видел — права доступа не на объекты, а на операции. Если делать права доступа на операции, то получится код, проверяющий, что касса, кассир и сдающий деньги числятся за одним и тем же филиалом. Это код и это не гибко.
Этот код должен просто быть декларативным. И это гибко.
A>Не гибко, по той простой причине, что если кассу в Телави ограбили, я машины доставки пущу в Тбилиси, благо всего пара часов пути. А чтобы пустить их в Тбилиси мне надо переписывать код проверяющий права доступа.
Зачем переписывать? Если человек не имел права направлять машины в Тбилиси до ограбления, то не должен иметь право и после — может быть, это он и организовал это ограбление. Если кассу в Телави ограбили, то решение должен принимать человек с несколько большими полномочиями, чем региональный менеджер.
A>Если раздавать права доступа на объекты, то кассир из Батуми другие филиалы вообще не видит. Так как проверка прав доступа обеспечивает ссылочную целостность, он не только филиалы другие не видит, он ещё ин е может оформить на них никакие операции, не может просмотреть отчёты по ним и т.п. То есть я указав права доступа всего на один объект, разрулил проблемы с большим количеством операций. Поменять права — дело пяти минут и работа уже для администратора, а не программиста.
Ну, собственно, вывод прав на операции над одними объектами из прав на операции над другими объектами — тоже некоторая бизнес-логика. Просто у тебя вот такой бизнес-случай. У кого-то — другой. Пойми, что RBS покрывает все сценарии, в том числе и RLS. RLS — это просто частный случай, с правилами, вычисляемыми над Discretionary Access Control Lists.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>RBS для операций гораздо проще в создании, поддержке и управлении, чем RLS. G>>Только чтобы сделать RBS правильно думать надо. А вариант с RLS позволяет сказать "у меня все настраивается разрешениями, а дальше е****сь сами". A>Это всё только в теории. Практика показывает что управляемыми являются права доступа на элементарные операции над объектами, а не сложные бизнес-процессы.
Хреновая у тебя практика. RLS требует оперированием разрешениями на кучи объектов. При правильном подходе с RBS разрешений в разы меньше, но они с таким же успехом покрывают все потребности.
A>>>Нет ничего нормального в том, чтобы за счёт введения дополнительных групп пользователей, по группе на операцию, обходить бедность системы прав доступа. G>>А что значит "дополнительных"? В RBS группы (в смысле роли) создаются как раз для разделения групп разрешений.
A>Да-да-да, это и есть убогость. Подобная ситуация наблюдается в файловой системе старых Линуксов и Юниксов, где невозможно тонко раздать разрешения на объект и в итоге создаётся куча дополнительных групп пользователей, потом появляются всякие sudo, запись в файл через нарошный пайп и прочие извращения. Ты глубоко уверен что говоришь о чём-то прогрессивном, то твоим ошибкам уже лет 30. Сейчас у нас есть seLinux, HP-UX в которые сие исправили, потому что ошибка. Подожду 30 лет пока и ты эволюционируешь.
Так и знал что ты скатишься к ФС. Банально.
Посмотри разрешения в Windows — все привелегии раздаются в стиле RBS, а права на доступ к файлам — ACL. Причем при появлении XP именно ACL вызывали наиболшине непоняки и сложности в настройке (а у некоторых до сих пор вызывают).
Но для файлов другого не придумаешь. Если бизнес-системе есть какой-то контент, аналогичный по сути файлам в ФС, то для него имеет смыл RLS с ACL.
Разрешениями на высокоуровневые операции (аналог привелегий в ОС) гораздо удобнее управлять в RBS.
Так что эволюционировать тебе надо.
A>>>О да, все в дерьме и только ты в белом. Недостаточное тестирование и кривость рук это факторы существующие в любом проекте. G>>И что? Затыкать проблемы разработчиков кривыми архитектурными решениями, пороздая только новые проблемы? G>>Надо разработчиков учить, а не оберегать ((с) не помню кто) A>О нет, fine grained access rights это как раз правильная архитектура.
Ага, в переводе на русский звучит "с настройкой прав е****сь сами". Пользователями обычно нету дела до fine grained access rights на такие сущности как "филиал", "покупатель" итп.
G>>>>Кроме всего прочего RBS позволяет описывать гораздо больше сценариев, чем row-level security. G>>>>Пример Синклера: "Младший менеджер не имеет права отгружать заявку дороже 50000р без подтверждения старшего менеджера" отлично описывается в RBS, и нифига не работает в варианте row-level security. A>>>А и не должен работать, row-level security решает другие задачи. G>> G>>Какие? И как решать задачу описанную выше?
A>Я в последний раз пытаюсь до тебя донести элементарную истину. Row level security решает задачи доступа не требующие анализа объектов. Это настолько часто встречающаяся задача, что её крайне выгодно выделить в отдельную универсальную подсистему. Есть задачи которые в RLS не укладываются и их надо решать отдельно, но это не значит что универсальная система RLS перестала быть выгодной или раздавать права на объекты стало ошибкой.
Ага, есть RLS — давайте куда-нить приткнем, отличная логика.
Если пользоваться принципом KISS и YAGNI, то надобность в RLS возникает очень редко.
Кстати, как у тебя решается вопрос с павами доступа при таком требовании "Младший менеджер не имеет права отгружать заявку дороже 50000р без подтверждения старшего менеджера"?
A>Это очень просто. Пусть есть 4 сущности: A, B, C, D. Пусть они ссылаются друг на друга следующим образом A->B, A->C, D->A, D->B. Одним из указанных мною подмножеств будет (A, B, C). Хотя D и ссылается на сущности A и B, важно что A, B и C не ссылаются на D. Теперь, если добавить сущность E и ссылки E->A, E->C, то на (A, B, C) это никак не отразится и (A, B, C) останется ссылочно-целостным подмножеством сущностей.
А если добавить сущность E и ссылку A->E?
S>>1. Этих записей значительно, на порядки, меньше общего количества записей.
A>Теоретически для всех возможных задач такого доказать, конечно же, нельзя. А вот исходя из практики, моего опыта, да, так и есть.
Ок, поехали дальше. S>>2. Обеспечение актуальности кэша именно этих записей обеспечивает ссылочную целостность всей БД
A>Обеспечение ссылочной целостности этого кеша обеспечивает корреткность операций.
Ты не юли, ты доказывай. Мне вот, к примеру, очевидно, что в твоей системе за нефиг делать можно нарушить ссылочную целостность "большой" базы. A>Не допустимость, а корректность.
Определение корректности в студию. A>Для большинства операций нет необходимости иметь последние, потому что для большинства операций необходимые данные в кеше не меняются. Как часто, например, меняется список филиалов, клиентов, товаров? Так ли необходимо иметь актуальную версию списка при оформлении каждой операции, а следовательно перед каждой операцией проверять обновления?
A>В некоторых случаях актуальность важна. Например, прежде чем оформлять заказ на клиента, надо проверить что клиент не заблокирован за долги. Эту логику надо размещать на сервере. Но заметь, запрет на действие никак не связан с актуальностью кеша на клиенте. Если у оператора открылось окно оформления заказа, потому что клиент в кеше не заблокирован, но не оформился заказ, потому что клиент заблокирован в центральной БД, никакой катастрофы в этом, по большому счёту нет. Главное, выдать вменяемое сообщение, почему так произошло.
Ок, и каким образом твой кэш учитывает тот факт, что есть разные требования к актуальности данных? Ты вот приводил "катастрофический" пример про некорректность статистики по городам. Это что, так ужасно — думать, что в Тбилиси 102 клиента, а не 103?
A>Более того, есть мобильные торговые агенты. Человек берёт в руки покет, изредка ноутбук, и ездит по клиентам. "Ловит" не везде. Заказ, на уже заблокированного клиента может быть успешно сохранён в кеш, а загрузка его в центральную БД, и отказ в оформлении, произойдёт только вечером. Тут тоже нет никакой катастрофы. Если данный кеш ссылочно-целостный, то у меня не самая последняя версия БД, но достаточная для работы. Это значит, что просматривая объекты кеша и переходя по ссылкам мне не потребуется что-то запрашивать с сервера.
Определение "работы" в студию.
S>>3. Обеспечение актуальности кэша именно этих записей менее затратно, чем обеспечение актуальности кэша результатов конкретных запросов. A>По трафику и количеству запросов, без сомнения.
Доказательство в студию.
A>А вот актуальность я не обещал. Без push со стороны сервера это не реально.
Всё реально. Главное — понять, что такое "актуальность".
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, adontz, Вы писали: A>Я в последний раз пытаюсь до тебя донести элементарную истину. Row level security решает задачи доступа не требующие анализа объектов. Это настолько часто встречающаяся задача, что её крайне выгодно выделить в отдельную универсальную подсистему. Есть задачи которые в RLS не укладываются и их надо решать отдельно, но это не значит что универсальная система RLS перестала быть выгодной или раздавать права на объекты стало ошибкой.
Рома, ты бы сам почитал про историю пермиссий. Тебя не удивляет то, что в DACL NTFS есть черты предикатной системы, к примеру пермиссии на CREATOR_OWNER? Или, к примеру, что применили наследование DACL? Это как раз потому, что система RLS перестала быть выгодной.
В большинстве промышленных инсталляций серъёзных продуктов никто не заморачивается fine-grained security control. Вместо этого разрабатывается конкретная схема, т.е. как раз правила раздачи прав. И делается автоматика, которая наруливает эти права ровно одним, утверждённым образом. Делаются скрипты, которые "чинят" DACLы после вмешательств админов "в связи с ограблением кассы в Телави". Задачи-то все укладываются, RLS позволяет нарулить всё, что угодно. Вот только стоимость администрирования начинает в интересных случаях превышать разумные пределы.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, IT, Вы писали: IT>>Смотрел, мне семантика == тоже не нравится по тем же причинам — перекладывание большинства проверок на рантайм. S>Каких проверок?
В варианте
...Update(p => new Person { ID = 1, FirstName = "Tester", LastName = "Testerson" })
нечего лишнего не напишешь. Компилятор всё проверит и далее прямая трансляция в SQL в самом лучшем виде. Единственный косяк, который может быть, это вместо класса Person анонимный тип или ещё какая неуставная хрень.
Любой другой вариант либо дополнительная писанина, либо проверяется только в рантайм, либо и то и другое.
IT>...Update(p => new Person { ID = 1, FirstName = "Tester", LastName = "Testerson" })
IT>
IT>нечего лишнего не напишешь. Компилятор всё проверит и далее прямая трансляция в SQL в самом лучшем виде. Единственный косяк, который может быть, это вместо класса Person анонимный тип или ещё какая неуставная хрень.
Именно. А теперь приведи мне в этом стиле пример с Delayed и Discount, а то я што-то не проникся способом оставить другие свойства ордера в неизменности.
IT>Любой другой вариант либо дополнительная писанина, либо проверяется только в рантайм, либо и то и другое. IT>
IT>Здесь нужно писать дополнительные неочевидные методы. Нафиг такое счастье?
Ну, я бы ожидал от взрослого языка или макрогенератора наличия этих методов забесплатно. Чё там, если уж мечтать так мечтать, не так ли?
IT>
IT>...Update(c, d => d.City == originalCity, d => d.ComputedColumn);
IT>
IT>Здесь можно такого понаписать, что потом будешь долго соображать почему у тебя в рантайме выкидыши.
Ну, здесь всё действительно похуже.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
A>>Это очень просто. Пусть есть 4 сущности: A, B, C, D. Пусть они ссылаются друг на друга следующим образом A->B, A->C, D->A, D->B. Одним из указанных мною подмножеств будет (A, B, C). Хотя D и ссылается на сущности A и B, важно что A, B и C не ссылаются на D. Теперь, если добавить сущность E и ссылки E->A, E->C, то на (A, B, C) это никак не отразится и (A, B, C) останется ссылочно-целостным подмножеством сущностей. S>А если добавить сущность E и ссылку A->E?
Тогда подмножество (A, B, C) придётся увеличить как минимум на E.
S>>>2. Обеспечение актуальности кэша именно этих записей обеспечивает ссылочную целостность всей БД A>>Обеспечение ссылочной целостности этого кеша обеспечивает корреткность операций. S>Ты не юли, ты доказывай. Мне вот, к примеру, очевидно, что в твоей системе за нефиг делать можно нарушить ссылочную целостность "большой" базы.
Ну покажи пример
A>>Не допустимость, а корректность. S>Определение корректности в студию.
Я имел ввиду, что, на стороне клиента можно будет проверить все желаемые условия, в том числе довольно сложные и они правильно посчитаются. Например, правильно рассчитается *ожидаемая* скидка. Конечно можно при желании обновлять кеш, но делать это при каждом запросе необходимости нет никакой.
Надо заметить, что вне зависимости от подхода, если есть желание работать только с актуальными данными, то придётся помучаться. Можно обновление исходных данных и оформления заказа совершать в транзакции. Впрочем это плохо, потому что данное решение крайне плохо масштабируется. Так же, при операции клиент может передавать версию данных, на основе которых операция оформляется, а сервер отказывать в оформлении, если исходные данные устарели. На практике это очень хорошее решение. Очень хорошее оно в первую очередь потому, что деление данных в программе достаточно хорошо соответствует распределению обязанностей между персоналом. Скажем, клиенты распределены по торговым агентам (одному и тому же клиенту два агента с одинаковым ассортиментом не продают). Как следствие, кеш клиентского ПО торгового агента в штатном режиме работе, фактически, обновлять нет необходимости вообще, так как его меняет только сам торговый агент, совершая продажи. Бывают исключения, например корректировка остатка склада, но их можно обрабатывать обнулением кеша. Из практики, корректировка остатсков происходит раз в неделю, а операций продажи до ста в сутки. Соответственно, кеш себя абсолютно оправдывает.
A>>В некоторых случаях актуальность важна. Например, прежде чем оформлять заказ на клиента, надо проверить что клиент не заблокирован за долги. Эту логику надо размещать на сервере. Но заметь, запрет на действие никак не связан с актуальностью кеша на клиенте. Если у оператора открылось окно оформления заказа, потому что клиент в кеше не заблокирован, но не оформился заказ, потому что клиент заблокирован в центральной БД, никакой катастрофы в этом, по большому счёту нет. Главное, выдать вменяемое сообщение, почему так произошло. S>Ок, и каким образом твой кэш учитывает тот факт, что есть разные требования к актуальности данных? Ты вот приводил "катастрофический" пример про некорректность статистики по городам. Это что, так ужасно — думать, что в Тбилиси 102 клиента, а не 103?
Я показал природу проблемы. Неправильно считаться может всё что угодно. Самый простой пример — скидки, бонусы. При желании можно придумать ещё, у нас же не соревнование в богатстве фантазии.
A>>Более того, есть мобильные торговые агенты. Человек берёт в руки покет, изредка ноутбук, и ездит по клиентам. "Ловит" не везде. Заказ, на уже заблокированного клиента может быть успешно сохранён в кеш, а загрузка его в центральную БД, и отказ в оформлении, произойдёт только вечером. Тут тоже нет никакой катастрофы. Если данный кеш ссылочно-целостный, то у меня не самая последняя версия БД, но достаточная для работы. Это значит, что просматривая объекты кеша и переходя по ссылкам мне не потребуется что-то запрашивать с сервера. S>Определение "работы" в студию.
Берёт новые заказы, просматривает старые заказы (не старше месяца), считает прибыль и остаток мобильного склада (если есть мобильный склад).
S>>>3. Обеспечение актуальности кэша именно этих записей менее затратно, чем обеспечение актуальности кэша результатов конкретных запросов. A>>По трафику и количеству запросов, без сомнения. S>Доказательство в студию.
Антон, а что тут доказывать? И сам объём данных меньше, потому что нет дублирования, и необходимость в обновлении меньше.
A>>А вот актуальность я не обещал. Без push со стороны сервера это не реально. S>Всё реально. Главное — понять, что такое "актуальность".
Я думал, ты под актуальностью понимаешь синхронность с версией в центральной БД.
Здравствуйте, Sinclair, Вы писали:
S>Рома, ты бы сам почитал про историю пермиссий. Тебя не удивляет то, что в DACL NTFS есть черты предикатной системы, к примеру пермиссии на CREATOR_OWNER? Или, к примеру, что применили наследование DACL? Это как раз потому, что система RLS перестала быть выгодной.
Учитывая что row level security применили к дереву, опциональное наследование как раз очень органично выглядит.
CREATOR_OWNER это вообще сделано для совместимости со всякими Юниксами. Есть ещё CREATOR_GROUP, есть "главная" группа у доменных пользователей. Самому Windows права доступа на псевдоним CREATOR_OWNER не нужны, вполне подошёл бы механизм привелегий.
S>В большинстве промышленных инсталляций серъёзных продуктов никто не заморачивается fine-grained security control. Вместо этого разрабатывается конкретная схема, т.е. как раз правила раздачи прав. И делается автоматика, которая наруливает эти права ровно одним, утверждённым образом. Делаются скрипты, которые "чинят" DACLы после вмешательств админов "в связи с ограблением кассы в Телави". Задачи-то все укладываются, RLS позволяет нарулить всё, что угодно. Вот только стоимость администрирования начинает в интересных случаях превышать разумные пределы.
Ой, да ладно. Вот так всё плохо и никто не придумал ничего существенно лучше?
Здравствуйте, adontz, Вы писали: A>Тогда подмножество (A, B, C) придётся увеличить как минимум на E.
Тогда непонятно, зачем вообще обсуждать "добавление не расширяет".
A>Ну покажи пример
Очень просто. Вот у тебя были сущности A->B->C<-D.
Клиент запросил A, ты закачал A->B->C. Теперь клиент удалил C, убрав в B ccылку. Всё в порядке — у него ссылок на C больше нет, ссылочная целостность не нарушена. При коммите выяснится, что упс — есть еще D, про которого твой клиент ничего не знает.
A>Я имел ввиду, что, на стороне клиента можно будет проверить все желаемые условия, в том числе довольно сложные и они правильно посчитаются. Например, правильно рассчитается *ожидаемая* скидка. Конечно можно при желании обновлять кеш, но делать это при каждом запросе необходимости нет никакой.
Не очень понятно, что такое "правильно". Если объект, на основе которого скидка рассчитывается, изменился, то ничего правильного не получится.
A>Надо заметить, что вне зависимости от подхода, если есть желание работать только с актуальными данными, то придётся помучаться.
A>Можно обновление исходных данных и оформления заказа совершать в транзакции. Впрочем это плохо, потому что данное решение крайне плохо масштабируется. Так же, при операции клиент может передавать версию данных, на основе которых операция оформляется, а сервер отказывать в оформлении, если исходные данные устарели. На практике это очень хорошее решение. Очень хорошее оно в первую очередь потому, что деление данных в программе достаточно хорошо соответствует распределению обязанностей между персоналом. Скажем, клиенты распределены по торговым агентам (одному и тому же клиенту два агента с одинаковым ассортиментом не продают). Как следствие, кеш клиентского ПО торгового агента в штатном режиме работе, фактически, обновлять нет необходимости вообще, так как его меняет только сам торговый агент, совершая продажи. Бывают исключения, например корректировка остатка склада, но их можно обрабатывать обнулением кеша. Из практики, корректировка остатсков происходит раз в неделю, а операций продажи до ста в сутки. Соответственно, кеш себя абсолютно оправдывает. Я по прежнему жду доказательства того, что именно такой кэш себя оправдывает. По сравнению с более другими стратегиями кэширования.
A>Я показал природу проблемы. Неправильно считаться может всё что угодно. Самый простой пример — скидки, бонусы. При желании можно придумать ещё, у нас же не соревнование в богатстве фантазии.
Нет, у нас точная наука. Пока что ты оперируешь соображениями уровня "палец к носу". Ни понятия корректности, ни допустимости ты определить не хочешь. Никаких внятных утверждений доказывать не собираешься. И даже пример проблемы привести не можешь. О чём мы вообще говорим?
A>Берёт новые заказы, просматривает старые заказы (не старше месяца), считает прибыль и остаток мобильного склада (если есть мобильный склад).
Угу. Твой кэш заточен на то, чтобы ровно эти операции не требовали обращения к серверу, так?
A>Антон, а что тут доказывать? И сам объём данных меньше, потому что нет дублирования, и необходимость в обновлении меньше.
Здрасте, приехали. С чего объем данных-то меньше? В твоём примере было про A->B->C, и про D->E. Неужели же это будет меньше, чем только A и D? Ну давай, докажи.
A>Я думал, ты под актуальностью понимаешь синхронность с версией в центральной БД.
Это без транзакционности, естественно, невозможно гарантировать вообще никак.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
.
Если нам не помогут, то мы тоже никого не пощадим.
