对于股市数据来说，什么是好的关系数据库设计？
假设有两种类型的消息：QUOTE 和 TRADE。两者都有不同的领域。例如，TRADE 只有一个价格。 QUOTE 有买入价和卖出价。我希望按时间顺序处理消息，执行如下操作：
if (QUOTE) {
...
}
if (TRADE) {
...
}
我的问题是这两条消息的格式不同，因此我无法将它们放入同一个数据库表中。如果我无法将它们放入同一个数据库表中，如何按顺序处理？有合适的设计想法吗？
Suppose there are two types of messages, QUOTE and TRADE. Both have different fields. For example TRADE has only a single price. QUOTE has both a bid and ask price. I want process messages in time order to do something like the following:
if (QUOTE) {
...
}
if (TRADE) {
...
}
My problem is the two messages are in different formats so I can't get them into the same database table. If I can't get them into the same database table how do I process sequentially? Any ideas for a suitable design?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
答案完全取决于您正在做什么以及您的应用程序插入数据流的位置。
在一种极端情况下，您可能只是回答从 API 中提取的客户报价，并且基本上实现了缓存。在这种情况下，有两个表就可以了。
在另一个极端，您可能正在监控高频交易平台的实时报价，在这种情况下，吞吐量可能会完全排除使用数据库的可能性（围绕 lisp 构建的东西，例如 allegrograph，可能更合适），定期收集汇总统计数据除外。
The answer depends entirely on what you're doing and on where your app plugs into the data streams.
At one extreme, you might merely be answering customer quotes that you're pulling from an API, and basically implementing a cache. In this case two tables are fine.
At the other extreme, you might be monitoring real-time quotes for a high frequency trading platform, in which case the throughput will probably rule out using a database at all (things built around lisp, such as allegrograph, might be more appropriate), except to periodically collect aggregate statistics.
简而言之，“并非如此”对于股票市场和其他时间序列数据，像 Berkley DB 或 Mongo 这样的键值存储非常好。此外，从长远来看，像 NetCDF (http://en.wikipedia.org/wiki/NetCDF) 这样的数据格式可能会为您提供更好的服务。它还取决于您想要什么样的访问权限以及您想要存储多少时间。
您没有说明您对数据做了什么，这应该最能告诉您存储的选择。例如，高速交易应用程序与历史批处理系统（其中 Hadoop + NetCDF 会很棒）相比，会有不同的存储权衡。青年MMV
The short answer is, 'not really' For stock market and other time series data a key value store like Berkley DB or Mongo is pretty good. Also, a data format like NetCDF (http://en.wikipedia.org/wiki/NetCDF) will likely serve you better in the long run. It also depends on what kind of access you want and how much time you want to store.
You didn't indicate what you were doing with the data, which should inform your choices of storage more than anything. For example, a high-speed trading application will have different storage tradeoffs than a historical batch processing system (where Hadoop + NetCDF would be great). YMMV
Kdb+/q
对于刻度数据来说是一个非常好的选择。被各大银行使用。
这里是相关信息。
您可以安装试用版本并使用它。
Kdb+/q
Is a very good option for tick data. Used by major banks.
here is the info about that.
You can install a trail version and play with it.