【问题标题】:How to create 4-level nested relationship with Prisma如何使用 Prisma 创建 4 级嵌套关系
【发布时间】:2020-09-26 17:38:47
【问题描述】:

我有 3 种主要类型:公司、服务和专业。每个公司都有一份服务清单。每个服务都有一个专业列表。每个专业都有一个专业列表(子专业)。

Company 1
- Service 1
-- Specialty 1
--- Sub-specialty 1

所以 我正在 Prisma 1.34 上研究这个数据模型:

type Company {
  id: ID! @id
  name: String! @unique
  services: [Service]
}
type Service {
  id: ID! @id
  name: String! @unique
  companies: [Company]! @relation(link: TABLE)
  specialties: [Specialty]
}
type Specialty {
  id: ID! @id
  name: String! @unique
  companies: [Company]! @relation(link: TABLE)
  services: [Service] @relation(link: TABLE)
  sub_specialties: [Specialty] @relation(link: TABLE)
}

我的问题是,当我添加一家公司并在另一家公司为该公司使用相同的服务时,所有其他专业和子专业记录都将与该服务一起提供。我想让每家公司的专业和子专业领域都是独一无二的,但它们也应该在每家公司的相关服务下。

过去 3 天我一直在研究它,如果有任何帮助,我将不胜感激。

【问题讨论】:

    标签: graphql prisma


    【解决方案1】:

    这是我想出的解决方案:我在 ServiceItem 和 SpecialtyItem 表中拥有独特的服务和专业名称。每当我向公司添加新的Service 时,我都会将该Service 链接到唯一的特定ServiceItem。 Service 和 Specialty 从链接的 ServiceItem 和 SpecialtyItem 接收它的信息(仅此项目中的 name 属性)。这样,每当我更新我的ServiceItem 或SpecialtyItem 时,每个公司下的所有相关Service 和Specialty 字段都会更新。这是数据模型:

    type Company {
      id: ID! @id
      name: String! @unique
      services: [Service]! @relation(onDelete: CASCADE)
    }
    
    type ServiceItem {
      id: ID! @id
      name: String! @unique
    }
    
    type Service {
      id: ID! @id
      info: ServiceItem! @relation(link: INLINE)
      company: Company! @relation(link: INLINE)
      specialties: [Specialty] @relation(onDelete: CASCADE)
    }
    
    type SpecialtyItem {
      id: ID! @id
      name: String! @unique
    }
    
    type Specialty {
      id: ID! @id
      info: SpecialtyItem! @relation(link: INLINE)
      service: Service @relation(link: INLINE)
      sub_specialties: [Specialty] @relation(onDelete: CASCADE)
    }
    
    

    【讨论】:

      【解决方案2】:

      如果您致力于嵌套关系,那么您将不得不使 Service 类型具有非唯一名称。这将强制为每家公司创建一个新的Service 模型,同时仍然允许Specialty 更通用并具有更好的重用性。

      这里的逻辑是,如果有多个Services同名但Specialty属性不同,那么它们就不一样了。

      【讨论】:

      • 我在发帖之前尝试了这种方法,但它还有其他并发症,并不是最好的解决方案,因为以后在一家公司更新服务名称只会影响该公司。我希望服务也是独一无二的。所以我想出了我现在作为答案发布的解决方案:
      猜你喜欢
      • 2020-03-07
      • 2022-01-04
      • 2019-06-18
      • 2021-12-12
      • 2018-12-24
      • 2021-10-05
      • 2021-12-21
      • 2016-05-28
      • 1970-01-01
      相关资源
      最近更新 更多