Recently I assisted my colleague answer the question of making SQL Server Developer edition act/look like Standard Edition instead of its default behaviour which is to be the same as Enterprise Edition. Basically the answer to this question is that there is NO switch/setting/configuration to make developer edition act/look like standard edition.
So how does a developer developing applications that are going to ultimately released on standard edition work with developer edition or otherwise? Following are some options:
1) Stay with Developer Edition and understand / manage risk
Largest risk is DE hiding a performance hit when code is migrated to production. SE is single threaded for most operations whereas DE/EE exploits processor capabilities. This is the most problematic to determine impact into production.
DE has a number of capabilities that need to be clearly not used by developers. The list is provided below:
SQL DE/EE versus SQL SE capabilities:
http://www.microsoft.com/sqlserver/2008/en/us/editions-compare.aspx Easiest way to visualise Editions across workloads.
· Resource Governor
· Table/Index Partitions
· Indexed Views
· Asynchronous Database Mirroring
· Online Indexing
· Backup Compression
· Database Snapshots
· Oracle Publishing from replication perspective
· SQL Auditing
· Transparent Database Encryption
· Distributed Partition Views
· Change data Capture
· Partitioned cubes
· Account Intelligence
· Linked Measures & Dimensions
· Semi-additive measures
· Write back Dimensions
· Custom Rollups
· Scale out Reporting services implementation
· Data Driven Subscriptions
· Report Models
· Data Mining Tasks
o Query Transformation
o Mining Model Training Destination Adapter
· Fuzzy Grouping
· Fuzzy Lookup
· Term Extraction
· Dimension Processing
· Partition Processing
· Cross Validation
· Plug-in algorithms
· Sequence Prediction
2) Stay with Developer Edition and leverage Policy Management capabilities
Note: Some of the above capabilities could be controlled by the Policy Management features in SQL Server. These are not done out of the box and would require a DBA to set these up. If I get time, I may provide some examples of this in later posts.
Advantages here is that the DE environment will highlight automatically when the EE capabilities are switched on, however the performance risk still remains.
3) Evaluate cost of MSDN purchase
While I always first advocate a re-look at the value of Enterprise Edition in production the MSDN option is great for all alternatives. Simply put – buying MSDN for every developer all non production environments (like dev, test, UAT, training) to be correctly licensed for all the developers and users (testers and trainees). MSDN Professional subscriptions cover the OS and SQL and this includes all versions of SQL (including SE).
Premium and Ultimate will be appropriate if SharePoint and Exchange etc. need to be covered by MSDN too.
This option is a easy way to know that you are compliant by only needing to focus on Production licenses (once developers are licensed with right MSDN subscription).
Is it just me or the last column is cut off.