Los procedimientos almacenados se ejecutan en cualquier version de SQL Server, debe existir alguno instrucción especifica que hay que revisar dentro del procedimiento, pero el problema puede ser que no sea de versiones.

Esto es un problema de versiones, desde SQL Server 2016, se han eliminado varias limitaciones de OLTP en memoria, lo que hace que esta característica sea más útil. Una de las limitaciones eliminadas es la capacidad de crear una clave externa en tablas optimizadas para memoria, que es muy importante para garantizar la integridad de los datos dentro de estas tablas.

@@visoalgt pero entonces habría que usar otro tipo de índice, porque toda una base entera optimizada es completamente lo contrario a lo que se quiere hacer que es mejorar el rendimiento y muchos índices es el efecto contrario. Yo por un momento me pensé y si hago las tablas sin llaves foráneas y las hago optimizadas, ya posterior a eso hacer la integridad de los alter con las llaves foráneas, no lo he probado, pero me dejaría hacer la llave foránea después de haber creado las tablas optimizadas? O no me dejaría hacer las llaves foráneas después?

Saludos Jose, en cuanto a tus preguntas las respuestas son: 1. La implementación de tablas hash en SQL server se hace con indices hash que son indices en memoria, al estar en memoria son mas eficientes que un índice no agrupado de nivel de fila. 2. Los recursos que usa el SQL server son configurables todo el tiempo, de manera predeterminan una instancia usa toda la memoria disponible del servidor por lo que es bueno configurar un límite de memoria para no comprometer recursos del sistema operativo, también es configurable la ubicación en los discos duros de las diferentes bases de datos, hay discos más rápidos que otros y por distribución de cargas de trabajo es buena práctica distribuir las bases de datos en diferentes discos, muchos objetos temporales se crean en la base de datos TempDB y no en la base de datos en uso, es importante monitorear y administrar la base de datos TempDB 3. El paralelismo funciona todo el tiempo no solo en los indices. 4. Trabajaré en un video explicando los hint inner join.

Si la tabla tiene mucho movimiento yo me quedaría con indices de nivel de fila, los indices columnares benefician a consultas complejas.

No, la tabla se deja renombrar como una tabla común de SQL Server y se mantiene en memoria

Si, hay que hacer tunning a tu base de datos y luego aumentar los recursos al servidor, hecho esto si aun necesitas mejorar tus consultas se podría implementar tablas en memoria.

a partir de SQL 2012

La base de datos es parte de un material proporcionado en el curso www.udemy.com/desarrollo-de-bases-de-datos-con-sql-server-70-762/ por lo que no se proporciona por esta via.

La base de datos es parte de un material proporcionado en el curso www.udemy.com/desarrollo-de-bases-de-datos-con-sql-server-70-762/ por lo que no se proporciona por esta via.

La base de datos es parte de un material proporcionado en el curso www.udemy.com/desarrollo-de-bases-de-datos-con-sql-server-70-762/ por lo que no se proporciona por esta via.

Mil disculpas, que siento que no te gustara mi explicación, me esforzare más la próxima vez para escribir código y hablar al mismo tiempo, y que sea de tu agrado.

Mil disculpas .. tu tienes pelotas para hacer esto y se ve que eres profesional y certificado. Espero que lo tomes como una critica nomás.

No, nada que disculpar, gracias a ti por ver el video y voy a tratar de mejorar, algunos videos me salen mejor que otros, Gracias!

YaTu Sabes ponlo en velocidad 1.5 o 2, y evita hacer ese tipo de comentarios