这里是另一个集合/示例：
https://github.com/scrollmapper/bible_databases
这里你会看到SQL、XML、CSV和JSON。特别值得注意的是交叉引用表（非常广泛和惊人）和一个简单的verse-id系统，用于快速查询。
编辑：注意表格的id是书-章节-诗句的组合，总是唯一的。

SQL是最好的存储方式。考虑到您的需求，我们可以将它们分为两个主要部分

• 依赖于单个版本的信息
• 小型股
• 红字打印
• 不依赖于单个版本的信息
• 书，章，诗句号码
• 节标题
• 脚注（？）
• 交叉引用
• 评注

出于各种原因，我更喜欢将整个圣经项目存储到一个单一的表中，是的，称之为bible
为了您的视觉这里是我的屏幕我已经存储了近15个版本的圣经在一个表.幸运的是，不同的版本名称只是保持列宽.当你添加更多的版本在未来你的表水平增长，这是好的，因此行数保持不变（31102）.此外，我会要求你意识到保持组合的方便，（'Book，Chapter，Verse'）作为主键，因为在大多数情况下这是查找方式。

的数据
这就是我推荐的表格结构。

CREATE TABLE IF NOT EXISTS `bible` (
  `id` int(11) NOT NULL AUTO_INCREMENT, --Global unique number or verse
  `book` varchar(25) NOT NULL,  --Book, chapter, verse is the combined primary key
  `chapter` int(11) NOT NULL, 
  `verse` int(11) NOT NULL,
  `section_title` varchar(250)  NOT NULL, -- Section title, A section starts from this verse and spans across following verses until it finds a non-empty next section_title
  `foot_note` varchar(1000)  NOT NULL,  -- Store foot notes here
  `cross_reference` int(11) NOT NULL, -- Integer/Array of integers, Just store `id`s of related verses 
  `commentary` text  NOT NULL, -- Commentary, Keep adding more columns based on commentaries by difference authors
  `AMP` text  NOT NULL, -- Keep, keep, keep adding columns and good luck with future expansion
  `ASV` text  NOT NULL,
  `BENG` text  NOT NULL,
  `CEV` text  NOT NULL,
  PRIMARY KEY (`book`,`chapter`,`verse`),
  KEY `id` (`id`)
)

字符串

• 那小型大写字母和红色字母呢 *

好吧，小型大写字母&红色字母，您可以使用HTML或适当的格式存储在版本列中。在界面中，您可以根据用户的选择将其剥离，无论他是否需要红色字母或小型大写字母。
作为参考，您可以从下面下载SQL并以您的方式进行自定义
SQL格式的圣经

与其重新发明轮子，你可以考虑使用一个“圣经SDK”，比如AV Bible，它以一种开放的、自定义的二进制格式存储文本、格式、经文编号等。
我想他们有你列出的所有东西，除了交叉引用。

我还找到了http://www.lyricue.org/downloads/，其中包含几个mysql格式的圣经翻译。

这个仓库包含了SQL中给出的整个圣经。
https://github.com/godlytalias/Bible-Database

WernerCD的答案，但是将verseText存储为xml，这样您就可以添加像<red>e.g. Red Text</red>这样的格式化标记，并在应用程序中使用这些标记对其进行格式化

Mark Rushakoff的答案可能是最适合您的特定需求的。然而，更一般地，如果需要存储内容中包含数据的内容，或者如果您需要存储有关内容的数据，则通常使用Content Management System。您可以构建自己的（WernerCD的答案有一个表结构）或使用CMS product。这里的列表显示了所使用的各种技术（该列表中约有30种使用MySQL）

水平扩展数据库并不是很有效，因为可能会有非常大的表和复杂的更新。所以id，book，chapter，verse，V1，V2，V3，V4.
参考文献是静态的（书，章，节），所以它们可以用一个id填充在一个表中，这样你就有了整个圣经的框架。节内容可能有数百个版本，所以它最好存储在自己的表中，并与一个外键链接以识别参考文献。结构将是primary_id，foreign_id，version，content。
现在的内容只是填写需要，没有必要有成千上万的空字段，在未来你必须回去填写或需要扩大表格和回填所有现有的数据，每次你添加一个新的版本.只要填写的诗句，因为你得到他们更好地工作，我认为如果你自己建设.
这也是有意义的，因为一些版本只有NT或一些他们认为后来添加的诗句不可用，所以没有必要有空字段，你只是有数据，它链接到诗句参考。“版本”也可以是一个外键，以确定版本中的更多信息，如出版日期或长/短名称（即“NIV”，“新国际版”）这也适用于使用一个以上的版本的翻译，如1984年NIV与2011年NIV。两者都可以被识别为“NIV”，但内容不同，所以版本_id可以将另一个表与它所使用的版本的扩展信息链接起来。一旦数据被正确链接，您就可以按照您的意愿显示它，例如将发布日期/短版本名称组合成一个名称，如“NIV 1984”。或者具有对于显示名称唯一的单独列。
我不知道如何红色字母或脚注可以显示，我知道像biblegateway网站有这个作为一个切换开关，所以很高兴有这样的选择排序。这可能是一个特殊的静态标识符，直接在诗句内容中，稍后被解析为CSS标识符。它也可以是自己的外部表，但因为它是如此之小，所以一个索引将非常容易。这真的取决于你使用数据的目的，如果你想查询红色字母，那么最好是作为一个外来表（快），而不是搜索数据库中的红色字母（慢）。
对于脚注，由于它依赖于唯一的内容，因此最好将其存储在自己的表中。如何识别并放置在内容中可以使用内容中的静态引用点，如x number of characters in或x number of words in，然后再次使用外键与内容链接。因此脚注表可以是primary_id，foreign_id，reference，脚注和数据的示例可以是2304，452，64，“有些手稿不包括这个”。主键是2304，链接到内容表的外键是452，脚注放置64个字符，脚注是“有些手稿不包括这个”至于递增的脚注，比如A，B，C或者1，2，3所有这些都可以动态生成。如果重要的是要成为一个静态字母/数字，那么你可能想把它包括在数据中，但我宁愿有好的数据，允许这自动然后列出它作为静态数据。
这里的提示，不要添加数百列.这将只是一个头痛，它的电子表格思维.它是更好的工作，通过完美的查询链接表与正确的内容.

您可能需要将verse_number列拆分为verse_start和verse_end。例如，伊洛卡诺圣经中的历代志上6：78与第79节合并。因此，数据库必须能够处理以历代志上6：78-79为参考的单节。张贴链接以供参考。https://ebible.org/study/?w1=bible&t1=local%3Ailoulb&v1=R16_78
如前所述，节数（开始和结束）可能是特定的圣经版本。这完全取决于你正在处理的圣经版本。