Cita:
Empezado por cl2raul
he probado con mySQL y tengo problemas cuando lo conecto y no quiero salirme de los sqlite q son muy rapidos...
|
No es muy buena idea negarse a elegir la opcion apropiada (un software
hecho para multiusuario) por simple familiaridad como la opcion que tengo a la mano, pero que no solo no es la opcion apropiada, es *inversa* (sqlite
es para app monousuario y embeida a la misma = Lee el link. Eso es lo que dicen sus creadores. Hazles caso, es cierto).
Usar la herramienta/estrategia adecuada para el problema a la mano es uno de los fundamentos de una buena ingenieria.
Pa rematar "problemas cuando lo conecto" es un problema demasiado trivial! No es que sea mas lento, que no cumpla, que le falta.. simplemente no lo pudiste conectar?
Tener problemas en cuanto a conectarse, o aprender una nueva sintaxis, comandos, etc es TRIVIAl vs intentar implementar lo que hace mysql, pero en sqlite. Si no puedes con lo primero, ni a palos podras con lo segundo.
---
El asunto de fondo es que un software mult-usuario y mucho mas, una base de datos es un animal mas complejo que uno local. Es por eso que es mas "grande" el código de Mysql/Postgresql/firebird que el de sqlite. Aun si ambos tuvieran exactamente la misma funcionalidad, el con soporte mult-usuario/concurrente/servidor implementaria mas cosas y tendría que preocuparse de mas problemas.
Problemas que supones que puedes resolver mejor que lo que hacen los equipos de desarrolladores de Mysql. E incluso, de sqlite.
Torciendo un
dicho famoso en cuanto el desarrollo de software: "Detrás de cada app de base de datos local complicada se esconde una implementación incompleta, defectuosa, lenta y mal enfocada de la mitad de una app de base de datos multi-usuario".
---
En resumen: Usar la herramienta adecuada. Firebird es la mas parecida a sqlite en cuanto a que puede ser tanto embebida como remota. No soy para nada fan de Mysql, firebird & postgres son mucha mejor opción.
Existe un producto que es asi como lo quieres:
http://www.sqlabs.com/cubesql.php. Si ya estas muy amarrado a sqlite, yo me iria por esto, como *segunda mejor opcion* a usar la herramienta adecuada.
---
Ahora, aqui no estamos por desanimar a nadie de que intente alcanzar la luna y reinventar la rueda. De hecho, un programador hace exactamente eso y es lo bonito de esta profesión. Si a algún demente le da por hacer un sistema operativo en javascript, pues que lo haga!. Solo te estoy informando que la
complejidad de intentar que sqlite sea
como mysql es mayor a la de que mysql sea como mysql.
---
"Como crear mi propio server de X"
es lo que estas preguntando. Eso tiene una respuesta generica. Todos los "server" son masomenos la misma cosa: Una app independiente, que esta siempre "viva" probablemente como un servicio del OS, que acepta comandos de forma remota y usa un canal de comunicación para entenderse con N-clientes.
Digamos que lo mas simple fuera que usaras HTTP. Tomas Indy o Synapse, lo pones a escuchar en puerto, y recibes comandos en HTTP. Digamos que es un select, un cliente le mandaria algo como:
HTTP GET localhost:8070:/tablas/clientes/
y en el servidor tendrías una función que a esa ruta le retornas, quizas en JSON, los resultados.
En Delphi podrias usar DataSnap para eso, y te ahorras un monton de codigo elemental. El lio lo tendrias con el hecho de que N-clientes pueden acceder al mismo exacto tiempo a tu BD. Sqlite se puede usar en modo de
multiples hilos, pero debes prestar atencion a como exactamente hacer eso bien.
Hacer una implementacion basica de esto no debe tomarte mas de un par de dias, y quizas te sorprenda que parece ser mucho mas facil de lo que imaginabas. Asi que te recomiendo 100% que hagas eso (total: Que tu app pueda "hablar" http es de lo mas util y te da medio camino a que puedas tener clientes web/moviles, asi que es una habilidad esencial en estos dias).
PERO
Si pretendes que tu app funcione responsablemente con una carga de usuarios concurrentes importante, entonces debes aceptar que sqlite no es la mejor opcion. Recuerda:
"Detrás de cada app de base de datos local complicada se esconde una implementación incompleta, defectuosa, lenta y mal enfocada de la mitad de una app de base de datos multi-usuario".