Отслеживание аннотаций для коллекции книг с базой данных SQL

0

Мне нравится создавать основанное на базе данных веб-приложение (PHP с mySQL), которое отображает собранные работы (источники) нескольких древних и средневековых философов. Источники должны быть доступны на их оригинальных языках, в основном на древнегреческом, латинском и арабском языках. Пользователи должны иметь возможность переводить и комментировать любой контент источников.

Автор 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 не изменятся. Есть ли лучший подход к проблеме отслеживания аннотаций к разным видам контента?

  • 0
    Это похоже на шаг слишком далеко вверх по лестнице нормализации. Я бы выбрал полнотекстовые индексы вместо этого.
  • 0
    Насколько мне известно, полнотекстовый индекс предназначен для ускорения полнотекстового поиска. Хотя база данных также будет обслуживать поисковые запросы, ее основная цель - отслеживать переводы и комментарии к классическим источникам. В этом смысле база данных имитирует критический аппарат (как этот один . В дополнение к этому база данных будет устанавливать связи между комментариями (не отображенных в моем примере) и служат в качестве словаря для философских понятий. Но I'am боится , что слово по Подход слова (scrAuthori) приведет к проблемам с производительностью.
Показать ещё 1 комментарий
Теги:
database-design

4 ответа

0

Учитывая комментарии, я склонен к следующему решению.

Определения

Источники - это собрание сочинений нескольких авторов.

Содержимое источника состоит из любых слов, предложений, абзацев, глав и т.д. Вкратце содержание состоит из семантических единиц, найденных в конкретном источнике, например, Автор, название книги, страница 1, строка 4 - Автор, название книги, страница. 2, строка 5.

связи

Каждый контент может быть связан со многими переводами (один ко многим).

Каждый контент может быть связан со многими комментариями, а каждый комментарий - со многими (многие ко многим).

таблицы

Для 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

Вот изображение структуры.

Является ли это подходящим решением с точки зрения масштабируемости (собранные сочинения авторов будут добавляться с течением времени) и производительности (каждая таблица scrAuthori может содержать до миллиона строк)?

Поделиться
  • 0
    Кажется, хорошо на структуре изображения.
  • 0
    Примечание: один комментарий может относиться только к одному контенту. ИМХО не обязательно применять один комментарий ко многим материалам. В противном случае лучше добавить еще одну сущность: translate_attempt, которая должна идентифицировать пользователя, который переводит, и то, что он переводит. Может быть одна попытка одной книги.
0

@Ван Нг: Вы имеете в виду, разлагая что-то вроде этого?

Поделиться
0

Я бы предпочел разложить эту задачу на две части:

  1. Определить адресный подход. Например, это может быть начальный и конечный символ кавычки или что-то еще. В любом случае, для клиента он может быть представлен в разных интерфейсах (выберите параграф или главу и т.д.), Но это должен быть точный метод адресации.

  2. Хранить в таблице: author_id, book_id, quote_begin, quote_end, quote_identifier_for_user, user_id, action_id, action_data, action_date_time. Что-то вроде того.

Это должно предоставить вам вполне нормальную форму, простую в управлении и выборе данных.

Поделиться
0

@saritonin

Прочитав ваш комментарий, я снова посетил таблицу источников (scrAuthori). Рассматривая таблицу содержимого (authoriContents), я понял, что scrAuthori должен содержать только семантические единицы, из которых будет составлен контент, предназначенный для перевода или комментирования. Как вы и предлагали (пунктуация), я теперь склонен выбирать предложения.

На самом деле мое решение выглядит это

Отображение источников должно соответствовать опубликованной версии книг (строка за строкой, страница за страницей и т.д.), Поэтому я нашел какое-то сопоставление между предложениями и структурой рассматриваемой книги (например, числа Беккера для Аристотель).

Поделиться

Ещё вопросы

Сообщество Overcoder
Наверх
Меню