在处理基于 WordPress 的项目时,可以说部署中最令人沮丧或最乏味的方面之一实际上是使环境中的数据库彼此同步。
当然,在开发中使用测试数据、在暂存中使用用户数据以及在生产中使用实际数据是有道理的,但没有什么灵丹妙药,对吧?这意味着测试数据有时会起作用;其他时候则不会。
例如,假设您继承了一个项目,您必须为其拉取数据库,然后开始使用现有数据。或者假设您必须将整个网站或应用程序从一台服务器迁移到另一台服务器。
在这种情况下,测试数据并没有多大帮助。相反,您需要一个工具。当然,WordPress 导入器对于基本迁移来说是一个不错的工具,如果您熟悉数据库前端并使用 SQL 本身,那么运行 SQL 导出和导入是可以的。
但是那些介于两者之间的人呢?
事实是,当涉及到 WordPress 数据库迁移时,这是一个鱼龙混杂的情况,因为我们中的许多人的技能水平因我们最常使用的堆栈的哪一部分而异。
我的意思是:
这并不是说没有全栈开发人员。显然,有;然而,并不是每个人都处于这个位置。
因此,当谈到迁移 WordPress 数据库时,有些人的处境比其他人困难得多。或者,尽管人们对 SQL 很熟悉,但有些人可能只是在寻找一种工具来帮助简化整个过程。
在本系列中,我们将介绍一个能够实现此目的的实用程序,但在此之前,让我们快速了解一下 WordPress 数据库,以确保我们能够都在同一页面上。
当谈到讨论 WordPress 数据库时,可以写一整系列的文章来讨论每个表、每个列、架构、如何编写最佳查询等等。
这不是一个系列。
相反,我们将在本文中做两件事:
最终,这应该有助于为那些在前端花费更多时间的人解释或揭开一些底层工作的神秘面纱,并且可能帮助那些花更多时间在应用程序层使用 WordPress API 的人了解哪些功能匹配到哪个表(这最终可以编写更好的代码)。
总的来说,我想Wptuts+的大多数读者都知道什么是数据库。
直接来自维基百科:
数据库是有组织的数据集合。这些数据通常被组织为对现实的相关方面进行建模(例如,酒店房间的可用性),以支持需要此信息的流程(例如,查找有空房的酒店)。
这是一个公平的定义,但我认为它不能很好地说明 WordPress 数据库或类似的 Web 应用程序 - 它有点太笼统了。因此,从这里开始,让我们创建自己的工作定义,以便在本系列的其余部分中使用。
让我们试试这个:
数据库至少由一张表组成。表由行和列组成,每行都存储唯一的信息。每行称为一条记录。一个数据库中可以存在多个表,有时表之间可以相互关联。
也许我上面分享的内容中最令人困惑的部分是表可以相互关联。我们将在文章结束之前重新讨论这个想法 - 但首先,让我们讨论一下 WordPress 数据库。
简而言之,WordPress 数据库由 11 个表组成(除非您使用 Multisite,但这超出了本系列的范围)。
现在,每个表还有自己的一组列,表示表中存储的各种信息。例如,wp_posts
表有一个名为 post_content
的列,它表示存储在帖子中的实际内容。
表格及其说明如下:
这就是 WordPress 数据库的全部内容。它相对简单明了,对吗?
帖子保存在帖子表中,评论保存在评论表中,用户保存在用户表中,等等。当然,有一些细微的差别(例如页面存储在 Posts 表中);然而,这是一个相对不复杂的模式。
这是一件好事。
另外,还记得我们之前提到过一些表可以相互引用吗?评论表和帖子表就是一个很好的例子。由于评论是在特定帖子上留下的,因此评论需要知道它与哪个帖子 ID 关联,以便在加载帖子时,可以检索与该帖子 ID 相关的评论。
无论如何,这比我们在本系列中深入探讨的细节要多,但希望这足以给您一个想法。如果您对更多技术信息、表之间的关系、列等感兴趣,那么一定要查看有关数据库描述的 WordPress Codex 文章。
至此,我们已经涵盖了 WordPress 数据库入门知识中需要涵盖的所有内容。希望这有助于揭开您在 WordPress 中保存信息时幕后发生的事情的帷幕,但现在我们已经介绍了这一点,是时候看看一个可以使数据迁移变得极其简单的工具了。
考虑到我们现在已经了解了数据库的组织方式,我们还应该了解迁移的工作原理。
以上是迁移 WordPress 数据库入门:基本数据库知识的详细内容。更多信息请关注PHP中文网其他相关文章!