我正在使用Laravel开发一个类似Uber的应用程序，你可能知道它有不同的用户类型，可以有司机和普通用户。我不确定如何构建数据库，因为驱动程序可以有其他字段和关系，普通用户不，但我需要这两种类型能够登录。用户还可以驾驶并对驾驶员进行评分，只有驾驶员可以拥有他们的个人资料，驾照号码，驾驶年限，评分，并且只有他们可以拥有与正在驾驶的汽车等的关系。
我想知道你认为处理这种情况的最好方法是什么?- 保持驱动程序和用户在同一个用户表中，驱动程序字段为空，类型字段知道它是驱动程序还是普通用户?
问:如果我选择这个选项，我如何保证乘车的司机实际上是一个司机，而不是一个简单的用户?
| users | id |
|---|
| 名称 |
| driver_license_number |
| driver_years_driving |
| driver_rating |
你在user这个术语下把两个不同的东西联系在一起:user表示"在我的应用程序中注册的人"，而user表示"使用我的应用程序搭车的人"。在第一个定义中，驱动程序和非驱动程序都是用户，但在第二个定义中不是。
令人困惑的是，Driver实体只是一个具有更多字段的User实体，因此有可能根本不表示实体，只需向User实体添加更多列，并且，响应您的第一个问题，添加is_driver列来告诉哪个实体是哪个。
这样做会削弱数据库的功能，从而无法保证数据的有效性。你现在可以有一个没有driver_license_number的Driver行，因为你的数据库不知道什么是Driver，哎呀。
在数据库模式中显式有很多好处。数据库工作的一部分就是保证数据的一致性，帮助你的数据库帮助你。
我的建议是更进一步。凭据是一回事，他们有自己的位置。用户是另一种，他们得到他们的表(在您的示例中，用户似乎没有任何数据，但他们可能有比他们的名字更多的东西)。司机也是，他们也有自己的位置。| 凭证 | id |
|---|
| 用户名 |
| password_hash(您正在对密码进行散列，对吗?) |
我认为您应该使用两个单独的表。这将避免出现大量乘客和司机之间不共享的可空字段。此外，如果这些实体经常更改，那么ALTER TABLE在规模上就会有点麻烦。
连接在两个表之间的开销当然要大一些，但是由于我们选择了规范化，所以查询写起来更自然。
作为一个边注，无论你选择哪种方式写表，这个应用程序最终都会遇到扩展问题，因为MySQL不容易横向扩展。
但是，如果您想要简单的查询并避免可空字段，两个单独的表对我来说似乎是正确的选择。
考虑3个表(可能还有其他一些表):
- Persons——这包含了司机和乘客共同的东西，比如登录。
- 骑手—生物等 司机
如果这样更方便的话，可以构建两个视图:
- Rider_all—乘客与乘客之间的连接
- Driver_all——人与司机之间的连接