什么是你的第一个方法要小心一个实时数据库？
对于我的客户，我偶尔会在他们的实时数据库中工作，以便解决他们自己创build的问题，或者修复产品缺陷所造成的不良数据。 很像Unix root访问，这只是危险的。 我应该提前学习什么课程？
在实时数据上操作时要注意什么？
这三年来我学到了三件难事…
首先，如果您正在更新或删除实时数据，请首先使用您将使用的WHERE子句编写一个SELECT查询。 确保它的工作。 确保它是正确的。 然后将UPDATE / DELETE语句预先添加到已知的工作WHERE子句中。
你永远不想拥有
DELETE FROM Customers 坐在你的查询分析器等着你写WHERE子句…意外地打“执行”，你刚刚杀了你的客户表。 哎呀。
另外，根据您的平台，了解如何对表格进行快速备份。 在SQL Server 2005中，
SELECT * INTO CustomerBackup200810032034 FROM Customer
会将整个客户表中的每一行复制到一个名为CustomerBackup200810032034的新表中，然后在完成更新后删除，并确保一切正常。 如果最糟糕的情况发生，从表中恢复丢失的数据要比从磁盘或磁带恢复昨晚的备份容易得多。
最后，要小心级联删除摆脱你不打算删除的东西 – 在修改任何东西之前检查你的表的关系和关键限制。
BEGIN TRANSACTION;
这样你就可以在出错后回滚。
首先做一个备份：它应该是系统pipe理的第一条法则
编辑 ：纳入其他人说，确保你的更新有适当的WHERE子句。
理想情况下，更改现场数据库绝不应该发生（超出INSERT和基本维护）。 改变现场数据库的结构尤其充满了可能的恶业。
对您的副本进行更改，当您满意时，请将修复应用到现场。
通常，在我执行UPDATE或DELETE之前，我会编写相应的SELECT。
切勿进行更新，除非您处于BEGIN TRAN t1中 – 不在开发数据库中，不在生产中，不在任何地方。 永远不要在注释之外运行COMMIT TRAN t1 – 始终键入
--COMMIT TRAN t1
然后select语句才能运行它。 （显然，这只适用于GUI查询客户端。）如果你做这些事情，它将成为第二性质，你几乎不会失去任何时间。
我实际上有一个“更新”macros，types这个。 我总是粘贴这个来设置我的更新。 你可以做一个类似的删除和插入。
begin tran t1 update set where rollback tran t1 --commit tran t1
始终确保您的UPDATE和DELETE具有适当的WHERE子句。
回答我自己的问题：
在编写更新语句时，请按顺序写入。
- 写
UPDATE [table-name] - 写入
WHERE [conditions] - 回去写下
SET [columns-and-values]
select你想要更新的行之前，你说什么值你想改变比其他顺序更安全。 这使得update person set email = 'bob@bob.com'无法坐在您的查询窗口中，准备通过错误的按键来运行，准备好弄乱表格中的每一行。
编辑：正如其他人所说的，在写入DELETE之前，为删除写入WHERE子句。
作为一个例子，我创build这样的SQL
--Update P Set --Select ID, Name as OldName, Name='Jones' From Person P Where ID = 1000
我突出显示从最后到select并运行该SQL的文本。 一旦我确认它正在拉出我想要更新的logging，我就打开升级语句并运行它。
请注意，我使用了别名。 我从不更新表名称的明确性。 我总是使用别名。
如果我和事务和回滚/提交一起做，我真的很安全。
我的＃1方法要小心一个实时数据库？ 不要碰它。 🙂
备份可以撤消对数据库造成的损害，但是在这段时间内，您仍然可能引入负面影响。
无论你认为你正在使用的脚本有多坚实，都要经过一个testing周期。 即使“testing周期”是指针对您自己的数据库实例运行脚本，请确保您执行此操作。 在本地盒子上引入缺陷要比生产环境好得多。
- 检查，重新检查，并再次检查正在进行更新的任何陈述。 即使你认为你只是做一个简单的单一列更新，迟早你也不会有足够的咖啡，忘记了一个'where'子句，整个桌子就是这样。
其他一些我发现有用的东西：
-
如果使用MySQL，启用安全更新
-
如果你有一个DBA，要求他们这样做。
我发现这三样东西使我没有受到任何严重的伤害。
- 没有人希望备份，但每个人都渴望恢复
- 用外键引用创build你的数据库，因为你应该：
- 尽可能让自己更新/删除数据，并破坏其结构完整性/其他内容
- 如果可能的话，在永久存储它们之前必须提交更改的系统上运行（例如，在修复数据库时停用autocommit）
- 尝试找出你的问题的类，以便您了解如何解决没有麻烦
- 在数据库中备份数据库的例程，在testing服务器上总是有第二个数据库，所以你可以在这个数据库上工作
- 因为记住： 如果某件事情完全失败了，你需要尽可能快地起步和跑步
那么，现在我只能想到了。 采取大胆的段落，你看到什么对我来说＃1。 😉
也许考虑不要使用任何删除或下降。 或者，也许减less用户权限，以便只有特殊的数据库用户可以删除/删除的东西。
如果您正在使用Oracle或其他支持它的数据库，请在执行COMMIT之前validation您的更改。
数据应该总是通过脚本进行部署，通过脚本可以进行多次排练，以便在dev上正确使用。 当脚本的相关数据在dev上正确运行的时候，如果你真的想要小心的话，那么你就不能逃避这一步。
检查两次，提交一次！
在开始之前备份或转储数据库。
要增加@ Wayne所说的，在DELETE或UPDATE语句的表名之前写下你的WHERE 。
备份您的数据。 了解到，定期与客户数据库合作的难题之一。
总是添加一个使用子句。
我的规则（作为应用程序开发人员）：不要触摸它！ 这就是训练有素的DBA所为。 哎呀，我甚至不想去碰它。 🙂
每个环境的颜色不同：我们已经安装了PL \ SQL开发者（IDE for Oracle），所以当你login到生产数据库时，所有的窗口都是鲜红的。 有些甚至为开发和testing指定了不同的颜色。
确保在删除logging时指定一个where子句。
总是先testing任何超出开发数据select的查询，以确保它具有正确的影响。
- 如果可能，请求与某人配对
- 在回车之前总是数到3（如果单独使用，会激怒你的配偶！）
如果我用脚本更新数据库，我总是确保在脚本开始时放置一个或两个断点，以防万一我偶然碰到运行/执行。
在你的UPDATE之前，我会添加BEGIN TRAN的build议，不要忘了实际执行COMMIT; 如果您保留未提交的交易，您可以承担同样的损失。 在更新过程中，不要被电话，同事，午餐等分散注意力，否则在COMMIT或ROLLBACK之前，您会发现其他人都被locking。
在查询分析器中编写特别查询时，我总是注释掉任何破坏性查询（插入，更新，删除，删除，更改）。 这样，运行它们的唯一方法是突出显示它们，而不select注释部分，然后按F5键。
如前所述，我也认为这是一个好主意，首先用select来写你的where语句，并确保你正在修改正确的数据。
- 改变之前总是备份。
- 总是通过脚本来制作mods（例如ALTER TABLE）。
- 始终通过存储过程修改数据（例如，DELETE）。
创build一个只读用户（或者让DBA来做），并且只使用该用户来查看数据库。 为模式添加适当的权限，以便查看存储过程/视图/触发器/ etc的内容。 但没有能力改变他们。
