This document contains several practices and recommendations for SQL Server administrators. However, many of them reflect misconceptions, outdated practices, or outright harmful advice in the realm of modern SQL Server administration. Below is a review of each suggestion from a technical standpoint:

1. System Testing in Production
Review: Testing directly in production is generally a poor practice. It risks exposing real users to unvetted code, which can lead to data corruption, security breaches, and customer dissatisfaction. Testing environments should replicate production as closely as possible without using live production systems.
Recommendation: Use staging environments with anonymized production-like data for testing.

2. Use as Few Servers as Necessary
Review: Consolidating services onto a single server is not recommended for scalability, performance, or fault tolerance. Modern architectures favor separating services to avoid resource contention and to improve scalability and disaster recovery.
Recommendation: Use dedicated servers for critical services and scale horizontally as needed.

3. Use AUTO_SHRINK to Keep Data Files Lean and Mean
Review: AUTO_SHRINK is widely regarded as harmful. It can lead to database fragmentation and degrade performance. Disk space is typically not a primary bottleneck in modern systems.
Recommendation: Avoid AUTO_SHRINK. Instead, monitor and manage disk usage proactively.

4. Autogrow Files for Self-Managing Databases
Review: Autogrow should be a safety net, not a primary method of managing file growth. Unplanned growth events can cause performance issues.
Recommendation: Set appropriate initial file sizes and monitor growth. Use autogrow sparingly.

5. The SA Account Saves Time
Review: Sharing the SA account and using a single password is a significant security risk. This practice violates the principle of least privilege and makes auditing nearly impossible.
Recommendation: Use individual accounts with role-based access control (RBAC) and disable the SA account where feasible.

6. Indexes on Binary-Valued Columns
Review: Indexing binary-valued columns (e.g., Boolean flags) is rarely effective. Indexes work best on high-cardinality columns with diverse values.
Recommendation: Avoid indexing low-cardinality columns unless specific query patterns demand it.

7. Keep Server Memory Low for Large Databases
Review: SQL Server benefits significantly from ample memory for caching data and reducing disk I/O. Limiting memory unnecessarily degrades performance.
Recommendation: Allocate memory based on workload and server capacity.

8. ORMs Are the Best Way to Develop Well-Performing Code
Review: ORMs (Object-Relational Mappers) are convenient but often generate inefficient SQL. Reliance on ORMs without optimization can lead to performance issues.
Recommendation: Use ORMs judiciously and supplement them with optimized, hand-written SQL when needed.

9. Always Use NOLOCK in SQL Statements
Review: Using NOLOCK can lead to dirty reads and inconsistent results, particularly in mission-critical systems. It is not a blanket solution for performance.
Recommendation: Use NOLOCK only when stale or incomplete data is acceptable, and carefully document its use.

10. Do Not Change MAXDOP
Review: Leaving MAXDOP at its default value can lead to suboptimal performance in many cases. It should be tuned based on workload and server configuration.
Recommendation: Configure MAXDOP appropriately after evaluating your workload.

11. No Backup or Restore Plan for BI Systems
Review: BI systems still require backups for schema protection, disaster recovery, and to safeguard against ETL or human errors.
Recommendation: Implement a robust backup and recovery plan for all systems, including BI.

12. SQL Server Works Better with Looping Code
Review: Iterative row-by-row processing (RBAR—"Row By Agonizing Row") is inefficient. Set-based operations are the foundation of SQL and are far more performant.
Recommendation: Use set-based SQL queries and avoid looping constructs whenever possible.

Conclusion

While some advice here might be well-intentioned, much of it is outdated, misleading, or counterproductive in modern SQL Server environments. Following these suggestions could lead to security vulnerabilities, performance issues, and operational inefficiencies.

Would you like me to rewrite this document with corrected recommendations?