структура модели базы данных

Question

У меня есть столбец групп . Группы имеет другой тип, сохраненный в group_types (покупатели, продавцы, рефери). Только когда группа относится к типу покупателя, она имеет другой тип (более специализированный), например, электрический и механический.

Я немного озадачен тем, как я буду хранить это в базе данных.

Кто-то может предложить мне структуру базы данных?

спасибо

Answer 1

Сохраните group_types как иерархический стол (с моделью nested sets или parent-child):

Parent-child

typeid parent name

1      0      Buyers
2      0      Sellers
3      0      Referee
4      1      Electrical
5      1      Mechanic

SELECT  *
FROM    mytable
WHERE   group IN
        (
        SELECT  typeid
        FROM    group_types
        START WITH
                typeid = 1
        CONNECT BY
                parent = PRIOR typeid
        )

выберет всех покупателей в Oracle.

Nested sets:

typeid lower  upper  Name
1      1      2      Buyers
2      3      3      Sellers
3      4      4      Referee
4      1      1      Electrical
5      2      2      Mechanic

SELECT  *
FROM    group_types
JOIN    mytable
ON      group BETWEEN lower AND upper
WHERE   typeid = 1

выберет всех покупателей в любой базе данных.

Nested sets может быть реализован где угодно и более производительно, если вам не требуется иерархическое упорядочение или частые обновления group_types.

Parent-child легко реализуется в Oracle и SQL Server и с небольшими усилиями в MySQL. Это позволяет легко изменять структуру и иерархическое упорядочение.

См. Эту статью в моем блоге о том, как реализовать ее в MySQL:

• Иерархические запросы в MySQL

Answer 2

тип группы: ID, имя («покупатели», «продавцы», «рефери»)

group: GroupTypeID, ID, Name («электрический» и «механический», если grouptypeid == «покупатели»)

contact: GroupTypeID (NOT NULL), GroupID (NULL), другие атрибуты

Таблица групп заполняется записями для групповых типов по мере необходимости.

Contact.GroupID может быть НЕДЕЙСТВИТЕЛЕН, так как GroupType не должен иметь никаких групп.

Пользовательский интерфейс должен позаботиться о выборе группы. Вы можете иметь триггер, проверяющий логику группы / типа.

Answer 3

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

Например, допустим, ваша основная таблица:

People
  PersonId int, PK
  GroupTypeId int, FK to GroupTypes
  Name varchar(100)

GroupTypes
  GroupTypeId int, PK
  GroupTypeName varchar(20)

BuyerTypes
  BuyerTypeId int, PK
  BuyerTypeName varchar(20)

BuyerData
  PersonId int, FK
  BuyerTypeId int FK

==== Кроме того, BuyerData будет иметь составной первичный ключ (PK) для PersonId и BuyerTypeId

При извлечении данных о покупателе вы можете использовать запрос типа

SELECT *
  FROM People P 
    INNER JOIN BuyerData BD on (P.PersonId = BD.PersonId)
    INNER JOIN BuyerTypes BT on (BD.BuyerTypeId = BT.BuyerTypeId)

Answer 4

Вы можете попробовать:

Group
group_id
group_name
group_parent_id

with entries (1, buyers, 0), (2, sellers, 0), (3, referee, 0), (4, electrical, 1), (5, mechanical, 1)

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

Answer 5

Вы можете хранить дополнительные типы, такие как buyer_mechanical или buyer_electrical.