GUI para MySql

No conocía a Tanaceto, pero el señor Google me ha llevado hasta una página de su blog donde cuenta cómo poner en Ubuntu un interface gráfico de usuario (GUI, in English) para MySql.

Resulta que está disponible sin virguerías (aunque es una virguería que esté disponible); sólo hay que entrar en el gestor de paquetes Synaptic, buscar mysq-admin, marcar e instalar.

Con las galletas que me he dado dudo que se me olvide dónde encontrarlo, pero lo dejo anotado aquí a) por si las moscas, mi memoria no es de fiar, y b) ¿y si a alguien le sirve de algo, lo bien que quedo, y lo barato que me sale? ¿Eh? ¿Eh?

Anotando el script de MySql

Ya tengo otra tontería solucionada: el script de la base de datos. Andaba yo dándole vueltas a cómo irlo publicando. Ahora es un juego con un par de tablas, pero la idea es, obviamente, que se vaya complicando y alargando, y no me parecía buena idea ir pegando en posts el script remodelado. Queda espantoso, es poco práctico y al cabo de unos cuantos quedaría un blog lleno de código repetido y farragoso.

Así que dediqué un rato a jugar con el blog y he descubierto que blogger (o sea, el servicio de Google que aloja este blog gratuito) no permite (o yo no lo he conseguido) colgar archivos, para poder poner el script de forma que pudiera descargarse. Tras buscar una solución por la red, he visto que la gente, y está bastante extendido, lo que hace es un documento con Googledocs, lo hace público, y esto hace que Google le asigne un enlace (véase link) al documento. Se coge dicho enlace, se pega en el blog y andando.

He aquí el que, ahora, es un ejemplo, pero se irá actualizando. De momento, me parece una pasada ir haciendo distintos documentos según crezca el script porque lo producido ni siquiera se pueden llamar versiones, así que el contenido del link se irá actualizando sin más, perdiéndose lo anterior. Si esto llega a ponerse serio, se deja un documento con una versión estable y se crea otro. Pero ahora su función básica es servir de documento en la nube, que es justamente para lo que lo quiero.

El contenido del link es, claro, parecido al que puse en un post anterior, pero cambian, en fin, las formas. Es éste. Si no lo he hecho mal, el documento no está compartido, si no que es público. Es decir, cualquiera puede verlo y copiarse el texto, que es de lo que se trata, pero nadie puede editarlo. Si no es así, please tell me :-)

Scripts en MySql y claves ajenas

Finalmente, he avanzado algo que debo anotar para compartir y para no olvidar: he descubierto, tras no pocos avatares dada mi natural tendencia a irme por las ramas, cómo funcionan los scripts en MySql, y debo decir que es bastante chorra. Nos voy a poner un ilustrativo ejemplo (y digo nos porque esto mismo miraré yo la próxima vez que tenga que hacerlo) (y la siguiente) (y la otra...):

$mysql -uroot -p < archivoBD.sql

Pregunta el password, y ¡hala!, el contenido del archivo scriptBD.sql a la saca. Y para separar las sentencias dentro del archivo, un fermoso punto y coma. Así, un mínimo script tiene una pinta parecida a esta:

create database `definicion`;

CREATE TABLE `definicion`.`SEXOS` (
`CoSex` tinyint(4) NOT NULL,
`DesSex` varchar(15) character set latin1 NOT NULL,
PRIMARY KEY (`CoSex`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_spanish_ci;
insert into definicion.SEXOS values (0, 'Desconocido');
insert into definicion.SEXOS values (1, 'Femenino');
insert into definicion.SEXOS values (2, 'Masculino');

Bueno, pues con esto tenemos creada la base de datos «definicion», dentro de ella la tabla «SEXOS» con el juego de caracteres Unicode (esto está por ver, probaremos acentos, etc.) y aprovechamos para introducir tres sexos de nuestros conejillos de indias. Bien. Pues ahora viene el otro descubrimiento: las claves ajenas.

No las claves ajenas en sí mismas, cachondos, si no cómo codificarlo en MySql. Vamos a crear, por ejemplo, una tabla de las personas que podrán solicitar pruebas y pondremos una clave ajena para relacionar la tabla con la de SEXOS reción creada.

CREATE TABLE `definicion`.`FACULTADOS` (
`CoFac` smallint(6) unsigned NOT NULL,
`IdProfFac` varchar(20) character set latin1 NOT NULL,
`FirmaFac` varchar(50) character set latin1 default NULL,
`CoSexFac` tinyint(4) NOT NULL default 0,
PRIMARY KEY USING BTREE (`CoFac`),
INDEX (`CoSexFac`),
FOREIGN KEY (`CoSexFac`) REFERENCES `SEXOS`(`CoSex`)
) ENGINE=MyISAM AUTO_INCREMENT=4 DEFAULT CHARSET=utf8 COLLATE=utf8_spanish_ci;

Bien, varias cosas. Mis pesquisas me han llevado a descubrir que MySql necesita un índice en cada tabla sobre el campo (los campos, en realidad) que vamos a relacionar. Por un lado, en la tabla SEXOS, ya lo tiene porque es la clave primaria. Por otro lado, los facultados para pedir tendrán un código (interno, numérico, asignado por el sistema, gracias), algún código identificativo, un texto con el que firmar, y, de momento, un sexo.

A este campo, el sexo del facultado, le hacemos un índice y luego le decimos que es clave ajena y que referencia al campo del código del sexo en la tabla SEXOS. Ya está: la definición ya se la traga. El próximo paso, antes de seguir, será ver si efectivamente nos impide meter datos en FACULTADOS con un sexo no existente en la tabla SEXOS. Pero eso no será hoy ;-)

Arrancando: Debian & MySql

Pretendo hacer un sistema de software libre, relativamente complejo, en el que gran peso del mismo recaerá en la base de datos. Mi conocimiento del software libre es, digamos, mejorable (por ser indulgente conmigo mismo), pero, como leí hace poco en alguna parte (siento no mencionar el autor, la fuente no es fiable), «el hombre que mueve montañas empieza apartando guijarros». Amo allá.

Primer paso: un PC que se ha quedado viejo, formateo y Debian al canto. ¿Por qué Debian? Uf, otro día. Pero se pretende que funcione en todas partes. Desde el principio, lo más multiplataforma que sea posible. Digamos que Debian es el que menos desconozco, y se trata de sentirse cómodo, ¿no? Pero no es inamovible: cuando surja un argumento de peso, se cambia.

Mi inconstancia (a lo que se añaden temporadas de imposibilidad real) hace que las actualizaciones me lleven por árboles de problemas que intento podar. Voy optando, como solución, poco a poco, por el minimalismo. Coherentemente, le dejo desprovisto de OpenOffice, con gran pena pero es poco necesario para este proyecto, y dejo pendiente liberarle de más cosas, optimizar arranques y todas esas cosas.

Segundo paso: instalo MySql. ¿Por qué? Porque es, desde la perspectiva del usuario principiante (véase, un servidor), la más conocida de las que cumplen la condición si ne qua non: es software libre. ¿Y ya está? En realidad, no. Llevo una temporada leyendo comparativas (aunque pueden no ser muy fiables), he probado un par de cosas (pero no muy en serio) y no tengo más criterio de momento. Como la elección de Debian

De momento, dejo rastro de la intención... y ahora toca filosofar. Y aprender MySql. Prometo resumen.