Структура базы данных: будет ли эта структура работать с этим m: m?

Question

Вот моя проблема: (с использованием MySQL)

У меня есть 2 сущности, называемые «магазины» и «клиенты».У меня также есть таблица M: M между «клиентами» и «магазинами», называемая «клиенты_шопами» (соглашение по именованию CakePHP).Причина, по которой я так поступаю, заключается в том, что это SaaS-приложение, в котором у «клиентов» может быть много «магазинов», а у «магазинов» определенно будет много «клиентов».

Однако я не хочучтобы дать магазину возможность ОБНОВИТЬ / УДАЛИТЬ «клиентскую» запись, поскольку в действительности «магазин» будет «РЕДАКТИРОВАТЬ / УДАЛИТЬ» этого «клиента» из своих собственных записей, а не из основной таблицы «клиенты», котораяуправляется «клиентами».

В любом случае, используя эту структуру, «магазин» может выполнить запрос к таблице «clients_shops», чтобы получить список своих клиентов, а «клиент» может выполнить запрос, чтобы получить список своих «магазинов».,Пока все хорошо ...

Пока база данных выглядит так:

table.clients
client_id (PK, AI, NN)

table.shops  
shop_id (PK, AI, NN)

table.clients_shops  
clients_shops_id (PK,AI,NN)  
client_id (FK)  
shop_id (FK)

ORM выглядит так:

shops hasMany clients_shops  
clients hasMany clients_shops

Пока все хорошо (Я думаю ...) но вот мой вопрос.Допустим, есть третья таблица с именем «поездки».В таблице «поездки» хранится информация об отдельных бронированиях, в результате чего «клиент» будет резервировать место для «поездки», которую предоставляет «магазин».Это где мой мозг становится мягким.Как мне установить эти отношения?

Это так:

table.trips
trips_id (PK,AI,NN)
clients_shops_id (FK) [which would contain keys for both the shop and the client]

Или есть лучший способ сделать это, как в другой таблице, использующей clients.client_id AND clients_shops.clients_shops_id.

Заранее спасибо всем, кто действительно прочитал все это!

Answer 1

Вот логическая схема для обработки того, что вы ищете.В зависимости от ваших требований вы можете изменить неидентифицирующие отношения (Client :: Trip & Shop :: Trip) на идентифицирующие отношения.Если вы сделаете это, я бы ограничил только изменение Shop :: Trip на идентификацию.Также внесите изменения в количество элементов по своему усмотрению.

Answer 2

Если это не требуется вашим ORM, вам не нужен суррогатный внешний ключ для клиентов / магазинов и всего, что к нему относится.

Создайте композит PRIMARY KEY и обратитесь к нему из других источников:

CREATE TABLE clients_shops
        (
        client_id INT NOT NULL,
        shop_id INT NOT NULL,
        PRIMARY KEY (client_id, shop_id)
        );

CREATE TABLE trips
        (
        trip_id INT NOT NULL PRIMARY KEY,
        client_id INT NOT NULL,
        shop_id INT NOT NULL,
        trip_data …,
        CONSTRAINT fk_trips_clients_shops
                FOREIGN KEY (client_id, shop_id)
                REFERENCES clients_shops
        );

В этой модели предполагается, что вы поддерживаете отношения клиент / магазин отдельно от транзакций клиентов и не позволяете клиентам покупать в магазинах, если они не "связаны".

Возможно, вы хотите, чтобы отношения появлялись автоматически, когда клиент заказывает поездку из магазина. В этом случае вам нужна только вторая таблица, а первая таблица - это просто

SELECT  DISTINCT client_id, shop_id
FROM    trips

Answer 3

Я бы, наверное, составил таблицу командировок так:

table.trips
trip_id (PK)
shop_id (FK to shops)
client_id (FK to clients)
other_trip_column_etc

Я бы не стал ссылаться на таблицу m-m clients_shops из таблицы поездок - просто ссылаюсь на таблицы магазинов и клиентов с отдельными внешними ключами.

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