Campo Booleano en Oracle

Oracle usa Y/N para valores booleanos. Para completar, debe tenerse en cuenta que pl/sql tiene un tipo booleano, solo las tablas no lo tienen.

Si está utilizando el campo para indicar si el registro debe procesarse o no, puede considerar usar Y y NULL como valores. Esto hace que para un índice muy pequeño (leer rápido) que ocupa muy poco espacio.

Para usar la menor cantidad de espacio debe usar un campo CHAR restringido a 'Y' o 'N'. Oracle no admite tipos de datos BOOLEANOS, BIT o TINYINT, por lo que el byte de CHAR es lo más pequeño posible.

La mejor opción es 0 y 1 (como números - otra respuesta sugiere 0 y 1 como CHAR para la eficiencia del espacio, pero eso es un poco demasiado retorcido para mí), usando NOT NULL y una restricción check para limitar el contenido a esos valores. (Si necesita que la columna sea nullable, entonces no es un booleano con el que está tratando, sino una enumeración con tres valores...)

Ventajas de 0/1:

• Idioma independiente. 'Y' y ' N ' estaría bien si todos lo usaran. Pero no lo hacen. En Francia usan 'O' y ' N ' (he visto esto con mis propios ojos). No he programado en Finlandia para ver si usan 'E' y 'K' allí, sin duda son más inteligentes que eso, pero no puedes estar seguro.
• Congruente con la práctica en lenguajes de programación ampliamente utilizados (C, C++, Perl, Javascript)
• Se reproduce mejor con la capa de aplicación, por ejemplo, Hibernar
• Conduce a SQL más sucinto, por ejemplo, para averiguar cuántos plátanos están listos para comer select sum(is_ripe) from bananas en lugar de select count(*) from bananas where is_ripe = 'Y' o incluso (yuk) select sum(case is_ripe when 'Y' then 1 else 0) from bananas

Ventajas de 'Y'/'N':

• ocupa menos espacio que 0/1
• Es lo que Oracle sugiere, por lo que podría ser lo que algunas personas están más acostumbrados a{[13]]}

Otro poster sugirió 'Y'/null para ganancias de rendimiento. Si ha demostrado que necesita el rendimiento, entonces es bastante justo, pero evite ya que hace que la consulta sea menos natural (some_column is null en lugar de some_column = 0) y en un join izquierdo mezclará falsedad con registros inexistentes.

Ya sea 1/0 o Y / N con una restricción de verificación. ether way está bien. Personalmente prefiero 1/0 ya que hago mucho trabajo en perl, y hace que sea muy fácil hacer operaciones booleanas de perl en campos de base de datos.

Si quieres una discusión realmente en profundidad de esta cuestión con uno de los Oráculos head honchos, echa un vistazo a lo que Tom Kyte tiene que decir sobre esto Aquí

La base de datos en la que hice la mayor parte de mi trabajo usaba 'Y' / 'N' como booleanos. Con esa implementación, puedes realizar algunos trucos como:

1. Cuente las filas que son verdaderas:
   SELECCIONE SUM (CASO CUANDO BOOLEAN_FLAG = 'Y' ENTONCES 1 ELSE 0) DE X

2. Al agrupar filas, aplique la lógica" Si una fila es verdadera, entonces todas son verdaderas":
   SELECCIONE MAX (BOOLEAN_FLAG) DE Y
   Por el contrario, utilice MIN para forzar el agrupamiento false si una fila es false.

Un ejemplo de trabajo para implementar la respuesta aceptada agregando una columna "booleana" a una tabla existente en una base de datos oracle (usando el tipo number):

ALTER TABLE my_table_name ADD (
my_new_boolean_column number(1) DEFAULT 0 NOT NULL
CONSTRAINT my_new_boolean_column CHECK (my_new_boolean_column in (1,0))
);

Esto crea una nueva columna en my_table_name llamada my_new_boolean_column con valores predeterminados de 0. La columna no aceptará valores NULL y restringe los valores aceptados a 0 o 1.

En nuestras bases de datos utilizamos una enumeración que garantiza que se pase VERDADERO o FALSO. Si lo hace cualquiera de las dos primeras formas, es demasiado fácil comenzar a agregar un nuevo significado al entero sin pasar por un diseño adecuado, o terminar con ese campo char que tiene valores Y, y, N, n, T, t, F, f y tener que recordar qué sección del código usa qué tabla y qué versión de true está utilizando.