数据库结构:这个结构可以用这个m:m吗?

时间:2011-03-18 19:03:48

标签: mysql database-design cakephp orm m2m

这是我的问题:(使用MySQL)

我有2个实体叫做“商店”和“客户”。我在“客户”和“商店”之间也有一个名为'clients_shops'的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

到目前为止一直很好(我想......)但这是我的问题。假设有一个名为“trip”的第三个表。 “旅行”表存储有关个人预订的信息,其中“客户”将预订由“商店”提供的“旅行”。这是我的大脑变得糊涂的地方。我该如何设置这种关系?

是这样的:

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的表格。

提前感谢任何真正读过这一切的人!

3 个答案:

答案 0 :(得分:1)

除非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

答案 1 :(得分:1)

这是处理您要找的内容的逻辑图。根据您的要求,您可以将非身份关系(Client :: Trip& Shop :: Trip)更改为识别关系。如果你这样做,我会限制它只改变Shop :: Trip来识别。也可以根据需要更改基数。

enter image description here

答案 2 :(得分:0)

我可能会像这样制作旅行表:

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表表示客户与商店之间的当前关系。这次旅行不应该依赖于这些关系,因为它们可能会在将来发生变化,你可能不希望旅行的数据随着时间的推移而改变 - 它应该是一个交易记录,它确切地说明了商店,客户和旅行是什么无论当前客户与商店之间的关系如何,都会在该时间安排。