这个代码优先数据库设计是好的c#吗？答案

【问题标题】：Is this code first database design is good c#?这个代码优先数据库设计是好的c#吗？
【发布时间】：2014-01-26 05:34:24
【问题描述】：

我正在使用 EntityFramework 6 代码进行在线面试预订项目。在这个项目中，候选人只能从任何国家预订面试。我必须管理国家、城市、日期和时间段，并将控制权交给管理员，以便他/她可以根据面试的可用性插入值。

为此，我决定使用以下数据库架构（此数据库架构仅用于管理每个国家/地区的面试时段）

国家 [与城市有一对多关系]

Id
Name
Code

城市 [与日期有一对多关系]

Id
Name
CountryId

日期 [与 TimeSlot 有一对多关系]

Id
Date
Booked
CityId

时隙

Id
Start
End
Duration
Booked
DateId

为了管理每个国家/地区的可用和已预订面试时间段，我决定创建上述表格（粗体）和属性（代码块）。我也提到了表之间的关系。

我不擅长数据库设计，所以我只想请你们检查一下，让我知道我在哪里可以做得更好？？

【问题讨论】：

【解决方案1】：

命名字段的一般规则...如果听起来太常见，例如“名称”、“日期”、“ID”等，那么您最好添加一些内容以使其类似于 fldName 等。保留名称很麻烦，因为很多组件都使用它。除了字段名称，它们对我来说都很好。

【讨论】：

【解决方案2】：

除了 robnick 的出色建议之外，请考虑以下几点：

日期似乎没有多大作用，考虑将它与 TimeSlot 合并。复制日期信息可能会导致 Date 和 TimeSlot 之间的日期不同步。
无法判断谁预订了时间段。几乎可以肯定，您在 TimeSlot 中需要 PersonID 或其他东西。
使用此设计，您无法预订尚未创建的时间段。这成为维护负担。考虑删除 Booked 属性并仅在预订 TimeSlot 后创建实体实例。在配置中配置可用时隙或使用不同的实体模型可能会更容易。

【讨论】：

【解决方案3】：

我个人更喜欢根据他们的表给 PK 的唯一名称，例如CountryId 而不是 Id - 让阅读 FK 更容易。
日期是一个相当糟糕的表名称 - 也许 BookingDate 甚至只是 Booking 更好？ TimeSlot 也一样，可能是 BookingTimeSlop？
Start 和 End 又是糟糕的名称，可能是 StartTime 或 StartOfBooking... End 也是如此。
持续时间 - End 和 Start 之间的区别...为什么需要存储该值？

你的桌子确实有不错的参考。诚信做得很好。祝你好运！

【讨论】：