gpt4 book ai didi

mysql - 在数据库中存储多个产品选项

转载 作者:搜寻专家 更新时间:2023-10-30 20:37:47 25 4
gpt4 key购买 nike

首先让我说我知道我在标题中使用了“产品”这个词,尽管这是关于“服务”的,但我觉得这个概念和我试图实现的与产品选项的方法是一样的与我在标题中使用“服务选项”相比,每个人都可以更轻松地联系起来。

我正在为我的新汽车维修业务网站构建数据库。我正在努力寻找一种方法来存储我提供的各种服务的选项。例如:

一位客户上网要求更换前刹车卡钳。在这种情况下,服务是“制动钳更换”,服务选项是“前”。我将这些存储在表中:

Services

| ID | Service Name |
----------------------------------
| 1 | Brake Caliper Replacement |
| 2 | Oil Change |

我有第二个表,其中存储了每项服务的所有潜在选项,并指示该选项是必需的还是可选的。我在报价过程中使用网站上的这些字段,以确保他们选择所需的选项之一。

服务选项

| ID | Service_Id | Service Option | Required | Optional |
----------------------------------------------------------
| 1 | 1 | Front | 1 | 0 |
| 2 | 1 | Rear | 1 | 0 |
| 3 | 1 | Pad Replacement| 0 | 1 |

现在,当他们填写报价的其余部分并使用他们想要的选项选择服务时,我正在为如何存储关系而苦苦挣扎。

这是我目前的设置方式:

Quote

| ID | Customer Id | Vehicle Id |
---------------------------------
| 1 | 1 | 2 |

Quote Service

| Quote Id | Service Id | Service Option Id |
---------------------------------------------
| 1 | 1 | 1 |
| 1 | 1 | 3 |
| 1 | 2 | null |

但并非所有服务都具有必需或 optional 。但我正在尝试确定存储所有这些数据以生成报价的最佳方式。任何人都可以就此设计是否有意义或以不同的方式看待我可能没有想到的事情提供一些帮助吗?

最佳答案

我想最灵活的设计是一个自连接的服务产品表,有些是必需的,有些不是,这取决于每个服务在其父项下的挂起方式。它始终为层次结构中的子类别级别提供最大的灵 active 。

create table service
( -- services (and sub-services) self-join hierarchy
-- pricing naturally has no business in this table
-- it must be kept high-level and generic enough to handle all autos
-- from Hyundai to BMW
serviceId int auto_increment primary key,
description varchar(255) not null, -- the service name
required int not null, -- 1 means required, 0 means optional
parentId int not null -- 0 means no parent, otherwise serviceId of parent
);

甚至可以在表服务中使用外键约束,但那是针对版本 2。

Quote 将有两列:quoteIdserviceId

关于mysql - 在数据库中存储多个产品选项,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/32751132/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com