Есть таблица контрагентов. Нужно, чтобы каждый созданный контрагент мог создавать своих контрагентов. Реализовать хочу 2-мя таблицами: 1 таблица контрагентов(со своими полями и ограничениями уникальности) и 2-я таблица иерархической структуры:
- Инкремент, айдишник родительского контрагента и айдишник его заведеного контрагента. Думаю это правильно.
Заполняться таблицы будут из клиентского приложения, и вывод будет делаться туда же. Вопрос в безопастности на уровне базы данных.
Контрагент будет заходить в программу под своим логином/паролем. Соответственно как сделать, чтобы ни каким ошибочным запросом этот контрагент не смог увидеть не своих созданных контрагентов? Как это можно сделать (логином в базу/схемой или чем-нибудь еще) ?

shelsoftblest Реализовать хочу ...
Простой вопрос о дублях в такой схеме
1) А что будет если есть некая организация ООО "Рога и копыта" которую завел и Контрагент1 и Контрагент2 ? Организация то одна а заведена дважды ?
2) Или конрагент2 является Контрагентом1
....
Вот тут ваши две таблицы не катят И по всей видимости без кросс-таблиц связи вам не обойтись. Что-то типа <контрагент> => <доступные_контрагенты> => <все_конрагенты>

Ну да, как раз об этом щас и думаю. =)
В вашем варианте можете рассказать, что такое доступные_контрагенты?

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

Так, а на уровне хранимых процедур вы имеете ввиду для каждого пользователя создавать свою хранимку и в ней делать нужны выборки/фильтры ну и всякие дополнительные проверки?

Senya_LblestТак, а на уровне хранимых процедур вы имеете ввиду для каждого пользователя создавать свою хранимку и в ней делать нужны выборки/фильтры ну и всякие дополнительные проверки?Озверели?!

Так я ж и прошу объяснить..

Денис Ильинчеловек начал думать в правильном направлении, но немножко не додумал.
хранимая процедура, скажем, будет одна. будут даны пользователю права на её исполнение.
скажем, эта процедура будет возвращать.. ну скажем, она будет возвращать всех подчинённых пользователя.
в момент исполнения хранимой процедуры id пользователя, который её вызвал - известен.
далее есть несколько способов, самый тупой и лобовой - это написать большой оператор switch / case. не лобовой - обратиться к таблице подчинения с headID = (id нашего пользователя)
в общем идея такая - нужные данные (и только те, к которым имеет право доступа!) пользователь получает благодаря своему волшебному userID.
в sql server этот id можно получить с помощью функции suser_id(), аналогичные штуковины есть и на (всех?..) остальных СУБД.

как то так.

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