数据库作业56 数据库的设计(铁路购票系统)

数据库作业56 之 设计数据库(铁路购票系统)

一、评分标准

 

二、评判结果

 

三、本次作业小结

  在本次评判的作业中,大家都设计出了自己的数据库并且编写了相应的代码,态度都很认真。

  优点(飘扬):

      在设计上,大家都有意识地用chen方法或crow's foot方法绘制E-R(Entity Relationship Diagram)图即实体联系图,并有序严谨地表示各个实体之间的关系,以及实体中的属性;此外在范式问题上,大家也能遵循数据库的范式(为了优化数据库,尽可能减少冗余)。

      在语法上,大家都提供了代码,虽然存在小错,但大部分代码能和实体对应起来。

  问题与不足:

      在设计上主要问题是第三范式的问题,比如像列车在经停站的停靠时间,建议大家不使其出现在表中,因为停靠时间可以用到站时间与离站时间计算所得,虽然停靠站时间座位字段在表中出现并没错,但为了优化数据库的结构,提高存储效率,遵循第三范式是有必要的;此外对于列车的停靠站,一趟列车可能不止一个停靠站,所以在不违反第一范式(无重复的列)的条件下,将列车的停靠信息单独作为一个实体会更好些。

      本次大部分问题(小错)出现在语法上,在编写代码时,符号一定要用半角符号书写,引号、括号尤其需注意;此外主键是唯一的,不能向表中插入重复键,否则违反了主键的唯一性。另外,需注意的是代码需要与实体对应起来,不能有使设计的数据库与代码建立不了对应关系。

      大家可以根据自己设计和代码中的问题加以修改完善自己的数据库~ 加油!

 

转载于:https://www.cnblogs.com/wandawill6/p/9125347.html

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
12306数据库设计 原⽂地址:http://blog.csdn.net/hnkontecna/article/details/61672983 标签 标签 PostgreSQL , 12306 , 春节 , ⼀票难求 , 门禁⼴告 , 数组 , 范围类型 , 抢购 , 排他约束 , ⼤盘分析 , ⼴告查询 , ⽕车票 背景 背景 马上春节了,⼜到了⽕车票的销售旺季,⼀票难求的问题依旧存在吗? 还记得10年前春节前买⽕车票得在放票前1天搬个⼩板凳去排队,对于热门路线,排⼀个晚上都有可能买不到票。 随着互联⽹的发展,⼏年前建设了12306⽹上购票系统,可以从电脑上买票,但是不要以为在电脑上就能买到票。 我记得12306刚推出时,经常发⽣12306⽹站打不开,⽆法付款的问题。 为什么呢? 原因很简单,春节期间⽹上购票的⼈可能达到⼏亿的级别,⽽且放票⽇期是同⼀天同⼀个时间点,也就是说同⼀时刻12306要接受⼏亿⽤ 户的访问。 处理能⼒和实际的访问需求更不上,带来的结果就是⽹站打不开,系统不稳定的现象。 后来12306想了分线路分时段开启的办法,想办法把不同线路的⽤户错开时间来访问12306的⽹站,但是这个⽅法起初的效果不明显,并 不是所有⽤户都知道的(就好像你临时通知今天不上班,但还是有⽤户会来单位的),所以⼤多数⽤户还是集中在⼀个点去访问12306的 ⽹站。 随着硬件的发展,技术的演进,12306系统越来越趋于成熟,稳定性和响应速度也越来越好。 据说现在很多商家还开通了云抢票业务,本质上是让你不要冲击12306系统了,把需求提前收集,在放票时,这些系统会进⾏排队与合并 购买,这种⼿段可以减少12306的访问并发。 抢⽕车票是很有意思的⼀个课题,对IT⼈的智商以及IT系统的健壮性,尤其是数据库的功能和性能都是⼀种挑战。 接下来我们⼀起来缕⼀缕有哪些难点,⼜有怎样的解决⼿段。 ⼀、铁路售票系统 ⼀、铁路售票系统 - 西天取经之路开始啦 西天取经之路开始啦 铁路售票系统最基本的功能包括 查询余票、余票统计、购票、车次变化、退票、改签、中转乘车规划 等。 每个需求都有各⾃的特点,例如 1. 查询余票,⽤户在购票前通常会查⼀下到达⽬的地有哪些余票,它属于⼀个⾼并发的操作,同时需要统计余票张数,需要很强的CPU来 ⽀撑实时的查询。 2. 购票购票和查询不⼀样,购票是会改变库存的,所以对数据库来说是更新的操作。 ⽽且购票很可能发⽣冲突,例如很多⼈要买同⼀趟车的票,那就出现冲突了,到底卖给谁呢? 需要考虑锁冲突,尽量的让不同的⼈购买时可并⾏,或者可以合并多⼈的购票请求,来减少数据库的更新操作。 3. 中转乘车,当⽤户需要购买的起点和到达站⽆票时,需要计算中转的搭乘⽅案。 ⽐如从北京到上海,如果没有直达车,是不是该转车呢?转哪趟,在哪⾥转就成了问题,简单⼀点就是买票的⼈⾃⼰想。 ⾼级⼀点的话,可以让12306给你推荐路线,这个涉及的是数据库的路径规划功能。 我们来逐⼀分析⼀下这些需求的特点。 1 查询余票 查询余票 1. 普通的余票查询需求 你如果要买从北京到上海的⽕车票,通常会查⼀下哪些车次还有余票。 查询的过滤条件可能很多,⽐如 1.1. 上车站、下车站、中转站 1.2. 车次类型(⾼铁、动车、直达、快速、普客、...) 1.3. 出发⽇期、时段 1.4. 到达⽇期、时段 1.5. 席别(硬座、硬卧、...站票) 1.6. 过滤掉没有余票的车次 展⽰给⽤时还要考虑到怎么排序(是按始发时间排呢,还是按票价,或者按余票数量排?),怎么分页。 眼见不⼀定为实 查询余票通常不是实时的、或者说不⼀定是准确的,有可能是后台异步统计的结果。 即使是实时统计的结果,在⾼并发的抢票期间,你看到的信息对你来说也许很快就会失效。 ⽐如你看到某趟车还有100张票,很可能等你付款的时候,已经卖光了。 所以在⾼峰期,余票信息的参考价值并不⼤,不要被迷惑了。 2. 查询余票的另⼀个更⾼级的需求是路径规划, ⾃动适配(根据⽤户输⼊的中转站点s) 这个功能以前可能没有,但是总有⼀天会暴露出来,特别是车票很紧张的情况下。 就⽐如从北京到上海,直达的没有了,系统可以帮你看看转⼀趟车的,转2趟车的,转N趟车的。(当然,转的越多越复杂)。 从中转这个⾓度来讲,实际上已经扯上路径规划的技术了。 怎么中转是时间最短的、价格最低的、中转次数最少的等等。(⾥⾯还涉及转车的输⼊要求(⽐如⽤户要求在⼀线城市转车,或者必须要转 ⾼铁))。 关于路径规划,可以参考⼀下PostgreSQL pgrouting,已⽀持多种路径规划算法,⽀持算法的⾃定义扩展。 简直是居家旅⾏,杀⼈灭⼝的必备良药。 师⽗⼩⼼,有妖怪。。。 师⽗⼩⼼,有妖怪。。。 1. ⼤多数⽤户是有选择综合症的,通常来说,⽤户可能会查

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值