我想知道设计用于存储字谜json数据的数据库的最佳方法。由于该网站目前正处于状态,因此只需将整个对象传递给前端视图即可呈现纵横字谜:
{
grid: [15][15], // 2D array of letters
clues: {
across: {
clue_id: "here's an across clue"
...
}, // Arbitrary number of clues
down: {
clue_id: "here's a down clue"
...
} // Arbitrary number of clues
}
}在设计数据库时,最明智的选择是什么?
我的本能反应是使用MySQL或Postgres,并将json数据存储在一列中:
crossword _id | crossword_data
在未来,用户可能会“最喜欢”的线索。在这种情况下,是否更好地将所有网格和不同表的线索分离出来?
Crosswords Table [has many clues]
-----------------------------------
| crossword_id | crossword_grid |
-----------------------------------
Clues Table [has one crossword]
----------------------------------------------------------
| clue_id | clue_direction | clue_text | crossword_id |
----------------------------------------------------------还是最好将纵横字谜数据存储在单独的NoSql数据库中?
如能就此事作出任何指示,将不胜感激。
发布于 2017-11-14 23:20:59
你正在做的是一个足够好的方法。我对doxdb做了类似的操作,doxdb是映射到blob的ID。我的blob是一个BSON,它是用于优化的JSON的二进制表示,然后在更新记录时创建单独的表。
从某种意义上说,苹果邮件就是这样做的,除了BLOB之外,他们使用消息文件,并在此基础上构建数据库。
像elasticsearch和mongo这样的nosql文档数据库可以用作您的数据存储,并且有一个MySQL来提供您可以用来查询的表。
发布于 2017-11-15 17:05:49
我认为在NoSql还是关系DB之间做出决定并不是很重要,但是如果您选择关系DB路由,下面是一些建议。
如果您的用例涉及到让用户使用预定义的单词和线索创建自己的纵横字谜,我将这样建模:
Crossword Table [one crossword per row]
------------------------------------------------
| crossword_id | clue_text | crossword_text |
------------------------------------------------我看不出有什么令人信服的理由进一步规范这一点,因为你可以在每个填字游戏中有不止一个线索。单词和它们的线索很可能可以作为原子单位来处理,并且被编辑成一个pait。
它们的位置或方向只有在网格的上下文中才是重要的:
Grid [one row per crossword grid]
------------------------------
| grid_id | size_x | size_y | ... (maybe a column to distinguish different grids)
------------------------------和
Placement Table [holds crosswords as well as their positions in the grid]
--------------------------------------------------------
| crossword_id | grid_id | pos_x | pos_y | direction |
--------------------------------------------------------在这里,direction可以是表示across和down两个值的整数或字符字段。
如果您认为需要这样做,可以向letters表中添加一个Grid列,但对于已经建模的数据来说,这将是多余的。
https://softwareengineering.stackexchange.com/questions/360759
复制相似问题