Question

我喜欢创建一个数据库驱动的Web应用程序（带有mySQL的PHP），该应用程序显示了几位古代和中世纪哲学家收集的作品（源）。来源应以其原始语言提供，主要是古希腊语，拉丁语和阿拉伯语。用户应该能够翻译和评论任何来源的内容。

作者的i收集的作品存储在scrAuthori中：

 PK
|scrAuthoriId|booktitle|page|line|position|word
|1           |bookA    |1   |1   |1       |word1
|2           |bookA    |1   |1   |2       |word2
...
|342         |bookB    |234 |3   |11      |word3453

作者的i收集的作品具有令人感兴趣的不同种类的内容：单词，涵盖超过两个单词的表达，一个句子，一个句子，一个段落，多个段落等。用户可以定义哪些内容是（即BookA，第1页，第3行到BookA，第3页，第5行）。会翻译内容并为其添加注释。

内容在authoriContents中定义：

 PK                FK1          FK2
|authoriContentsId|scrAuthoriId1|scrAuthoriId2|
|1                |1            |100
|231              |234          |1029

translationsAuthori中的翻译：

 PK                    FK
|translationAuthorIId|authorIContentsId|translation|
|1                   |3                |uvw
|2                   |3                |xyz
|2                   |45               |abc

评论与内容之间的关系必须是多对多的：用户的评论涉及两个或多个内容，并且内容中可以有多个评论。

authorIContents_author1Comments：

 FK                FK
|authoriContentsId|authoriCommentsId
|1                |3        
|4                |3        
|231              |45

authoriComments：

 PK                FK
|authoriCommentsId |comment
|3                 |comment on content 1 and 4
|45                |comment on content 231

由于这是我的第一个数据库应用程序，因此我不确定该解决方案是否可行。鉴于性能，将收集的作品逐字存储是一个错误的决定吗？每个scrAuthori，i = 1, 2, ... 10将有多达一百万行。建立后，scrAuthori的行将不会更改。对于跟踪各种内容的注释，是否有更好的方法？

Answer 1

@saritonin

阅读您的评论后，我再次访问了源表（scrAuthori）。考虑到内容表（authoriContents），我意识到scrAuthori应该只包含语义单元，这些语义单元将构成要翻译或注释的内容。如您所建议（标点符号），我现在倾向于选择句子。

实际上我的解决方案看起来像this

资源的显示必须忠实于书籍的出版版本（逐行，逐页等），因此我发现从句子到所讨论的出版书籍的结构有一些映射（例如亚里士多德的Bekker数字）。

Answer 2

我宁愿将任务分解为两部分：

定义寻址方法。例如。它可能指向了引号的开始和结束符号，或其他。无论如何，对于客户来说，它可以用不同的界面表示（选择段落或章节等），但这应该是精确的寻址方法。
存储在表中：author_id，book_id，quote_begin，quote_end，quote_identifier_for_user，user_id，action_id，action_data，action_date_time。诸如此类。

这应该为您提供非常正常的格式，易于管理和选择数据。

Answer 3

@ Van Ng：您是说分解像 this？

Answer 4

考虑到评论，我倾向于以下解决方案。

定义

来源是几位作者的作品集。

来源的

内容由任何单词，句子，段落，章节等组成。总而言之，内容由特定来源中的语义单元（例如作者，书名，页面）组成1，第4行到作者，书名，第2页，第5行。

关系

每个内容可能与许多翻译（一对多）相关。

每个内容可能与许多评论相关，并且每个 comment 与许多 contents （很多）

表格

对于N位作者，他们是N个表，每个表逐行包含该作者收集的作品。作者i的收藏作品表：

scrAuthori

PK
lineId | booktitle | page | linenumber | line
1      | aaa       | 1    | 1          | aaa
2      | aaa       | 1    | 2          | bbb

作者表：

authors

PK
authorId  | name
a1        | author1
a2        | author2

contents

PK          FK         (scrAuthori.linenumber)
contentId | authorId | lineBegin | lineEnd
1         | a1       | 3         | 5
2         | a1       | 6         | 100

翻译表：

translation

PK              FK          
translationId | contentId | translation
1             | 3         | aaa
2             | 4         | bbb

评论表：

comment

PK          FK          
commentId | comment
1         | aaa
2         | bbb

内容和注释之间的关联表：

contents_comments

PK                  FK          FK           
content_commentId | contentId | commentId
1                 | 1         | 1
2                 | 1         | 2

Here是该结构的图像。

从可扩展性（作者的作品将不时添加）和性能（每个scrAuthori表最多可包含一百万行）的角度来看，这是一个合适的解决方案吗？

使用SQL数据库跟踪书籍的批注

4 个答案: