Как лучше всего хранить Библию в SQL?

расширение DB горизонтально не очень эффективно с потенциалом наличия очень больших таблиц и сложных обновлений. так идентификатор, книга, глава, стих, V1, V2, V3, V4... Vn просто, кажется, смотрит на проблему как электронная таблица вместо того, чтобы использовать в своих интересах то, что должен предложить DB.

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

теперь содержание просто заполняет по мере необходимости и нет никакой потребности иметь тысячи пустых полей, что в будущем необходимо возвратиться и заполнить или бывший должный развернуть таблицу и заделать все существующие данные каждый раз, когда Вы добавляете новую версию. просто заполните стихи, поскольку Вы получаете их, какие работы лучше я думаю если Вы создающий его сами.

Это также имеет смысл, поскольку некоторые версии только имеют NT или некоторые стихи, что они думают, были добавлены, позже не доступны, таким образом, нет никакой потребности иметь пустые поля, у Вас просто есть данные, и это связывается со ссылкой стиха. "версия" может также быть внешним ключом для идентификации большей информации в версии как дата публикации или длинное / краткое название (т.е. "NIV", "Новая Международная версия") Это также работает хорошо при использовании больше чем одного пересмотра перевода как NIV 1984 года по сравнению с 2011 NIV. Оба могут быть идентифицированы как "NIV", но отличаться по содержанию, таким образом, version_id может связать другую таблицу с расширенной информацией о версии, это использует. После того как те данные находятся в, и связанный правильно можно отобразить их однако, Вы желаете, например, объединения имени даты/короткой версии публикации, делающего имя как "NIV1984", или имеете отдельный столбец, уникальный для отображаемого имени.

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

со сносками, так как это зависит от уникального содержания, это было бы лучше всего сохранено в его собственной таблице. то, как это определяется и помещается в содержание, могло использовать статические контрольные точки в содержании как x количество символов в или x количество слов в и затем связанный с содержанием с помощью внешнего ключа снова. Таким образом, таблица сноски могла быть чем-то как primary_id, foreign_id, ссылка, сноска и пример данных могли быть 2304, 452, 64, "некоторые рукописи не включают это". Первичный ключ был бы 2304, внешний ключ, который связывается с таблицей содержания, 452, сноска помещается 64 символа в, и сноска является "некоторыми рукописями, не включают это" Что касается сноски постепенного увеличения как A, B, C или 1, 2, 3 все это может быть динамично сгенерировано. Если важно быть статической буквой/числом затем, Вы могли бы хотеть включать его в данные, но у меня скорее будут хорошие данные, которые позволяют, это автоматически затем перечисляет его как статические данные.

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