我有一个数据库设计问题。
我目前正在Twitter消息上使用三种不同的NLP引擎（Stanford NLP，IBM Watson和OpinionFinder）对日内股票数据进行自然语言处理。
Stanford NLP和OpinionFinder都使用极性标志来表示情绪 - 正面，中立和负面。我可以在数据库中识别-1，0，1。
IBM Watson在文本上有五种不同的百分比（从0到100），称为愤怒，厌恶，恐惧，快乐和悲伤，这可以存储为浮点数或整数（即0.9或90） 。
每天（标识为date，格式为YYYY-mm-dd）有三个情绪行，每个NLP引擎一行。因此，可以有三个相同的symbol_id和date，这就是为什么我认为我还应该在复合唯一键中添加nlp_engine。我的计划是使用symbol_id date nlp_engine作为复合唯一键。
另一种方法是，我还有一个Prices表来存储股票价格/期货数据，它具有以下格式：
id | date | symbol_id | ...
因此，我可以使用Symbols.id中每天引用的Sentiments.prices_id，因为我只收集日内（每日）数据。
因此，我想创建一个名为Sentiments的表，其中包含以下列：
id | symbol_id | date | nlp_engine | anger | disgust | fear | joy | sadness | polarity | created_at | updated_at
说明：
id - 主键
symbol_id（Symbols table的外键，其中包含我的股票代码+ date和nlp_engine列的复合唯一键
date - （包含symbol_id和nlp_engine的复合唯一键）
nlp_engine - （我应该为此使用字符串，还是应该创建一个名为NLPEngines的新表并使用nlp_engine_id？这也应该是symbol_id的复合唯一键和date）
anger - 浮动
disgust - 浮动
fear - 浮动
joy - 浮动
sadness - 浮动
polarity - 有符号整数，例如-1，0，1
我只想对这个数据库设计进行一些批评 - 谢谢。
答案 0 :(得分：1)
您的数据结构听起来很可靠，但这取决于您将如何存储/检索此数据。
此数据是计算的结果，如果它需要是实时的并且是一次性的，您可能需要考虑使用更接近缓存存储或NoSql的东西。但同样，取决于你手头的问题。
Laravel在单表继承方面不是特别灵活。您需要解析正确的类来处理不同引擎之间的交互。如果sentiments表数据不需要进行规范化，那么您将把来自不同引擎的数据转换为不合理的格式。你最好创建3个不同的表，每个引擎一个。
但是，如果您绝对需要能够将多个引擎结果绑定到一个Price，那么我认为您采取了正确的方法。我建议使用访问器/更改器来规范化您的数据，以便您的应用程序的其余部分不必知道如何操作。