使用实时数据库时,您最关键的一点是什么？

对于我的客户,我偶尔会在他们的实时数据库中工作,以便解决他们为自己创建的问题,或者为了修复我的产品错误创建的错误数据.就像Unix root访问一样,这很危险.我应该提前学到什么课程？

关于操作实时数据,你要做的第一件事是什么？

1> Paul Tomblin..：

---

BEGIN TRANSACTION;

这样你就可以在错误后回滚.

---

@Graeme,你不应该在生产数据库上做DDL.您应该编写一个脚本,在测试数据库上运行它,并在测试数据库通过QA后,然后在生产服务器上运行它.

---

Eduardo,到目前为止得到了45票,因为 - 大部分时间 - 你的手指在键盘上完全向下移动之前就开始出现冷汗 - 但是为时已晚,无法停止手指.

2> Dylan Beatti..：

---

多年来我学到了很多东西......

首先,如果您正在对实时数据进行更新或删除,请首先使用您将使用的WHERE子句编写SELECT查询.确保它有效.确保它是正确的.然后将UPDATE/DELETE语句添加到已知的工作WHERE子句中.

你永远不想拥有

DELETE FROM Customers

坐在您的查询分析器中等待您编写WHERE子句...不小心点击"执行",您刚刚杀死了您的Customer表.哎呀.

此外,根据您的平台,了解如何快速备份表格.在SQL Server 2005中,

SELECT *
INTO CustomerBackup200810032034
FROM Customer

将整个Customer表中的每一行复制到一个名为CustomerBackup200810032034的新表中,然后您可以在完成更新后删除并确保一切正常.如果发生了最糟糕的情况,那么从这个表中恢复丢失的数据比尝试从磁盘或磁带恢复昨晚的备份要容易得多.

最后,要警惕级联删除删除你不打算删除的东西 - 在修改任何内容之前检查你的表的关系和关键约束.

---

或者更好,但不要使用级联任何东西.

3> warren..：

---

先做备份:它应该是系统管理的第1号法则

编辑:结合其他人的说法,确保您的更新有适当的WHERE条款.

理想情况下,永远不应该更改实时数据库(超出INSERT和基本维护).改变实时数据库的结构尤其充满潜在的不良业力.

4> Bob King..：

---

对副本进行更改,当您满意时,请将修复程序应用于实时.

5> Patrick McEl..：

---

通常在我执行UPDATE或DELETE之前,我会编写等效的SELECT.

6> Patrick Szal..：

---

除非你在BEGIN TRAN t1中,否则不要进行更新 - 不是在开发人员数据库中,不是在生产中,不是在任何地方.永远不要在评论之外运行COMMIT TRAN t1 - 始终输入

--COMMIT TRAN t1

然后选择语句以运行它.(显然,这仅适用于GUI查询客户端.)如果你做这些事情,它将成为第二天性,你几乎不会失去任何时间.

我实际上有一个"更新"宏来键入它.我总是粘贴它来设置我的更新.您可以为删除和插入创建类似的一个.

begin tran t1
update 
set 
where 
rollback tran t1
--commit tran t1

7> Wayne..：

---

始终确保您的UPDATE和DELETE具有正确的WHERE子句.

8> Kevin Conner..：

---

回答我自己的问题:

编写更新语句时,请按顺序写入.

写 UPDATE [table-name]

写 WHERE [conditions]

回去写吧 SET [columns-and-values]

在说出要更改的值之前选择要更新的行比在其他顺序中执行更安全.这使得无法update person set email = 'bob@bob.com'坐在您的查询窗口中,准备好通过错误的击键运行,准备好弄乱表中的每一行.

编辑:正如其他人所说的那样,在写WHERE之前为你的删除写下条款DELETE.

9> wcm..：

---

作为一个例子,我像这样创建SQL

--Update P Set
--Select ID, Name as OldName, 
    Name='Jones'
From Person P
Where ID = 1000

我突出显示从最终到Select并运行该SQL的文本.一旦我确认它正在拉动我想要更新的记录,我点击升级到高亮显示Update语句并运行它.

请注意,我使用了别名.我永远不会更新表名明确.我总是使用别名.

如果我与事务和回滚/提交一起执行此操作,我真的非常非常安全.

10> Gabriel Isen..：

---

我是一个小心使用实时数据库的方法吗？别碰它.:)

备份可以撤消您对数据库造成的损害,但在这段时间内您仍可能会产生负面影响.

无论你认为你正在使用的脚本有多么坚固,都要经过一个测试周期.即使"测试周期"意味着针对您自己的数据库实例运行脚本,也要确保执行此操作.与生产环境相比,在本地盒子上引入缺陷要好得多.

11> dmercer..：

---

检查,重新检查并再次检查正在进行更新的任何规则.即使你认为你只是做一个简单的单列更新,迟早你也没有足够的咖啡而忘记了'where'条款,整个表格都在筹码.

我发现其他一些有用的东西:

如果使用MySQL,请启用安全更新

如果您有DBA,请让他们这样做.

我发现这3件事让我不会受到任何严重的伤害.

12> Georgi..：

---

没有人想要备份,但每个人都渴望恢复

使用外键引用创建数据库,因为您应该:

让自己尽可能地更新/删除数据并破坏结构完整性/其他东西

如果可能,在永久存储更改之前必须提交更改的系统上运行(即在修复数据库时取消激活自动提交)

尝试识别您的问题的类,以便您了解如何解决问题

获取将备份添加到数据库中的例程,总是在手头的测试服务器上有第二个数据库,这样您就可以开始工作了

因为记住:如果某些事情完全失败,你需要尽可能快地重新启动和运行

嗯,这就是我现在能想到的一切.采取大胆的段落,你会看到我最新的#1.;-)