针对生产数据进行开发是不是很糟糕？
我一直听说根据生产数据进行开发是不好的做法，目前我正在转向 Dev> Stage> Production 模型，这主要是因为我有一名技术极少的新员工我宁愿不让他直接使用生产数据。
但是很长一段时间以来，我一直在直接处理生产数据，而且头痛很少，除了可能会有一些错误在这里或那里蔓延，例如拼写问题，糟糕的alt文本，链接指向错误的位置。这似乎是由于我缺乏同行评审，而不是因为使用实时数据。
那么为什么在现场开发这样糟糕的做法呢？
如果在开发期间运行的SQL命令包含现有数据库表上的INSERT或UPDATE，那么您将面临这些数据库表关键任务的风险。
有些地方会在某个时间间隔将生产数据同步到开发数据库中，例如，每周一次或在开发人员请求中，以便您开发新的数据。
但是，如果您的生产数据没有受到您正在进行的操作的风险，例如，如果您只是开发一些数据视图，通常这不是什么大问题。现在，如果您正在运行执行表扫描的报表，那么您可能会锁定表，然后您的现有用户会受到影响。
在这样的情况下我会推荐我的数据库管理员，如果没有“官方”DBA，我会谨慎行事。即使对我自己来说，创建开发数据库也很简单。在团队中，这是至关重要的。如果不这样做，如果你坚持只使用一个数据库，你可以在开发数据库表的前面添加DEV_并且感觉好一些。是的，这需要一些代码更改，但在开发中添加一些变量$debug = true等等，通常是值得的。
有很多方法可以解决这个问题。这非常依赖于你的情况。
您不希望针对生产服务器上的生产数据进行开发。有几个很大的原因。
- 开发会降低生产速度，并产生漏洞。如果您将计算机解锁并离开，会发生什么？
- 如果您犯了错误，访问您网站的人可以看到它。
- 如果您在数据库中的事务内部进行任何类型的数据更新，并且您没有立即提交它，或者事务需要一段时间才能完成，您将锁定所涉及的所有表，并且可能导致超时发生。
- 某些数据库系统，特别是SQL Server将仅在SELECT语句上执行表锁定！这意味着您可能无意中在网站上为人们提供超时或错误页面。
如果可能的话，我永远不会在活箱上进行开发工作。最好的办法是备份数据库和页面，然后使用副本然后推送更新。帮助我的一个工具是Msft的SyncToy。
好吧，你真的搞砸了数据。想象一下，在一个where子句中。即使你有每小时的备份，这也很难解决。
如果您有可用的生产数据，则使用它们进行测试是合理的，但是使用单独的测试数据库以及该数据的副本。否则很多东西都适用于你的少数“blabla”测试记录，但不适用于真实场景。
并且为了开发现场制作数据 - 记住墨菲定律“任何可能出错的东西都会出错。”而且很容易犯一个小错误，带来很大的不良后果。
如果您在没有安全带的情况下不开车，请不要开发生产数据。只是一个安全问题。