Recientemente, me vi en la necesidad de hacer una migración de MSAccess a MySQL (en realidad la hice a MariaDB), y cuando estuve normalizando la base de datos y agregando las relaciones respectivas me encontré con el famoso y a la vez desconocido mensaje:
Este error se produce en dos situaciones (básicamente):
La tabla tiene un error interno, ya sea por indexación o similares, en donde la solución es simplemente reconstruir la tabla.
Al agregar una relación, no hay integridad referencial, caso en el cual, generalmente, yo asigno como valor por defecto el valor NULL al campo relacional.
Pero este no fue mi caso en esta ocasión. Todo lucía bien, reconstruí la tabla, verifiqué la integridad referencial y todo lucía perfecto. Excepto porque no podía agregar campos relacionales a varias de las tablas. Le pregunté a San Google y otros santos, sin éxito, así que decidí ponerme a la tarea de probar alternativas hasta encontrar el problema.
Para hacer la historia corta, resultó ser un pequeñísimo detalle que había pasado por alto. Recuerdo cuando aprendí Oracle en donde mi instructor me decía que los nombres de los CONSTRAINTs en Oracle son únicos y no pueden duplicarse, así que probé suerte y funcionó.
La solución es simple y la voy a ilustrar con una consulta, en donde existe una tabla Customer (me está gustando este nombre para los ejemplos) y debe hacer referencia a la tabla City por el campo cityid. Así que la consulta (según mis propios estándares de nombres y normalización quedaría algo así:
ALTER TABLE `Customer`
ADD CONSTRAINT `Customer_Cityid_fk`
FOREIGN KEY (`cityid` )
REFERENCES `City` (`id` )
ON DELETE RESTRICT
ON UPDATE CASCADE
;
La parte importante es “ADD CONSTRAINT `Customer_Cityid_fk`”. En fin, problema resuelto.
¿Alguna vez se le presentó algún error en MySQL/MariaDB que no tuviera explicación aparente?
Luego de trabajar con costosas configuraciones de SQL Server y Oracle la gran mayoría de mi carrera profesional, casi siempre defendiendo estas alternativas de forma “viciada” a capa y espada es difícil abrir los ojos y ver otras opciones, especialmente por esa “propaganda” que apoya la idea (ahora extinta) que: SQL Server y/o Oracle son (o fueron) las mejores elecciones o alternativas de base de datos para la organización. Y creo que muchos solemos ser los “abogados” de las bases de datos comerciales.
Tal vez, estas bases de datos nos han dado de comer durante muchos años, no hay duda, incluso seamos profesionales, tal vez no expertos, pero sí profesionales en el manejo de estos motores, que muchas veces hemos tratado a los demás como “herejes” por no aceptar “la verdad”. Y así como hay profesionales “adictos” a estas bases de datos también, están quienes les guardan distancia por distintas razones.
¿MySQL? Por favor, ¿se están burlando?. ¿PostgreSQL?, Gracias, aunque es en proyecto serio, necesitamos una base de datos de la que podamos depender y confiar.
Suenan familiares las frases anteriores, ¿verdad?.
¿Cuántas veces hemos llevado a cabo algún “análisis” para determinar si, de hecho, SQL Server y/o Oracle eran las mejores elecciones no para mí, sino para el equipo, el cliente, el empleador y la organización?
0
Y si hemos realizado con diligencia esos análisis, ¿Qué hemos aprendido? Dos cosas:
SQL Server y Oracle son realmente bases de datos excelentes. (Está bien, eso ya lo sabíamos.)
SQL Server y Oracle son una elección errónea para el 95% de las necesidades de almacenamiento de datos, incluso a nivel empresarial.
Hoy en día, es agradable pensar en SQL Server y Oracle como las Estrellas de la muerte del universo de las bases de datos relacionales (para decirlo en términos de la Guerra de las Galaxias), es decir, extremadamente poderosas, monolíticas, brillantes, complejas casi más allá de la comprensión que una simple mente humana pueda llegar a tener, y que significan un gasto monumental de dinero excepto en esas raras situaciones cuando se necesita destruir un planeta.
He podido ver (al menos) a una docena de compañías derrochando dinero en bases de datos que no necesitan, impactando y confundiendo sus balances finales con esquemas de licencias que adornan las oficinas, perpetuando así la Falacia del Software de Marca:
En igualdad de condiciones, y asumiendo que se tiene el presupuesto, generalmente se prefiere un costoso (por no decir caro) bien “ajustado” producto comercial como [inserte el producto comercial aquí] a análogos más económicos [inserte producto open-source o de precio razonable aquí]. Los desarrolladores del proyecto XYZ usaron [costoso producto comercial], nuestro XYZ interno usa [producto comercial costoso], ergo, nueva política de la compañía: se utiliza [producto comercial costoso]. Claro, a $89,000 por licencia, [producto comercial costoso] es un poco costoso, pero a quién estamos engañando? Gastamos [inserte un monto realmente ridículo de dinero solo disponible en Monopoly aquí] en IT cada año.
Está bien claro, se ha gastado una cantidad ridícula de dinero en IT. Alguna vez se ha preguntado por qué?
Veamos el siguiente ejemplo en este cuadro (Está inglés pero creo que es bastante claro):
Por qué comprometer su proyecto, su organización, su imperio, para construir y mantener una “Estrella de la Muerte” cuando lo que realmente necesita es una nave X-Wing, un AT-AT, o por mucho, un Destructor de Estrellas? Especialmente dado que:
La gran mayoría de aplicaciones no necesita las capacidades de las últimas, grandes y majestuosas versiones de las base de datos de Microsoft y Oracle .
Firebird SQL, PostgreSQL y MySQL son 100% gratis (en el caso de MySQL hay una versión comercial) lo que significa que, sí eso mismo, no más fatalidad económica a causa de licencias comerciales. (Claro, cabe mencionar que Oracle ahora es dueño de Sun y por ende controla a MySQL.)
Oracle y SQL Server tiene características más potentes que MySQL o PostgreSQL o Firebird o cualquier otra base de datos de código abierto. Tienen una funcionalidad más integrada. Nadie podría afirmar lo contrario. Pero son los desarrolladores y DBAs y las personas que toman las decisiones de compra totalmente conscientes (por ejemplo) tan solo de cuán ricas y poderosas son las características técnicas de PostgreSQL?
Una base de datos de clase empresarial, PostgreSQL cuenta con sofisticadas funciones como el control de concurrencia multi-versión (MVCC), puntos de restauración en el tiempo, tablespaces, replicación asincrónica, transacciones anidadas (savepoints), copias de seguridad en línea/en caliente, un sofisticado analizador/optimizador de consultas, y un sistema write ahead para la tolerancia a fallos. Es compatible con conjuntos de caracteres internacionales, codificación de caracteres multibyte, Unicode, y tiene en cuenta la configuración regional para el ordenamiento, sensibilidad a mayúsculas y minúsculas, y formateo. Es altamente escalable, tanto en la enorme cantidad de datos que puede manejar como en el número de usuarios concurrentes que puede gestionar. Hay sistemas PostgreSQL activos en entornos de producción que manejan 4 terabytes de datos sin problemas.
Dejando las configuraciones de PostgreSQL a un lado, están los desarrolladores conscientes de que MySQL tiene más 11 millones de instalaciones incluyendo gigantes tales como Facebook, YouTube, Flickr, y Wikipedia? Claro, Todo el mundo lo sabe. MySQL se ejecuta en la web, cierto? Entonces, realmente necesitamos el soporte de visualización hiper-cúbica cuatri-dimensional de las bases de datos comerciales cuando las necesidades en datos de la mayoría de organizaciones es modesta, y cuando las dos o tres bases de datos de código abierto han comprobado repetidamente sus capacidades y temple?
No.
No a menos que su necesidad pertenezca al 1% de los escenarios, aprovechando las características únicas de las bases de datos propietarias Oracle/SQL Server. (En tal caso, puede que tenga otro tipo de problema.)
De lo contrario la respuesta es simplemente: no.
Pero no permita que eso lo detenga! Por todo los medios, si usted está en un contrato gubernamental sobrecosteado donde desperdiciar dinero es fomentado, adelante y despréndase de ese dinero que le hace tanto estorbo y adquiera una de esas costosas bases de datos cerradas. Si cuando Microsoft o Oracle dicen “salte!” su organización dice “qué tan alto?”, prosiga y cierre el trato adquiriendo esa licencia costosa de plataforma “superior”. Si su organización está dominada por un montón de bocones aspirantes a evagelistas de tecnología que llevan a cabo una agenda personal, como generalmente es el caso, entonces probablemente no hay mucho que usted pueda hacer en este caso.
Pero si ud cuida el dinero, si cree que…
No! NO está bien desperdiciar una cuarto de millón de dólares al año en licencias de bases de datos a pesar de que el presupuesto IT esté en decenas de millones…
… y si tiene actualmente tiene el poder para influenciar sobre las decisiones de compra, entonces utilice bases de datos de código abierto siempre que le sea posible, y bases de datos comerciales cuando absolutamente deba hacerlo.
Hace un par de días anunciábamos la compra de Sun por parte de Oracle y ya se está lanzando MySQL versión 5.4, sin pasar por la 5.2, ni 5.3. Sun (ahora Oracle) señala en su sitio que esto se debe al gran paquete de mejoras implementadas en el núcleo del motor que promete en algunos casos aumentos de velocidad hasta de un 90% más que su predecesora la versión 5.1. Todo este alboroto ha sido por el parche enviado por Google en donde se da soporte a más de 4 procesadores optimizando las consultas y ejecutándolas en tiempo récord.
Aunque apenas es una versión Preview, se le está dando la importancia de versión estable y vaya que parece serlo. Aprovecha mejor los recursos del servidor y efectivamente las consultas son ejecutadas a mayor velocidad. El Optimizador ha sido mejorado sustancialmente y algunas mejoras a los procedimientos almacenados y el soporte de parámetros OUT en las sentencias preparadas merecen la actualización a la versión 5.4. Definitivamente, Sun (y desde luego Google) se ha lucido con los fans de MySQL antes de despedirse y empezar a llamarse Oracle.
Hoy 23 de abril, es muy bien conocido como el día del libro, y hemos aprovechado la oportunidad para lanzar nuestro magazine virtual, desde donde podrá consultar diariamente las noticias de actualidad tecnológica más importantes del mundo, y hoy para inaugurar no es un día cualquiera, pues varios eventos tecnológicos han sido de relevancia tecnológica en el mundo.
Para comenzar hoy se ha lanzado la tan esperada versión de Ubuntu: Jaunty Jackalope (9.04); que promete optimizaciones no presentes en ninguna otra distribución hasta ahora, especialmente en cuanto a velocidad de arranque se refiere y consumo de recursos, todo desde un solo CD. Aunque para los de habla hispana nos vendría bien el DVD ya que contiene los paquetes de idiomas, no incluídos en el CD de la distribución. Mas información la encontramos en el portal de ubuntu. Y para los que desean afinar su Ubuntu Jaunty Jackalope: un enlace al taller GNU/Linux.
Esta semana también pudimo presenciar la compra de Sun por parte del gigante de las bases de datos: Oracle, ha sido un movimiento estratégico bastante importante por parte de Oracle si tenemos en cuenta que IBM estaba tras el mismo objetivo. Las repercusiones de esta compra son más que evidentes: el sistema operativo para correr Oracle DB será Solaris/OpenSolaris, y (adivinen) el lenguaje: Java, así que hay Java para rato, y quedan preguntas especialmente en cuanto al futuro de tecnologías como OpenOffice y MySQL, aunque no sería extraño ver una integración entre Oracle DB y MySQL lo cual sería una fusión bien interesante, pero a la vez un movimiento estratégico que apuntaría a promocionar y comercializar la base de datos de casa. Amanecerá y veremos.
Por último, para no extender la bienvenida, Google anuncia una API para acceder a Google Analytics, que facilitará el trabajo a consultores y empresas de consultoría web a la hora de presentar informes a sus clientes sobre el desempeño de sus websites.
Nuevamente, bienvenidos y esperamos mantenerles informados sobre la actualidad de la tecnología.
