Max number of values in IN clause

Somebody asked me about this a few days ago, and this person (really sure of what he was talking about) told me: "You can only pass a limit of 200 items in a IN clause (during a DELETE)"

I'm not an Expert DBA (know it all), but I do remember that you can pass up to 1000 elements. And that was my counter argument to this guy (as always if you don't believe me double check with your best friend or test it
In the past it used to be 256 elements, but that was in Oracle 8.

Getting column info from Oracle table you don't own (without using describe)

How would one get columns information on table which he doesn't own, but has select granted? This is, without using DESCRIBE table_name

My answer is:

select owner, column_name from all_tab_columns where table_name = 'STUDENT';

MSSQL Restore locked database

Below is a short snippet that will allow you to restore your database by putting it in single user mode.

After restoring (if without errors) it will be in multi user mode again. If it is not you can still run the

alter database DATABASE_NAME set multi_user

command to put it back in original mode.

USE master;
 
ALTER DATABASE [DATABASE_NAME] SET single_user WITH ROLLBACK immediate;
 
restore DATABASE [DATABASE_NAME] FROM disk = 'C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\Backup\YOUR_AWESOME_BACKUP.bak';

Run a SQLPlus script and pass a parameter as input

Simple:
call sqlplus user/password@database @your_script.sql abc123 qwe890 <br />
Then your script:
begin dbms_output.put_line(&&1);
dbms_output.put_line(&&2);
end;
/

Conditions in One Line

Interesting point, how can I do 1 LINE If statements like in Java: a==b?true:false This is the answer: SELECT ACCT_ORDER.cidb_order_id, (CASE WHEN mtn_order_type = 'E' AND mtn_order_state = 'P' THEN 1 ELSE 0 END) I'll see on resultset cidb_order_id, 1 or 0 (segun sea el caso) The same sentence could be used on UPDATES: UPDATE CUST_ACCT_ORDER_STATS SET addline_pending_cnt = CASE WHEN addline_pending_cnt - my_add_count < 0 THEN 0 ELSE addline_pending_cnt - my_add_count END WHERE cust_id = my_cust_id AND acct_num = my_acct_num;

My first official LEFT JOIN

When I was at school I always was afraid of using LEFT OR RIGHT Joins, well, almost 6 years after I'm done with school, I had to do my first one: SELECT ACCT_ORDER.CUST_ID, ACCT_ORDER.ACCT_NUM, MTN_ORDER.mtn, MTN_ORDER.mtn_order_type, MTN_ORDER.mtn_order_state, MTN_ORDER.mtn_order_state_date, MTN_ORDER.bdy_mtn, MTN_ORDER.cidb_order_id, MTN_STATE.mtn_eligibility_state, MTN_STATE.mtn_eligibility_state_date, ACCT_ORDER.pos_order_id, ACCT_ORDER.pos_pre_order_id, ACCT_ORDER.pos_loc_cd, ACCT_ORDER.order_state, ACCT_ORDER.order_state_date FROM CUST_ACCT_ORDER ACCT_ORDER LEFT JOIN CUST_ACCT_MTN_ORDER MTN_ORDER ON ACCT_ORDER.acct_num = MTN_ORDER.acct_num AND ACCT_ORDER.cust_id = MTN_ORDER.cust_id AND ACCT_ORDER.cidb_order_id = MTN_ORDER.cidb_order_id LEFT JOIN CUST_ACCT_MTN_STATE MTN_STATE ON MTN_ORDER.cust_id = MTN_STATE.cust_id AND MTN_ORDER.acct_num = MTN_STATE.acct_num AND MTN_ORDER.mtn = MTN_STATE.mtn WHERE( (ACCT_ORDER.pos_order_id = p_pos_order_id AND ACCT_ORDER.pos_loc_cd = p_pos_loc_cd) OR ACCT_ORDER.pos_pre_order_id = p_pos_pre_order_id ) ORDER BY MTN_ORDER.mtn;

SQL Joins explained with Venn's Diagrams

SQL Joins explicados de forma gráfica con diagramas Venn

Una simple ayuda

El lenguaje SQL es aveces el gran olvidado por los desarrolladores, cada vez abundan mas los frameworks que abstraen al desarrollador del contacto con el modelo de negocio.

He escrito este documento, basándome en otros similares para ayudar a entender con un diagrama de Vann, los diferentes tipos de Join's que SQL92 soporta.

Existen tecnologías que abstraen completamente del modelo de negocio, para el desarrollador funcionan creando una serie de clases de Dominio que define el modelo, sin importar qué base de datos o de qué fabricante sea esta. Por ejemplo Ruby on Rails, GRails, ... usando un conjunto de tecnologías, como Hibernate configuradas por convención dentro del propio framework.

También es muy extendido el uso de aplicaciones que permiten modelar el negocio de forma gráfica, ERM (como DBSchema), y normalmente después se usa un ORM's que les hacen el trabajo sucio de forma elegante y segura.

Todo vale, pero la realidad de las empresas TIC es que necesitan profesionales serios y conscientes que entiendan y controlen todas las capas para que un sistema funciona como se espera y está diseñado, y no se deje nada al azar.

El desarrollador, muy frecuentemente recurre a activar trazas o aplicaciones de monitorización de actividad que nos desvelen, qué está haciendo nuestro framework con nuestro modelo de negocio. Existen aplicaciones que esnifan directamente de la base de datos esta información para que podamos analizarla, el obsoleto Profile y Analyzer que incluía Microsoft SQL Server es un ejemplo de ellos.

Finalmente cuando tenemos delante la query sucede que hace tanto tiempo que no trabajamos con SQL que no entendemos qué hace exactamente, sobre todo si está trabajando con tablas relacionadas y nos encontramos con una consulta que afecta a varias entidades.

Espero que este documento ayude a reducir el tiempo invertido a descubrir porqué se comporta una SQL de un modo u otro.

Convenciones Este documento asume que siempre que la "TABLA A" esta a la izquierda y la "TABLA B" a la derecha de las sentencias. Para los ejemplos vamos a utilizar 2 tablas que van a contener los siguientes datos: id name | id name 1 Roberto | 1 Alex 2 Juan | 2 Carlos 3 Rubén | 3 Juan 4 Carlos | 4 Saúl
INNER JOIN SELECT * FROM TableA INNER JOIN TableB ON TableA.name = TableB.name id name | id name 2 Juan | 2 Carlos 4 Carlos | 3 Juan El resultado son solo el conjunto de registros que coinciden en ambas tablas.
FULL OUTER JOIN SELECT * FROM TableA FULL OUTER JOIN TableB ON TableA.name = TableB.name id name | id name 1 Roberto | null null 2 Juan | 3 Juan 3 Rubén | null null 4 Carlos | 2 Carlos null null | 1 Alex null null | 4 Saúl El resultado es el conjunto total de registros de ambas tablas, coincidiendo aquellos registros cuando sea posible. Si no hay conicidencias, se asignan nulos.
FULL OUTER JOIN WHERE SELECT * FROM TableA FULL OUTER JOIN TableB ON TableA.name = TableB.name WHERE TableA.id IS null OR TableB.id IS null id name | id name 1 Roberto | null null 3 Rubén | null null null null | 1 Alex null null | 4 Saúl El resultado es un conjunto de records únicos en la TablaA y en la TablaB, hacemos el Full Outer Join y excluimos los registros que no queremos con el Where
LEFT OUTER JOIN SELECT * FROM TableA LEFT OUTER JOIN TableB ON TableA.name = TableB.name id name | id name 1 Roberto | null null 2 Juan | 3 Juan 3 Rubén | null null 4 Carlos | 2 Carlos El resultado son todos los registros de la TablaA, y si es posible las coincidencias de la TablaB. Si no hay coincidencias, el lado derecho mostrará nulos.
LEFT OUTER JOIN WHERE SELECT * FROM TableA LEFT OUTER JOIN TableB ON TableA.name = TableB.name WHERE TableB.id IS null id name | id name 1 Roberto | null null 3 Rubén | null null El resultado es un conjunto de registros que solo están en la TablaA, no en la TablaB. Hacemos lo mismo que en un Left Outer Join, pero eliminamos los registros que no queremos de la TablaB con el Where
CROSS JOIN Existe también la posibilidad de cruzar todos los registros con todos (producto cartesiano), imposible de dibujar con un diagramas Venn SELECT * FROM TableA CROSS JOIN TableB Imaginarse el resultado de todos los registros por todos es muy fácil, si tenemos 4 registros en cada tabla 4 x 4 = 16.	¡Ojo al hacer esto en tablas con muchos registros!