4 replaced http://dba.stackexchange.com/ with https://dba.stackexchange.com/
source | link

Much like the vein of the question that was posted here previously around "Should developers be able to query production databases?Should developers be able to query production databases?" I wanted to get your thoughts on another particularly annoying topic!

Many companies prevent developers from install SQL Server Express and the like on development machines, instead promoting the use of centralised development SQL Servers.

Specifically this is done to ensure:

  • Patch level consistency between development servers and production
  • Ability to prove and validate any patches on the above
  • Data security; only data on the development servers gets used for development
  • Recoverability; data is recoverable and still backed up
  • Collation differences that can cause problems when moved to production

To me all these arguments are particularly invalid, with perhaps the exception of the patching ones; but if a database on a local machine is purely used for development activities, and not testing, then the patching would be proven out when an application progressed through Test / UAT etc to Production.

Collation does not appear to be a valid reason, as if this was a concern for the database it should be set when it's created anyway. Only SharePoint and SCCM have issues around this as far as I know ;)

Now, assuming it's ONLY for development, and the database will not be "moved" to production and the only movements would be:

  • Scripts that created the database being generated for deployment to production
  • Backups from "production" third party systems being restored and truncated where appropriate for validation and development

Can anyone see any issues? Am I missing something?

I guess one of the biggest concerns would be the ability for local db instances coming out of date, but thats a software management issue, not a DBA one IMO.

Much like the vein of the question that was posted here previously around "Should developers be able to query production databases?" I wanted to get your thoughts on another particularly annoying topic!

Many companies prevent developers from install SQL Server Express and the like on development machines, instead promoting the use of centralised development SQL Servers.

Specifically this is done to ensure:

  • Patch level consistency between development servers and production
  • Ability to prove and validate any patches on the above
  • Data security; only data on the development servers gets used for development
  • Recoverability; data is recoverable and still backed up
  • Collation differences that can cause problems when moved to production

To me all these arguments are particularly invalid, with perhaps the exception of the patching ones; but if a database on a local machine is purely used for development activities, and not testing, then the patching would be proven out when an application progressed through Test / UAT etc to Production.

Collation does not appear to be a valid reason, as if this was a concern for the database it should be set when it's created anyway. Only SharePoint and SCCM have issues around this as far as I know ;)

Now, assuming it's ONLY for development, and the database will not be "moved" to production and the only movements would be:

  • Scripts that created the database being generated for deployment to production
  • Backups from "production" third party systems being restored and truncated where appropriate for validation and development

Can anyone see any issues? Am I missing something?

I guess one of the biggest concerns would be the ability for local db instances coming out of date, but thats a software management issue, not a DBA one IMO.

Much like the vein of the question that was posted here previously around "Should developers be able to query production databases?" I wanted to get your thoughts on another particularly annoying topic!

Many companies prevent developers from install SQL Server Express and the like on development machines, instead promoting the use of centralised development SQL Servers.

Specifically this is done to ensure:

  • Patch level consistency between development servers and production
  • Ability to prove and validate any patches on the above
  • Data security; only data on the development servers gets used for development
  • Recoverability; data is recoverable and still backed up
  • Collation differences that can cause problems when moved to production

To me all these arguments are particularly invalid, with perhaps the exception of the patching ones; but if a database on a local machine is purely used for development activities, and not testing, then the patching would be proven out when an application progressed through Test / UAT etc to Production.

Collation does not appear to be a valid reason, as if this was a concern for the database it should be set when it's created anyway. Only SharePoint and SCCM have issues around this as far as I know ;)

Now, assuming it's ONLY for development, and the database will not be "moved" to production and the only movements would be:

  • Scripts that created the database being generated for deployment to production
  • Backups from "production" third party systems being restored and truncated where appropriate for validation and development

Can anyone see any issues? Am I missing something?

I guess one of the biggest concerns would be the ability for local db instances coming out of date, but thats a software management issue, not a DBA one IMO.

    Tweeted twitter.com/StackDBAs/status/799233879273943040
3 Adding a link
source | link

Much like the vein of the question that was posted here previously around "Should developers be able to query production databases?"Should developers be able to query production databases?" I wanted to get your thoughts on another particularly annoying topic!

Many companies prevent developers from install SQL Server Express and the like on development machines, instead promoting the use of centralised development SQL Servers.

Specifically this is done to ensure:

  • Patch level consistency between development servers and production
  • Ability to prove and validate any patches on the above
  • Data security; only data on the development servers gets used for development
  • Recoverability; data is recoverable and still backed up
  • Collation differences that can cause problems when moved to production

To me all these arguments are particularly invalid, with perhaps the exception of the patching ones; but if a database on a local machine is purely used for development activities, and not testing, then the patching would be proven out when an application progressed through Test / UAT etc to Production.

Collation does not appear to be a valid reason, as if this was a concern for the database it should be set when it's created anyway. Only SharePoint and SCCM have issues around this as far as I know ;)

Now, assuming it's ONLY for development, and the database will not be "moved" to production and the only movements would be:

  • Scripts that created the database being generated for deployment to production
  • Backups from "production" third party systems being restored and truncated where appropriate for validation and development

Can anyone see any issues? Am I missing something?

I guess one of the biggest concerns would be the ability for local db instances coming out of date, but thats a software management issue, not a DBA one IMO.

Much like the vein of the question that was posted here previously around "Should developers be able to query production databases?" I wanted to get your thoughts on another particularly annoying topic!

Many companies prevent developers from install SQL Server Express and the like on development machines, instead promoting the use of centralised development SQL Servers.

Specifically this is done to ensure:

  • Patch level consistency between development servers and production
  • Ability to prove and validate any patches on the above
  • Data security; only data on the development servers gets used for development
  • Recoverability; data is recoverable and still backed up
  • Collation differences that can cause problems when moved to production

To me all these arguments are particularly invalid, with perhaps the exception of the patching ones; but if a database on a local machine is purely used for development activities, and not testing, then the patching would be proven out when an application progressed through Test / UAT etc to Production.

Collation does not appear to be a valid reason, as if this was a concern for the database it should be set when it's created anyway. Only SharePoint and SCCM have issues around this as far as I know ;)

Now, assuming it's ONLY for development, and the database will not be "moved" to production and the only movements would be:

  • Scripts that created the database being generated for deployment to production
  • Backups from "production" third party systems being restored and truncated where appropriate for validation and development

Can anyone see any issues? Am I missing something?

I guess one of the biggest concerns would be the ability for local db instances coming out of date, but thats a software management issue, not a DBA one IMO.

Much like the vein of the question that was posted here previously around "Should developers be able to query production databases?" I wanted to get your thoughts on another particularly annoying topic!

Many companies prevent developers from install SQL Server Express and the like on development machines, instead promoting the use of centralised development SQL Servers.

Specifically this is done to ensure:

  • Patch level consistency between development servers and production
  • Ability to prove and validate any patches on the above
  • Data security; only data on the development servers gets used for development
  • Recoverability; data is recoverable and still backed up
  • Collation differences that can cause problems when moved to production

To me all these arguments are particularly invalid, with perhaps the exception of the patching ones; but if a database on a local machine is purely used for development activities, and not testing, then the patching would be proven out when an application progressed through Test / UAT etc to Production.

Collation does not appear to be a valid reason, as if this was a concern for the database it should be set when it's created anyway. Only SharePoint and SCCM have issues around this as far as I know ;)

Now, assuming it's ONLY for development, and the database will not be "moved" to production and the only movements would be:

  • Scripts that created the database being generated for deployment to production
  • Backups from "production" third party systems being restored and truncated where appropriate for validation and development

Can anyone see any issues? Am I missing something?

I guess one of the biggest concerns would be the ability for local db instances coming out of date, but thats a software management issue, not a DBA one IMO.

2 edited tags
| link
1
source | link