blocks|key|387661|text|这取决于很多变量。通常，将它们放在不同的服务器上会更好。这实际上取决于您如何使用sql+server。如果你只有数据库，不要使用太多的管理工具，比如夜间进程来修改数据和其他工作，你可能没问题。但是，从开发数据库到生产数据库的开发过程中，您确实面临着代码溢出的风险。将它们分开比较安全，特别是对于创建sql+server的开发实例所需的少量资金而言。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|387662|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

It depends on a lot of variables. It's generally better to have them on different servers. This is really depending on how you use sql server. If you just have databases, don't use a lot of the management tools, like nightly processes to alter data and other jobs you might be OK. You are running a real risk of having bleed over code from developing on the dev database to the production one though. It's safer to have them separated out, especially for the small amount of money needed to create a dev instance of sql server.

blocks|key|1686222|text|我不认为我会那么做。如果只有我，那么当然：)但是如果有一群人，天知道他们会运行什么查询。对于这样的事情，我们总是使用测试服务器。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1686223|致以最好的问候，唐|1686224|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

i don't think i'd do that. if it was just me, then sure:) but if there's a bunch of people god only knows what queries they might run. we always use a test server for such things.

best regards,
don

blocks|key|387028|text|最佳实践是使用独立的服务器。其次，在同一台服务器上使用独立的实例。其次，在实例上使用单独的数据库。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|387029|但是，无论选择哪种隔离机制，我都不会让任何开发人员将RDP放入生产SQL+Server+(或生产任何东西)中。使用单独的终端服务器，其中包含工具和所有内容。|387030|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Best practice would be separate servers. Next best, separate instances on same server. Next best, separate databases on a instance.

However, I wouldn't be letting any developers RDP into a production SQL Server (or production anything), regardless of choice of segregation mechanism. Use a separate terminal server with tools and everything there.

blocks|key|387081|text|您可以在同一实例上使用dev和prod+db。只需确保设置了权限，这样开发人员就不能接触prod数据库。消极的是在dev中长时间运行的查询将影响prod。在SQL+SERVER+2005中，更好的解决方案是有一个dev+"instance“和一个prod+"instance”。然后是有人在你的dev实例上做了错事，然后就把那个疯狂的东西拿下来了。在SQL+server2008中，您可以设置CPU使用计划，这有助于限制可以使用多少资源。你应该对此进行调查。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|387082|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

You can have dev and prod db on the same instance. Just make sure the permission are setup so that developers cannot touch the prod db. The negative is a long running query in dev will impact prod.
In SQL SERVER 2005 a better solution is to have a dev "instance" and a prod "instance".
Then is someone mis-behaves on the dev instance you and just bring down that insance.
In SQL server 2008 you can setup up CPU usage plans which can help throttle how much resources can be used. You should investigate that.

blocks|key|387062|text|我发现这是一种糟糕的做法，原因如下：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|387063|首先，假设你的一个开发人员搞砸了，做了一些事情，最终占用了你服务器的所有处理能力。Oops+prod没有好的原因而关闭了。|387064|其次，开发人员很容易更改错误的数据库。Oops+prod没有好的原因而关闭了。至少，您可以通过不给开发人员任何产品权利来避免这种情况(作为最佳实践，您无论如何都应该这样做)。|387065|第三，如果数据库在同一台服务器上，它必须有一个不同的名称，这会使移动到prod的东西变得困难和容易出错。我认为这也意味着你不太可能通过源代码控制的脚本正确部署。如果您选择将对象从一个数据库复制到另一个数据库，那么您也会遇到问题。首先，如果对象中已经有数据，您可能会意外地将其清除(希望您有备份)，或者您可能会移动新的表结构，但会错过诸如PKs和FKS以及默认值、触发器、约束和索引等内容，或者向导可能需要更长的时间才能完成移动，因为它在后台创建和填充新表，然后删除旧表并重命名新表，而不是使用alter+table。Oops+prod停机或严重减慢，没有充分的理由。|387066|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

I find this a poor practice for several reasons:

First suppose one of your devs messes up and does something that ends up taking all of the processing power of your server. Oops prod is down for no good reason.

Second, devs could easliy change the wrong database. Oops prod is down for no good reason. At least you can avoid this by not giving any production rights to devs (which you should be doing anyway as a best practice.)

Third, if the database is the on the same server it has to have a different name, this can make moving things to prod difficult and error prone. I think it also means it will be less likely that you deploy correctly through source controlled scripts. If you choses to copy objects from one database to the other, then you can have issues with that as well. First if there is data in the object already, you may accidentally wipe it out (hope you have a backup) or you may move the new table structure but miss things like the PKs and FKS and default values and triggers and constraints and indexes or the wizard might take much longer to do the move because in the background it is creating and populating a new table and then droping the old and renaming the new one rather than using alter table. Oops prod is down or seriously slowed for no good reason.

blocks|key|387828|text|我倾向于同意“独立服务器”的观点，尽管我们公司的大多数日常开发工作都是在本地机器上完成的--因此我们在本地安装了SQL+Server。当然，如果您正在开发报表或需要生产数据的东西，这可能是一件痛苦的事情。在这种情况下，这里的开发人员通常会得到导出的生产数据的一个子集，以便使用。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|387829|然而，对于验收测试和部署，我们确实使用了单独的实例。|387830|开发人员可能不应该拥有生产访问权限，除非他们也是进行应用程序部署的人(就像我所在的小团队一样)。如果您最终在同一服务器上使用不同的DB，我至少会锁定RDP访问，并单独授予对每个开发DB的访问权限。这就是它在这里的工作方式--目前我对我们的任何服务器都没有管理权限，只能管理专门属于我的团队的应用程序的数据库。|387831|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

I tend to agree with the "separate servers" folks, although with my company we actually do most of our day to day development work on our local machines -- so we have SQL Server installed locally. This can be a pain, of course, if you're developing reporting or something that needs production data. In that scenario, developers here usually get a subset of production data exported to work with.

For acceptance testing vs. deployment though, we do use separate instances.

Developers probably shouldn't have production access UNLESS they're also the ones who do application deployments (as can be the case with small teams like the one I'm in). If you do end up using separate DBs on the same server, I would at least lock down RDP access and grant access to each development DB on an individual basis. That's how it works here -- I don't have admin rights to any of our servers at this time, and can only admin databases for applications that belong specifically to my team.

blocks|key|386984|text|这取决于你对你的实时服务的重视程度。我知道我不会信任我和我的肥手在与活动应用程序相同的硬件上运行SQL。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|386985|即使应用程序不是业务关键型的，并且应用程序也不是数据绑定的，您也可以在未使用的台式机上设置开发环境，那么为什么不这样做，而不去冒险呢？|386986|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

It depends how much you value your live service. I know I wouldn't trust me and my fat hands running SQL on the same hardware as a live application.

Even if the application is not business critical, and the app is not data-bound, you can set up a development environment on an unused desktop machine, so why wouldn't you do that instead of take the risk?

blocks|key|1688292|text|我使用的设置通常是SQL+Server本地实例上的DEV数据库(对于我来说是开发版，但Express可能也可以)，是SQL+Server测试实例上的QA数据库。在我们的环境中，它位于W2K3的一个虚拟实例上--即将成为W2K8。生产数据库位于SQL+server的专用实例或各种群集实例之一上。我们根本不把PROD/QA/DEV混为一谈。我使用RedGate+SQL+Compare在不同系统之间同步模式，包括数据库的不同开发人员实例。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1688293|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

The set up I use is typically DEV database on a local instance of SQL Server (Development Version for me, but Express would probably also work), a QA database on a test instance of SQL Server. In our environment, this is located on a virtual instance of W2K3 -- soon to be W2K8. Production databases live either on dedicated instances of SQL server or on one of various clustered instances. We don't mix PROD/QA/DEV at all. I use RedGate SQL Compare to synchronize schemas between the various systems, including different developer instances of the database.

blocks|key|242267|text|只要团队对服务器(无论是SQL还是Windows)没有任何管理员特权，并且他们的用户登录只授予潜在地销毁开发数据库及其相关文件的访问权限，并且拒绝访问生产数据库，那么这将是“正常的”|type|unstyled|depth|inlineStyleRanges|entityRanges|data|242268|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

It will be 'OK' as much as the team don't had any administrator privileges over the server (either SQL or Windows), and their user log-ins just grant access to potentially destroy just the development database and it's associated files, having denied access to production databases

blocks|key|242312|text|出于其他应用程序测试的原因，我们在单独的域上创建了生产服务器(即虚拟服务器)的副本。这允许Windows服务器名称、SQL服务器名称、数据库名称完全相同(第三方应用程序上的许多设置都需要此级别的配置才能使不同的进程工作。)现在，我们可以通过创建生产服务器的精确虚拟映像来重新构建测试环境。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|242313|我对在虚拟机上运行SQL+Server持怀疑态度，但它为我们的小公司提供了很大的灵活性。我们喜欢认为我们的数据库是关键的，但它是内部使用的，有一些停机时间只会让员工改变他们的午餐时间。|242314|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

For other application testing reasons, we created a copy of our production server (which is a virtual server) on a separate domain. This allowed the Windows Server Name, SQL Serer Name, Database name to be exactly the same (lots of settings on 3rd party apps require this level of configuration to get different processes to work.). Now we can rebuild a test environment by creating an exact virtual image of our production server.

I was sceptical about running SQL Server on a virtual machine, but it has given our small company a lot of flexibility. We like to think our databases are critical, but it is for internal uses and having some down time would just have workers shift their lunch hour.

Sometimes we have upwards to 4-6 people either RDPed looking at data in SQL Management Studio, or hitting the server with LINQpad, Toad, etc from various locations while developing in mostly ASP.NET and Flex with WebOrb. Is this bad? Bad in the sense that we are trying to keep our live production app stable and as lag free as possible for global users?

Is it 'ok' to develop with a DEV database residing on the same SQL server as the live production app?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

有时，我们有多达4-6个人在RDPed中查看SQL Management Studio中的数据，或者使用LINQpad、Toad等从不同的位置访问服务器，同时主要使用ASP.NET和WebOrb进行开发。这是不是很糟糕？糟糕的是，我们试图保持我们的实时生产应用程序的稳定性，并尽可能地为全球用户提供无延迟的服务？

问使用与实时生产应用驻留在同一SQL服务器上的DEV数据库进行开发是“可以的”吗？
EN

回答 10

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问使用与实时生产应用驻留在同一SQL服务器上的DEV数据库进行开发是“可以的”吗？EN

回答 10

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问使用与实时生产应用驻留在同一SQL服务器上的DEV数据库进行开发是“可以的”吗？
EN