数据库架构-预订平台
Database schema - booking platform
我是一名从事小型个人项目的 CS 学生。这是一个用户可以与自由摄影师预约的平台。我将在这个项目中使用 Postgres，但在设计数据库时我仍然遇到一些问题。
Photographer:
photographer_id (PK)
name (string)
registration_date (string)
company_id (int) # as photographers are not full time employee, they do have their own company
id_path (string) # id picture path (passport for example)
rating (int)
User:
user_id (PK)
name (string)
registration_date (string)
Shooting:
shooting_id (PK)
photographer_id (FK)
user_id (FK)
date (date)
pictures_path (string) #path where the pictures of the shooting are stored
location_id (FK)
Location:
location_id (PK)
country (String)
city (String)
一位用户请求拍摄给定的 day、time 和 location。一次拍摄总是30分钟。一旦用户进行了预约，该平台就会在给定的日期、时间和地点提供摄影师。示例：user_z 请求在 November 23th 3:00 pm 的 Berlin 拍摄。该平台将寻找在给定时间和地点可用的所有摄影师。假设在 Berlin 3:00 pm November 23th 我们有 3 位可用的摄影师：
photographer_id | name
------------------------
3746 | Thomas
5436 | Sofia
0835 | Maria
我们不会联系他们中的 3 个人，越快回复就会得到这份工作。相反，每个摄影师都会根据 2 个标准获得分数：1) rating 和 2) cancellation rate
取消率是指摄影师在接受工作后取消预约的次数。
所以摄影师将根据该分数进行排名。如果我们回到 Berlin on November 23th at 3:00 pm 的示例，队列如下所示：
photographer_id | name | score
--------------------------------
3746 | Thomas | 0.32
5436 | Sofia | 0.48
0835 | Maria | 0.95
平台会先向Maria发送请求。如果她在 30 分钟后没有回复或拒绝，我们将向 Sofia 发送请求，依此类推。我为此创建了一个新的 table，但我仍然不太确定结构，我还有很多事情要弄清楚。
Requests:
request_id (PK)
user_id (FK) #from the user table
date_of_request (date) #when the request was made by the user on the platform
location_id (FK) # from the location table, where the client wants to have a shooting
date (date) # when the client wants to have a shooting
cancelled (boolean) # true is the request was cancelled by the client or no photographer was found for the given location and time
我不知道我所做的是否有意义，但我在请求时遇到了一些困难 table。 -
我是否应该有另一列，photographer table 中的 photographer_id (fk) 或 shooting [=68= 中的 shooting_id (fk) ] ？因为如果一个摄影师接受一个请求，我需要能够link吗？我的问题是 requests 和 shooting table 有很多重复的列。
我的第二个问题是摄影师排名的分数。我需要两个元素来计算该分数
rating 和 cancellation rate。我的评分已经 photographer table 但我还没有 cancellation rate 分数。我仍在弄清楚如何在平台 (Flask) 上计算该分数，但我想我需要一个专用的 table 来计算该分数？
如果您有其他建议，那将非常有帮助！
其实你的已经很不错了。但我已经提出了一些建议供您考虑。
Photographer:
photographer_id (PK)
name (string)
registration_date (string)
company_id (int) # as photographers are not full time employee, they do have their own company
id_path (string) # id picture path (passport for example)
rating (int)
Changes
protogrepher_id int generated identity
registration_date should be type date not string
add: contact information, unless that is in company
Client:
client_id (PK)
name (string)
registration_date (string)
Changes
make name client (indicates the purpose of entity, further within IT user often has bad connotation)
client_id int generated identity
registration_date should be type date not string
add contact information (see Requests)
Location:
location_id (PK)
country (String)
city (String)
change
protogrepher_id int generated identity
registration_date should be type date not string
add: address (what happens if there are multiple locations in same city
say from your example Berlin- a city of 4M inhabitants covering 30K sq km)
Requests:
request_id (PK)
client_id (FK) #from the client table
date_of_request (date) #when the request was made by the client on the platform
location_id (FK) # from the location table, where the client wants to have a shooting
date (date) # when the client wants to have a shooting
cancelled (boolean) # true is the request was cancelled by the client or no photographer was found for the given location and time
change
protographer_id int generated identity
registration_date should be type date not string
date should be timestamp as that included the time as well as date
add: status Pending - Request made, but no photographer
Accepted - Photographer has accepted job
Canceled - The request is canceled, can indicate why/who canceled
add: contact information (see Client) - need to be able to notify client when accepted or canceled. That information could come from client table
Shooting:
shooting_id (PK)
photographer_id (FK)
client_id (FK)
location_id (FK)
date (date)
pictures_path (string) #path where the pictures of the shooting are stored
change
shooting_id int generated identity
registration_date should be type date not string
This is the decision do you need to make: keep this as an individual table, or combined into Requests. Either way a session is an Approved Request. As you indicated the columns overlap considerable - but that is not necessary. You can combine them bu moving photographer_id to Requests and eliminating Shootings or keep Shootings but eliminate Client_id, location_id, and date then adding Request_Id. There is no loss of information either way.
您的具体问题：
- 将 Shooting_id 添加到摄影师。 绝对不会。如果会发生什么
摄影师有多次拍摄？你可以获得所需的
通过 FK 从拍摄到摄影师的信息。
- 我无法解决等级问题，因为您还在研究中。然而，我
会倾向于根本不存储它，因为它是一个计算值。如果
你把它存储起来，它就变成了一个静态值，并且是一个维护问题。如何
经常更新。
缺少元素： 在指示的添加列旁边
- 您没有任何信息表明已向摄影师发送工作邀请，也没有
任何捕捉他们负面反应的方法。
- 您表示评分取决于摄影师的取消
速度。但是你没有什么可以捕捉到的。也许建议
请求中的状态，但这由您决定。
我是一名从事小型个人项目的 CS 学生。这是一个用户可以与自由摄影师预约的平台。我将在这个项目中使用 Postgres，但在设计数据库时我仍然遇到一些问题。
Photographer:
photographer_id (PK)
name (string)
registration_date (string)
company_id (int) # as photographers are not full time employee, they do have their own company
id_path (string) # id picture path (passport for example)
rating (int)
User:
user_id (PK)
name (string)
registration_date (string)
Shooting:
shooting_id (PK)
photographer_id (FK)
user_id (FK)
date (date)
pictures_path (string) #path where the pictures of the shooting are stored
location_id (FK)
Location:
location_id (PK)
country (String)
city (String)
一位用户请求拍摄给定的 day、time 和 location。一次拍摄总是30分钟。一旦用户进行了预约，该平台就会在给定的日期、时间和地点提供摄影师。示例：user_z 请求在 November 23th 3:00 pm 的 Berlin 拍摄。该平台将寻找在给定时间和地点可用的所有摄影师。假设在 Berlin 3:00 pm November 23th 我们有 3 位可用的摄影师：
photographer_id | name
------------------------
3746 | Thomas
5436 | Sofia
0835 | Maria
我们不会联系他们中的 3 个人，越快回复就会得到这份工作。相反，每个摄影师都会根据 2 个标准获得分数：1) rating 和 2) cancellation rate
取消率是指摄影师在接受工作后取消预约的次数。
所以摄影师将根据该分数进行排名。如果我们回到 Berlin on November 23th at 3:00 pm 的示例，队列如下所示：
photographer_id | name | score
--------------------------------
3746 | Thomas | 0.32
5436 | Sofia | 0.48
0835 | Maria | 0.95
平台会先向Maria发送请求。如果她在 30 分钟后没有回复或拒绝，我们将向 Sofia 发送请求，依此类推。我为此创建了一个新的 table，但我仍然不太确定结构，我还有很多事情要弄清楚。
Requests:
request_id (PK)
user_id (FK) #from the user table
date_of_request (date) #when the request was made by the user on the platform
location_id (FK) # from the location table, where the client wants to have a shooting
date (date) # when the client wants to have a shooting
cancelled (boolean) # true is the request was cancelled by the client or no photographer was found for the given location and time
我不知道我所做的是否有意义，但我在请求时遇到了一些困难 table。 -
我是否应该有另一列，
photographertable 中的photographer_id (fk)或shooting[=68= 中的shooting_id (fk)] ？因为如果一个摄影师接受一个请求，我需要能够link吗？我的问题是requests和shootingtable 有很多重复的列。我的第二个问题是摄影师排名的分数。我需要两个元素来计算该分数
rating和cancellation rate。我的评分已经photographertable 但我还没有cancellation rate分数。我仍在弄清楚如何在平台 (Flask) 上计算该分数，但我想我需要一个专用的 table 来计算该分数？
如果您有其他建议，那将非常有帮助！
其实你的已经很不错了。但我已经提出了一些建议供您考虑。
Photographer:
photographer_id (PK)
name (string)
registration_date (string)
company_id (int) # as photographers are not full time employee, they do have their own company
id_path (string) # id picture path (passport for example)
rating (int)
Changes
protogrepher_id int generated identity
registration_date should be type date not string
add: contact information, unless that is in company
Client:
client_id (PK)
name (string)
registration_date (string)
Changes
make name client (indicates the purpose of entity, further within IT user often has bad connotation)
client_id int generated identity
registration_date should be type date not string
add contact information (see Requests)
Location:
location_id (PK)
country (String)
city (String)
change
protogrepher_id int generated identity
registration_date should be type date not string
add: address (what happens if there are multiple locations in same city
say from your example Berlin- a city of 4M inhabitants covering 30K sq km)
Requests:
request_id (PK)
client_id (FK) #from the client table
date_of_request (date) #when the request was made by the client on the platform
location_id (FK) # from the location table, where the client wants to have a shooting
date (date) # when the client wants to have a shooting
cancelled (boolean) # true is the request was cancelled by the client or no photographer was found for the given location and time
change
protographer_id int generated identity
registration_date should be type date not string
date should be timestamp as that included the time as well as date
add: status Pending - Request made, but no photographer
Accepted - Photographer has accepted job
Canceled - The request is canceled, can indicate why/who canceled
add: contact information (see Client) - need to be able to notify client when accepted or canceled. That information could come from client table
Shooting:
shooting_id (PK)
photographer_id (FK)
client_id (FK)
location_id (FK)
date (date)
pictures_path (string) #path where the pictures of the shooting are stored
change
shooting_id int generated identity
registration_date should be type date not string
This is the decision do you need to make: keep this as an individual table, or combined into Requests. Either way a session is an Approved Request. As you indicated the columns overlap considerable - but that is not necessary. You can combine them bu moving photographer_id to Requests and eliminating Shootings or keep Shootings but eliminate Client_id, location_id, and date then adding Request_Id. There is no loss of information either way.
您的具体问题：
- 将 Shooting_id 添加到摄影师。 绝对不会。如果会发生什么 摄影师有多次拍摄？你可以获得所需的 通过 FK 从拍摄到摄影师的信息。
- 我无法解决等级问题，因为您还在研究中。然而，我
会倾向于根本不存储它，因为它是一个计算值。如果 你把它存储起来，它就变成了一个静态值，并且是一个维护问题。如何 经常更新。
缺少元素： 在指示的添加列旁边
- 您没有任何信息表明已向摄影师发送工作邀请，也没有
任何捕捉他们负面反应的方法。 - 您表示评分取决于摄影师的取消 速度。但是你没有什么可以捕捉到的。也许建议 请求中的状态，但这由您决定。