1

Хорошо, так вот это «в двух словах», что я пытаюсь выполнить ...Пользователи должны создавать динамические правила, которые применяются к другим пользователям доступ к группе

Пользователи моего приложения может пойти и создать новая группа. Они могут указывать критерии для других пользователей, которые они разрешают/запрещают определять, кому разрешено вступать в группу.

Пример: Возраст: 12 - 16 лет старых Рост: 5 - 6 футов

В таблице данных, который хранит правила будет, как: Разрешить или Запретить Флаг (Y/N) AgeStart: 12 AgeEnd: 16 HeightStart: 5 HeightEnd: 6

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

Имеет ли это смысл? Также могут быть правила ИСКЛЮЧЕНИЯ, которые идут против этого ... , например, первый «Разрешить: Y» может быть в возрасте от 12 до 30, но может быть добавлена ​​вторая запись в возрасте от 25 до 28, поэтому пользователю придется встречаться с обоими критерии для входа.

Любые покупатели на этом?

+0

звучит тривиально - в чем проблема? –

ответ

0

Да, вы можете хранить правила в своей базе данных, используя любой вид DSL, имеет смысл для вас, но SQL не является решением для интерпретации или обеспечения соблюдения правил.

Будет гораздо проще получить поле правил в вашем приложении и интерпретировать его там. У вас будет доступ к полнофункциональным библиотекам парсеров для интерпретации правила и более простым способом написания кода OO для его применения.

Поскольку вам нужно всего лишь запустить правило, когда пользователь пытается присоединиться к группе, это не должно быть большой стоимостью для выполнения запроса, чтобы получить определение правила. Это, безусловно, будет много меньше дорого, чем пытаться реализовать синтаксический анализатор правил и принудительный контроль в SQL!

Другой способ задумываться об этом: база данных хранит данные, а не код. Вы можете реализовать это, сохранив определение правил как строки в базе данных, но позвольте базе данных рассматривать их как стенографические строки, а не пытаться интегрировать их как код, который может выполнять РСУБД.

+0

Я не согласен. До тех пор, пока вы хотите иметь доступ к базе данных из нескольких приложений, вы * определенно * хотите, чтобы база данных содержала * всю логику *, необходимую для обеспечения соответствия соответствующих контрактов приложениям. Еще один способ взглянуть на это: ** базы данных должны инкапсулировать необработанные данные и предоставлять интерфейсы к этим данным, будь то через представления, хранимые процедуры или другие методы. ** –

+0

@ChrisTravers, вы внедрили собственный бизнес-логический парсер DSL в TSQL? Я утверждаю, что это будет проще реализовать в библиотеке, которая используется каждым из ваших многочисленных приложений. –

+0

Зачем вам это делать в TSQL? Сделайте это в .net как функцию, которую функции TSQL могут вызывать внутри бэкэнда SQL Server. Таким образом, вы можете получить доступ к одному и тому же коду от клиента. Net, клиента Linux/Perl и тому подобного. –

1

Большое спасибо за ответ! Однако прошлой ночью или ночью перед тем, как я нашел эту статью: http://msdn.microsoft.com/en-us/library/aa964135%28SQL.90%29.aspx

Это позволило решить наши проблемы. 1 Теперь запрос в хранимой процедуре может точно указать, какие элементы имеют право.

-Josh

Смежные вопросы