- 主题:[小白求教]那些复杂的数据库在什么场景有价值呢
销售情况的揭示，资源揭示，资源管理，就是典型的在线分析呀。售票是典型的在线交易，他们必须同平台运行。这个系统就是oltp，OLAP混合系统。OLAP不能够影响oltp的运行。
这样的系统就需要大型的，复杂的商业数据库系统。
【 在 RuralHunter 的大作中提到: 】
: 你说的这些属于olap，但上面买票锁坐等就是oltp没有疑问。如果那些你要算olap那银行取钱要锁金额的也属于olap了
:
--
修改:ylh0315 FROM 221.218.60.*
FROM 221.218.60.*
不一样。进行结账显然属于olap。分日期车次，分线路，分席别数据汇总，典型的立方体剖面分析，就是OLAP。每个查询都要涉及大量数据，如果锁表，那么，查询期间，大量的车次的票都不能卖了，卡住了。
【 在 RuralHunter 的大作中提到: 】
: 你说的这些属于olap，但上面买票锁坐等就是oltp没有疑问。如果那些你要算olap那银行取钱要锁金额的也属于olap了
:
--
FROM 221.218.60.*
是。
难度在于，不能把一个席位卖给多人，也不能抢丢了，谁也没买着。
与股票不同，抢某一只股票，不会在意哪一张，大数不差就行。银行也不在意那钱的具体号码。
【 在 oldwatch 的大作中提到: 】
: 属于有很强即席查询需求的OLTP
: 数据库实现大难点之一
:
--
修改:ylh0315 FROM 221.218.60.*
FROM 221.218.60.*
我没说银行那边。就是票务系统这边，也得先自己结了，才能与银行对账清算。
【 在 roy 的大作中提到: 】
: 结账是银行根据12306发过来的交易指令来进行的，在银行自己的数据库里
: 对账也只看日期和交易流水号，不需要车次线路信息
:
--
FROM 221.218.60.*
12306设计的并不是太好，当初的数据库没选好。现在它需要限制查询量，在高峰期禁止一些部门任意查询。
【 在 mango7788 的大作中提到: 】
: 我不知道12306是怎么设计和实现的
: 但我不觉得12306涉及的查询有多大
--
FROM 221.218.60.*
售票系统要先按窗口，渠道，结账，再汇总报财务。
依据售票量。窗口是售票员换班就必须立即结账，现金，pos，各种移动支付的，都要立即算清楚。先把售票员的款项结算清楚，再把单位结清，再报财务总结算这个是日结。
渠道结账当日清。
【 在 roy 的大作中提到: 】
: 一般来说，售票系统、财务系统是分开的
: 在设计上就应该用transaction保证这两个系统的记录是一致的，这是典型的OLTP应用场景。对不对账其实意义不大。
: 对账的时候按每个账户的总数核对就行，车次什么的没必要。
: ...................
--
FROM 221.218.60.*
余票信息是从席位库提取的，必须实时。
结账是从存根库提取的。
存根是每笔交易实时存放的，先记存根，后出票。
结账后才能把结账信息发送到财务库。
【 在 roy 的大作中提到: 】
: 余票信息（库存）、窗口销售、网售可以放在不同的表里。
: 窗口结账不会影响网售。
: 而且也不会有你说的按车次线路查询的需求
: ...................
--
FROM 221.218.60.*
按车次线路到站方向的各种席别余票查询是管理部门必须实时进行的。他要随时了解进度以便调度资源，各铁路局都有客调，负责调度本局资源，但是车次车辆席别这些都在全国统一的数据库里，一大堆人在一个数据库里鼓捣自己的数据。
24小时不间断，一边卖一边鼓捣数据。所以说OLTP与OLAP混合系统。
【 在 roy 的大作中提到: 】
: 余票信息（库存）、窗口销售、网售可以放在不同的表里。
: 窗口结账不会影响网售。
: 而且也不会有你说的按车次线路查询的需求
: ...................
--
修改:ylh0315 FROM 221.218.60.*
FROM 221.218.60.*
是。
现在就不是Oracle，是sybase。
就是你说的第二种方法。一般需要设置隔离级，读脏数据。系统设计保证脏数据不脏。
在另外的系统中，使用Oracle。就采用Oracle的方法。
【 在 bnso 的大作中提到: 】
: 关于日结，你这个说法不太对。
: 1、依赖数据库技术在进行日结的，是一种比较“笨”的办法。比如你说的靠日志来进行回溯，oracle中专业术语叫闪回查询。它可以靠undo、更长时间靠闪回日志来实现。
: 2、非oracle数据库做不了日结？错！靠应用逻辑来实现，通常会有一张营业日表记录当前营业日区间几点到几点。所有明细进入时，会自动去带上这个营业日作为其日结的营业日期。发出日结指令时，营业日切换，并不影响新的明细进入，新明细的营业日和之前的已经不同了。oltp可以继续了，那么日结你改怎么算怎么算，数据本身又不会乱。
--
修改:ylh0315 FROM 221.218.61.*
FROM 221.218.61.*