Campo "tipo Bits" en Firebird
 

Buenas, me explico.
Necesito poner en un campo de una tabla los números que me salen de un sorteo. Es decir, siempre salen 10 números en cada sorteo (sobre un universo de 90 números). La idea era poner un 0 o un 1 según el valor que haya salido en la posición correcta.
De ahí, si salieron los números: 10, 12, 14, 16; tendría algo así. (El universo lo hago de 20 para achicar la cosa)

00000000010101010000 <-- Hay 20 posiciones y los "1" marcan los lugares que salieron sorteados.

Ahora bien, este tipo de notación ¿cómo la pongo en Firebird 2.5? ¿Solamente tengo la opción de un varchar(20)? Teniendo en cuenta que después tengo que hacer algunas cosas con eso, como por ejemplo: "decir cuáles son los números que salieron en pantalla".
Una de las cosas que también debo hacer con esto en un "AND". Esto sería, cierta progresión de números (de 20 lugares, 0 o 1) contra otras que están almacenadas (de 20 lugares, 0 o 1)

Si tengo otra progresión, digamos: 00100100010010000000; tengo que hacer (00100100010010000000 AND 00000000010101010000) y ver el que salió.

¿Cómo es conveniente guardar estos datos para luego poder manipularlos de la mejor manera?
Bueno, espero haber sido claro.

Gracias.

Parece que FB tiene soporte parcial, usando un campo integer y funciones de BIT:

https://stackoverflow.com/questions/...-to-bit-in-sql

Código SQL [-]
Integer field: 7 = 00000111

SELECT 
   bin_and(field, 1) as bit1, 
   bin_and(field, 2) as bit2, 
   bin_and(field, 4) as bit3,
   bin_and(field, 8) as bit4,
   ... 
FROM T

¿Y por qué no guardas los números tal cual, en campos integer?
Recuerdo haber guardado cosas en bits, pero de eso hace muchos años, cuando el espacio en disco era muy limitado, los primeros discos duros que usé eran de 4 Megas :eek:

Si entiendo, de lo que hablas no es de almacenar un valor binario como tal si no de guardar el resultado del sorteo de una manera que solo tu sistema lo logre entender y que en este caso se parece a un valor binario.

(10 posiciones)

1 = 1000000000
2 = 0100000000
3 = 0010000000
..
10 = 0000000001

Y si el resultado del sorteo es 4, 7, 10 almacenas la cadena 0001001001.

No se porque lo harás así, pensaría que porque de esta manera quien observe los datos directamente en la base de datos no los comprenderá inmediatamente y al verlo que se parecen a un binario pensará que es eso y no podrá obtener el resultado del sorteo. Solo es especulación.

Si es este el caso, Pues creo que ya tienes una manera bastante curiosa de hacer las cosas y las rutinas que interpretan estas cadenas no creo que sean demoradas. Otra posibilidad sería guardar los valores del sorteo cifrados en la DB y así hasta podrías almacenarlos en diferentes columnas o en tablas detalles. Seoane en su web tiene bibliotecas muy buenas para esto ;)

Si no es el caso, olvídalo :D

Los bitarrays tienen usos muy interesantes (no solo es para ahorrar espacio!):

http://blog.getspool.com/2011/11/29/...redis-bitmaps/

Ahora que he leido un monton sobre arquitecturas de bases de datos, los bitmap index permiten de forma eficiente hacer un monton de cosas:

https://stackoverflow.com/questions/...ndexes-helpful

En especial, acelerar un monton de tareas relacionadas con analiticas, optimizar consultas del tipo AND, OR, NOT, COUNT, etc.

------

Pero si la razon de esto es hacer "seguridad mediante oscuridad" es la razon equivocada.

SQL es un lenguaje relacional, y tiene excelente soporte para tareas de conjuntos.

La razon de usar bitarrays es para obtener eficiencia a escala y formas creativas de hacer estadisticas.

Ya, la primera vez que usé 'bitarrays' fue para guardar "estados" en un sistema de base de datos multiusuario que creé en 1994. Lo apliqué a una gestión comercial hecha en lenguaje C, al igual que la base de datos, del tipo c-isam. Quedó un sistema rapidísimo en red local, tanto con msdos, drdos y win31, que es lo que había por aquella época.

Edito: Esa fue la segunda vez, la primera vez fue antes, en 1987, ahí sí que lo usé para ahorrar espacio en disco.

Tambien los Set:

http://www.delphibasics.co.uk/RTL.asp?Name=Set

Son una implementacion de bitarray. Asi que es algo muy usado en Pascal ;)

^\||/^\||/^\||/

Jajajajja. La razón no es "seguridad mediante la oscuridad", la razón es mas simple.

Cada sorteo tiene alrededor de 200.000 cartones, los cuales pueden tener 1 o varias combinaciones de 10 número cada uno. Todo esto con un universo de 90 números (1 al 90) para el sorteo.

Si mi tabla de registros de cartones tuviera 10 campos, cada uno INTEGER, para un único sorteo necesitaría 4 bytes * 200.000 registros = 800.000 bytes que son 781 KBytes aprox por sorteo. Si bien no es tanto, suena mas engorroso trabajar con esto que con un valor único que contenga a los valores en un solo campo (bueno, no se)

Si de repente, mi cliente decide hacer un sorteo con 12 números (o de 8), en lugar de 10, ya tendría que pensar en una estructura (tabla) propia para poner los números de la generación de cartones. Para esto tendría que poner otra tabla. :(

En realidad, estoy buscando la mejor manera de registrar en la BBDD los números correspondiente a los cartones que voy a generar. Son muchos por sorteo y estoy pensando a futuro, para no tener que penar con estructura monstruosas. De ahí que acepto todas las sugerencias que me puedan dar al respecto. :)

Gracias.

Eso no es nada :)

Así eran aquellos discos duros en los tiempos mozos de Casimiro:



:D

Ese era ya el modelo nuevo, con bus de datos de 2 bits :p