请教一下股票相关数据的数据库设计。

2016-07-11 16:34:39 +08:00
 billgreen1

当前情况

  1. 有一张 OHLCV 表,日度的,也就是每个交易日都有一条记录。格式如下:

id, trade_date, stock_code, open, high, low, close, volume

其中 id 主键,自增。 通过 trade_date 和 stock_code 可以唯一确定一行。

目前觉得不合理的地方:

1. id 目前没有用处,目前查询都是通过查询一段时间范围内, 一些股票的数据。
2. 重复过多,每天大约有 2000+个股票数据, 这样 trade_date 就要重复 2000+次。
3. 和其他表合并不方便。目前合并的时候,都是通过 trade_date 和 stock_code 来判断唯一性。
这两个字段都要在其他表中存储。
  1. 有一些基本面的数据,是季度的 date , stock_code, f1, f2, f3, .....

date 只有四种可能: XXXX-03-31, XXXX-06-30, XXXX-09-30, XXXX-12-31. (但是这些日期不一定是 trade_date.) 分别表示第 1,2,3,4 季度数据。由于数据发布的滞后性, 我需要对于日度数据: 1 、 2 、 3 月底采用上一年 Q3 的数据; 4 、 5 、 6 、 7 月底用本年 Q1 的数据; 8 、 9 月底用本年 Q2 的数据; 10 、 11 、 12 用本年 Q3 的数据。

还有一些表, 也是日度数据, 有 id, trade_date, stock_code, col1, col2, col3 , ...... 同样的 id 自增;主键。 同样是 trade_date, stock_code 唯一的确定一行数据。

这张表和 OHLCV 合并时,就是靠 trade_date, stock_code 来和 OHLCV 的相应的行来对应。

我觉得应该有更好的方法。

先行谢过了。

7848 次点击
所在节点    MySQL
14 条回复
b821025551b
2016-07-11 16:56:57 +08:00
1.id 无论是否有用都要留;
2.trade_data 提出一个单独表, OHLCV 里的 trade_date 存新表的 id ;
3.trade_date 和 stock_code 可以判断唯一性,那么是否对于 id 也是唯一的,是否可以直接用“没有用处”的 id 。
billgreen1
2016-07-11 17:24:20 +08:00
@b821025551b id 是自增主键,当然也是唯一的。

假设 OHLCV 是价格表(表名称 price), 日度数据。表里现存 id, trade_date_id, stock_id, open, high, low, close, volume 等。由于其 id 是自增的,当日也能唯一确定一条数据。


另有日度因子表(表名称 factors.) 日度数据。 表里也要存 id, trade_date_id, stock_id, fac1, fac2, fac3, ....

我要将这两个表合并的时候,还是得设置 where price.trade_date_id = factors.trade_date_id and

price.stock_id = factors.stock_id.

主要问题是很多表中都有相同的两列(trade_date/stock_code) 或者 ( trade_date_id/stock_code_id)
billgreen1
2016-07-11 17:29:15 +08:00
@b821025551b 很多时候,两张表没有“关系”, 唯一联系就是通过(trade_date_id, stock_code_id)配对。
leedstyh
2016-07-11 17:40:41 +08:00
ID 没用,取消吧,不要纠结 date 和 code 的重复,股票数据天然的 key 就是 ticker+timestamp ,你 factor 的表我猜是每天的 TA 数据吧,和 ohlcv 存成一张表呢? fundamental 数据存另外一张表怎么样

事实上我是用 kv 数据库来存股票数据的
billgreen1
2016-07-11 18:23:12 +08:00
@leedstyh 你说的对,是每天的 TA 数据。 问题是太多了,放到一张表里有点太吓人。现在是想着按类别存放,比如动量类,波动类,等。另外还有每日的估值类因子。
fcicq
2016-07-11 20:28:47 +08:00
楼主没钱上商用列存啊
billgreen1
2016-07-11 23:15:54 +08:00
@fcicq 可以详细说说嘛?不了解商用列存是什么
fcicq
2016-07-11 23:31:14 +08:00
@billgreen1 因为回复的时候没仔细看节点. MySQL 没有列存引擎. 重复 2000 次对于列存来说没什么特别的.
8bit
2016-07-11 23:39:45 +08:00
股票 id ,名称之类都可以抽出来,行情这种单独一张表出来,楼主设计的时候要估算下总体数据量
8bit
2016-07-11 23:42:13 +08:00
日期可以单独来张表,应付查询。一些区间行情可以计算的
billgreen1
2016-07-12 07:46:31 +08:00
@8bit 我目前在这样考虑呢,谢谢啦。
股票代码一张表: stock
id, stock_code

交易日期一张表: trade_date
id, trade_date

price 表
设置两个外键约束(stock_code_id, trade_date_id)
id, stock_code_id, trade_date_id, open, high, low, close, volume

这样就是需要 join stock , trade_date 两个表
8bit
2016-07-12 08:13:12 +08:00
@billgreen1 日期就冗余行情里面,没必要提出来
realpg
2016-07-12 08:56:06 +08:00
@billgreen1
关键表全部数字化 该有的冗余都应该有
很多看起来不该有的冗余在统计时如果避免两个巨大的表 join ,都应该设计
估计好数据量,每个查询的预计检索数据量,查询品读,超过一定范围,就要考虑检索时间了

另外,总在用的数据表,基础数据表,能数字就数字型,省空间,检索快
xchange
2016-07-12 18:03:00 +08:00
国内几个大的公司内部的行情表里 trade date 都是冗余的;股票的代码、名称、缩写等信息等等都是做一张单独的证券代码表,每个股票有一个内部代码,通过内部代码和其他表关联。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/291754

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX