Ir al contenido



Foto

Alternativa a Zeos y cual DB recomiendan


  • Por favor identifícate para responder
20 respuestas en este tema

#1 Gaston

Gaston

    Advanced Member

  • Miembros
  • PipPipPip
  • 72 mensajes

Escrito 24 octubre 2016 - 08:21

Hola, por suerte me ha ido bien y mi prototipo fue aprobado, utilicé SQLite y Zeos con Lazarus 1.6 sobre Linux, luego compile para Windows sin ningún problema, grata sorpresa. 

El tema es que necesito de vuestra experiencia para que me orienten sobre servidores de bases de datos. Mi experiencia además de la citada, es que tengo MariaDB funcionando en la PC porque la necesite para hacer un ejercicio del libro de Lazarus. Buscando info las opiniones están divididas.

El volumen de datos, la tabla más grande puede tener unos 7.000 registros anuales.

Zeos no me termina de convencer, de hecho encontré un bug que data del año 2008 el primer reporte y luego el mismo bug reportado en 2012 y sin solución hasta hoy, de hecho desde el foro explican como arreglar el inconveniente. 

Resumiendo, creo que la elección pasa por Firebird, MariaDB o PostgreSQL. Y conjuntamente las herramientas de conexión, no sé sí necesito agregar algún paquete a Lazarus como hice con Zeos o me puedo arreglar con lo que ya trae incorporado. Busco lo menos complicado posible. siempre hablando de DB relacionales.

Cualquier comentario, experiencia, consejo, será agradecido.

 

Saludos.

 

Al margen de eso, falta la traducción en Lazarus de un componente de impresión, así que lo hice y lo adjunto por sí a alguien le sirve: printer4lazstrconst.es.po

Perdón pero me dice que no tengo permiso para adjuntar el archivo.


  • 0

#2 Delphius

Delphius

    Advanced Member

  • Administrador
  • 5.999 mensajes
  • LocationArgentina

Escrito 24 octubre 2016 - 09:13

Hola, por suerte me ha ido bien y mi prototipo fue aprobado, utilicé SQLite y Zeos con Lazarus 1.6 sobre Linux, luego compile para Windows sin ningún problema, grata sorpresa. 

El tema es que necesito de vuestra experiencia para que me orienten sobre servidores de bases de datos. Mi experiencia además de la citada, es que tengo MariaDB funcionando en la PC porque la necesite para hacer un ejercicio del libro de Lazarus. Buscando info las opiniones están divididas.

El volumen de datos, la tabla más grande puede tener unos 7.000 registros anuales.

Zeos no me termina de convencer, de hecho encontré un bug que data del año 2008 el primer reporte y luego el mismo bug reportado en 2012 y sin solución hasta hoy, de hecho desde el foro explican como arreglar el inconveniente. 

Resumiendo, creo que la elección pasa por Firebird, MariaDB o PostgreSQL. Y conjuntamente las herramientas de conexión, no sé sí necesito agregar algún paquete a Lazarus como hice con Zeos o me puedo arreglar con lo que ya trae incorporado. Busco lo menos complicado posible. siempre hablando de DB relacionales.

Cualquier comentario, experiencia, consejo, será agradecido.

 

Saludos.

 

Al margen de eso, falta la traducción en Lazarus de un componente de impresión, así que lo hice y lo adjunto por sí a alguien le sirve: printer4lazstrconst.es.po

Perdón pero me dice que no tengo permiso para adjuntar el archivo.

 

Hola Gastón,

Yo la verdad que sobre componentes de acceso a base de datos en Lazarus/CodeTyphon no te sabría recomendar otro que fuera Zeos. Que es lo que yo uso.

Desconozco otras suites, y si es que las hay Open Source y/o Free Software. La suite SQLdb, que es la por defecto que viene en Lazarus, soporta varios motores de base de datos y está probada que funciona. Aunque su diseño y forma de trabajar un tanto diferente a la de Zeos. Esta suite tiene formalmente el componente Transaction como lo es en IBX en Delphi.

El defecto de SQLdb es que no cuenta con un abanico de mayores componentes y especializados como por ej. los StoredProc.

 

Tuve las mismas dudas (hilo 1, hilo 2) que tú hace un tiempo. Y al final le pude (y tuve que) perdonar sus defectos a Zeos.

Me pica la curiosidad sobre los bugs que comentas. Nos puede servir a modo de ayuda y advertencia para el resto de la comunidad que nos comentes sobre ellos.

 

Si deseas probar SQLdb sugiero que leas la wiki. Para comenzar, sugiero esto y esto. También hay un tutorial. En el primer artículo tiene los enlaces al mismo.

 

También está la posibilidad de emplear IBX. Si, ahora se ha portado IBX para Lazarus. El proyecto estuvo dormido un buen tiempo, pero ahora está más activo. Aunque claro: esto es válido para trabajar con Firebird (y tengo la sospecha de si es que de casualidad podría soportar Interbase).

La otra posibilidad es salir fuera del mundo "gratuito" y mirar opciones de paga. He leído buenos comentarios sobre Unidac y que yo sepa y tengo entendido soporta Lazarus.

 

Sobre los motores, en DelphiAccess tenemos una tendencia de elegir Firebird. Aunque hay usuarios que optan por PostgreSQL primero. En mi opinión, la elección del motor depende de cada proyecto, de las necesidades técnicos-operativas, y hasta del propio cliente e incluso puede ser motivo a que se nos condicione a usar X motor (el cliente paga, el cliente "manda")... por que por ejemplo, si el cliente ya tiene una infraestructura informática basada en SQL Server, no es mala idea aprovecharla y directamente que la aplicación a desarrollar trabaje con ese motor. Y si nos dicen que tiene que ser en MySQL porque quiere, o porque ya tiene todo basado en él pues no queda otra y hacerle caso.

 

Suites para todos hay. Las hay generales como Zeos, como las particulares.

 

Respecto a la traducción de la documentación de un componente me parece muy (y más) adecuado que te pongas en contacto con el desarrollador del mismo y se la entregues. De esta forma la comunidad se beneficia y se realiza todo por los canales oficiales.

 

Por medidas de seguridad, tenemos deshabilitado adjuntar archivos a los usuarios "nuevos". Se te habilitará la función en cuanto llegues a los 20 mensajes (si, creo recordar que lo configuramos en 20).

 

Saludos,


  • 1

#3 FerCastro

FerCastro

    Advanced Member

  • Miembro Platino
  • PipPipPip
  • 619 mensajes
  • LocationCiudad de México

Escrito 24 octubre 2016 - 10:43

Hola Gastón,

 

Si andas buscando librerias de código abierto, no podría darte alguna opción. Pero si tienes unos dólares que te sobran puedes comprar las liberías de Devart.

 

Yo llevo trabajando casi 10 años con ellas y según mi muy particular y limitado punto de vista, no existe mejor librería para trabajar la capa de conectividad que este componente.

 

www.devart.com

 

 

Saludos!!


  • 1

#4 Delphius

Delphius

    Advanced Member

  • Administrador
  • 5.999 mensajes
  • LocationArgentina

Escrito 24 octubre 2016 - 10:54

Hola Gastón,

 

Si andas buscando librerias de código abierto, no podría darte alguna opción. Pero si tienes unos dólares que te sobran puedes comprar las liberías de Devart.

 

Yo llevo trabajando casi 10 años con ellas y según mi muy particular y limitado punto de vista, no existe mejor librería para trabajar la capa de conectividad que este componente.

 

www.devart.com

 

 

Saludos!!

 

Yo ya le había comentado sobre UniDAC ;) 

Tu que tienes experiencia usándolos, podrías darnos más detalles sobre ellos. He leído muchos comentarios y todos hablan maravillas de él. ¿Es para tanto?

 

Saludos,


  • 0

#5 Gaston

Gaston

    Advanced Member

  • Miembros
  • PipPipPip
  • 72 mensajes

Escrito 24 octubre 2016 - 12:12

Gracias Delphius, como siempre muy interesante todo, ya marqué los links para estudiarlos y creo que deberé darle una segunda oportunidad a Zeos, según parece, el tema también es la escasa documentación que hay, además tuve problemas de update, el autocommit no es tan auto... pero puede ser que yo le esté errando en algunas cosas también, no sería extraño, vengo de los .dbf así que es lo más probable...

 

El bug que encontré, está aquí y lo solucioné haciendo lo contrario a lo que un desarrollador propone. que es poner


delphi
  1. ValidateUpdateCount=False 

sin comillas, en Properties de las Propiedades del ZQuery. El bug es que en un DBGrid cada x actualización por modificación de datos tiraba un error de que solo se puede hacer una actualización a la vez, pero este error no lo tiraba a la 2da. actualización, sino que lo tiraba a la 4ta, o a la 1ra. o a la 10ma, ahí olfateé que probablemente fuera un bug, Zeos cuenta mal, tiene un problema ahí para ciertos casos, y bueno, ValidateUpdateCount=False no necesita mucha explicación.


delphi
  1. msgid ""
  2. msgstr ""
  3. "Content-Type: text/plain; charset=UTF-8\n"
  4. "Project-Id-Version: \n"
  5. "POT-Creation-Date: \n"
  6. "PO-Revision-Date: \n"
  7. "Last-Translator: \n"
  8. "Language-Team: \n"
  9. "MIME-Version: 1.0\n"
  10. "Content-Transfer-Encoding: 8bit\n"
  11. "X-Generator: Poedit 1.8.4\n"
  12. "Plural-Forms: nplurals=2; plural=(n != 1);\n"
  13. "Language: es\n"
  14.  
  15. #: printer4lazstrconst.p4lrsadvanced
  16. msgid "Advanced"
  17. msgstr "Avanzado"
  18.  
  19. #: printer4lazstrconst.p4lrsbanners
  20. msgid "Banners"
  21. msgstr "Banners"
  22.  
  23. #: printer4lazstrconst.p4lrscancel
  24. msgid "Cancel"
  25. msgstr "Cancelar"
  26.  
  27. #: printer4lazstrconst.p4lrsend
  28. msgid "End"
  29. msgstr "Fin"
  30.  
  31. #: printer4lazstrconst.p4lrsgeneral
  32. msgid "General"
  33. msgstr "General"
  34.  
  35. #: printer4lazstrconst.p4lrslandscape
  36. msgid "Landscape"
  37. msgstr "Horizontal"
  38.  
  39. #: printer4lazstrconst.p4lrsmargins
  40. msgid "Margins"
  41. msgstr "Márgenes"
  42.  
  43. #: printer4lazstrconst.p4lrsok
  44. msgid "Ok"
  45. msgstr "OK"
  46.  
  47. #: printer4lazstrconst.p4lrsorientation
  48. msgid "Orientation"
  49. msgstr "Orientación"
  50.  
  51. #: printer4lazstrconst.p4lrspagespersheet
  52. msgid "Pages per sheet"
  53. msgstr "Páginas por hoja"
  54.  
  55. #: printer4lazstrconst.p4lrspapersize
  56. msgid "Paper size"
  57. msgstr "Tamaño del papel"
  58.  
  59. #: printer4lazstrconst.p4lrspapersource
  60. msgid "Paper source"
  61. msgstr "Fuente del papel"
  62.  
  63. #: printer4lazstrconst.p4lrspapertype
  64. msgid "Paper type"
  65. msgstr "Tipo de papel"
  66.  
  67. #: printer4lazstrconst.p4lrsportrait
  68. msgid "Portrait"
  69. msgstr "Vertical"
  70.  
  71. #: printer4lazstrconst.p4lrsprinterproperties
  72. msgid "Printer properties"
  73. msgstr "Propiedades de la impresora"
  74.  
  75. #: printer4lazstrconst.p4lrsresolution
  76. msgid "Resolution"
  77. msgstr "Resolución"
  78.  
  79. #: printer4lazstrconst.p4lrsreverselandscape
  80. msgid "Reverse landscape"
  81. msgstr "Horizontal invertido"
  82.  
  83. #: printer4lazstrconst.p4lrsreverseportrait
  84. msgid "Reverse portrait"
  85. msgstr "Vertical invertido"
  86.  
  87. #: printer4lazstrconst.p4lrsstart
  88. msgid "Start"
  89. msgstr "Comenzar"
  90.  

Ese código corresponde al archivo: printer4lazstrconst.es.po para traducir el diálogo de la ventana de impresión, la segunda ventana precisamente,que puede ir en la carpeta del proyecto junto al resto de las traducciones. Perdón pero no tengo ni idea de como contactar al encargado de esto en Lazarus, hace 2 meses estaba probando el "Hello World"... Los otros dos archivos se encuentran en las carpetas de Lazarus, LCL y LazReport y son lclstrconsts.es.po y lr_const.es.

 

FerCastro, gracias por la recomendación, aparenta ser un muy buen producto según la web, no tengo nada contra el software pago, de hecho cobro por mi software, pero además de no estar en condiciones económicas adecuadas en este momento, recién estoy empezando a entender el mundo de SQL y sus derivados, sus motores, librerías, paquetes, servidores, layers, transactions y cosas que hasta hace poco para mí era chino mandarín. Cuando entienda bien todo esto, seguro lo pruebo si tiene alguna versión Trial y si lo entiendo y me facilita la vida, lo compro.

 

Delphius, estoy leyendo esto http://www.mwasoftware.co.uk/ibxy me interesa, es una especie de FireBird"Lite", es un motor SQL de Borland, un manejador de FireBird o estoy entendiendo mal. La última versión salió hace muy poco para Lazarus 1.6 con FPC 3.0 que es justo lo que tengo. Lo has usado? Si es así, es más simple que PostgreSQL que me da la sensación de que es muy bueno pero complicado.

 

El servidor es un Windows 2008, lo que hay ahí no importa porque sería reemplazado con mi sistema.

 

Saludos y gracias por su tiempo.

 

 


  • 0

#6 FerCastro

FerCastro

    Advanced Member

  • Miembro Platino
  • PipPipPip
  • 619 mensajes
  • LocationCiudad de México

Escrito 24 octubre 2016 - 12:38

Estimado Delphius,

 

Desde 2007 que tuve la necesidad de conectarme a MySQL y que conocí MyDAC no he soltado esos productos.

 

- Actualizaciones continuas

- Multiplataforma (Win, Laz y Firemonkey)

- UNIDAC, que te permite con un solo componente conectarte a diferentes bases de datos, la mayoría de ellas de manera nativa, otras por medio de ODBC.

- Soporte casi inmediato.

- Conectividad directa (sin necesidad, por ejemplo si trabajas con SQLIte, que es mi casi, de incluir los DLL's.

- Para Oracle no creo en verdad que exista algo que los supere. Algo hicieron estos rusos para volar en Oracle (en este momento mientras escribo estoy depurando código con ODAC, la versión de Devart para oracle, y creeme, es un sukhoi de 5ta generación.

 

 

Tengo un proyecto que se conecta a SQLite, FireBird y MySQL y utilizando el Unidac declaro mis conectores y es increíble la rapidez, estabilidad y sencillez para conectarse.

 

Supongo que existen otras que pudieran ser mejores, pero la verdad es que no las conozco y ya no ando buscando, estoy casado con ellas y hasta ahora ha sido un matrimonio de luna de miel.

 

- No me pagan por el comercial  :)

 

Saludos!!


  • 1

#7 egostar

egostar

    missing my father, I love my mother.

  • Administrador
  • 13.677 mensajes
  • LocationMéxico

Escrito 24 octubre 2016 - 12:42

Estimado Delphius,

 

Desde 2007 que tuve la necesidad de conectarme a MySQL y que conocí MyDAC no he soltado esos productos.

 

- Actualizaciones continuas

- Multiplataforma (Win, Laz y Firemonkey)

- UNIDAC, que te permite con un solo componente conectarte a diferentes bases de datos, la mayoría de ellas de manera nativa, otras por medio de ODBC.

- Soporte casi inmediato.

- Conectividad directa (sin necesidad, por ejemplo si trabajas con SQLIte, que es mi casi, de incluir los DLL's.

- Para Oracle no creo en verdad que exista algo que los supere. Algo hicieron estos rusos para volar en Oracle (en este momento mientras escribo estoy depurando código con ODAC, la versión de Devart para oracle, y creeme, es un sukhoi de 5ta generación.

 

 

Tengo un proyecto que se conecta a SQLite, FireBird y MySQL y utilizando el Unidac declaro mis conectores y es increíble la rapidez, estabilidad y sencillez para conectarse.

 

Supongo que existen otras que pudieran ser mejores, pero la verdad es que no las conozco y ya no ando buscando, estoy casado con ellas y hasta ahora ha sido un matrimonio de luna de miel.

 

- No me pagan por el comercial   :)

 

Saludos!!

 

Y mira que lo vendes bien, porque no te pones en contacto con ellos :D :D :D

 

Saludos


  • 0

#8 Delphius

Delphius

    Advanced Member

  • Administrador
  • 5.999 mensajes
  • LocationArgentina

Escrito 24 octubre 2016 - 03:26

Gracias Delphius, como siempre muy interesante todo, ya marqué los links para estudiarlos y creo que deberé darle una segunda oportunidad a Zeos, según parece, el tema también es la escasa documentación que hay, además tuve problemas de update, el autocommit no es tan auto... pero puede ser que yo le esté errando en algunas cosas también, no sería extraño, vengo de los .dbf así que es lo más probable...

 

El bug que encontré, está aquí y lo solucioné haciendo lo contrario a lo que un desarrollador propone. que es poner


delphi
  1. ValidateUpdateCount=False 

sin comillas, en Properties de las Propiedades del ZQuery. El bug es que en un DBGrid cada x actualización por modificación de datos tiraba un error de que solo se puede hacer una actualización a la vez, pero este error no lo tiraba a la 2da. actualización, sino que lo tiraba a la 4ta, o a la 1ra. o a la 10ma, ahí olfateé que probablemente fuera un bug, Zeos cuenta mal, tiene un problema ahí para ciertos casos, y bueno, ValidateUpdateCount=False no necesita mucha explicación.


delphi
  1. msgid ""
  2. msgstr ""
  3. "Content-Type: text/plain; charset=UTF-8\n"
  4. "Project-Id-Version: \n"
  5. "POT-Creation-Date: \n"
  6. "PO-Revision-Date: \n"
  7. "Last-Translator: \n"
  8. "Language-Team: \n"
  9. "MIME-Version: 1.0\n"
  10. "Content-Transfer-Encoding: 8bit\n"
  11. "X-Generator: Poedit 1.8.4\n"
  12. "Plural-Forms: nplurals=2; plural=(n != 1);\n"
  13. "Language: es\n"
  14.  
  15. #: printer4lazstrconst.p4lrsadvanced
  16. msgid "Advanced"
  17. msgstr "Avanzado"
  18.  
  19. #: printer4lazstrconst.p4lrsbanners
  20. msgid "Banners"
  21. msgstr "Banners"
  22.  
  23. #: printer4lazstrconst.p4lrscancel
  24. msgid "Cancel"
  25. msgstr "Cancelar"
  26.  
  27. #: printer4lazstrconst.p4lrsend
  28. msgid "End"
  29. msgstr "Fin"
  30.  
  31. #: printer4lazstrconst.p4lrsgeneral
  32. msgid "General"
  33. msgstr "General"
  34.  
  35. #: printer4lazstrconst.p4lrslandscape
  36. msgid "Landscape"
  37. msgstr "Horizontal"
  38.  
  39. #: printer4lazstrconst.p4lrsmargins
  40. msgid "Margins"
  41. msgstr "Márgenes"
  42.  
  43. #: printer4lazstrconst.p4lrsok
  44. msgid "Ok"
  45. msgstr "OK"
  46.  
  47. #: printer4lazstrconst.p4lrsorientation
  48. msgid "Orientation"
  49. msgstr "Orientación"
  50.  
  51. #: printer4lazstrconst.p4lrspagespersheet
  52. msgid "Pages per sheet"
  53. msgstr "Páginas por hoja"
  54.  
  55. #: printer4lazstrconst.p4lrspapersize
  56. msgid "Paper size"
  57. msgstr "Tamaño del papel"
  58.  
  59. #: printer4lazstrconst.p4lrspapersource
  60. msgid "Paper source"
  61. msgstr "Fuente del papel"
  62.  
  63. #: printer4lazstrconst.p4lrspapertype
  64. msgid "Paper type"
  65. msgstr "Tipo de papel"
  66.  
  67. #: printer4lazstrconst.p4lrsportrait
  68. msgid "Portrait"
  69. msgstr "Vertical"
  70.  
  71. #: printer4lazstrconst.p4lrsprinterproperties
  72. msgid "Printer properties"
  73. msgstr "Propiedades de la impresora"
  74.  
  75. #: printer4lazstrconst.p4lrsresolution
  76. msgid "Resolution"
  77. msgstr "Resolución"
  78.  
  79. #: printer4lazstrconst.p4lrsreverselandscape
  80. msgid "Reverse landscape"
  81. msgstr "Horizontal invertido"
  82.  
  83. #: printer4lazstrconst.p4lrsreverseportrait
  84. msgid "Reverse portrait"
  85. msgstr "Vertical invertido"
  86.  
  87. #: printer4lazstrconst.p4lrsstart
  88. msgid "Start"
  89. msgstr "Comenzar"
  90.  

Ese código corresponde al archivo: printer4lazstrconst.es.po para traducir el diálogo de la ventana de impresión, la segunda ventana precisamente,que puede ir en la carpeta del proyecto junto al resto de las traducciones. Perdón pero no tengo ni idea de como contactar al encargado de esto en Lazarus, hace 2 meses estaba probando el "Hello World"... Los otros dos archivos se encuentran en las carpetas de Lazarus, LCL y LazReport y son lclstrconsts.es.po y lr_const.es.

 

FerCastro, gracias por la recomendación, aparenta ser un muy buen producto según la web, no tengo nada contra el software pago, de hecho cobro por mi software, pero además de no estar en condiciones económicas adecuadas en este momento, recién estoy empezando a entender el mundo de SQL y sus derivados, sus motores, librerías, paquetes, servidores, layers, transactions y cosas que hasta hace poco para mí era chino mandarín. Cuando entienda bien todo esto, seguro lo pruebo si tiene alguna versión Trial y si lo entiendo y me facilita la vida, lo compro.

 

Delphius, estoy leyendo esto http://www.mwasoftware.co.uk/ibxy me interesa, es una especie de FireBird"Lite", es un motor SQL de Borland, un manejador de FireBird o estoy entendiendo mal. La última versión salió hace muy poco para Lazarus 1.6 con FPC 3.0 que es justo lo que tengo. Lo has usado? Si es así, es más simple que PostgreSQL que me da la sensación de que es muy bueno pero complicado.

 

El servidor es un Windows 2008, lo que hay ahí no importa porque sería reemplazado con mi sistema.

 

Saludos y gracias por su tiempo.

 

Vaya, eso del DBGrid que te jode no lo he visto... será que es como dicen en ese hilo que afecta cuando se usa UpdateSQL. Yo no lo uso, yo directamente me encargo de tener mis ZQuery e indicarle la SQL, ya sea un INSERT, UPDATE, DELETE, SELECT.

De todas formas tendré presente tu caso.

 

Eso del pseudo autocommit te entiendo. Tuve la misma impresión... y desconozco si es cosa de jugar con las propiedades y configurarlo bien. Yo de todas formas en base a mis pruebas llegué a la conclusión que es mejor dejarlo a AutoCommit en true y hacer explícitamente el Commit y/o RollBack cuando yo lo necesite (y obviamente iniciar la transacción antes). Ya me he acostumbrado a trabajar así y hasta ahora (cruzo los dedos, y toco madera) no me ha dado sorpresas.

 

Pensé que el componente al que tradujiste su archivo era uno de terceros. Si es parte de Lazarus creo que lo mejor es preguntar en su foro. Ellos seguro se encargarán del tema o te sabrían asesorar mejor. Desconozco como es que trabajan ellos, si es que tienen a alguien propio dedicado a hacer las traducciones, documentaciones, etc. O si cada colaborador debe hacer ese trabajo.

En Firebird al menos tienen un subequipo que se dedica formalmente a traducir los docs. Eso lo se porque en su momento yo ofrecí mi traducción de los documentos que forman la Commands Lines y me pusieron en contacto con el encargado de la traducción al español (que casualmente es/era Argentino, cordobés si no me equivoco). Al final parece que quedó en la nada, era la época en que estaba saliendo 2.1 y mi docs eran para la 1.5.6 y además me pedían que aprendiera a usar un sistema que ellos usan para hacer la doc. Y no le encontraba la vuelta.

 

Respecto a IBX para Lazarus (o IBX4Laz por darle una "abreviatura") es una suite de componentes que trabaja de forma similar a SQLdb y está diseñado para conectarse al motor Firebird. No lo he usado en Lazarus, conozco el uso de IBX (el "original") porque lo usaba en Delphi 6. Ahora bien, desconozco que tan similar sea el fork respecto al original.

Para nuevos proyectos tengo pensado probarlo. No quisiera arriesgarme a hacer un cambio de componentes para mi proyecto actual.

 

En cuanto a motores de base de datos, si me dices que elija uno me voy por Firebird sin dudarlo. Lo he usado en conjunto con D6, y también lo sigo usando ahora para mis proyectos ahora con Lazarus, y más recientemente desde que adquirí Berlin 10.1 Starter edición gratuita también lo usaré (junto a Zeos como suite ya que Starter no viene con componentes de acceso a bases de datos y hay que instalarles los de terceros)

No te digo que elijas a Firebird, pues como he dicho: la elección es un depende. A muchos de nosotros nos encanta Firebird, pero también hay miembros que prefieren PostreSQL, y otros se irán por MySQL o su fork MariaDB.

 

Lo cierto es que lo que debería hacerse es no casarse con un único motor ni lenguaje. Si, la poligamia con las herramientas informáticas es una tendencia y bien vista. ¿Porqué? Porque si nos aferramos a un único lenguaje, motor, e incluso componentes o bibliotecas nos volvemos muy dependientes de ellos y si en el día de mañana por X motivo se discontinúan será tarde y caro hacer el divorcio.

Ahora, del dicho al hecho...  :D Como he dicho: "debería". En la práctica es más complicado. Uno se siente a cómodo y a gusto con X cosa, lo conoce, sabe lo que se puede hacer y mientras sirva seguirá usandolo.

 

Por el motor no deberías preocuparte demasiado, después de todo todos aplican SQL. Si es cierto que cada motor adereza el estandar con sus propias cosas. Eso es cosa de leer la documentación. Yo al menos puedo destacar que el equipo de Firebird se encarga de mantener una muy buena documentación al día (en inglés, obviamente) No te sabría decir de otros proyectos Open Source como PostgreSQL o SQLite (1)

 

(1) No incluyo en la lista a MySQL porque no es realmente Open Source, en realidad su licencia es dual. Aunque también habría que tomar con pinzas el caso de PostgreSQL, hay quienes dicen que en realidad no es tan Open Source (de hecho Firebird le tira sus chascarillo en su frase: The true open source database). Y SQLite si bien es un motor, hay que advertir que es sólo para monousuarios.

 

Sea el motor que elijas, vas a poder trabajar... ya sea de forma cliente como lo es para Firebird, por vía ODBC como lo es en DB2 por ejemplo, etc.

 

Saludos,


  • 2

#9 Delphius

Delphius

    Advanced Member

  • Administrador
  • 5.999 mensajes
  • LocationArgentina

Escrito 24 octubre 2016 - 03:29

Estimado Delphius,

 

Desde 2007 que tuve la necesidad de conectarme a MySQL y que conocí MyDAC no he soltado esos productos.

 

- Actualizaciones continuas

- Multiplataforma (Win, Laz y Firemonkey)

- UNIDAC, que te permite con un solo componente conectarte a diferentes bases de datos, la mayoría de ellas de manera nativa, otras por medio de ODBC.

- Soporte casi inmediato.

- Conectividad directa (sin necesidad, por ejemplo si trabajas con SQLIte, que es mi casi, de incluir los DLL's.

- Para Oracle no creo en verdad que exista algo que los supere. Algo hicieron estos rusos para volar en Oracle (en este momento mientras escribo estoy depurando código con ODAC, la versión de Devart para oracle, y creeme, es un sukhoi de 5ta generación.

 

 

Tengo un proyecto que se conecta a SQLite, FireBird y MySQL y utilizando el Unidac declaro mis conectores y es increíble la rapidez, estabilidad y sencillez para conectarse.

 

Supongo que existen otras que pudieran ser mejores, pero la verdad es que no las conozco y ya no ando buscando, estoy casado con ellas y hasta ahora ha sido un matrimonio de luna de miel.

 

- No me pagan por el comercial   :)

 

Saludos!!

 

¡Que buen comercial les saliste! :D

¡Y que vivan los novios por siempre! :D

 

Quizá cuando tenga un proyecto bien grande, y la solvencia económica me anime a usarla.

 

Saludos,


  • 0

#10 Agustin Ortu

Agustin Ortu

    Advanced Member

  • Moderadores
  • PipPipPip
  • 802 mensajes
  • LocationArgentina

Escrito 24 octubre 2016 - 09:00

Lo cierto es que lo que debería hacerse es no casarse con un único motor ni lenguaje. Si, la poligamia con las herramientas informáticas es una tendencia y bien vista. ¿Porqué? Porque si nos aferramos a un único lenguaje, motor, e incluso componentes o bibliotecas nos volvemos muy dependientes de ellos y si en el día de mañana por X motivo se discontinúan será tarde y caro hacer el divorcio.

Ahora, del dicho al hecho...   :D Como he dicho: "debería". En la práctica es más complicado. Uno se siente a cómodo y a gusto con X cosa, lo conoce, sabe lo que se puede hacer y mientras sirva seguirá usandolo.

 

Por el motor no deberías preocuparte demasiado, después de todo todos aplican SQL. Si es cierto que cada motor adereza el estandar con sus propias cosas. Eso es cosa de leer la documentación

 

 

 

Muy buen comentario

 

Yo creo que la unica metrica posible entre las distintas suites es basicamente velocidad.

 

Luego la unica caracteristica que considero necesaria es poder ejecutar consultas, y poder ejecutar comandos. El resto se encargan los objetos.

 

Como dice el amigo Delphius, es preferible no depender de los componentes y poner una capa de abstraccion en el medio; de esta manera tu aplicacion se conecta a cualquier combinacion de bd + componentes y no tenes que andarte preocupando demasiado de las "bondades" o "carencias" de cada uno. 

 

Yo sigo pensando que un DataSet es un mediador, o un objeto de transporte, que viaja desde la bd, y llega a la "capa" que hablaba mas arriba, y debe morir ahi; pasando a las otras capas, se debe convertir o adaptar en otra cosa

 

No le veo mucha diferencia a una aplicacion que realiza consultas a servicios web por ejemplo: Se realiza una consulta (TXXXQuery) o se le envian comandos (TXXXCommand) usando una "conexion" (Indy, Synapse) y los resultados vuelven en un "conjunto de datos" (TDataSet) que puede ser json o xml, entre otros

 

Es que lo bueno de diseñar asi es que, no solo logras la abstraccion de la bd + componentes (que es relativamente trivial) sino que tambien terminas creando codigo que puede "hablarse" con webservices, porque realmente no le importa de donde viene la data

 

Pero por otra parte si uno es nuevo y esta emepzando, o necesita un prototipo, o hacer un demo, o esta corto de tiempo, la curva de aprendizaje de la arquitectura RAD con sus controles data aware, es muy amigable, es ridiculo lo rapido que se puede sacar un software y que funcione bien


Editado por Agustin Ortu, 24 octubre 2016 - 09:02 .

  • 1

#11 Gaston

Gaston

    Advanced Member

  • Miembros
  • PipPipPip
  • 72 mensajes

Escrito 25 octubre 2016 - 12:49

Gracias por los consejos, aunque a veces me pierdo y me veo tentado de la simplicidad de SQLite sin servidor, ya que es mono usuario entre comillas, sólo en las milésimas de segundos en las cuales se actualiza, al menos así lo cuentan en su sitio, en el cual utilizan su propio SQLite y dicen tener 400.000 consultas mensuales, obvio, solo consultas. Pero carece de algo tan elemental como usuario y contraseña, así que creo deberé instalar un servidor Linux, ya que no me llevo bien con los servidores de MS, y que Lazarus y sus componentes de alguna forma se encarguen del asunto, ya que el sistema correrá en equipos con Windows 7, así que será una hermosa ensalada porque para completar todo, la programación la hago sobre Linux, veremos hasta donde llega la magia de Lazarus :cheesy:

Delphius, ahí dejé el archivo traducido en el foro como me indicaste, es una muy pequeña contribución, un grano de arena.

 

Saludos.


  • 1

#12 FerCastro

FerCastro

    Advanced Member

  • Miembro Platino
  • PipPipPip
  • 619 mensajes
  • LocationCiudad de México

Escrito 25 octubre 2016 - 09:22

Pero carece de algo tan elemental como usuario y contraseña, 

 

Gastón, SQLite no tiene Usr/psdw, pero con un poco de trabajo puedes gestionar perfectamente tus usuarios con sus contraseñas, y si de seguridad se trata, puedes encriptar la base de datos de tal manera que es muy difícil que alguien la abra.

 

De lo que nativamente carece, hasta donde me quedé, es de Stored procedures (puedes agregar un add on y trabajarlo), pero pues monousuario así que en teoría no manejas concurrencia.

 

Ahora bien, si compartes la carpeta y haces los accesos directos como se hacía con los DBF's puedes manejar perfectamente un sistema en red. Claro, no es un servidor propiamente pero trabaja bien, te lo digo por experiencia. 

 

Saludos!!


  • 1

#13 Gaston

Gaston

    Advanced Member

  • Miembros
  • PipPipPip
  • 72 mensajes

Escrito 25 octubre 2016 - 10:48

Hola FerCastro, estuve leyendo varios debates acerca de SQLite, sus ventajas y desventajas. De momento me sirvió en el prototipo y es bueno saber que, como en tu caso, funciona bien, porque una de mis dudas era como se comportaría SQLite con una DB de más de 5 tablas y 100 registros. Respecto a los Stored Procedures creo te refieres a las Foreign Keys, te cuento que si bien permite definirlas, en la práctica las ignora, al menos a mí el borrado en cascada no me ha funcionado, buscando sobre el tema ya no recuerdo si las ignoraba Zeos o no están soportadas en SQLite. Igual como soy un dinosaurio de Clipper y DBF estoy acostumbrado a hacer "a mano" todo eso.

Intentaré con Firebird o MariaDB, porque la verdad, creo que es lo correcto para este proyecto en particular. Dejaré a SQLite para programas más sencillos. Como bien dijeron en este hilo, "no hay que casarse con nadie".

 

Saludos.


  • 0

#14 Delphius

Delphius

    Advanced Member

  • Administrador
  • 5.999 mensajes
  • LocationArgentina

Escrito 25 octubre 2016 - 11:48

Hola FerCastro, estuve leyendo varios debates acerca de SQLite, sus ventajas y desventajas. De momento me sirvió en el prototipo y es bueno saber que, como en tu caso, funciona bien, porque una de mis dudas era como se comportaría SQLite con una DB de más de 5 tablas y 100 registros. Respecto a los Stored Procedures creo te refieres a las Foreign Keys, te cuento que si bien permite definirlas, en la práctica las ignora, al menos a mí el borrado en cascada no me ha funcionado, buscando sobre el tema ya no recuerdo si las ignoraba Zeos o no están soportadas en SQLite. Igual como soy un dinosaurio de Clipper y DBF estoy acostumbrado a hacer "a mano" todo eso.

Intentaré con Firebird o MariaDB, porque la verdad, creo que es lo correcto para este proyecto en particular. Dejaré a SQLite para programas más sencillos. Como bien dijeron en este hilo, "no hay que casarse con nadie".

 

Saludos.

 

Los procedimientos almacenados son rutinas que se ejecutan en el servidor de base de datos. Los hay del tipo seleccionables, es decir que pueden ser usados para devolver un conjunto de datos como si se tratase de una consulta o una vista.

Los SP son muy útiles para efectuar grandes operaciones sobre registros de una o más tablas. Por ejemplo podría usarse para obtener las cuentas T en un sistema contable; actualizar el inventario, seleccionar un conjunto de datos, procesarlo (hacer algo con ellos) y mostrar los resultados, con lo cual sería un caso de un SP seleccionable.

Muchas de las operaciones a nivel negocio podrían definirse en el motor como SP en lugar de implementarlo en el sistema.

Un ejemplo de uso puede ser para marcar un registro activo y los demás inactivos en una tabla llamada configuración. El SP ejecutará un UPDATE en la tabla y cambiará a true el registro en cuestión y luego repetirá el proceso para los distintos pero esta vez marcándolos con falso.

La imaginación es el límite.

 

Ojo: no confundas los SP con los triggers o disparadores. Los disparadores también son rutinas, pero éstos se efectúan (o disparan... de allí su nombre) cuando se hace un after/before ABM sobre alguna tabla.

A un SP uno debe invocarlo ya sea por sistema, algo como SELECT SP(parametros); o si no es seleccionable ejecutarlo con un componente TStoredProc. En fin: que uno debe indicar cuando va a ejecutarse un SP.

 

SQLite carece de SP, y no recuerdo si también de los triggers.

 

Saludos,


  • 1

#15 Gaston

Gaston

    Advanced Member

  • Miembros
  • PipPipPip
  • 72 mensajes

Escrito 26 octubre 2016 - 11:54

Gracias Delphius, me clarificaste muchísimo un tema que hubiera estado días tratando de entender. Debo aprender más de SQL que parece facilitar mucho las cosas.

 

Saludos.


  • 0

#16 FerCastro

FerCastro

    Advanced Member

  • Miembro Platino
  • PipPipPip
  • 619 mensajes
  • LocationCiudad de México

Escrito 15 noviembre 2016 - 01:29

Hola FerCastro, estuve leyendo varios debates acerca de SQLite, sus ventajas y desventajas. De momento me sirvió en el prototipo y es bueno saber que, como en tu caso, funciona bien, porque una de mis dudas era como se comportaría SQLite con una DB de más de 5 tablas y 100 registros. Respecto a los Stored Procedures creo te refieres a las Foreign Keys, te cuento que si bien permite definirlas, en la práctica las ignora, al menos a mí el borrado en cascada no me ha funcionado, buscando sobre el tema ya no recuerdo si las ignoraba Zeos o no están soportadas en SQLite. Igual como soy un dinosaurio de Clipper y DBF estoy acostumbrado a hacer "a mano" todo eso.

Intentaré con Firebird o MariaDB, porque la verdad, creo que es lo correcto para este proyecto en particular. Dejaré a SQLite para programas más sencillos. Como bien dijeron en este hilo, "no hay que casarse con nadie".

 

Saludos.

 

 

Gastón,

 

perdón por la tardanza, he andado un poco ocupado en esto de la búsqueda de la super luna  (y)

 

SQLite no soporta stored procedures, y los índices externos funcionan muy bien. Ahora, no es transaccional desde que es una base de datos local y monousuario. Su comportamiento es realmente estable, tengo una aplicación pequeña, 18 tablas y la más grande anda soportando más menos 30k registros y es una bala al momento de hacer selecciones.

 

Ahora, no podrás comparar SQLite con un servidor de base de datos como MySQL, es como comparar un buen carro con un super deportivo. Has probado PostgreSQL? Tiene un buen que no la utilizo, pero a mi parecer, y sin haber probado todas, creo que después de Oracle es la más potente entre las uso libre.

 

Saludos!!


  • 2

#17 Agustin Ortu

Agustin Ortu

    Advanced Member

  • Moderadores
  • PipPipPip
  • 802 mensajes
  • LocationArgentina

Escrito 15 noviembre 2016 - 02:52

Ojo que SQLite, en cuanto a velocidad estoy seguro de que le pasa el trapo a muchos "grandes". Obviamente tiene sus limitaciones como ya se menciono la concurrencia, no soporta SP, etc.

 

Mientras hablemos de magnitudes menores a los millones, cualquier base de datos, cualquier motor, y de hecho si la base de datos esta diseñada "como el traste", o las consultas no estan optimizadas, la respuesta va a ser siempre RAPIDA

 

Que te ande lento algo como eso es como decir "se te escapo la tortuga", osea es mas dificil hacerlo andar lento que rapido

 

Ahora bien, si el procesamiento lo haces iterando sobre un TDataSet es otro cantar; y de hecho, una vez que el DataSet llego a tu aplicacion, el cuello de botella ya deja de ser la BD y pasa al programa; no va a ser mas rapido iterar un DataSet que vino de MySQL que iterar uno de SQLite (o si lo es, es despreciable)

 

Si queres velocidad, lo mejor es NO iterar un DataSet en la aplicacion; si tu iteracion es para decir "si se cumple tal cosa, entonces hago esto" es preferible filtrar con un select from where; si tenes que sumar, contar, totalizar, etc es mucho mas rapido devolver con un stored o usando funciones de agregacion del sql (count, sum, max, etc)

 

Con 100 registros no estas probando nada; 100 registros no existe. De hecho los 30 mil que menciona FerCastro tampoco existen: son cantidades insignificantes. Desde el "jugetito" de SQLite hasta el "mostro" de Oracle, estan todos diseñados para trabajar con miles de millones de registros


Editado por Agustin Ortu, 15 noviembre 2016 - 02:55 .

  • 2

#18 FerCastro

FerCastro

    Advanced Member

  • Miembro Platino
  • PipPipPip
  • 619 mensajes
  • LocationCiudad de México

Escrito 15 noviembre 2016 - 03:34

 

Con 100 registros no estas probando nada; 100 registros no existe. De hecho los 30 mil que menciona FerCastro tampoco existen: son cantidades insignificantes. Desde el "jugetito" de SQLite hasta el "mostro" de Oracle, estan todos diseñados para trabajar con miles de millones de registros

 

De hecho la única manera probada de hacer que un servidor de base de datos vaya lento es omitir índices, hacer joins por campos no indexados, hacer querys no optimizados. TODOS están programados para hacer eso, selecciones precisas.


  • 1

#19 Gaston

Gaston

    Advanced Member

  • Miembros
  • PipPipPip
  • 72 mensajes

Escrito 15 noviembre 2016 - 04:18

Hola Fer, Agustín, exacto, de hecho hoy a la madrugada posteé esto porque estaba demorando 1 segundo cada 10 registros, la iteración sobre el DS y actualización vía el mismo me estaba matando, así que como bien siempre me recomendaron acá, le tiré todo lo posible SQLite y problema resuelto. Pensé en los índices, los creé y la lentitud era la misma. Lo importante es resolver y aprender nuevas técnicas.

 

PostgreSQL, tiene buena pinta, pero para ser sinceros, he hecho decenas de búsquedas y todos (Firebird, MariaDB, etc...) tienen sus defensores y casi no encontré artículos imparciales. Pienso que mientras acepte SP y se lleve bien con Zeos, cualquiera puede andar bien. Veré como va MariaDB, lo instalé sin problemas, hice algunas pruebas con dbeaver y va bien, todo localhost, cuando lo instale en el servidor veremos que pasa.

 

No recuerdo si fuiste vos Agustín, pero alguien acá me dijo que la clave está en los DataSet y lo tengo muy presente.

 

Algo que me llama la atención es que los programas con SQLite que desarrollo en Linux, funcionan más rápido en Windows, lo comento porque veo que en este foro no hay esas guerras ridículas de  Windows vs. Linux y se puede hablar objetivamente. También noto buena onda entre desarrolladores Delphi y Lazarus, una grata sorpresa.

 

Saludos.


  • 0

#20 Agustin Ortu

Agustin Ortu

    Advanced Member

  • Moderadores
  • PipPipPip
  • 802 mensajes
  • LocationArgentina

Escrito 15 noviembre 2016 - 07:59

El problema que tenías en ese código era que estabas recorriendo un DataSet, realizando un cálculo y un post, con una conexión a un grid. Y el solo hecho moverte en un DataSet ya provoca que el grid deba actualizarse (cambio el registro actual) eso implica que tiene que mover la flechita que señala el registro actual, chequear los eventos, disparar los que asignaste, fijarse si en el grid el registro está visible o tiene que hacer scroll, volver a dibujar todo

 

Después el post te genera la misma cadena otra vez

 

Por eso hablaba de desconectar los datos del grid temporalmente

 

Si agarras un DataSet mediano, lo conectas al grid, y haces un simple while not eof next, eso tiene su demora

 

Pero si le agregas un DataSet.DisableControls antes del loop, y cuando lo terminas, pones un DataSet.EnableControls lo hace muchísimo más rápido

 

Lo de que todo gira en torno al DataSet era más bien una referencia a que muchos se complican la vida con los controles data aware porque con un par de clicks mágicamente tenés una aplicación. Y digo se complican porque dicen "tengo un dbgrid y necesito que el grid muestre solamente los registros que..", y no, olvídate del grid, hay que ir más abstracto posible, en ese caso el DataSet: filtra el DataSet o cambia el query que el grid va a reflejar los cambios


  • 1