我应该删除(SQL和数据库)什么?

我很好奇,我应该删除任何东西吗? 现在我正在build立一个网站(为我自己),允许您订阅用户,然后每次用户上传内容时都会收到一条消息。

或者评论,如果有一个线程,有人写你的评论的直接评论,你会得到一个消息这样说。 我应该删除这些还是只是简单地隐藏它?

每个订阅有三个(64位)int。 id,commentId,recipientId。 你可以通过commentIdfind谁在给你写评论表。 如果我不使用删除它将有一个第四个诠释状态(显示,隐藏/删除)。

我应该离开还是删除它们? 如果我应该删除它们,那为什么? 我可以看到,也许当有个人用户,你必须删除请求,但其他那么我应该删除?

我不知道我将使用哪个SQL数据库

-编辑-

多谢你们。 现在,除了我可以生成的东西,我什么也不删除。 比如那个订阅的东西呢。

我所在的公司为某些受pipe制行业的人员提供软件,所以一般情况下我都有“不要删除任何东西 ”的态度,因为如果你删除了任何东西,就失去了审计线索的完整性。 而是将信息标记为已删除(或将其移动到表格的存档版本),并logging谁“删除”以及何时“删除”。

真正删除的唯一原因是

  • 如果您的空间不足(但这些日子磁盘便宜)
  • 为了提高效率(但是如果你的数据结构是很好的索引而不是很糟糕的话,
  • 出于法律原因(如果您被要求删除某人的详细信息,您将很可能必须遵守,这取决于当地的数据保护法律,或者内容本身违反了某些法律)

如果用户不小心删除了一些有用的内容,并且可以将其恢复,那么您的用户可能会感激不到任何真正被删除的内容。 如果以前向网站提供有价值的信息的用户感到厌恶,并且在复仇时删除所有post,则可以轻松地撤消删除操作。

另一个非常重要的问题是:你必须在服务条款中明确指出,当用户看不到时,信息可能不会真正被删除,并提供一个path(如果只是“发送电子邮件x @ xx并请求做)“),让他们真正删除有权依照相关法律要求删除的数据。

通常,今天的现代磁盘大小和IO性能意味着您不必删除logging以节省空间或保持性能。 通常,logging中的“logging已删除”字段可将logging标记为已删除(或作为其他状态)与审计跟踪。

一些行业要求您出于监pipe原因不要删除“交易”数据。 你已经知道你是否需要这样做。 如果有任何付款信息,您通常需要保留7年的数据(或提供数据)(英国会计法)。

出于其他目的,实际上有一个很好的理由来物理删除数据。

如果不在那里,这是不可发现的。

“信息自由法”(在英国)规定,如果数据是可以被发现的,那么它被包括在search范围之内。 这包括“软删除”logging和历史备份。

对于某些系统,我们确保我们清理旧的logging,并在'如此之多'之后重新使用/销毁旧的备份磁带/文件,以确保它不可用于FOI请求。 (维护一个可以追溯到几年的FOI请求,并且需要从档案备份中恢复数百个旧邮箱,成本非常高)。

这与OPERATIONAL备份不同。 我们保留备份,以便在发生灾难时进行恢复。 我们还有一个“logging存储”,用于纸质和电子媒体,必须保存,我们将电子邮件等复制到该商店。

我的直觉是永远不会删除任何东西。 你永远不知道什么时候可能需要它。 如果我不得不从工作表中删除数据出于任何原因,我倾向于将其移动到一个归档表。

话虽如此,如果是自己使用的数据,这可能是矫枉过正的,不可思议的是有任何法律上的理由看到旧的数据。 你没有多说你的应用程序,但是一个用户可以要求查看旧数据,理由是另一个用户已经诽谤他们?

JR

是否删除取决于您可用的资源数量和您要收集的数据量。 我已经在不允许删除的地方处理过项目。 这只是意味着所有的数据项目都会得到一个开始date和结束date。 数据项在此期间将是有效的,而不是之前,之后。 因此,可以通过将结束date设置为今天来“删除”某些内容。
不幸的是,这也意味着你必须检查你想要select的每个数据项目的当前date。 使用SQL,这将需要额外的条件来查询。
其实,更糟的是,你甚至可以考虑禁用编辑。 当一个数据项被编辑时,你只需要设置结束date到现在,并使用相同的键和修改来创build一个新的数据项。 这样,你将收集大量的数据,但这将是非常历史的,没有被删除。 在这种情况下,开始/结束date还应包含一个时间组件。 (当时钟倒转一个小时的时候,你不得不担心夏令时)。但基本上,你的系统只会插入新的项目,而不是修改或删除任何东西。

你必须决定你的数据是否值得永久保存! 大家都说磁盘很便宜,但那不是全部的事实。 这取决于您的存储解决scheme和您的环境。

如果在SAN上使用光纤通道磁盘,并且磁盘空间不足,则由于arrays空间不足而需要添加另一个磁盘arrays,因此不再便宜。

在你的情况下,似乎你不会存储大量的数据,磁盘空间可能不是一个问题,但你的数据在10年有多相关?

另外要考虑的是整体性能,而不仅仅是磁盘空间。 我认为将历史数据存储在另一个表中,甚至另一个数据库中是一个好主意。 这样我就less了维护等等。我知道,还有其他的解决scheme来存档历史数据,比如分区,但是如果它的数据没有定期使用,为什么要实现更复杂?

在过去的6年中,我一直在大型数据库中工作,如果您有一张拥有5亿个logging的表格,那么索引策略是非常具有挑战性的。 :)如果您的查询使用索引查找,但是索引不包含您需要的所有数据,那么将在索引中find的每个logging都使用聚簇索引查找。 假设你得到10%的表格,你最终将有5万个聚集索引查找,而且这根本不便宜。 它不花你的钱,但它会花费你的performance。

/HåkanWinther

你不应该删除的原因:

  1. 你以后可能会想要

您应该删除某些内容的原因:

  1. 你想确保没有未经授权的人可以再次阅读(例如,一个存储的信用卡号码:如果你删除了入侵者不能得到它)
  2. 您希望确保不能向您索取信息(例如,通过信息自由法的要求)
  3. 由于空间或速度的原因,您希望保持较小的数据大小(适当的索引和分区可以帮助解决速度问题)。
  4. 您需要依法删除(例如隐私法)。

这总是一个权衡,但保持太多数据的法律意义是重要的。 隐私和安全是这些日子经常被忽视的事情。 实际的数据库性能可能不需要删除数据,除非数据集很大。 即使是具有数百万行和数十列的表,也可能不需要删除,如果您正确分区并确保您的查询始终使用适当的分区。 至于法庭命令或FOIA要求您存储的数据,那么只有您可以决定您对此的感受,以及您的客户感受如何。 我限制使用Gmail的一个原因正是这个原因:我的数据存储在美国(我在加拿大),美国机构甚至可能访问我的已删除邮件。

同时请记住,隐私,安全和“信息自由法”的法律因国家而异; 你需要知道你所在的每个国家的这些法律。 也许如果你的服务器都在一个国家限制外国法律的范围,但也许没有。 如果您的数据敏感,请咨询律师。

您真正要问自己的问题是:保存数据的成本(增加的存储成本,保留可删除数据的责任)比删除数据的成本便宜(写入删除查询的工时,删除需要保留的数据的责任,以及由于运行删除查询而导致停机或性能降低的可能性)? 无论哪个更便宜,随它去吧。

我可以看到脱机存档和/或删除数据的一种情况是,当您运行OLAP查询来汇总数据并将其存储在汇总表中时。

每月网站统计就是一个很好的例子。 一旦您为2009年6月生成了多个网页浏览量,这绝不会改变。 而且,从汇总表中添加所有页面视图会更快,然后扫描包含当前月份的在线交易的表格,而不是扫描整年的日志并生成完全在线的报告。

如果是我,我将确保将联机表复制到“2009年6月”,运行汇总查询并将数据保存到汇总表中,然后存档复制的联机表,然后删除所有条目原来的在线表格。 但是我也有点偏执!

一般来说,在任何地方,使用OLAP生成汇总数据的效率更高,因为这样的数据在此之前是静态的,因此可以对旧数据进行归档/删除。 否则,不,我使用删除标记系统,以避免打破与我通常广泛的活动日志logging系统的关系完整性。