dma_caviarА что означает Гость, какие-то особенности в доступе? Не роль ли это?)
Конечно роль, я не об этом. Сначала как их дифференцируйте? По той причине что не нашли в memberships логина мы не можем говорит что он "просто сотрудник",а не гость. Как узнать что он гость?

Я так представляю:
1.подсоединяюсь к БД,
2.запросом в DBLookupCombobox выбираю сотрудника и в таблице memberships ищу его роли
3.если у него роли несколько выбираю нужный роль
4. отсоединяюсь от бд и подсоединяюсь с этой ролью

А если гость, тогда включить на форме checkbox и прямо с ролью guest подключиться к бд, минуя вышесказанные этапы 1-4?
Вы как поступаете в случае guest?

dma_caviarЕсли чел гость, то назначаю ему роль Гость.
Или Вы имеете ввиду если он сам себя регистрирует? Можно тогда по умолчанию эту роль назначать. Или если вообще без ролей значит не будет иметь доступ туда куда не надо - т.е. это и есть "гость".

говорите "Если чел гость, то назначаю ему роль Гость." - Кааааааааааак узнаете что он гость по вашей схеме, который предложили? Вы сами как делаете?

dma_caviarDelphi159в таблице memberships ищу его роли
Если вы про ту схему которую я предложил, то memberships это не роли юзера. Это доступ (ID, логин, пароль, соль, всякие флаги, типа неудачные попытки и т.п.). А роли юзера и всякие заморочки доступа связаны именно с этим ID.
Неправильно высказался, в memberships- login и пароль найду, а роли- в таблице roles или в системной таблице(пока не решил создать или нет таблицу roles).

ViPRosАнатоЛой,

прально
"сотрудника" воще может не быть как такового
Что значит не быть? Допустим некий сотрудник имеет логин "asdr14" или "User147". Они кому-нибудь говорят кто выписал накладной? Никому и ничего. А если если между этими таблицами(users,persons) будет связь, уже можно узнать кто залогинился и выписал накладной или сделал приход- Вася Пупкин или Иван Иванич. Со всеми таблицами связи будут идти от users, а не от сотрудник.

АнатоЛойСегодня у вас пользователь Сотрудник Вася Пупкин (пользуется UI вашей системы), а завтра - используемая на предпрятии ERP (пользуется API вашей системы).
Вы имеете ввиду создать пользователи не в БД, а в security2.fdb?

АнатоЛойDelphi159, я отвечал на вопрос в стартовой теме: нужно ли разделять "Пользователя" и "Сотрудника".

Ответ: да, нужно.
"Пользователь" = некто (персона)/нечто (система), пользующееся интерфейсами (UI, API) нашей системы .
"Сотрудник" - некто (персона), имеющий отношения с нашей организацией .

Тот факт, что одна и та же персона :
- может выступать или не выступать в роли сотрудника компании
- может выступать или не выступать в роли пользователя системы,
не самый лучший способ совместить "Пользователей" и "Сотрудников" в одной таблице.

"Пользователи" - подмножество объединения "Персон" и "Систем".
"Сотрудники" - подмножество "Персон".

Пересечение "Пользователей" и "Сотрудников" в общем случае меньше и чем "Пользователи", и чем "Сотрудники".

Атрибуты "Пользователей" не пересекаются с атрибутами "Сотрудников".

У "Пользователя" есть НЕОБЯЗАТЕЛЬНАЯ ссылка на "Сотрудника" или на "Персону".
У "Сотрудника" есть НЕОБЯЗАТЕЛЬНАЯ ссылка на "Пользователя".

Мдааа, самый исчерпывающий ответ! Вопросов почти не остался, кроме:

1) Уже не сомневаюсь в необходимости отдельной таблицы Emplyees, но не могу понять в чём необходимость таблицы Persons? . В таблице Persons включаем тех людей, кто не сотрудник, например:
а."гость"-осматривает мою программу,собирается в будущем её купить
б. "будущий оператор программы"-пока не принимали на работу и изучает программу
в. Аудит...
Зачем для них сделать запись в persons (ФИО, паспорт...)- это же будет лишняя, никому ненужная информация? Они все временные гости в системе, имея привилегию только на select, мы можем всем им давать доступ к БД с одной ролью Guests. Зачем несотрудников конкретизировать?

2) Как гостям давать права на доступ к БД? Имею в виду каким может быть алгоритм:
а. Ели не ввёл логин и пароль- тогда он гость и пусть заидёт с ролью Guests.
б. иметь на форме чекбокс "гости". Если включен, disable 2 edits:login, passwoed и заходить как гость.
в. создать заранее один user "гость". Но где его запихнуть? только для этого создать вышесказанную таблицу persons?
у кого как реализован?

посмотрите что получилось, покритикуйте кто чем может....
зелёные таблицы- связывающие(многие ко многим).

Mr.FontaineDelphi159, ну разве что для связки полей id_roles-id_users использовать отдельную табличку, а в таблице roles оставить id_roles и name. Также предусмотреть, возможность привязки роли к группе пользователей.

да ещё в таблице users_groups поле id_users_groups лишнее, ибо везде всё равно будет привязки или к группе или к пользователю.

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

Mr.Fontaineнормально
Вы только об отношении таблиц users, empl(выходя из заголовка топика) или о диаграмме в целом? Я прощу всех покритиковать целую диаграмму, связи контрагента с другими таблицами, поля таблиц(что не хватает, лишние, не в том таблице и т.д.).

Кот Матроскин
... мигрировавших полей.

В смысле?

Кот МатроскинDelphi159,

Ну в смысле - у Вас у таблиц юридических лиц и контрагентов отношение 1:1, верно?
И в одной и в другой есть поле "юридический адрес". В чем смысл? У этих полей одно и то же значение? Тогда это ФЗ.

Согласен, кроме этого manager и identcode тоже должны быть только у юриков. Спасибо!

Кот МатроскинDelphi159,

Да в том-то и дело, что по Вашей диаграмме все поля этой таблицы повторяют соответствующие поля контрагента - и упомянутые Вами, и Name, и ChiefAccount
Согласен, доработаю эту часть,это легко исправить.Просто потом добавил таблицу legalentities и и там и там остались. Спасибо!
Больше критических замечании у кого-нибудь есть?