2011-01-29 3 views
2

Мне интересно, можно ли получить реальное имя таблиц/полей, из которых исходит каждое поле в выражении выбора.Как получить информацию о инструкции SQL Select

Допустим, у вас есть две таблицы, кредиторы и дебиторы имеют поля Код, имя и телефон.

Если пользователь вводит следующую инструкцию SQL:

SELECT Code AS CustomerCode, Name AS CustomerName, Phone AS ContactNumber FROM Debtors. 

Это приведет к SQL сервер возвращает имена полей CustomerCode, CUSTOMERNAME и ContactNumber.

Можно ли получить с SQL-сервера какие-то метаданные, которые сопоставляют каждое поле с его реальным именем и таблицей?

Программно, учитывая инструкцию SQL select, я хочу иметь возможность определять реальное имя каждого поля и настоящее имя таблиц, из которых они происходят.

Я не хочу самостоятельно анализировать SQL, поэтому я подумал, что может быть отправлено сообщение на сервер sql и вернуть эту информацию без данных строки.

Что мы пытаемся сделать, это реализовать безопасность на уровне таблиц и полей. Пользователь может ввести оператор sql для выбора полей из таблицы или нескольких таблиц (с использованием объединений) и отображения результатов в таблице. Поля динамически добавляются к элементу управления сеткой, но только те, которые пользователю разрешено видеть.

Если пользователь присоединяется к нескольким таблицам, как мы знаем программно, какие поля приходят из какой таблицы? проблема ухудшается, если они используют псевдонимы в SQL.

В настоящее время это работает над старым встроенным движком sql (который использует проприетарную базу данных), который может вернуть всю необходимую информацию таблицы/поля без данных строки, поэтому часть модели безопасности приложений построена вокруг этого. Однако перемещение этого приложения на нечто вроде SQL-сервера может оказаться затруднительным, если мы не сможем заставить это работать.

Помимо сервера Sql, любые другие базы данных sql поддерживают этот тип функциональности?

+0

Это сложно сделать в общем, потому что столбцы набора результатов не всегда отображаются непосредственно в столбцы таблицы.(на самом деле их часто нет). У вас может быть столбец результатов, который представляет собой сумму значений в строках в таблице A и таблице B. Или у вас может быть таблица, данные которой используются для соединения, которое не показано в наборе результатов. – payne

ответ

2

Насколько я знаю, вы не можете получить эту информацию.

Возможно, вы справитесь со своей проблемой во многих базах данных, используя защиту GRANT/REVOKE в самой базе данных. Предполагая, что пользователи регистрируются в самой базе данных (а не только в вашем приложении), многие СУБД позволяют вам использовать привилегии GRANT SELECT для ограниченных столбцов из таблицы. Используя этот метод, он не обманет сервер, если пользователь указывает ALIASes для столбцов.

Быстрый google указывает, что по крайней мере PostgreSQL, SQL Server и Oracle предлагают защиту GRANT SELECT на уровне столбцов на основе идентификатора пользователя.

Интересный вопрос, кстати.

+0

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

+0

Мне тоже, но, по-видимому, OP действительно нужно это сделать и, по-видимому, уже делает это в коде приложения. Если он может переместить его на уровень базы данных, я не могу себе представить, что будет поддерживать любой _harder_ (он может переназначить существующий интерфейс управления для использования GRANT и REVOKE). Если он _really_ должен это сделать, большинство баз данных уже справятся с этим. –

+0

Использование гранта/отзыва звучит так, как нам нужно, спасибо за это. Еще одна проблема заключается в том, что пользователь может написать запрос, а затем развернуться по возвращенным результатам. Например, пользователь записывает запрос на выбор счетов из таблицы счетов (номер счета-фактуры, дата счета, имя клиента, общий брутто, общий налог). Если вы затем дважды щелкните по строке, которую приложение просматривает в первом столбце, и выясняет, что этот столбец пришел из таблицы счетов. –

1

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

Способом решения проблемы является удаление всего доступа из таблиц и предоставление доступа только через представления с соответствующими разрешениями доступа.

+0

Это не говорит о том, что у нас есть зернистость, которую запрашивает OP. –

+0

Разрешения столбцов действительно возможны в MS SQL 2k8; но управлять ими можно, скажем так, интересно. –

+0

также примечание: DENY на уровне таблицы не имеет приоритета над GRANT уровня столбца. Эта несогласованность в иерархии разрешений была сохранена для обратной совместимости. http://msdn.microsoft.com/en-us/library/ms188371.aspx –

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