一个公共数据模式应该被分离到它自己的sql表中吗？

将多个表的公共子集拆分为具有类型键的自己的表时，是否有一种优先级方法

例如： Hipmunk允许您搜索包含“行程详细信息”的航班

进行搜索后，会有一个最近的搜索跟踪器，您可以将航班保存到“我保存的航班”中。此外，如果您预订了航班，那么可能也会有相关记录。因此，下表都有“跳闸详细信息”，加上一些其他位

因此，复制所有表中的列或为该公共对象创建一个公共表是否有好处。是否所有3个表都有from、to、department、arrival或arrival，还是将其抽象为一个trip_details表，然后该表有from、to、arrival、department、type。类型将是用于搜索、保存和预订的枚举

我被要求提供一些示例表，所以它们就在这里

方法1

recent -> id,from,to,departure,return,user_id
saved  -> id,from,to,departure,return,user_id,flight_id
booked -> id,from,to,departure,return,user_id,flight_id,confirmation_number,payment_type... etc

方法2

trip_details -> id,from,to,departure,return,user_id, type(recent,saved,booked)

recent -> id, trip_details_id, user_id
saved  -> id, trip_details_id, user_id, flight_id
booked -> id, trip_details_id, user_id, confirmation_number, payment_type... etc

注意： 行程详细信息行永远不会在3个表中共享。方法2不会减少冗余数据

编辑 为了帮助澄清，这些不是我的表格，我试图在摘要中弄清楚这一点。也许一个编程的例子也会有所帮助请不要过于关注实现细节，因为我正试图解决这样一个问题：“如果3个表都有5列，它们的类型相同，并且在概念上表示一个对象，那么该对象是否应该存在于自己的表中？即使将其移动到自己的表中也不会减少数据冗余？”

---

通常，在整个数据库中，所有表中的每个数据单元只应表示一次。例如，如果希望用户预订航班，可以使用三个表：

用户

飞行

预订

用户应包含与用户相关的所有数据（姓名、密码、地址等）

航班应包含与航班相关的所有数据（飞机、起飞时间、目的地等）。每一次飞机旅行都会在表格中有一行来描述它

然后，预订将保存所有保存的航班信息，并引用其他两个表（因此它必须包含userId和flightId作为外键，但在此之后，如果您愿意，可以添加其他信息）

预订表也将作为保存的航班列表加倍

编辑：为了澄清，如果您希望保存未预订航班的航班，您有两个选项。 1） 为保存的航班制作单独的表格。 2） 在您的预订/行程表中添加一列，指示航班是否已预订或保存

就我个人而言，我会使用选项2，除非与常规预订相比，有可能会有大量保存的搜索

EDIT2：你应该重新设计这个数据库。这里有三个表，都存储相同的信息。没有理由将“最近”和“保存”作为单独的表，也没有理由为此设置“最近”表

试着根据上述模式重新设计。因此，每个航班应该在数据库中表示一次且仅表示一次，每个用户表示一次且仅表示一次，然后预订的航班将是一个仅包含用户唯一id和航班唯一id的表

如果要保存航班而不进行预订，您可以复制book flights表并将其称为saved flights，也可以将其添加到同一个表中，该表具有确定航班是预订的还是刚刚保存的某些属性

我在这里看到的最大问题是，所有表都包含属性（from、to、execution和return）。所有这些都可以保存在一个表中，并在这里使用单个属性（flight_id）进行跟踪

即使您希望将保存的、最近的和预订的表分开，也可以这样做。目前，您有四个属性出现在三个表中，如果信息重复，则这应该是一个单独的属性

简短答复:

这样做：

航班（id（pk）、出发时间、出发时间、目的地、返回时间）

用户（id（主键）、姓名等）

最近（id（主键）、用户id（fk）、航班id（fk））

预订（id（主键）、用户id（fk）、航班（fk）、确认号等）

---

这将解决99%的问题。您将通过查询数据库而不是通过布局数据库的方式来处理其余的功能

首先，是的，总体思路主要是尽可能减少数据冗余/重复数据

但也有类似于您所介绍的情况，让我们总结一下，并告诉我，如果我在某个地方的解释是错误的：

有三个地方 1.行程详情 2.我保存的航班 3.预定的航班

这里的行程详细信息是对可用行程的一般搜索，您已将其保存在表“trips”中

“我保存的航班”是一个选项，用户可以在其中保存该航班，这样他们就不必搜索

迄今为止最好的方法：
在“My_Saved_Flights”表中，使用“Saved_on_date”和“User_ID”等数据从“trip”表中保存“trip_ID”
现在，当您将显示我保存的航班时，您将使用左连接获得行程以及当前价格和状态

现在第三个是预定的航班
这已经成为历史，所以你需要看到，正常的出行时间在某一天或某一天确实会发生变化？如果他们需要，您需要存储这些详细信息，否则您可以存储ID

我更喜欢部分存储，也就是说，在一个单独的文本列中存储有可能发生变化的内容

{departure_location: Orlando,destination_location: Miami,departure_date: 2016-05-05,return_date: 2016-05-10}

---

我希望我能帮上忙

听起来你会从了解更多有关的信息中受益。这是有用的信息。将它们移动到trip_details将无助于减少数据冗余，因为搜索可以与保存的航班具有相同的详细信息。规范化似乎只适用于防止数据重复的情况—您只需要三个表。旅行，得救了，波

var recentSearch = {
    tripDetails: {
        departure_date: '2015-01-05',
        return_date: '2015-01-10',
        from: 'Orlando',
        to: 'Chicago' 
    }
}

var savedSearch = {
    tripDetails: {
        departure_date: '2015-01-05',
        return_date: '2015-01-10',
        from: 'Orlando',
        to: 'Chicago' 
    }
}

var booked = {
    flight_id: 1234,
    confirmation_number: 3456,
    book_date: '2015-12-12'
    tripDetails: {
        departure_date: '2015-01-05',
        return_date: '2015-01-10',
        from: 'Orlando',
        to: 'Chicago' 
    }

}

{departure_location: Orlando,destination_location: Miami,departure_date: 2016-05-05,return_date: 2016-05-10}