suso:
> Hola Mariano, gracias por tan explicíta respuesta :)
No hay porque :)
>>> Hola, pues eso, si yo tuviera una base de datos con sqlite(monopuesto
>>> y monousuario), y quisiera trabajar con ella en red(sé que sqlite no
>>> es para red) sería complicado el tema, me supongo que el hermano mayor
>>> es Postgresql, tendría que hacer traspaso de datos como de access a
>>> sqlite, o cualqier otro sistema.
>>
>> Para hacer el transpaso, podes entrar por línea de comandos al programa
>> de administración (sqlite3) y hacer un dump que te grabará los datos en
>> formato de órdenes SQL (CREATE TABLE, INSERT, etc.), que luego deberás
>> revisarlo y ejecutarlo en PostgreSQL (por línea de comandos, PgAdmin3,
>> etc.):
> Esto se puede hacer todo por código, pero se puede ahcer de forma
> desatendida, es decir, si el cliente tiene que hacer esto, se verá con
> problemas, es correcto?
Por lo que vi, el SQL que genera (exporta) SqLite es bastante compatible
con postgres, no tendrías que tener muchos inconvenientes, sería cuestión
de probarlo.
Igualmente podes hacer una migración del esquema "manualmente", y luego
copiar los datos con un programa "automáticamente".
> Todo esto viene a cuento, de que tengo un sistema, que va a trabajar en
> monousuario, quizás en "x" tiempo, debar prepararse para red, pero
> mientras tanto, hacer que el/os cleinte/s, deban instalar postgres en un
> portátil o pc de sobremesa(pues...), auqnue he leído que se puede hacer
> instalación de postgesql en modo desatendido y "silenciosa.
El instalador para windows PgInstaller tiene opciones para hacer la
instalación de manera desatendida ("automática"), con las opciones que
necesites:
http://pginstaller.projects.postgresql.org/silent.html
Para el controlador ODBC también es posible hacer algo similar.
Si bien, al principio, instalar postgres puede parecer mas complicado que
usar una base de datos local, a la larga creo que ganas en performance,
estabilidad, seguridad y facilidad de mantenimiento.
Además, simplificas el código (no tenés que cambiar las rutinas de altas,
bajas, modificaciones y consultas para access/sqlite y para postgresql).
Si bien siempre es muy parecido el código SQL y el acceso a datos, cada
base tiene sus particularidades que hay que tener en cuenta (más usando
ADO y VB).
> Por eso, pensé en sqlite y/o firebird, si después tengo que migrar, pues
> que fuera lo menos "molesto" posible para mí, desde el punto de vista
> del tratamiento del código, y para el cliente para el traspaso de datos
> Intento con todo esto, que, si llegado el caso se pasa a red, sea lo
> menos "doloroso" posible:)
Por lo que te explicaba antes, y según mi experiencia personal, es menos
"doloroso" empezar de entrada con un buena base (pg), a probar con una
base "local" y luego tener problemas de performance (ancho de banda,
procesamiento), concurrencia (varios usuarios), estabilidad (se
pincha...), etc., y tener que migrar a otro motor y adaptar el código.
Sds
Mariano
--
TIP 10: no uses HTML en tu pregunta, seguro que quien responda no podrá leerlo
