|
PostgreSQL: Cómo exportar o migrar una base de datos MySQL a PostgreSQL de forma manual
Explicamos 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 PostgreSQLExisten 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:
Algunos inconvenientes (contras) de PostgreSQL:
Para el caso de MySQL, exponemos algunas de sus ventajas (pros):
Algunos inconvenientes (contras) de MySQL:
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 PostgreSQLPor 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: AjpdSoft Copia Seguridad MySQL 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 PostgreSQLBien 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 testearlas 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í: Virtualización con VMware Server 2.0, acceso remoto a máquinas virtuales Una vez preparada la máquina virtual (con el sistema operativo elegido), instalaremos PostgreSQL, como indicamos aquí: Para Windows: Instalar y administrar PostgreSQL en Microsoft Windows 7 Para Linux: Instalar el motor de base de datos PostgreSQL 8.4 en GNU Linux Ubuntu 10 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 PostgreSQLEs 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 PostgreSQLDeberemos 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 PostgreSQLEn el siguiente artículo se pueden consultar los tipos de datos de MySQL: Tipos de datos en MySQL Server En este otro artículo se pueden consultar los tipos de datos de PostgreSQL: Tipos de datos data types en el motor de base de datos 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 PostgreSQLIndicamos algunos tipos de datos MySQL y su correspondiente PostgreSQL:
Campos autoincremento de MySQL, simular el auto_increment de MySQL en PostgreSQL con secuenciasEn 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: 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:
Por:
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: 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:
2. Crear la tabla y en el campo "codigo" usar la secuencia anterior con: 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 PostgreSQLPara el caso de la declaración de las restricciones de claves (claves únicas y claves primarias), MySQL, al exportar con mysqldump, quedarán así:
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í:
Otra forma de definirlas en PostgreSQL, fuera de la consulta SQL de creación, es: 1. Para la clave primaria:
2. Para las claves únicas:
Tipo de motor de base de datos InnoDB y MyISAMMySQL 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:
ó
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 PostgreSQLEn 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: Instalar y administrar PostgreSQL en Microsoft Windows 7 En este otro artículo instalamos PostgreSQL en Linux: Instalar el motor de base de datos PostgreSQL 8.4 en GNU Linux Ubuntu 10
Probar y adaptar en caso necesario las aplicaciones que accederán a PostgreSQLUna 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ónUna 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í: Administración de PostgreSQL, creación de usuarios (roles), catálogos 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:
Para realizar la importación definitiva de MySQL a PostgreSQL, ejecutaremos el siguiente comando indicando el archivo de script sql:
Por supuesto, una vez ejecutado el comando para la importación deberemos revisar que los datos se han importado correctamente.
AnexoEjemplo de script de SQL generado con PostgreSQL Dump-- -- 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 Ejemplo de script de SQL generado con MySQL Dump-- 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`,
Artículos relacionados
CréditosArtículo realizado íntegramente por Alonsojpd miembro fundador del proyecto AjpdSoft. Anuncios
Enviado el Domingo, 14 noviembre a las 20:52:36 por ajpdsoft
|
|