我首先使用EntityFramework 6代码进行在线面试预约项目。在这个项目中,候选人只能预订来自任何国家的面试。我必须管理国家、城市、日期和时段,并将控制权交给管理员,以便他/她可以根据面试的可用性插入值。
因此,我决定使用以下数据库模式(此数据库模式仅用于管理每个国家的面试时段)
国家[与城市有一对多关系]
Id
Name
Code
城市[与日期]有一对多关系
Id
Name
CountryId
日期[与时隙有一对多关系]
Id
Date
Booked
CityId
时隙
Id
Start
End
Duration
Booked
DateId
为了管理每个国家的可用和预订面试时段,我决定创建以上表格(粗体)和属性(代码块)。我还提到了表格之间的关系。
我不擅长数据库设计,所以我只想让你们复习一下,让我知道我在哪里可以做得更好??
- 我个人更喜欢根据PK的表给出PK的唯一名称,例如CountryId而不是Id,这使得阅读FK要容易得多
- 对于一张桌子来说,日期是一个相当糟糕的名字——也许BookingDate甚至只是Booking更好?TimeSlot也是如此,也许是BookingTimeSlop
- "Start"one_answers"End again"都是糟糕的名称,可能是StartTime或StartOfBooking。。。End也是如此
- 持续时间-结束和开始之间的区别。。。为什么你需要存储这种价值
你的桌子确实有不错的参考完整性,做得很好。祝你好运
除了robnick的优秀建议外,还可以考虑以下内容:
- Date似乎没有多大作用,可以考虑将其与TimeSlot合并。重复日期信息会导致日期和时隙之间的日期不同步
- 无法判断谁已经预订了TimeSlot。几乎可以保证你会在TimeSlot中需要一个PersonID或其他东西
- 使用此设计,您无法预订尚未创建的TimeSlot。这就成为了一种维护负担。请考虑删除Booked属性,并仅在预订了TimeSlot之后创建实体实例。在配置中配置可用时隙或使用不同的实体模型可能会更容易
命名字段的一般规则。。。如果它听起来像"Name"、"Date"、"ID"等太常见了,那么你最好添加一些东西,使其像fldName等。保留名称很麻烦,因为很多组件都使用它。除了字段名称之外,它们在我看来还不错。