Cómo migrar un servidor de base de datos MySQL Server a un servidor de base de datos PostgreSQL. Explicamos cómo convertir manualmente un fichero de script SQL generado con mysqldump para ser ejecutado y exportado a PostgreSQL. Explicamos cómo hacer la copia de seguridad en MySQL y cómo importarla (tras su adaptación) a PostgreSQL. Mostramos una tabla de correspondencias entre tipos de datos MySQL y PostgreSQL.
- ¿Por qué migrar de MySQL Server a PostgreSQL? MySQL vs PostgreSQL.
- Consejos iniciales antes de la migración de MySQL a PostgreSQL.
- Copia de seguridad de MySQL Server lógica (a fichero SQL).
- Copia de seguridad física de MySQL (ficheros de la BD).
- Realizar pruebas de las aplicaciones de nuestra empresa en la nueva BD PostgreSQL.
- Copia de seguridad física de MySQL (ficheros de la BD).
- Elección del sistema operativo para el servidor de PostgreSQL.
- Cambiar tipos de datos no coincidentes entre MySQL y PostgreSQL.
- Campos autoincremento de MySQL, simular el auto_increment de MySQL en PostgreSQL con secuencias.
- Restricciones de clave (llave única), diferencias entre MySQL y PostgreSQL.
- Tipo de motor de base de datos InnoDB y MyISAM.
- El sistema operativo de los servidores de MySQL y de PostgreSQL.
- Probar y adaptar en caso necesario las aplicaciones que accederán a PostgreSQL.
- Importación del fichero SQL en PostgreSQL resultante de la exportación de MySQL y la adaptación.
- Anexo.
¿Por qué migrar de MySQL Server a PostgreSQL? MySQL vs PostgreSQL
Existen multitud de motivos para cambiar nuestro motor de base de datos de MySQL Server a PostgreSQL. A continuación expondremos algunos de ellos. Aunque hay que hacerlo con precaución y conocimiento de causa, pues es un paso importante y delicado.
No existe un motor de base de datos mejor que otro, existe nuestro entorno y el motor de base de datos que mejor se adapte a él, según nuestras exigencias. Por lo que la decisión de migrar de un motor de base de datos a otro es muy personal.
PostgreSQL es un motor de base de datos mucho más robusto que MySQL, posee una estructura al estilo de Oracle y es Open Source y gratuita, con licencia GPL. En cambio MySQL tiene un sistema de licenciamiento dual, posee una parte privada y otra GPL. Si bien MySQL es un proyecto Open Source, desde su adquisición por parte de Oracle se ha parado bastante. Casi no salen nuevas versiones ni mejoras.
Algunas de las ventajas (pros) de PostgreSQL:
- Ejecución eficaz tanto de SQL estático (por ejemplo, PHP) como de SQL parametrizado (por ejemplo, de Java).
- Optimizador avanzado basado en costo, con opciones de planes de ejecución y recopilación de estadísticas para personalización.
- Indexación parcial, funcional, de múltiples índices combinados, con cuatro tipos de índice diferentes.
- Sistema de compresión de datos TOAST (The Oversized-Attribute Storage Technique).
- Gran escalabilidad al ampliar el número de procesadores o la memoria RAM.
- Soporta rollback, subconsultas, transacciones y control de integridad referencial.
- Soporta triggers y procedimientos almacenados.
- Soporta tipos de datos para sistemas SIG ó GIS (Sistema de Información Geográfica).
- Tiene licencia BSD, mucho más permisiva que la GPL.
- El desarrollo de PostgreSQL no está controlado por una empresa, sino que es dirigido por una comunidad de desarrolladores que trabajan de forma desinteresada, altruista, libre y/o apoyados por organizaciones comerciales. Es un proyecto en contínua actualización, lanzando nuevas versiones con muchas mejoras cada cierto tiempo.
- Posee casi todas las características de otros motores de base de datos comerciales como Oracle, Microsoft SQL Server, Informix.
- Utiliza control de concurrencia multi-versión.
- Totalmente conforme a ACID (Atomicity, Consistency, Isolation and Durability: Atomicidad, Consistencia, Aislamiento y Durabilidad) en sus transacciones.
Algunos inconvenientes (contras) de PostgreSQL:
- Consume bastantes recursos en el equipo donde se instala.
- Es más lento en consultas SELECT que MySQL, aunque no en todos los casos y configuraciones.
Para el caso de MySQL, exponemos algunas de sus ventajas (pros):
- En determinadas configuraciones con el motor MyISAM puede ser muy rápido, sobre todo en consultas SELECT.
- Soporta múltiples motores de almacenamiento: MyISAM, Merge, InnoDB, BDB, Memory/heap, MySQL Cluster, Federated, Archive, CSV, Blackhole y Example en 5.x, permitiendo al usuario escoger la que sea más adecuada para cada tabla de la base de datos, dependiendo del uso que se le vaya a dar.
- Agrupación de transacciones, reuniendo múltiples transacciones de varias conexiones para incrementar el número de transacciones por segundo.
- MySQL Embedded Database.
- Suele consumir pocos recursos del equipo donde se instala, en función de la configuración elegida.
- Existen multitud de aplicaciones para la administración de MySQL.
Algunos inconvenientes (contras) de MySQL:
- Ante todo la adquisición de MySQL por parte de Oracle no deja claro su futuro. No queda claro si se seguirá el desarrollo de MySQL con nuevas versiones con mejores y más características.
- Facilidad de uso y configuración: MySQL es bastante más sencilla de administrar y configurar que PostgreSQL.
- Hasta la versión 6 que sigue en estado alpha no soporta integridad referencial.
- De momento no implementa una buena escalabilidad por lo que no es aconsejable para grandes bases de datos.
En resumen, cada motor de base de datos será interesante para cada situación. La elección del motor de base de datos a usar es muy personal y dependerá de las necesidades y uso que se le vaya a dar. Por ejemplo, para una empresa que quiera montar un servidor web con un sitio web dinámico que sea muy rápido y requiera de pocas modificaciones e inserciones se recomienda MySQL con el motor MyISAM. En cambio, para empresas que requieran de un robusto motor de base de datos con muchas modificaciones e inserciones concurrentes será conveniente usar PostgreSQL.
Así pues no nos podemos decantar por un motor u otro, pues sería un error, cada motor tiene sus ventajas y sus inconvenientes.
Consejos iniciales antes de la migración de MySQL a PostgreSQL
Por supuesto, no en todos los entornos es recomendable cambiar o migrar de MySQL a PostgreSQL. Por ejemplo, en casos de servidores web con Apache, MySQL y PHP, no siempre es recomendable pasar de MySQL a PostgreSQL. MySQL puede ser más rápido en determinados entornos que PostgreSQL. Sobre todo cuando no hay muchas inserciones (INSERT) o modificaciones (UPDATE), cuando hay muchas consultas. En este caso, usando MyISAM de MySQL pueden obtenerse mejores resultados que con PostgreSQL.
Y repetimos, no es conveniente migrar por migrar de un motor de base de datos a otro, conviene estudiar bien las características de cada uno y analizar las que mejor se adapten a nuestro entorno. Hay que tener en cuenta que el uso que se le da a cada base de datos en cada organización o empresa es muy personal. Por ejemplo, una empresa dedicada a la contabilidad y facturación no tendrá los mismos requisitos que una empresa dedicada a servicios web.
Por ello, antes de lanzarse a realizar un cambio de estas dimensiones, es fundamental analizar y realizar las pruebas pertinentes de rendimiento, productividad y disponibilidad en entornos de virtualización. Así garantizaremos que el cambio será exitoso, de lo contrario podremos tener «sorpresas» desagradables.
Copia de seguridad de MySQL Server lógica (a fichero SQL)
Por supuesto y como siempre hemos de realizar copia de seguridad de los datos de MySQL. Vamos a explicar cómo hacer una copia lógica (exportación de los datos a fichero SQL). Esta copia será la usada para la migración o importación a PostgreSQL, usaremos el fichero generado aquí y lo adaptaremos para poder ser ejecutado en PostgreSQL.
Para realizar una copia de seguridad lógica podremos usar cualquier aplicación del mercado o alguna gratuita. Por ejemplo, podremos usar AjpdSoft Copia Seguridad MySQL, como indicamos en el siguiente artículo:
En realidad, la aplicación anterior usa el comando mysqldump de MySQL.
También podremos usar MySQL Administrator, herramienta gratuita disponible en la web de MySQL. Una vez abierta y conectados a la base de datos MySQL, pulsaremos (a la izquierda) en «Backup», pulsaremos en «New Project» y seleccionaremos en «Schemata» el esquema del que haremos copia de seguridad, pasándolo a la derecha con el botón «>». En «Project Name» introduciremos el nombre del proyecto de copia de seguridad, por ejemplo «Copia_ajpdsoft». Si queremos guardar el proyecto pulsaremos «Save Project», si queremos ver más opciones pulsaremos «Advanced Options» y si queremos programarlo para que se ejecute de forma periódica pulsaremos en «Schedule». En nuestro caso lo ejecutaremos directamente pulsando en «Execute Backup Now» pues queremos migrar el sistema MySQL a PosgreSQL y no queremos volver a hacer copia de seguridad:
Por supuesto, en el caso de hacer copia de seguridad para una migración a otro entorno, como es este caso, debemos asegurarnos de que ningún equipo cliente esté accediendo a la base de datos MySQL mientras hacemos la copia de seguridad. Pues si algún cliente accede y hace modificaciones no quedarán guardadas en el fichero de copia de seguridad y no serán migradas a PostgreSQL. Por lo que debemos asegurarnos de que la copia de seguridad para la migración definitiva se hace sin ningún usuario conectado.
Copia de seguridad física de MySQL (ficheros de la BD)
Es conveniente realizar también una copia de los ficheros físicos que conforman la base de datos MySQL. Si vamos a eliminar el servidor con MySQL para cambiarlo por uno con PostgreSQL es muy recomendable hacer copia también de los ficheros físicos de la base de datos, además de la copia lógica. La ubicación de estos ficheros puede consultarse en el fichero my.ini de configuración de MySQL, en el parámetro datadir.
Para hacer la copia de seguridad física de MySQL detendremos el servicio previamente:
Una vez detenido haremos un «copiar pegar», copiaremos los ficheros en un medio no volátil (CD, DVD, unidad de cinta, etc.) y lo guardaremos en lugar seguro. No es conveniente eliminar esta copia de seguridad, pues si se complica el proceso de migración a PostgreSQL siempre podremos volver a MySQL.
Realizar pruebas de las aplicaciones de nuestra empresa en la nueva BD PostgreSQL
Bien usando virtualización o mediante cualquier otro método, es muy recomendable montar un servidor PostgreSQL (en Windows o en Linux) y probar las aplicaciones de nuestra empresa que lo vayan a usar. Incluso aunque los desarrolladores nos aseguren que las aplicaciones son compatibles con PosgreSQL, antes de realizar el cambio de MySQL a PostgreSQL es conveniente testarlas en entornos de prueba (virtualizados o no).
Lo más sencillo y menos costoso es instalar algún software de virtualización como VMware, como indicamos aquí:
Una vez preparada la máquina virtual (con el sistema operativo elegido), instalaremos PostgreSQL, como indicamos aquí:
Para Windows:
Para Linux:
Cuando ya tengamos el entorno de pruebas deberemos cambiar las conexiones de nuestras aplicaciones (por el método indicado por los desarrolladores) para que «apunten» al servidor de PostgreSQL de prueba. Verificaremos que todo funciona correctamente.
Elección del sistema operativo para el servidor de PostgreSQL
Es muy importante tener claro el sistema operativo donde se instalará el motor de base de datos PostgreSQL y que convertiremos en servidor de PostgreSQL. No haremos una comparativa entre GNU Linux y Microsoft Windows para PostgreSQL en este manual porque no es el objetivo. Pero sí queremos dejar claro que es recomendable que hagáis las pruebas de rendimiento, estabilidad y disponibilidad o bien con máquinas virtuales o bien en entornos de prueba real. Tanto si se elige Microsoft Windows como si se elige GNU Linux lo importante es que previamente se hayan barajado los pros y los contras para la organización.
Para el caso de la elección del sistema operativo ocurre lo mismo que para el caso de la elección del motor de base de datos ¿Microsoft Windows vs GNU Linux? ¿MySQL vs PostgreSQL? en todos los casos existen ventajas e inconvenientes. Es cuestión de elegir el sistema operativo que mejor se adapte a las necesidades de la empresa.
Cambiar tipos de datos no coincidentes entre MySQL y PostgreSQL
Deberemos reemplazar los tipos de datos de MySQL no coincidentes con los de PostgreSQL por su correspondiente. Por ejemplo, el tipo de datos «int(10)» de MySQL es equivalente al tipo de datos «integer» de PostgreSQL.
Tipos de datos MySQL y PostgreSQL
En el siguiente artículo se pueden consultar los tipos de datos de MySQL:
En este otro artículo se pueden consultar los tipos de datos de PostgreSQL:
Siguiendo estos manuales, reemplazaremos en el fichero SQL resultante de la exportación de los datos y tablas de MySQL los tipos de datos de MySQL con sus correspondientes PostgreSQL.
Tabla de correspondencias entre algunos tipos de datos de MySQL y PostgreSQL
Indicamos algunos tipos de datos MySQL y su correspondiente PostgreSQL:
| MySQL | PostgreSQL |
| INT(10) | INTEGER |
| TINYINT | SMALLINT |
| MEDIUMINT | INTEGER |
| BIGINT UNSIGNED | NUMERIC(20) |
| DOUBLE | DOUBLE PRECISION |
| FLOAT | REAL |
| TINYTEXT | TEXT |
| MEDIUMTEXT | TEXT |
| LONGTEXT | TEXT |
| BINARY(n) | BYTEA |
| VARBINARY(n) | BYTEA |
| TINYBLOB | BYTEA |
| BLOB | BYTEA |
| MEDIUMBLOB | BYTEA |
| LONGBLOB | BYTEA |
| DATETIME | TIMESTAMP |
| AUTO_INCREMENT | SERIAL (o usar secuencias para generar el autoincremento) |
Campos autoincremento de MySQL, simular el auto_increment de MySQL en PostgreSQL con secuencias
En MySQL el «tipo de datos» autoincremento al uso no existe, MySQL permite generar autoincrementos añadiendo la cláusula «AUTO_INCREMENT» en la creación de una tabla, por ejemplo:
|
1 2 3 4 5 6 |
CREATE TABLE bdajpdsoft.departamento ( codigo integer NOT NULL AUTO_INCREMENT, nombre varchar(150) NOT NULL, codigoubicacion integer ) |
En el caso de PostgreSQL, sí que incorpora un tipo de dato llamado «serial» que es autoincremental. Con lo cual, en nuestro fichero SQL exportado de MySQL, deberemos reemplazar las líneas:
nombre_campo integer AUTO_INCREMENT
Por:
nombre_campo serial
En realidad, al indicar el tipo de datos «serial», será el propio PostgreSQL el que cree una secuencia y la asigne al campo. Por ello PostgreSQL también permite simular los autoincrementos a partir de secuencias (al igual que Oracle). Si queremos usar secuencias en vez del tipo de datos «serial» (que al final será lo mismo), para cada auntoincremento (auto_increment) que tengamos en el SQL de MySQL tendremos que crear una secuencia y luego, en el SQL de creación de la tabla, en el campo que es autoincremento habrá que añadir: DEFAULT NEXTVAL(‘nombre_esquema.nombre_secuencia).
Será algo así, si tenemos este SQL de creación de una tabla en MySQL:
|
1 2 3 4 5 6 |
CREATE TABLE bdajpdsoft.departamento ( codigo integer NOT NULL AUTO_INCREMENT, nombre varchar(150) NOT NULL, codigoubicacion integer ) |
La consulta quedará dividida en dos para el caso de PostgreSQL:
1. Crear la secuencia para el autoincremento del campo «codigo» con:
|
1 2 3 4 |
CREATE SEQUENCE departamento_codigo INCREMENT BY 1 MINVALUE 1 START 1; |
2. Crear la tabla y en el campo «codigo» usar la secuencia anterior con:
|
1 2 3 4 5 6 |
CREATE TABLE bdajpdsoft.departamento ( codigo integer NOT NULL DEFAULT NEXTVAL(bdajpdsoft.departamento_codigo), nombre varchar(100) NOT NULL, PRIMARY KEY (codigo) ); |
Donde: «bdajpdsoft» será el nombre del esquema que usemos en PostgreSQL y «departamento» será el nombre de la tabla.
Restricciones de clave (llave única), diferencias entre MySQL y PostgreSQL
Para el caso de la declaración de las restricciones de claves (claves únicas y claves primarias), MySQL, al exportar con mysqldump, quedarán así:
|
1 2 3 4 5 6 |
CREATE TABLE bdincidencias.categoria ( codigo integer NOT NULL, nombre_campo_unico varchar(75) NOT NULL, fechaalta datetime, PRIMARY KEY (codigo), UNIQUE KEY nombre_clave_unica (nombre) ); |
Para el caso de PostgreSQL, la clave primaria (PRIMARY KEY) se declarará igual que para MySQL, y para las claves únicas, se declararán así:
|
1 2 3 4 5 6 |
CREATE TABLE bdincidencias.categoria ( codigo integer NOT NULL, nombre_campo_unico varchar(75) NOT NULL, fechaalta datetime, PRIMARY KEY (codigo), UNIQUE (nombre_campo_unico) ); |
Otra forma de definirlas en PostgreSQL, fuera de la consulta SQL de creación, es:
1. Para la clave primaria:
|
1 2 |
ALTER TABLE ONLY nombre_tabla ADD CONSTRAINT nombre_clave PRIMARY KEY (nombre_campo); |
2. Para las claves únicas:
|
1 2 |
ALTER TABLE ONLY nombre_esquema.nombre_tabla ADD CONSTRAINT nombre_clave UNIQUE (nombre_campo); |
Tipo de motor de base de datos InnoDB y MyISAM
MySQL admite varios engines (InnoDB, MyISAM, CSV, Archive, Memory, Blackhole, etc.), dependiendo del que hayamos elegido para cada tabla, en el SQL resultante de la exportación con mysqldump, mostrará algo así en cada tabla:
ENGINE=InnoDB
ó
ENGINE=MyISAM
PostgreSQL no admite tipos de engine, por lo que deberemos eliminar estas declaraciones del fichero SQL resultante de la exportación de los datos de MySQL con mysqldump.
El sistema operativo de los servidores de MySQL y de PostgreSQL
En principio, el sistema operativo en el que estén ubicados los servidores de MySQL (origen de la migración) y de PosgreSQL (destino de la migración) es indiferente para el proceso de migración.
Lógicamente si utilizamos GNU Linux, Mac OS X ó Windows, los comandos, aplicaciones y ubicaciones de archivos variarán. Pero el procedimiento de exportación de MySQL a fichero SQL y de modificación (adaptación) del fichero SQL e importación a PostgreSQL será similiar en cualquiera de los sistemas operativos.
En el siguiente artículo explicamos cómo instalar y administrar PostgreSQL en Windows 7:
En este otro artículo instalamos PostgreSQL en Linux:
Probar y adaptar en caso necesario las aplicaciones que accederán a PostgreSQL
Una vez realizada la migración de MySQL a PostgreSQL deberemos asegurarnos de que las aplicaciones de nuestra empresa de facturación, contabilidad, recursos humanos, etc. que guardaban los datos en MySQL funcionan correctamente en PostgreSQL. Para ello deberemos saber el tipo de conexión que usan (ODBC, nativa, etc.) para adaptarla al nuevo motor de base de datos PostgreSQL.
Además, habrá que asegurarse de que las aplicaciones no usen funciones específicas de MySQL como por ejemplo DESCRIBRE table, SHOW DATABASES, SHOW TABLES, etc. que no existen en PostgreSQL. De ser así habrá que adaptarlas a PostgreSQL, contactando con los desarrolladores de las aplicaciones para que realicen las modificaciones pertinentes.
También habrá que tener en cuenta y verificar si las aplicaciones de nuestra empresa que usaban MySQL utilizan funciones de SQL propias de MySQL (cadena de texto, fecha y hora, etc.), que también habrá que adaptar a PostgreSQL.
Importación del fichero SQL en PostgreSQL resultante de la exportación de MySQL y la adaptación
Una vez que hayamos adaptado el fichero SQL resultante de la exportación de MySQL para que pueda ser ejecutado correctamente en PostgreSQL, como hemos indicando en pasos anteriores, lo revisaremos y lo importaremos a PostgreSQL, a continuación explicamos cómo realizar esta importación.
1. En primer lugar crearemos la conexión al servidor, la base de datos y el esquema como indicamos aquí:
2. En el caso de PostgreSQL en GNU Linux abriremos una ventana de terminal, iniciaremos sesión con el usuario postgres, para ello ejecutaremos el comando GNU Linux:
su postgres
Introduciremos la contraseña del usuario postgres (contraseña que configuramos en la instalación de PostgreSQL)
Para realizar la importación definitiva de MySQL a PostgreSQL, ejecutaremos el siguiente comando indicando el archivo de script sql:
psql -U postgres -f /home/ajpdsoft/copia_mysql.sql
Por supuesto, una vez ejecutado el comando para la importación deberemos revisar que los datos se han importado correctamente.
Anexo
Ejemplo de script de SQL generado con PostgreSQL Dump
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 |
-- PostgreSQL database dump -- Started on 2010-11-08 21:49:17 CET SET statement_timeout = 0; SET client_encoding = 'UTF8'; SET standard_conforming_strings = off; SET check_function_bodies = false; SET client_min_messages = warning; SET escape_string_warning = off; -- TOC entry 1789 (class 1262 OID 16384) -- Name: bdajpdsoft; Type: DATABASE; Schema: -; Owner: postgres CREATE DATABASE bdajpdsoft WITH TEMPLATE = template0 ENCODING = 'UTF8' LC_COLLATE = 'es_ES.utf8' LC_CTYPE = 'es_ES.utf8'; ALTER DATABASE bdajpdsoft OWNER TO postgres; \connect bdajpdsoft SET statement_timeout = 0; SET client_encoding = 'UTF8'; SET standard_conforming_strings = off; SET check_function_bodies = false; SET client_min_messages = warning; SET escape_string_warning = off; -- TOC entry 6 (class 2615 OID 16385) -- Name: esajpdsoft; Type: SCHEMA; Schema: -; Owner: postgres CREATE SCHEMA esajpdsoft; ALTER SCHEMA esajpdsoft OWNER TO postgres; SET search_path = esajpdsoft, pg_catalog; SET default_tablespace = ''; SET default_with_oids = false; -- TOC entry 1497 (class 1259 OID 16388) -- Dependencies: 6 -- Name: factura; Type: TABLE; Schema: esajpdsoft; Owner: postgres; Tablespace: CREATE TABLE factura ( codigo integer NOT NULL, fecha date, importe money, codigocliente integer, numero character varying(20) NOT NULL, num_fac integer ); ALTER TABLE esajpdsoft.factura OWNER TO postgres; -- TOC entry 1496 (class 1259 OID 16386) -- Dependencies: 1497 6 -- Name: factura_codigo_seq; Type: SEQUENCE; Schema: esajpdsoft; Owner: postgres CREATE SEQUENCE factura_codigo_seq START WITH 1 INCREMENT BY 1 NO MAXVALUE NO MINVALUE CACHE 1; ALTER TABLE esajpdsoft.factura_codigo_seq OWNER TO postgres; -- TOC entry 1792 (class 0 OID 0) -- Dependencies: 1496 -- Name: factura_codigo_seq; Type: SEQUENCE OWNED BY; Schema: esajpdsoft; Owner: postgres ALTER SEQUENCE factura_codigo_seq OWNED BY factura.codigo; -- TOC entry 1793 (class 0 OID 0) -- Dependencies: 1496 -- Name: factura_codigo_seq; Type: SEQUENCE SET; Schema: esajpdsoft; Owner: postgres SELECT pg_catalog.setval('factura_codigo_seq', 4, true); -- TOC entry 1498 (class 1259 OID 16396) -- Dependencies: 6 -- Name: nota; Type: TABLE; Schema: esajpdsoft; Owner: postgres; Tablespace: CREATE TABLE nota ( codigo integer NOT NULL, nota text ); ALTER TABLE esajpdsoft.nota OWNER TO postgres; -- TOC entry 1499 (class 1259 OID 16399) -- Dependencies: 1498 6 -- Name: nota_codigo_seq; Type: SEQUENCE; Schema: esajpdsoft; Owner: postgres CREATE SEQUENCE nota_codigo_seq START WITH 1 INCREMENT BY 1 NO MAXVALUE NO MINVALUE CACHE 1; ALTER TABLE esajpdsoft.nota_codigo_seq OWNER TO postgres; -- TOC entry 1794 (class 0 OID 0) -- Dependencies: 1499 -- Name: nota_codigo_seq; Type: SEQUENCE OWNED BY; Schema: esajpdsoft; Owner: postgres ALTER SEQUENCE nota_codigo_seq OWNED BY nota.codigo; -- TOC entry 1795 (class 0 OID 0) -- Dependencies: 1499 -- Name: nota_codigo_seq; Type: SEQUENCE SET; Schema: esajpdsoft; Owner: postgres SELECT pg_catalog.setval('nota_codigo_seq', 1, true); -- TOC entry 1777 (class 2604 OID 16391) -- Dependencies: 1496 1497 1497 -- Name: codigo; Type: DEFAULT; Schema: esajpdsoft; Owner: postgres ALTER TABLE factura ALTER COLUMN codigo SET DEFAULT nextval('factura_codigo_seq'::regclass); -- TOC entry 1778 (class 2604 OID 16401) -- Dependencies: 1499 1498 -- Name: codigo; Type: DEFAULT; Schema: esajpdsoft; Owner: postgres ALTER TABLE nota ALTER COLUMN codigo SET DEFAULT nextval('nota_codigo_seq'::regclass); -- TOC entry 1785 (class 0 OID 16388) -- Dependencies: 1497 -- Data for Name: factura; Type: TABLE DATA; Schema: esajpdsoft; Owner: postgres COPY factura (codigo, fecha, importe, codigocliente, numero, num_fac) FROM stdin; 3 2010-01-01 €120,00 1 0001/2010 \N 4 2010-11-08 €154.525,00 2 0002/2010 \N \. -- TOC entry 1786 (class 0 OID 16396) -- Dependencies: 1498 -- Data for Name: nota; Type: TABLE DATA; Schema: esajpdsoft; Owner: postgres COPY nota (codigo, nota) FROM stdin; 1 Prueba de tipo de datos Text para importación \. -- TOC entry 1780 (class 2606 OID 16395) -- Dependencies: 1497 1497 -- Name: factura_numero_key; Type: CONSTRAINT; Schema: esajpdsoft; Owner: postgres; Tablespace: ALTER TABLE ONLY factura ADD CONSTRAINT factura_numero_key UNIQUE (numero); -- TOC entry 1782 (class 2606 OID 16393) -- Dependencies: 1497 1497 -- Name: factura_pkey; Type: CONSTRAINT; Schema: esajpdsoft; Owner: postgres; Tablespace: ALTER TABLE ONLY factura ADD CONSTRAINT factura_pkey PRIMARY KEY (codigo); -- TOC entry 1784 (class 2606 OID 16409) -- Dependencies: 1498 1498 -- Name: nota_pkey; Type: CONSTRAINT; Schema: esajpdsoft; Owner: postgres; Tablespace: ALTER TABLE ONLY nota ADD CONSTRAINT nota_pkey PRIMARY KEY (codigo); -- TOC entry 1791 (class 0 OID 0) -- Dependencies: 3 -- Name: public; Type: ACL; Schema: -; Owner: postgres REVOKE ALL ON SCHEMA public FROM PUBLIC; REVOKE ALL ON SCHEMA public FROM postgres; GRANT ALL ON SCHEMA public TO postgres; GRANT ALL ON SCHEMA public TO PUBLIC; -- Completed on 2010-11-08 21:49:17 CET -- PostgreSQL database dump complete |
Ejemplo de script de SQL generado con MySQL Dump
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 |
-- MySQL Administrator dump 1.4 -- Server version 5.1.42-community /*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */; /*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */; /*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */; /*!40101 SET NAMES utf8 */; /*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */; /*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */; /*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */; -- Create schema gestionagricola CREATE DATABASE IF NOT EXISTS gestionagricola; USE gestionagricola; -- Definition of table `caja` DROP TABLE IF EXISTS `caja`; CREATE TABLE `caja` ( `codigo` int(10) unsigned NOT NULL AUTO_INCREMENT, `fecha` datetime NOT NULL DEFAULT '0000-00-00 00:00:00', `importe` float NOT NULL DEFAULT '0', `saldo` float NOT NULL DEFAULT '0', `concepto` varchar(200) NOT NULL DEFAULT '', `codusuarioa` int(10) unsigned DEFAULT NULL, `codusuariom` int(10) unsigned DEFAULT NULL, `fechaa` datetime DEFAULT NULL, `fecham` datetime DEFAULT NULL, `codigotecnico` int(10) unsigned DEFAULT NULL, `tipo` varchar(10) DEFAULT NULL, PRIMARY KEY (`codigo`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1; -- Dumping data for table `caja` /*!40000 ALTER TABLE `caja` DISABLE KEYS */; /*!40000 ALTER TABLE `caja` ENABLE KEYS */; -- Definition of table `chequepagare` DROP TABLE IF EXISTS `chequepagare`; CREATE TABLE `chequepagare` ( `codigo` int(10) unsigned NOT NULL AUTO_INCREMENT, `fechavencimiento` datetime DEFAULT NULL, `codigotercero` int(10) unsigned NOT NULL DEFAULT '0', `importe` float DEFAULT NULL, `banco` varchar(100) DEFAULT NULL, `tipo` varchar(10) NOT NULL DEFAULT '', `iban` varchar(30) DEFAULT NULL, `ccc` varchar(20) DEFAULT NULL, `serie` char(2) DEFAULT NULL, `numero` varchar(15) DEFAULT NULL, `numero2` varchar(15) DEFAULT NULL, `fechaalta` datetime DEFAULT NULL, `observacion` varchar(255) DEFAULT NULL, `codusuarioa` int(10) unsigned DEFAULT NULL, `codusuariom` int(10) unsigned DEFAULT NULL, `fechaa` datetime DEFAULT NULL, `fecham` datetime DEFAULT NULL, PRIMARY KEY (`codigo`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1; -- Dumping data for table `chequepagare` /*!40000 ALTER TABLE `chequepagare` DISABLE KEYS */; /*!40000 ALTER TABLE `chequepagare` ENABLE KEYS */; -- Definition of table `cita` DROP TABLE IF EXISTS `cita`; CREATE TABLE `cita` ( `codigo` int(10) unsigned NOT NULL AUTO_INCREMENT, `asunto` varchar(150) NOT NULL DEFAULT '', `ubicacion` varchar(150) DEFAULT NULL, `comienzo` datetime DEFAULT NULL, `fin` datetime DEFAULT NULL, `descripcion` text, `codigocategoria` int(10) unsigned DEFAULT NULL, `codusuarioa` int(10) unsigned DEFAULT NULL, `codusuariom` int(10) unsigned DEFAULT NULL, `fechaa` datetime DEFAULT NULL, `fecham` datetime DEFAULT NULL, PRIMARY KEY (`codigo`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1; -- Dumping data for table `cita` /*!40000 ALTER TABLE `cita` DISABLE KEYS */; /*!40000 ALTER TABLE `cita` ENABLE KEYS */; -- Definition of table `cobro` DROP TABLE IF EXISTS `cobro`; CREATE TABLE `cobro` ( `codigo` int(10) unsigned NOT NULL AUTO_INCREMENT, `fecha` datetime DEFAULT NULL, `importe` float DEFAULT NULL, `codigocliente` int(10) unsigned DEFAULT NULL, `descripcion` varchar(255) DEFAULT NULL, `codusuarioa` int(10) unsigned DEFAULT NULL, `codusuariom` int(10) unsigned DEFAULT NULL, `fechaa` datetime DEFAULT NULL, `fecham` datetime DEFAULT NULL, `fichero` longblob, PRIMARY KEY (`codigo`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1; -- Dumping data for table `cobro` /*!40000 ALTER TABLE `cobro` DISABLE KEYS */; /*!40000 ALTER TABLE `cobro` ENABLE KEYS */; -- Definition of table `contacto` DROP TABLE IF EXISTS `contacto`; CREATE TABLE `contacto` ( `codigo` int(10) unsigned NOT NULL AUTO_INCREMENT, `nombre` varchar(100) NOT NULL DEFAULT '', `telefonoparticular1` varchar(20) DEFAULT NULL, `telefonoparticular2` varchar(20) DEFAULT NULL, `telefonoparticular3` varchar(20) DEFAULT NULL, `telefonoparticular4` varchar(20) DEFAULT NULL, `movilempresa1` varchar(20) DEFAULT NULL, `movilempresa2` varchar(20) DEFAULT NULL, `movilempresa3` varchar(20) DEFAULT NULL, `movilempresa4` varchar(20) DEFAULT NULL, `emailparticular1` varchar(150) DEFAULT NULL, `emailempresa1` varchar(150) DEFAULT NULL, `emailparticular2` varchar(150) DEFAULT NULL, `emailparticular3` varchar(150) DEFAULT NULL, `emailparticular4` varchar(150) DEFAULT NULL, `direccionparticular` varchar(250) DEFAULT NULL, `direccionempresa` varchar(250) DEFAULT NULL, `horariotrabajo` varchar(150) DEFAULT NULL, `empresa` varchar(100) DEFAULT NULL, `webparticular` varchar(250) DEFAULT NULL, `webempresa` varchar(250) DEFAULT NULL, `observacion` varchar(255) DEFAULT NULL, `fechaalta` datetime DEFAULT NULL, `ubicacion` varchar(40) DEFAULT NULL, `extension1` varchar(20) DEFAULT NULL, `extension2` varchar(20) DEFAULT NULL, `telefonoempresa1` varchar(20) DEFAULT NULL, `telefonoempresa2` varchar(20) DEFAULT NULL, `telefonoempresa3` varchar(20) DEFAULT NULL, `telefonoempresa4` varchar(20) DEFAULT NULL, `movilparticular1` varchar(20) DEFAULT NULL, `movilparticular2` varchar(20) DEFAULT NULL, `movilparticular3` varchar(20) DEFAULT NULL, `movilparticular4` varchar(20) DEFAULT NULL, `fax1` varchar(20) DEFAULT NULL, `fax2` varchar(20) DEFAULT NULL, `emailempresa2` varchar(150) DEFAULT NULL, `emailempresa3` varchar(150) DEFAULT NULL, `emailempresa4` varchar(150) DEFAULT NULL, `codigotercero` int(10) unsigned DEFAULT NULL, `codusuarioa` int(10) unsigned DEFAULT NULL, `codusuariom` int(10) unsigned DEFAULT NULL, `fechaa` datetime DEFAULT NULL, `fecham` datetime DEFAULT NULL, PRIMARY KEY (`codigo`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1; -- Dumping data for table `contacto` /*!40000 ALTER TABLE `contacto` DISABLE KEYS */; /*!40000 ALTER TABLE `contacto` ENABLE KEYS */; -- Definition of table `documento` DROP TABLE IF EXISTS `documento`; CREATE TABLE `documento` ( `codigo` int(10) unsigned NOT NULL AUTO_INCREMENT, `documento` longblob, `fechaalta` datetime DEFAULT NULL, `version` varchar(40) DEFAULT NULL, `nombre` varchar(150) DEFAULT NULL, `ruta` varchar(255) DEFAULT NULL, `caracteristicas` text, `codusuarioa` int(10) unsigned DEFAULT NULL, `codusuariom` int(10) unsigned DEFAULT NULL, `fechaa` datetime DEFAULT NULL, `fecham` datetime DEFAULT NULL, `codigoregistro` int(10) unsigned DEFAULT NULL, `ventana` varchar(50) DEFAULT NULL, `guardarbd` char(1) DEFAULT NULL, PRIMARY KEY (`codigo`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1; -- Dumping data for table `documento` /*!40000 ALTER TABLE `documento` DISABLE KEYS */; /*!40000 ALTER TABLE `documento` ENABLE KEYS */; -- Definition of table `formapago` DROP TABLE IF EXISTS `formapago`; CREATE TABLE `formapago` ( `codigo` int(10) unsigned NOT NULL AUTO_INCREMENT, `nombre` varchar(100) NOT NULL DEFAULT '', `codusuarioa` int(10) unsigned DEFAULT NULL, `codusuariom` int(10) unsigned DEFAULT NULL, `fechaa` datetime DEFAULT NULL, `fecham` datetime DEFAULT NULL, `dias` int(10) unsigned DEFAULT NULL, `descripcion` varchar(250) DEFAULT NULL, PRIMARY KEY (`codigo`), UNIQUE KEY `formapago_nombre` (`nombre`) ) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=latin1; -- Dumping data for table `formapago` /*!40000 ALTER TABLE `formapago` DISABLE KEYS */; INSERT INTO `formapago` (`codigo`,`nombre`,`codusuarioa`, `codusuariom`,`fechaa`,`fecham`,`dias`,`descripcion`) VALUES (1,'Contado',1,NULL,'2008-01-25 17:41:30',NULL,0,'Contado'), (2,'15 días',1,1,'2008-01-25 17:41:40','2008-01-25 17:42:04',15,'Quince días'), (3,'60 días',1,NULL,'2008-01-25 17:41:52',NULL,60,'60 días'); /*!40000 ALTER TABLE `formapago` ENABLE KEYS */; -- Definition of table `incidencia` DROP TABLE IF EXISTS `incidencia`; CREATE TABLE `incidencia` ( `codigo` int(10) unsigned NOT NULL AUTO_INCREMENT, `fecha` datetime DEFAULT NULL, `codigocliente` int(10) unsigned DEFAULT NULL, `importecoste` float DEFAULT NULL, `importecliente` float DEFAULT NULL, `asunto` varchar(255) DEFAULT NULL, `incidencia` text, `incidenciaresolucion` text, `fecharesolucion` datetime DEFAULT NULL, `estado` varchar(30) DEFAULT NULL, `tipo` varchar(30) DEFAULT NULL, `codigotecnico` int(10) unsigned DEFAULT NULL, `prioridad` varchar(10) DEFAULT NULL, `contacto` varchar(100) DEFAULT NULL, `completado` int(10) unsigned DEFAULT NULL, `fechavencimiento` datetime DEFAULT NULL, `codigorecurso` int(10) unsigned DEFAULT NULL, `codigocontacto` int(10) unsigned DEFAULT NULL, `codusuarioa` int(10) unsigned DEFAULT NULL, `codusuariom` int(10) unsigned DEFAULT NULL, `fechaa` datetime DEFAULT NULL, `fecham` datetime DEFAULT NULL, `aceptada` char(1) DEFAULT NULL, PRIMARY KEY (`codigo`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1; -- Definition of table `parametro` DROP TABLE IF EXISTS `parametro`; CREATE TABLE `parametro` ( `codigo` int(10) unsigned NOT NULL AUTO_INCREMENT, `nombre` varchar(50) DEFAULT NULL, `valor` varchar(100) DEFAULT NULL, PRIMARY KEY (`codigo`) ) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=latin1; -- Dumping data for table `parametro` /*!40000 ALTER TABLE `parametro` DISABLE KEYS */; INSERT INTO `parametro` (`codigo`,`nombre`,`valor`) VALUES (1,'version','1.0.1.50 (25-01-2008)'); /*!40000 ALTER TABLE `parametro` ENABLE KEYS */; -- Definition of table `parcela` DROP TABLE IF EXISTS `parcela`; CREATE TABLE `parcela` ( `codigo` int(10) unsigned NOT NULL AUTO_INCREMENT, `nombre` varchar(100) NOT NULL DEFAULT '', `lugar` varchar(100) DEFAULT NULL, `superficie` float DEFAULT NULL, `numeropies` float DEFAULT NULL, `poligono` varchar(45) DEFAULT NULL, `parcela` varchar(45) DEFAULT NULL, `fechaalta` datetime DEFAULT NULL, `codigovariedad` int(10) unsigned DEFAULT NULL, `fechaplantacion` datetime DEFAULT NULL, `goterospie` float DEFAULT NULL, `litroshoragotero` float DEFAULT NULL, `observacion` text, PRIMARY KEY (`codigo`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1; -- Dumping data for table `parcela` /*!40000 ALTER TABLE `parcela` DISABLE KEYS */; /*!40000 ALTER TABLE `parcela` ENABLE KEYS */; /*!40101 SET SQL_MODE=@OLD_SQL_MODE */; /*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */; /*!40014 SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS */; /*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */; /*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */; /*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */; /*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */; |
