问题标签 [vertical-partitioning]

我面临着必须向已经有 32 列的表添加 64 个新列。例如：

大多数情况下，这些新列中的大多数将包含null.

如果我将这 64 个新列垂直分区到一个新表中，那么每次 iSELECT来自客户：

必须将其转换为连接才能获得分区值（即，在我不需要新列的地方永远不会获得性能提升）：

所以这是对列进行分区的一个缺点。

另一个缺点是我必须同时管理将行插入两个表，而不仅仅是一个。

我能想到的最后一个问题是，SQL Server 现在必须在INNER JOIN我想访问“客户”的任何时候执行。现在和永远都会浪费 CPU 和 I/O 来连接真正是一张表的表 - 除了我决定将它们拆分。

所以我的问题是：我为什么要把它们分开？

当它们大部分为空时，将 64 列垂直分区到单独的表中是否有任何价值？Null 占用的空间很小....

有哪些优点？

编辑：为什么我还要考虑分区？它主要是空数据，将使表中的列数增加三倍。肯定是坏了！

We'll be converting a fairly long lease application form into a web application for submission via PHP in to a PostgreSQL database.

I abide by the maxim "Normalize till it hurts, then denormalize till it works" (Attr:SQLMenace) but as I jump in I figured I'd tap the collective mind.

Here is what the paper form currently looks like: http://www.borgermanagement.com/forms/commercialApplication.pdf (not the actual form but close)

A lot of the data is mandatory and will be submitted over a couple of views with the option to save a partially completed application for completion at a later date. The submitted application will be reviewed for approval (preferably in one view similar to the pdf). There isn't likely to be much in-depth analysis of the data down the road.

How would you structure your data in this case? To normalize or not? To vertically partition or not?

我最近向表中添加了 LastUpdate 列，并添加了一个触发器以保持更新。由于我不想讨论以免侮辱与我一起工作的任何人的原因，已决定由于 LastUpdated 列将很少使用，我们应该使用垂直分区并将该列存储在单独的表中。这对我来说似乎有点过分，因为该表已经包含 43 列。有人建议我可能会支持他们做得太过分了吗？或者他们真的是对的？

编辑（9/29）
对不起，我是一个可怕的人！“他们”决定不对表格进行垂直分区，所以我忘了回到这个问题。为了完成我开始的事情......

@JNK，该表仅包含仅包含 Id 列（即“身份”）的 PK。

@elevener，感谢您的输入。如果“他们”决定我们应该继续在这个表或其他表上进行垂直分区，这肯定会有所帮助。

我有 4 张桌子

我希望另一个表 E 可以仅引用 B OR C（而不是 D）。我可以在里面写什么

?

我有一个有 60 列的表，并且想对其进行垂直分区，或者更像将其划分为按列划分的更多小表。如何使用 postgres 9.2 在数据库中进行垂直分区？做了很多谷歌，但找不到任何有用的东西。

我要垂直分区的表是：

提前致谢

我有一个 mysql 数据库以每年 45-50% 的速度增长。在过去的几年里，它的大小已经增加到相当大的数量，现在导致生产中的性能问题。

在测试环境中分析它时，我发现有一个表有大约 20 列，其中 4-5 列类型为 longtext。这有大约 180 万条记录，并且经常被应用程序访问。我浏览了许多 mysql 性能博客，并感觉到垂直分区在这种情况下可能会有所帮助，所以想尝试一下手动将表分成两部分，一个表中的所有 logntext 列和另一个表中的其他列由主键映射的表，并观察到导致问题的同一查询的性能提高了 80%。

现在，我不确定是否可以在不手动破坏表的情况下在数据库级别实现垂直分区，就像我使用手动选项一样，这将需要对代码和查询进行大量更改，这可能会导致生产中出现其他一些意外。

请建议 MySql 是否真的支持数据库级别的垂直分区。我试图用谷歌搜索它，但只找到了水平分区的例子，没有提到垂直分区。感谢您对此的帮助。

PS 我不是数据库专业人士，所以我所做的一切都是基于 MySql 博客/论坛上的建议/反馈。

谢谢

我努力通过垂直分区优化我的表的性能。以下 Select 语句应该从 postgre imho 中得到更多优化：

我的架构如下所示：

SQL：

因此，您可能会认识到我并不真的需要 ProductB 来进行选择查询。然而，正如您在此处看到的，它在执行过程中被加入。

我的问题是如何强制 postgre 只扫描 ProductA？我是否需要额外的约束，编辑配置文件，还是无法通过 postgre 中的垂直分区获得性能优势？提前非常感谢。:)

我目前正在处理一个项目，我必须处理很多用户字段（+/- 80）。我的第一种方法是（现在仍然是）将用户表垂直划分为 4 个表：主要信息、管理信息、银行信息、统计信息。3 个额外表行的 id 是指主表的自动递增 id。

我的问题是：

1. 这样做是否相关？
2. 看起来，通过我进行关联的方式，Doctrine 无法一次性将一个对象刷新到数据库中：

MyVendor\User\UserBundle\Entity\UsersInfosBank 类型的实体缺少为字段“id_user”分配的 ID。此实体的标识符生成策略要求在调用 EntityManager#persist() 之前填充 ID 字段。如果您想要自动生成标识符，则需要相应地调整元数据映射。

该项目将在 3 周内投入生产，因此我们仍然能够回到更传统的方式将这些数据存储到一个巨大的表中……

****************更新*****************

下面是完整的代码逻辑*******************

我刚刚删除了大部分与我的问题无关的属性和方法……</p>

是的，我正在使用 FOSUserBundle ;)

用户主要

用户信息管理员

用户信息统计

这是我创建用户的方式（通过安全的管理区域表单）：

我正在使用 mysql，我有一个用户表，其中包含一些基本信息，如姓名、姓氏、年龄、性别等。我想提供一个名为 profile 的功能，用户将在其中放置其他信息，如工作地点、替代联系方式等. 这些新的栏目不是固定的，以后可以有更多的栏目。据我所知，可以有两种方法：

1) 每次需要时添加新列，这会将 Null 条目放置到新添加列的先前行中。

2）添加一个新表，其中将包含所有列名称的列 ID，以及一个包含键值之类的结构的表，每个用户具有该特定新列的条目，如下所示：

表 1：用户 ID | 名字 | 年龄 | ……

表 2：列 ID | 列名 | 数据类型

表 3：用户 ID | 列 ID | 价值

哪种方法适合我的方案？

我想垂直拆分现有的（已经填充了数据）。

假设我的起始表 ( trip) 如下所示：

我想把这张表分成两张表，应该是，一张 forperson和trip。

将每个唯一的人复制到表中person时，我希望将该表中自动创建的uniqueidentifier列person.pId（主键）复制到原始表中新创建的uniqueidentifier列trip.personid中，并将其转换为外键。（然后我会从原始表中删除trip.personandtrip.age列，并根据我的需要对数据进行结构化。）

当我将人员行插入新表时，我想我可以使用触发器，如下所示：

但是，我明白了：

SET显然，触发器仅在执行了所有（可能是多个！）插入之后才执行，并且到那时我的语句不再允许对插入的查询。

我也想过OUTPUT在语句上使用一个子句INSERT，但这也行不通

所以我现在想知道，这一切都错了吗？是否有另一种方法可以自动创建两个新拆分的表之间的键和关系？

编辑期望的结果：餐桌旅行：

表人

（ID 字段当然应该都是唯一标识符）