外键&；实体框架关系设计

本文关键字：关系 框架 实体 amp 外键 | 更新日期: 2023-09-27 18:00:31

我的SQL数据库中有两个表当前有问题。第一个，MasterPartsList只是我们系统中所有零件号的入口点，由属性pn给出。第二个表MasterPartsLists包含MasterPartsList中组件的父子（物料清单）信息，由属性给定：

parentAssyPn以及作为来自MasterPartNumbers的外键的pn。

两张表看起来像：

 MasterPartNumbers (parent) one -> many     MasterPartsLists (children)
 (PK) pn                                    (fk) pn
      desc                                       parentAssemblyPn  (could also be a fk)
                                                 qty
                                                 price

这就引出了问题1:

Q1：对于MasterPartsList中的顶级组件零件号，我应该吗

a。保留parentAssyPn NULL，只使用有问题的装配零件号填充pn，并且在表中没有主键

b。设置parentAssyPn=pn，并使用parentAsseyPn ObservableCollectionpn`创建partial key？

Q2：在这两种情况中的任何一种情况下，这将如何影响我如何从我的应用程序中适当地将我的实体框架实体数据保存回数据库（两个表），我在应用程序中公开了CCD_16 s的数据？

提前感谢！

外键&；实体框架关系设计

是否允许更改数据模型？

如果MasterPartsList中的一个零件可以显示为多个MasterPartNumbers的子零件，则是多对多关系。

我建议使用以下表格：

零件

零件号（PK）

描述

价格

和

装配

Parent_pn（PK）（FK）

零件号（PK）

数量

您的完整零件库存存储在零件表中。"部件"表中不存储任何顶级部件。

对于表Assembly，请将其解读为：要组装零件｛Parent_pn｝，我需要｛PartNumber｝的｛qty｝个项目。（根据需要重复以完成Parent_pn的组装。）

编辑：让我们举一个简单的例子，笔由彩色墨水、笔筒和笔帽组成。

您的零件表看起来像：

1、红笔

2、蓝笔

3、红墨水

4、蓝墨水

5、桶

6、盖

装配：

1，3，1-红色笔需要红色墨水

1，5，1--红笔需要一个桶

1，6，1-红色笔需要一个

2，4，1--蓝色笔需要蓝色墨水

2，5，1--蓝色笔需要一个桶

2，6，1--蓝色笔需要一个大写

通过这个例子，我们可以看到这是一种多对多的关系：-主部件（例如红笔）由许多组件组成。-一个部件（例如盖子）可以用来组成许多主要部件。

这适用于您的场景吗？

相关文章：