如何建立数据驱动的 WordPress 网站

多年来，对数据驱动网站的需求不断增加，因为我们生活在一个大多数业务决策都由数据驱动的世界中。 全球创建的数据量可能高达 180 泽字节。

开发数据库驱动的网站是一项艰巨的任务。 每时每刻，您的 CMS 都会被数据淹没，而有效地处理这些数据是一项挑战。

别担心！

在这里，我们解释了如何开发数据驱动的 WordPress 网站。 但在此之前让我们了解什么是数据驱动网站？

什么是数据驱动网站？

数据驱动的网站与其静态变体有很大不同。 一个主要区别是您（管理员）可以在新数据出现时快速更新数据驱动的网站。

事实上，此类网站的唯一目的是展示最新内容。 因此，与静态网站不同，它会定期按时更新。

这意味着数据驱动的网站不是一次性项目。 这是一个持续的过程。 换句话说，您的网站需要足够灵活以适应频繁的更改。

底线是——网站数据库将是数据驱动网站中受影响最大的元素。 让我们考虑几个例子来说明这一点。

• 在在线商店中，每次下新订单或新客户注册时，网站数据库都会不断变化。
• 许多网站从第三方平台收集数据。 您可能希望存储此数据，然后以易于理解的格式对其进行过滤和显示。 这使得有必要对数据库进行优化。
• 另一种情况是当您的网站数据库更频繁地更新时，您希望在显示更新数据之前对其进行处理。 这也是 WordPress 数据库优化的用武之地。

WordPress 作为 CMS 非常适合数据驱动的网站

数据驱动的网站需要内容管理系统 (CMS) 才能高效工作。 CMS 使您能够轻松和结构化地管理网站内容。 WordPress 是符合要求的最受欢迎的 CMS。

WordPress 默认数据库模式由开发人员在对前端和后端站点的每个请求中使用的几个表组成。 此外，还有许多用于帖子和页面、评论、术语、用户帐户和设置的表格。

WordPress 作者在优化资源使用方面做得不错，并设计了表格来存储几乎无穷无尽的数据。

存储在 WordPress 中的数据

WordPress 允许您将任何自定义实体保存为帖子、具有唯一标识符、名称、内容或与特定用户关联的创建/修改日期的对象。

元条目使用与帖子关联的键值对。 事实上，您可以无缝地将实体作为帖子进行操作，并向它们添加一组元参数。 这种通用的面向后的方法是从数据库服务器存储和检索数据的最简单和最快的方法。

我们在使用 WordPress 数据库结构时面临的常见问题

每个 WordPress 站点（在某种程度上）都使用数据库来存储和提供内容。 WordPress 为帖子提供了非常直观的机制。 但与此同时，它打开了通向数据库性能问题的大门。 主要专注于静态内容的小型站点可以在此内置解决方案上非常有效地播放。 但是，上面示例中提到的更大、更复杂的服务需要更智能的方法。

当您开始向 WordPress 添加数据时，post 元表的大小将由于其键值对而开始增加。 您通过网站添加的所有内容可能都需要将信息存储在后元中。

当数据在显示给用户之前在后台进行处理时，您可能会遇到数据传输问题。 例如，如果您每天收到数以千计的订单，那么在生成月度和周度收入报告时就会遇到问题。

这也适用于其他情况。 例如，如果您从第三方平台大量且频繁地为您的网站数据库提供数据，那么当您想要过滤和显示最新数据时，增加的帖子元表大小会导致问题。 发生这种情况是因为数据库查询需要更多时间来处理该数据。

WordPress 数据库结构的局限性

是什么导致了这个问题？

在 WordPress 中，帖子元表使用与帖子关联的键值对。 简而言之，如果客户从您基于 WordPress 的在线商店购买商品，它将以键值对的形式存储所有数据。

这些问题只有在键值对设计如下所示时才能解决，方法是最小化行数并将它们转换为列。 不幸的是，这不在我们手中。

它将在后元表中占用更少的空间。 但是根据 WordPress 数据库结构，post 元表在全球范围内使用，无法更改。

可能的解决方案

幸运的是，为了让您摆脱困境，我们找到了两种可能的解决方案。

他们是：

1.解决方案一（使用自定义订单表）

您无法优化默认 WP po​​st_meta 表的结构，但您可以根据您的要求创建一个表并将订单数据存储在那里。 您需要与经验丰富的 WordPress 专家合作，因为它需要对默认的 WooCommerce 订单功能进行一些更改。

这是分步过程。

• 在 WordPress 专家的帮助下，您可以创建优化的自定义订单数据表，如下所示：

• 现在，请您的开发人员指示 CMS 从自定义表中插入和获取新订单。
• 接下来，请您的开发人员将您的旧订单数据迁移到新创建的自定义订单表。
• 但是，这是一个定制的解决方案，因此如果您不将此订单数据与任何其他插件一起使用，它将适用。 如果你使用插件，它们仍然会尝试从 post_meta 表中获取数据。

2.方案二

假设您从 API 或任何第三方平台提供网站数据库。 您有数以千计的记录进来，并希望在网站上显示它们时详细过滤它们。 问题是，如果您将所有这些数据存储在自定义帖子类型中，它将以传统的 WP 方式存储，这意味着在 post_meta 表中。 同样，数据的多样性被存储为键值对。 简而言之，您将无法详细过滤此数据。

• 例如，假设您创建了一个食谱网站，其中的食谱数据来自 API。 您已经设置了一个食谱列表页面并添加了一个过滤器。 该过滤器包含各种选项，如膳食类型、课程、饮食、蛋白质选项、难度级别、方法、其他营养选项等等！
• 如果此食谱数据存储在自定义帖子类型中，则食谱属性也将作为键值对存储在 post_meta 表中。

• • 当用户尝试使用不同的过滤选项过滤数千个食谱时，WordPress 默认数据库查询将开始循环遍历每条记录以找到匹配的结果。 随着 post_meta 表的大小增加，需要的时间会越来越长。 这可能会导致数据交付问题向前推进。
  • 您可以创建优化的自定义表，而不是创建自定义帖子类型来存储此数据。 它将避免增加默认 post_meta 表的大小，并帮助您在需要时提高处理/过滤数据的效率。

下面是一个经过良好优化的表的示例：

• 使用这样的解决方案，您的用户在尝试过滤这些食谱时将在几秒钟内获得结果。

结论：

在这个日益数字化的世界中，对数据驱动网站的需求是不可否认的。 具体且可操作的数据洞察力可以推动更多的销售并产生更好的销售线索。 这符合您的代理机构/品牌的最大利益。 借助这些快速提示，您可以创建和维护一个更加数据驱动的 WordPress 网站。 现在就试试这些，让我们知道它们是如何提供帮助的。

您是否在为 WordPress 网站的性能而苦苦挣扎？ 联系我们获取定制解决方案。