Voy a una entrevista de trabajo y no tengo experiencia con MS SQL Server. Sin embargo, tengo 1 año con Oracle. ¿Hay una diferencia tan grande entre los dos? ¿Qué preguntas de programación puedo esperar?
Respuestas
¿Demasiados anuncios?Soy un DBA de Oracle y SQL Server que ahora pasa demasiado tiempo en SQL Server.
Para no ser grosero, pero para alguien que SOLO tiene 1 año de experiencia en Oracle, entonces dudo que estés totalmente inmerso en Oracle, pero las diferencias más obvias son:
- La PRIMER diferencia más grande: Control de transacciones. En Oracle TODO es una transacción y no es permanente hasta que hagas
COMMIT
. En SQL Server, no hay control de transacciones (por defecto). Un error a mitad de un procedimiento almacenado NO REVERTIRÁ el DDL en pasos anteriores.
Obviamente, si envuelves el DML de TSQL en BEGIN TRANSACTION y COMMIT se revertirá, pero esto es raro en el código de SQL Server que he visto.
- La SEGUNDA diferencia más grande: MVCC. En SQL Server y Oracle es diferente. SQL Server permitirá lecturas sucias, y las escrituras pueden bloquear lecturas en MS SQL (de nuevo, es configurable pero por defecto en SQL Server es para rendimiento y no para consistencia de lectura, a diferencia de Oracle donde la consistencia de lectura es por defecto e inflexible).
También considera:
-
Cuando configuras un servidor Oracle, tiendes a tener una base de datos con muchos "usuarios/esquemas", y tablespaces que son compartidos por todos tus usuarios. SQL Server tiene bases de datos separadas que no comparten archivos de disco.
-
SQL Server usa "logins" para darte acceso a la instancia de SQL Server y cada base de datos tiene "usuarios" que se asignan a un login para obtener acceso individual a las tablas y vistas, etc.
-
Típicamente, todos los objetos en una base de datos son propiedad de dbo.
-
TSQL es similar a PL/SQL, pero (en mi opinión) menos poderoso. Es posible que necesites simplificar tu SQL para que funcione tan bien como esperarías en Oracle.
-
¡El SQL Server Management Studio (2008 SP1) es fantástico!
-
Si te gusta Oracle, todo lo de "ir bajo el capó" y la "optimización del plan de explicaciones", entonces esta formación y experiencia te funcionarán bien contra personas que simplemente codifican directamente en SQL Server TSQL y esperan que el servidor funcione rápido por arte de magia.
-
SQL Server no tiene paquetes. Esto podría empezar siendo una ventaja (los paquetes PL/SQL pueden ser una molestia) pero eventualmente empezarás a tener un gran lío de procedimientos almacenados con nombres similares en la base de datos y desearás poder organizarlos y agruparlos mejor.
Consejo final, siempre juega con tus fortalezas. Admite que no tienes mucha experiencia en SQL Server pero destaca que conoces los principios de cómo funciona un RDBMS, cómo desarrollar una aplicación basada en datos y cómo diseñar el rendimiento desde el principio, etc.
Fortalezas de Oracle:
- un mejor sistema de transacciones
- paquetes
- Bucles For en Cursor
- declaraciones ancladas (variables declaradas como table.column%type)
- valores iniciales para declaraciones de variables
- variables %rowtype
- mucho menos sobrecarga para cursores
- triggers BEFORE
- triggers FOR EACH ROW
- Aunque las secuencias requieren disciplina o triggers antes de cada fila, son más flexibles que las columnas de identidad de SQL Server.
Fortalezas de SQL Server:
- Transact-SQL es solo un lenguaje, por lo que no tienes que preocuparte por qué es SQL, qué es SQL*PLUS y qué es PL/SQL.
- Debido a que T-SQL es solo un lenguaje, las colecciones de T-SQL funcionan decentemente con SQL. Puedes unir variables de tabla T-SQL a tablas reales. Esto tiende a significar que, aunque PL/SQL es más poderoso para la programación procedimental, simplemente no necesitas hacer programación procedimental en T-SQL.
- Si realizas una consulta select sin un objetivo, los resultados se devuelven automáticamente al cliente. Para código de producción, esto significa que no necesitas declarar y pasar sys_refcursor. Para trabajos de investigación ad hoc, esto significa que puedes hacer fácilmente scripts que realicen búsquedas y muestren múltiples conjuntos de registros.
- SQL Server Management Studio es mucho mejor que SQL*Plus o SQL Developer. Debido a que simplemente muestra cualquier conjunto de registros devuelto, los procedimientos de recuperación de datos son muy fáciles de probar.
- configuración de conectividad de cliente más fácil (nada tan malo como tnsnames)
- menos confusión sobre qué controladores usar, aparte de JDBC
- Declara una columna "Int Identity Not Null Primary Key" y luego puedes olvidarte de ella.
- Cada nombre de variable comienza con un símbolo "@" que se ve terrible, pero evita colisiones de nombres entre variables y columnas.
- El caso que declaraste para una tabla o columna se recordará, pero no distingue entre mayúsculas y minúsculas, y no estás limitado a 30 caracteres.
- Crystal Reports puede llamar a procedimientos almacenados de SQL Server, donde tiendes a verse obligado a usar una vista con Oracle.
Aquí hay una comparación de conceptos, terminología y sintaxis, etc. y una comparación de rendimiento/limitaciones
También, busca en SO con etiquetas o palabras clave como [sql-server], [oracle], "diferencia" etc. ya que supongo que este tema ha sido abordado con facilidad, aunque no encontré rápidamente tales referencias.
Oracle y SQL Server tienen extensiones diferentes de SQL. Oracle tiene PL/SQL, mientras que SQL Server tiene Transact-SQL (T-SQL). Eso significa que aunque SQL (SELECT, INSERT, UPDATE, DELETE) es similar a un nivel básico, la sintaxis diverge rápidamente dependiendo de lo que estés intentando hacer.
Cuando trabajo con la estructura de decisión/control de flujo en T-SQL, creo que es menos flexible que en PL/SQL - CASE es una expresión en T-SQL, por lo que no se puede usar para el control de flujo, mientras que no es el caso en Oracle. Otra molestia que tengo con T-SQL es que si quieres realizar más de una operación dentro de una rama IF - toda la rama debe estar contenida en un bloque BEGIN END. Oracle no tiene ese requisito, pero debes definir el END IF.
Los tipos de datos son similares, pero Oracle no discrimina entre los tipos integer/decimal - todo es NUMBER con la opción de especificar el grado de precisión. Las funciones de fecha en SQL Server son más flexibles.
Siendo ambos productos populares, es fácil buscar en Google una funcionalidad equivalente en uno para el otro. No significa que exista, pero alguien probablemente ha publicado una solución alternativa.