根据生产数据进行开发是否不好？

我一直听说，根据生产数据进行开发是一种不好的做法，并且目前正朝着Dev> Stage> Production模型发展，这主要是因为我有一个技能最低的新员工，而我宁愿没有他还可以直接处理生产数据。

但是很长一段时间以来，我一直以最小的麻烦直接使用生产数据，除了可能在这里或那里出现一些错误，诸如拼写问题，错误的替换文本，指向错误位置的链接之类的东西。这似乎是由于我缺乏同行评议，而不是因为使用实时数据。

那么，为什么在实时站点上进行开发却是如此糟糕呢？

如果在开发过程中运行的是包含现有数据库表INSERT或UPDATE在现有数据库表上的SQL命令，则可能会冒着那些数据库表对任务至关重要的风险。

有些地方每隔一段时间（例如，每周一次或应开发人员要求）将生产数据同步到开发数据库中，以便您可以使用新数据进行开发。

但是，如果您的生产数据不会受到您所做工作的威胁，例如，如果您只是在开发某些数据的视图，通常这没什么大不了的。现在，如果您正在运行进行表扫描的报告，则有可能锁定表，然后现有用户会受到影响。

在这种情况下，如果没有“官方” DBA，我会请我的数据库管理员处理，我会谨慎一些。创建一个开发数据库非常简单，甚至对我自己也是如此。在团队中至关重要。失败的话，如果您坚持只拥有一个数据库，则可以给开发数据库表加上前缀DEV_并感觉好一点。是的，这需要进行一些代码更改，但是在开发中$debug = true，在开发等过程中添加一些变量通常是值得的。

有很多方法可以解决这个问题。这非常取决于您的情况。

您不想在生产服务器上针对生产数据进行开发。有两个重要原因。

1. 开发会减慢您的生产速度并产生漏洞。如果您使计算机处于解锁状态并走开，该怎么办？
2. 如果您输入有误，则访问您网站的人可以看到它。
3. 如果您在数据库中的事务内进行任何类型的数据更新，而没有立即提交，或者事务需要一段时间才能完成，则将锁定所有涉及的表，并且可能导致超时。
4. 一些数据库系统，特别是SQL Server，有时会仅在SELECT语句上做表锁定！这意味着您可能会无意中使网站上的用户超时或出现错误页面。

如果可能的话，我永远不会在现场进行开发工作。最好的选择是对数据库和页面进行备份并使用副本，然后推送更新。Msft的SyncToy是帮助我大忙的一个工具。

好吧，您真的可以将数据弄乱。想象一下，放弃where子句。即使您每小时进行一次备份，也很难解决。

如果您没有系安全带就不要开车，就不要开发生产数据。只是一个安全问题。

如果您有可用的生产数据，则可以合理地使用它们进行测试，但请使用单独的测试数据库以及该数据的副本。否则，许多事情将对您的少数“ blabla”测试记录起作用，但对实际情况却无效。

对于使用实时生产数据进行开发，请记住墨菲定律“任何可能出错的地方都将出错。”，很容易犯一个小错误，带来严重的不良后果。