Hace ya unos días que ocurrió el tremendo accidente de aviación de Barajas. No comentaré nada sobre el morbo con el cual se ha tratado el tema ni sobre el envilecimiento de los medios de comunicación. Simplemente, he estado investigando sobre algo que me ha llamado siempre la atención: las cajas negras de los aviones.
Primero, los tópicos o lugares comunes: las cajas negras no son negras, están situadas en la cola del avión (la zona que menos daños sufre del avión), son indestructibles, … En fin, todo lo que se nos ha contado machaconamente desde la televisión.
Una caja negra es un instrumento de grabación de los datos de vuelo y de las conversaciones que se desarrollan en el avión. El sistema grabador de datos (DFR) guarda la información más relevante del vuelo: velocidad del aire, rumbo, altura, situación horizontal, aceleración vertical … y así hasta más de trescientos datos. Los distintos sensores situados en el avión envían la información a un dispositivo electrónico que es el encargado de tratarla y almacenarla. El sistema grabador de voces (CVR) registra todas las conversaciones que se producen en la cabina, incluyendo las de radio. En ocasiones también se pueden guardar las conversaciones producidas en el pasaje. Dependiendo del sistema usado, puede almacenarse entre treinta minutos y dos horas de conversaciones. Cuando se acaba la cinta, vuelve a empezar a grabar por el inicio otra vez. Estas conversaciones no pueden ser borradas hasta que el avión está totalmente detenido. La grabación se realiza o bien en cinta magnetoscópica o en un sistema digital.
¿Cómo podemos asegurar que una caja negra es indestructible? Está fabricada en titanio, o en algún material con una resistencia similar (he leído también acero). Aguanta toneladas de peso, impactos de varias veces la fuerza de la gravedad y temperaturas de miles de grados. No voy a dar datos concretos porque las fuentes ofrecen valores dispares. Supongo que dependerá del modelo concreto. En cualquier caso, incluyen una protección térmica, un aislante y una coraza. Como test de prueba, se lanzan con un cañón contra un muro, para valorar su resistencia al impacto.
Están preparadas para aguantar en el agua, a cientos de metros de profundidad. Incluso en esas circunstancias son capaces de enviar una señal electrónica durante un mes.
En fin, nada más. Sólo expresar la esperanza de que la tecnología nos ayude cada vez más a salvar vidas. Creo que esa es su misión principal. He copiado toda la información de:
http://news.bbc.co.uk/hi/spanish/science/newsid_1544000/1544369.stm
http://www.avionteca.com/cajanegraaviones.htm
http://www.rescate.com/cajanegra.html
http://www.versionfinal.com.ve/wp/wp-content/uploads/Lasvocesdelatragedia_EB4F/info_caja_negra.pdf

Hace unos días, como solución al spam que nos llega al correo, Makj nos propuso implementar una solución basada en listas grises. El concepto de listas grises es un siguiente paso de los ya conocidos de listas blancas (direcciones desde las cuales aceptaremos los correos) y de listas negras (direcciones desde las que no aceptaremos correos. Como ejemplo, la lista negra de la wikipedia).

El funcionamiento de las listas grises es tremendamente simple: decir no la primera vez. Cuando nos envíen un correo desde una dirección que no conozcamos, el servidor responderá dando un error y pidiendo que se reenvíe el correo más tarde. Si este correo se reenvía, lo cuál es el funcionamiento por defecto de cualquier servidor, entonces será aceptado. Ahora viene la duda ¿Cómo se supone que pararemos el spam si cuando los propios spammers nos  reenvíen los correos éstos serán aceptados? La respuesta es genial por simple: los spammers, en la mayoría de los casos, no reenvían. Al manejar tantas direcciones, no se pueden tomar el lujo de guardar las direcciones “erróneas” para intentarlo más tarde.

El gran problema de las listas grises es el retraso del primer correo que recibimos de una dirección. Es más, puede darse la paradoja de que, si nos envían más de uno, nos lleguen antes los sucesivos. Esto se soluciona “entrenando” a la lista gris. Es decir, dejarla abierta para que vaya “aprendiendo” cuales son los correos confiables. Parece ser que la solución ideal es esa: una combinación de listas grises que pueda acceder a una lista blanca de direcciones iniciales.

No tenía intención de escribir más artículos de Oracle esta semana (no quiero ser tan pesado). La cuestión es que me ha llegado vía mail la revista digital de Oracle y … aparece un artículo que no me resisto a comentar.
El hombre que más sabe de Oracle del mundo, Tom Kyte, escribe un genial articulo sobre los problemas que pueden provocar los triggers en Oracle, y que alternativas se pueden tomar.

Creo que, si os interesa el tema, os deberíais leer el artículo. Es genial como soluciona con tablas y vistas el problema de prescindir de los triggers. En cualquier caso, quería señalar tres aspectos muy importantes:

1. NUNCA se deben utilizar en los triggers funciones o procedimientos sobre los cuales no se pueda realizar un rollback. Por ejemplo, envío de mails, ya que si se produce un rollback en la base de datos, los mails ya habrán sido enviados.

2. Pensar siempre en las repercusiones de los triggers, y tenerlos en cuenta cuando se analice el código de la aplicación. En cualquier caso, valorar si son necesarios e intentar prescindir de ellos. Es típico que la tabla de empleados tenga una columna del tipo nombre_completo que sea una concatenación del nombre y los dos apellidos. En lugar de escribir un trigger con el código:


:new.nombre_completo := :new.nombre||' '||:new.apellido_1||' '||:new.apellido_2;


Sería más correcto eliminar la columna y el trigger. Después podemos crear nombre_completo como un campo de una vista o como una columna virtual.

3. Es necesario entender como funcionan los triggers … y Oracle en general. Si intentáis consultar sobre la tabla en el trigger de modificación, os saltará un error de “tabla mutando”. Este error es más un aviso que un error. Si nos lo saltamos (existen mecanismos) el resultado de la operación es totalmente impredecible, lo cual es un auténtico desastre. No tenemos más remedio que replantearnos el modelo de datos.

Creo que debería haber titulado el post con la frase más contundente de Tom: “I find them a pain in the neck”. Como conclusión, la misma a la que llega él: “Los triggers deben ser la excepción, no la norma. Deben ser utilizados sólo cuando no se pueda realizar lo mismo de otra forma”