我正在寻找的是具有相应字段/类型的表名的细分。
我要存储的圣经将使用英语,需要支持以下内容:
答案 0 :(得分:9)
以下是您的另一个集合/示例:
https://github.com/scrollmapper/bible_databases
在这里,您将看到SQL,XML,CSV和JSON。特别值得注意的是交叉引用表(相当广泛和令人惊叹)和一个简单的verse-id系统,用于快速查询。
编辑:请注意,表格的ID是书本章节组合,始终是唯一的。
答案 1 :(得分:9)
SQL是存储它的最佳方式。考虑到您的要求,我们可以将它们分成两个主要部分
依赖于个人版本的信息
不依赖于个人版本的信息
出于各种原因,我更喜欢将整个圣经项目存储到一个SINGLE表中,是的,将其称为bible
为了您的视觉,我的屏幕是我在单个表格中存储了近15个版本的圣经。幸运的是,不同的版本名称只是作为列宽保存。当您在将来添加更多版本时,您的表会水平增长,这是可以的,因此行数保持不变(31102)。此外,我将要求您实现将('Book,Chapter,Verse')组合作为PRIMARY键的便利性,因为在大多数情况下这是查找方式。
这就是我推荐的表结构。
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并按照自己的方式进行自定义
答案 2 :(得分:8)
您可以考虑使用AV Bible之类的“圣经SDK”,而不是重新发明轮子,它以开放的自定义二进制格式存储文本,格式,经文数字等。
我认为他们拥有您列出的所有内容,但交叉引用除外。
答案 3 :(得分:3)
我还发现http://www.lyricue.org/downloads/包含了几种mysql格式的圣经翻译。
答案 4 :(得分:2)
所有WernerCD的答案,但将verseText存储为xml,以便您可以添加<red>e.g. Red Text</red>
等格式标签,并使用标签在应用程序中对其进行格式化
答案 5 :(得分:1)
Mark Rushakoff的回答可能是最符合您特殊需求的。但更常见的是,如果需要存储内容中包含数据的内容,或者如果您需要存储有关内容的数据,则通常会使用Content Management System。您可以构建自己的(WernerCD的答案有表格结构)或使用CMS product。此处的列表显示了所使用的各种技术(此列表中约有30个使用MySQL)
答案 6 :(得分:1)
此存储库包含sql中给出的完整圣经。
答案 7 :(得分:0)
水平扩展数据库不是很有效,因为它可能具有很大的表和复杂的更新。所以id,书,章,经文,V1,V2,V3,V4 ... Vn似乎只是在像电子表格那样看问题,而不是利用数据库提供的功能。
参考文献是静态的(书,章,经文),因此可以在一个表中填充一个ID,并带有完整的圣经框架。这些经文的内容可能具有数百个版本,因此最好将其存储在自己的表中,并与外键链接以标识参考。该结构将是primary_id,foreign_id,版本,内容。
现在内容只是按需填写,无需再有成千上万个空白字段,以后您就必须回去填写或扩展表格并在每次添加时回填所有现有数据一个新版本。只需在获取时填写经文,效果更好,我想如果您自己构建。
这也很有意义,因为某些版本仅具有NT或他们认为后来添加的某些经文不可用,因此不需要仅包含数据的空字段,它就链接到经文引用。 “版本”也可以用作外键,以标识版本中的更多信息,例如发布日期或长/短名称(即“ NIV”,“新国际版本”)。当使用多个版本的像1984年NIV与2011年NIV之类的翻译。两者都可以标识为“ NIV”,但内容不同,因此version_id可以将另一个表与有关其使用版本的扩展信息链接起来。一旦输入并正确链接了数据,就可以显示它,但是,例如,您可以结合使用发布日期/简短版本名称,使其名称类似于“ NIV1984”,或者在显示名称中使用单独的唯一列。
我不确定如何显示红色字母或脚注,而且我知道像biblegateway这样的网站都将其作为切换开关,因此可以选择按这种方式对其进行排序很好。带有红色字母的字母,这可能是直接在诗歌内容中的特殊静态标识符,稍后将其解析为CSS标识符。它也可以是它自己的外表,但是由于它很少,所以分隔符确实很容易。这实际上取决于您要使用的数据,如果您要查询红色字母,那么最好将其作为外表使用(快速),而不是在数据库中搜索定界符(缓慢)
带有脚注,因为它取决于唯一的内容,所以最好将其存储在自己的表中。如何标识内容并将其放置在内容中,可以使用内容中的静态参考点,例如x个字符或x个单词,然后再次使用外键与内容链接。因此,脚注表可能是诸如primary_id,foreign_id,reference,脚注之类的数据,数据示例可能是2304、452、64,“某些手稿不包含此内容”。主键是2304,链接到内容表的外键是452,脚注放在64个字符中,并且脚注是“某些手稿不包括此字符”至于递增的脚注,如A,B,C或1、2、3都可以动态生成。如果重要的是要有一个静态字母/数字,那么您可能希望将其包含在数据中,但我宁愿有好的数据可以自动将其列出,然后将其列为静态数据。
这是提示,不要添加数百列...这只会让人头疼,这是电子表格的想法。最好通过完美的查询来链接具有正确内容的表。