laravel项目案例_Laravel的多态关系：一个实际的使用案例

laravel项目案例

by Joe Dixon

通过乔·迪克森

Laravel的多态关系：一个实际的使用案例 (Laravel’s Polymorphic Relationships: A Practical Use Case)

Recently, when working on my side hustle Zero to Grow, I ran into quite a complex database design issue.

最近，当我忙于从零开始成长时 ，我遇到了一个非常复杂的数据库设计问题。

The solution involves a use case for Laravel’s Polymorphic relations that goes way beyond the comments example in the documentation.

该解决方案涉及Laravel的多态关系用例，该用例远远超出了文档中的注释示例。

有什么问题 (What’s the problem)

To get under the hood of this problem, you’ll need to understand a little bit more about the app I am building.

为了解决这个问题，您需要对我正在构建的应用程序有更多的了解。

Zero to Grow is an app aimed at developers who want to grow their side projects. Whether their goal is to increase traffic, retention, conversions or anything else; this app is here to help.

“零增长”是一款针对想要发展其附带项目的开发人员的应用程序。 他们的目标是增加流量，保留率，转换率还是其他？ 这个应用程式可以为您提供协助。

Upon signup, the user is asked to define the overall goals that they wish to achieve and the metrics they need to track along the way.

注册后，要求用户定义他们希望实现的总体目标以及在整个过程中需要跟踪的指标。

Once their goals are defined, the user then creates and runs tests on their side hustle with the aim of meeting those goals. An example of a test would be ‘Send at least one tweet per day to increase engagement’.

一旦定义了他们的目标，用户便可以创建并运行测试以达到这些目标。 测试的一个示例是“每天至少发送一条推文以提高参与度”。

As with goals, the user needs to define the metrics to track in order to determine whether or not the test was successful.

与目标一样，用户需要定义要跟踪的指标，以确定测试是否成功。

It should be possible for metrics to be updated as often as the user requires throughout the course of the test or goal.

在整个测试或目标过程中，应该有可能根据用户的要求经常更新指标。

To make things more complicated, we also have the concept of ideas. They can be either private to an individual user or made publicly available for others to use.

为了使事情变得更复杂，我们也有思想的概念。 它们可以是单个用户私有的，也可以是公开的，供其他用户使用。

Ideas are always the starting point of tests. The user will find an idea, either by creating it themselves or by searching the public directory, and begin testing it to see its impact on the overall goal.

想法永远是测试的起点。 用户可以通过自己创建一个想法或通过搜索公共目录来找到一个想法，然后开始对其进行测试以查看其对总体目标的影响。

设计架构 (Designing the schema)

In order to understand how polymorphic relations can help, I’m going to talk you through the schema I designed to solve this problem, piece by piece.

为了了解多态关系如何提供帮助，我将逐一讨论为解决这个问题而设计的模式。

目标和指标 (Goals and metrics)

A user may wish for their primary goal to be increasing the overall conversion rate of a landing page. To effectively measure this, they might want to track the total visitors to the landing page along with the total number of signups.

用户可能希望他们的主要目标是提高目标网页的总体转化率。 为了有效地衡量这一点，他们可能希望跟踪登录页面的总访问者以及注册的总数。

Upon starting the goal, the user should enter the base and target metric values. During the lifetime of the goal, they should regularly update the metrics with the latest values.

开始目标后，用户应输入基本和目标指标值。 在目标的有效期内，他们应定期使用最新值更新指标。

The data structure would look something like this.

数据结构看起来像这样。

This diagram is telling us each goal can have one or many metrics and each metric can have one or many entries.

该图告诉我们每个目标可以有一个或多个指标，而每个指标可以有一个或多个条目。

With this data structure, users will be able to create a goal and assign it with all of the metrics they wish to track. They will then be able to update the goal with new entries as required during the lifetime of the goal.

通过这种数据结构，用户将能够创建目标并将其分配给他们希望跟踪的所有指标。 然后，他们将能够在目标有效期内使用所需的新条目更新目标。

想法和指标 (Ideas and metrics)

A user should be able to define an idea and associate any metrics that should be tracked. In this respect, the data structure will look similar to that of goals and metrics above. However, we don’t need to worry about tracking the metrics until the user starts testing it.

用户应该能够定义一个想法并关联应该跟踪的任何度量。 在这方面，数据结构将类似于上述目标和指标。 但是，在用户开始测试之前，我们无需担心跟踪指标。

As with the previous example, each idea can have many metrics, which will satisfy our requirements.

与前面的示例一样，每个想法可以有许多指标，这些指标可以满足我们的要求。

测验 (Tests)

Tests are where things start to get interesting.

测试是事情开始变得有趣的地方。

As previously mentioned, ideas can be made publicly available and therefore tested by lots of different users. The fact that each test needs to be assigned to a goal makes this all the more complex.

如前所述，想法可以公开提供，因此可以由许多不同的用户进行测试。 每个测试都需要分配给一个目标这一事实使事情变得更加复杂。

Upon launching a new test, the user should enter its base and target metric values. Then, during the lifetime of the test, they should regularly add the latest values.

启动新测试后，用户应输入其基本和目标指标值。 然后，在测试的生命周期中，他们应定期添加最新值。

Essentially, this is a 3-way pivot table. The default naming convention for this table in Laravel would be idea_goal_user. It doesn’t exactly roll off the tongue.

本质上，这是一个三向枢轴工作台。 Laravel中此表的默认命名约定为idea_goal_user 。 它不能完全从舌头上滚下来。

Usually, I find that pivot tables tend to encapsulate some sort of feature or behavior, and I prefer to name it in a way that reflects this. In this instance, the combination of a goal, idea and user is everything needed to run a test. As such, this table becomes tests. It allows an idea to be used by multiple users as well as be assigned a goal.

通常，我发现数据透视表倾向于封装某种功能或行为，并且我更喜欢以反映这一点的方式对其进行命名。 在这种情况下，目标，想法和用户的结合是进行测试所需的一切。 因此，该表成为tests 。 它允许一个想法被多个用户使用并被分配一个目标。

What you may have noticed in the diagram above is that the entries table facilitates a many-to-many relationship between the tests and metrics tables.

在上图中，您可能已经注意到， entries表促进了tests表和metrics表之间的多对多关系。

A key design decision had to be made here. The fact that ideas are publicly available and can be tested by multiple users means that if this many-to-many relationship didn’t exist, it would be impossible to tell which user had entered a value against the metric.

在这里必须做出关键的设计决定。 想法是公开可用的并且可以由多个用户测试的事实意味着，如果不存在这种多对多关系，就无法判断哪个用户输入了该指标值。

多态关系如何提供帮助 (How Polymorphic relationships can help)

In looking at this schema, there are a couple of places where polymorphic relations can be used.

在查看此架构时，可以在几个地方使用多态关系。

First, the most obvious place to extract a polymorphic relation is between both the goals and ideas tables to the metrics table. Although different relations, the data for storing is identical between the two and so is the perfect use case.

首先，提取多态关系最明显的地方是目标表和构想表与度量表之间。 尽管关系不同，但两者之间用于存储的数据是相同的，因此是完美的用例。

Rather than defining separate tables for defining metrics such as goal_metrics and idea_metrics, simply define a single table and use a one-to-many polymorphic relationship to both. The migration might look something like this.

goal_metrics定义单独的表来定义诸如goal_metrics和idea_metrics度量， idea_metrics只需定义一个表并使用一对多的多态关系即可。 迁移可能看起来像这样。

With the model relationships defined like so:

使用如下定义的模型关系：

That’s all that is needed for this relationship. Making use of it is no different from defining a standard one-to-many relationship.

这就是这种关系所需要的。 使用它与定义标准的一对多关系没有什么不同。

The second use case is a little bit more difficult to spot and you might disagree with my approach. However, in my opinion, this is a really elegant solution.

第二个用例很难发现，您可能不同意我的方法。 但是，我认为这是一个非常优雅的解决方案。

Both metrics for goals and metrics for tests have a relationship with an entries table. This is where values associated with the defined metrics are stored.

目标指标和测试指标都与条目表有关系。 这是与定义的指标关联的值的存储位置。

For goals, the relationship should really be a one-to-many. A metric can have many entries, but an entry belongs to a metric.

对于目标，这种关系实际上应该是一对多的。 一个度量标准可以有许多条目，但是一个条目属于一个度量标准。

With tests, the relationship is slightly different as the metrics are defined against an idea that can be tested by multiple users. As such, each test can have many metrics and each metric can belong to many tests. This is a many-to-many relationship.

使用测试时，由于针对可以由多个用户测试的想法定义了指标，因此关系略有不同。 这样，每个测试可以具有许多度量，并且每个度量可以属于许多测试。 这是多对多的关系。

To solve this problem, an intermediate (or pivot) table can be defined between tests and metrics. It makes sense to call this table entries and store the values entered directly into this pivot table.

为了解决此问题，可以在测试和指标之间定义一个中间(或​​数据透视)表。 调用此表entries并将输入的值直接存储到此数据透视表中是很有意义的。

Although the relation between entries and bot tests and goals are different, I think in this case, it makes sense to break standard database normalization and use a single table to store all data entry of metrics.

尽管条目与自动测试和目标之间的关系不同，但我认为在这种情况下，打破标准数据库规范并使用单个表存储度量的所有数据条目是有意义的。

The implementation might look something like this:

实现可能看起来像这样：

With the model relationships defined like so:

使用如下定义的模型关系：

Interacting with these relationships is still extremely simple.

与这些关系进行交互仍然非常简单。

There you have it, a many-to-many polymorphic relationship.

在这里，它具有多对多多态关系。

As I mentioned earlier, it’s not the only way to solve this problem. You may wish to tackle the last many-to-many relationship using separate tables. Even though it breaks convention, keeping all of the metric entry data in the same table is a particularly graceful solution and a great example of the power of Laravel’s native polymorphic relationships.

如前所述，这不是解决此问题的唯一方法。 您可能希望使用单独的表处理最后的多对多关系。 尽管违反约定，但将所有度量标准条目数据保留在同一表中是一个特别优雅的解决方案，并且是Laravel原生多态关系的强大示例。

For me, designing the solution in this way makes it much easier to ‘grok’ what the application is doing for both new folks going into the project and myself, six months down the line. Ultimately though, to each their own! Would you have taken a different route? If so, let’s chat in the comments below — I’d love to read your thoughts.

对我来说，以这种方式设计解决方案使六个月后的项目开发新手和我自己的“开发”工作变得更加容易。 最终，尽管如此，每个人自己！ 您会选择其他路线吗？ 如果是这样，让我们​​在下面的评论中聊天-我很想阅读您的想法。

Originally published at joedixon.co.uk.

最初发布于joedixon.co.uk 。

翻译自: https://www.freecodecamp.org/news/a-practical-use-case-for-laravels-polymorphic-relationships-231ab425b95a/

laravel项目案例