Пользователи, клиенты, арендаторы, сотрудники — все в одной таблице?

В этом случае позвольте мне более конкретно рассказать о проблеме

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

В настоящее время у меня есть эта структура БД

Клиенты -> Организации -> связаны через rel_customer_addresses с таблицей адресов. (поскольку 1 клиент может иметь delivery_address, адрес счета и т. д.)

Пользователи -> Арендаторы -> связаны через rel_users_addresses с таблицей адресов (поскольку 1 пользователь может иметь delivery_address, адрес счета и т. д.)

Теперь у меня в таблице накладных есть customer_key. Проблема в том, что пользователь сам является клиентом, а счет-фактура от одного из его клиентов. Как указать моему веб-приложению искать пользователя, а не клиента?


database multi-tenant structure
person Gurinder Singh    schedule 21.03.2013    source источник
comment
Это действительно зависит от того, сколько данных вы будете хранить для каждой задачи. Эмпирическое правило — используйте только то, что вам нужно, но вам также не нужна одна большая и сложная в использовании база данных.   -  person Casey Dwayne    schedule 22.03.2013
comment
К вашему сведению, этот вопрос является открытым. Этот сайт в основном представляет собой стиль вопросов и ответов для конкретных вопросов по программированию. Они проголосуют за вас, если вы не будете осторожны. Удачи!   -  person Casey Dwayne    schedule 22.03.2013
comment
Спасибо за сообщение. Я переписал свой пост, чтобы быть более конкретным   -  person Gurinder Singh    schedule 23.03.2013

Ответы (1)


arrow_upward
0
arrow_downward

Поскольку вы смотрите на 2 отдельных объекта (клиентов и пользователей), я бы пошел дальше и использовал 2 отдельные таблицы, чтобы они использовали уникальный идентификатор (т. е. имя пользователя, SID).

Таким образом, нет никаких шансов, что один увидит информацию от другого без соответствующих разрешений.

Есть несколько способов контролировать это, но логика примерно такая.

If userID exists in table user, do this.
If userID exists in table customer, do this.
If userID exists in table user AND table customer, do this.

Таким образом, вы можете полностью контролировать ситуацию как самостоятельно, так и вместе. Другими словами, вы можете предоставить специальные разрешения для userID, который находится в таблице customer, или просто сделать его полностью отдельным (аналогично тому, как Facebook создает отдельную «идентификацию» для страниц по сравнению с учетной записью, на которую она зарегистрирована).

Надеюсь, это поможет!

person Casey Dwayne    schedule 23.03.2013
comment
Привет еще раз, спасибо за помощь. Я выбрал подход с использованием ролей и поместил все типы пользователей в одну таблицу. Это было проще всего, потому что в какой-то момент мне нужно было разрешить вход в систему всем типам пользователей, и теперь, когда они находятся в таблице пользователей, все упрощается. - person Gurinder Singh; 07.04.2013