Потребители, клиенти, наематели, служители - всички в една и съща таблица?

В този случай нека бъда по-конкретен за проблема

Имам таблица с хора (с клиент и доставчик) и имам таблица с потребители (за потребители, които могат да влизат).

В момента имам тази DB структура

Клиенти -> Организации -> свързани чрез rel_customer_addresses към адресната таблица. (като 1 клиент може да има адрес за доставка, адрес за фактура и т.н.)

Потребители -> Наематели -> свързани чрез 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
За информация този въпрос е отворен. Този сайт е предимно в стил Q и A за специфични въпроси по програмиране. Ще ви отхвърлят, ако не внимавате. Късмет!   -  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