EF实体的这种关系是什么关系？

[货郎大叔]

一个出身地城市，可能会对应N个男人和女人，但也有可能全是男人没有女人，反之亦然，而一个人只对应一个出生地城市。
请问，出生地城市City和男人Boy，City和女人Girl之间的实体关系是什么关系？不是一对多吧？

[threenewbee]

这个叫做 1:*
也就是 1对0或者多。

[货郎大叔]

引用 2 楼 datafansbj 的回复:

显然就是一对多啊，一个 City 对多个 Boy，一个 City 对多个 Girl，这是两个关系。当然如果把 Boy、Girl 抽象成 person 不再区分，那就是一个关系。

一对多啊？如果出生地全是Boy咋办，Girl怎么多的呢？

[datafansbj]

显然就是一对多啊，一个 City 对多个 Boy，一个 City 对多个 Girl，这是两个关系。当然如果把 Boy、Girl 抽象成 person 不再区分，那就是一个关系。

[wanghui0380]

没啥关系，结帖。忘不了数据库的人，永远不算合格的OO程序员。 OO程序员眼里有所谓的“一对多，多对多么” 写OO的人永远是 老师 { 学生[] } 学生 { 老师[] } 忘不了数据库，心里就天天惦记三范式，一对多，多对多，那么为啥要做OO程序员呢，DBA不香么？？ 如果以后有个EF2neo4j,你以后查询是图论的，那么你还纠结所谓的一对多，多对多么？你要知道“一张图 顶点和边 本来就是互相连的，还讨论啥一对多，多对多不是多余的说”

[货郎大叔]

没有关系？？？

[圣殿骑士18]

要在掌握正确方法的前提下，进行分析，否则就是无意义的。 比如，把人分成男人和女人，然后分析城市对应女人，这就不是正确的分法，这是建模错误。 我们要在正确的方向上来讨论问题。 实体可以分为城市，和人。而男人女人，只是人这个实体的一个属性，不是实体。 然后，你可以分析城市和人之间是什么对应关系了，那就是1:0..*，一个城市可以有0到多个人

[货郎大叔]

引用 10 楼 圣殿骑士18 的回复:

要在掌握正确方法的前提下，进行分析，否则就是无意义的。 比如，把人分成男人和女人，然后分析城市对应女人，这就不是正确的分法，这是建模错误。 我们要在正确的方向上来讨论问题。 实体可以分为城市，和人。而男人女人，只是人这个实体的一个属性，不是实体。 然后，你可以分析城市和人之间是什么对应关系了，那就是1:0..*，一个城市可以有0到多个人

城市和人之间的关系，我是知道的呢。 就好比一条1000的费用需要结账，包含100元的现金结账、100元的会员储值结账、100元的积分抵现结账……，我现在就想弄清楚1000的费用实体和现金结账实体、会员储值结账实体、积分抵现实体……之间是什么关系

[wanghui0380]

引用 4 楼 货郎大叔 的回复:

[quote=引用 2 楼 datafansbj 的回复:]显然就是一对多啊，一个 City 对多个 Boy，一个 City 对多个 Girl，这是两个关系。当然如果把 Boy、Girl 抽象成 person 不再区分，那就是一个关系。

一对多啊？如果出生地全是Boy咋办，Girl怎么多的呢？[/quote] 哎，老师带着一群学生，换个角度学生有一群老师，所以他们是多对多 那么好，一个城市有一群出生地是他的男人 或女人，换个角度一个男人或女人会有一群出生地么？ 当然，在换个角度。就讨论男，女。一个男人一生会有多个女人，一个女人一生会有多个男人，这是多对多。可是这个跟出身地有啥关系。 ok，在换个角度。你说我就像做个“探探”，我想搞给城市速配。我就想查，一个男人的出生地有多少女人。你查不出还是如何？？

[正怒月神]

User表 uid sex cityid 你说这个是什么结构 你要说一对一，也是正确的，因为一个人，只对应一个城市。 你要说多对一，也是正确的，因为从city的角度来看，他对应多个User实体。 但是你说，你如果早model中创建时。 你一半会创建

public class User
{
id,sex,cityid

public City city{get;set;}
}

public class City
{
cityid,name......

//但是你不会在city里创建一个User集合
//ICollection<User>  User;
}

原因也很好理解，你可以说一个人属于哪个城市。 但是不会说一个城市里有哪些具体的人。一般他们只是单向关系。

[正怒月神]

而且，城市和男人和女人的关系， 他们有什么关系？ 只是抽象成User和city的关系。 哪有什么男人和女人的区别？ 男人和女人的区别，只是体现在业务里，统计报表之类的用到而已。

[wanghui0380]

还是那句话，从逻辑上玩代码，别整天跟数据库较劲。 比如列数据库clickhouse，比如图数据库neo4j，比如离散数据库hbase。这种所谓的3范式，啥多对多都是无效讨论。 程序员只关心逻辑，不关心数据库。数据库是DBA的事情，你看到人家专门招聘ETL，DBA，说明这是人家的事情，不是你的事情 现在的倾向很明显，最近有两个卖书的对吧，你看有人理会不？一个号称10年DDD，结果去折腾仓储，有人理不？一个号称10年的ORM，有人理不？ 这都不是程序员的活，我们说可以跟你讨论一下那个DDD的前4章，讨论讨论逻辑，边界，划分。我可不想讨论啥单根，聚合根，啥仓储 同样那个ORM，我说我们可以讨论讨论DSL本身，讨论讨论OData，GrarpQL，但我们就是不想讨论啥什么ORM最佳使用

[圣殿骑士18]

引用 11 楼 货郎大叔 的回复:

[quote=引用 10 楼 圣殿骑士18 的回复:]要在掌握正确方法的前提下，进行分析，否则就是无意义的。 比如，把人分成男人和女人，然后分析城市对应女人，这就不是正确的分法，这是建模错误。 我们要在正确的方向上来讨论问题。 实体可以分为城市，和人。而男人女人，只是人这个实体的一个属性，不是实体。 然后，你可以分析城市和人之间是什么对应关系了，那就是1:0..*，一个城市可以有0到多个人

城市和人之间的关系，我是知道的呢。 就好比一条1000的费用需要结账，包含100元的现金结账、100元的会员储值结账、100元的积分抵现结账……，我现在就想弄清楚1000的费用实体和现金结账实体、会员储值结账实体、积分抵现实体……之间是什么关系[/quote] 不要为了设计而设计，我们要始终明白，人类创造工具是为了提高效率，不是为了设计。我们设计实体，是为了开发维护效率，不是为了设计。 按我的习惯，我不会设计现金结账，会员储值结账，积分抵现结转实体，只需要一个费用结账实体就行了，现金金额，储值卡金额，积分抵现，是这个实体的三个属性。

[xuzuning]

使用元数据概念，放弃关联模型

[晨易夕]

3#已经说得很好了，你在刻意回避OO概率？