2013-08-03 3 views
0

Я разрабатываю приложение, в котором у меня есть несколько типов пользователей. Все они нуждаются следующие данные:3 типа пользователей с разными данными

id | email | last_login

Помимо этих данных, у каждого есть какие-то данные типа конкретного. Например, у меня есть тип user с дополнительными данными:

first_name | last_name

и тип shop с дополнительными данными:

shop_name | adress | phone | website

и, наконец, поставщик типа

supplier_name | adress | phone | category

Я пытался найти решение, моя первая мысль заключалась в том, чтобы создать 1 таблицу и добавить дополнительный столбец extras с JSON-списком данных - но это было бы плохо для сортировки SQL-запросов.

Как я могу сделать это правильно?

ответ

0

Вы можете определить абстрактный клиент супер класса с 3-мя свойствами разделяемых среди всех из них:

abstract class Client { 
    int id; 
    string email; 
    date last_login; 
} 

Затем вы можете определить три отдельных детей каждый из которых представляет один из вас требуется тип. Поэтому, если вы согласны с концепциями объектной ориентации, это будет решено без каких-либо проблем. Используете ORM или самостоятельно обрабатываете слой доступа к данным?

+0

Мне просто нужна помощь в структуре базы данных :-) Я не уверен, как я могу собрать все это вместе в базе данных. – Maeh

0

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

Таким образом, вы бы создать три таблицы:

USER (id | email | last_login) 
SHOP (id | email | last_login | shop_name | adress | phone | website) 
SUPPLIER (id | email | last_login | supplier_name | adress | phone | category) 

Тогда в каком бы языке вы используете, вы можете создать объект, который содержит только общую информацию в таблице. Таким образом, в основном создайте объект только с id, email, last_login. Если ваш язык выбора поддерживает наследование, этот базовый объект можно расширить, включив в него поля для определенных производных классов.

Это известно как Concrete Table Inheritance

Для других методов наследования моделирования в базе данных см это post.

0

Вы уже правильно разделили данные.

User 
---- 
User ID 
Email 
Last Login Timestamp 


Person 
------ 
User ID 
Last Name 
First Name 


Shop 
---- 
Shop ID 
User ID 
Website 


Supplier 
-------- 
Supplier ID 
User ID 
Supplier Name 
Category ID 


Category 
-------- 
Category ID 
Category Name 


Address 
------- 
Address ID 
Address 


Phone 
----- 
Phone ID 
Phone 


ShopAddress 
----------- 
Shop ID 
Address ID 


ShopPhone 
--------- 
Shop ID 
Phone ID 


SupplierAddress 
--------------- 
Supplier ID 
Address ID 


SupplierPhone 
------------- 
Supplier ID 
Phone ID 

Магазин и поставщик могут иметь более одного адреса и более одного номера телефона.

+0

Поставщик не может существовать, не являясь пользователем? –

+0

@Neil McGuigan: Это то, что заявила ОП. «У меня есть несколько типов пользователей». –

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