Me gustaria saber porque no usan firebird?
1,748 views
Skip to first unread message
MiguelAngel
Oct 12, 2010, 9:32:23 AM10/12/10
to Mundo Visual FoxPro
Segun tengo entendido firebird es una de las mejores opcion a una base
de datos relacional libre, y con un buen soporte ademas
multiplataforma, con backup programable y algo que es lo que mas me
llama la atencion es su base de datos embedida que puede ser utilizada
sin intalacion. Muchos sistema realizado en esta plataforma con
lenguages como Delphi, PHP, mono etc.
Me interesaria saber su opinion.
de datos relacional libre, y con un buen soporte ademas
multiplataforma, con backup programable y algo que es lo que mas me
llama la atencion es su base de datos embedida que puede ser utilizada
sin intalacion. Muchos sistema realizado en esta plataforma con
lenguages como Delphi, PHP, mono etc.
Me interesaria saber su opinion.
MiguelAngel
Oct 12, 2010, 10:54:47 AM10/12/10
to Mundo Visual FoxPro
Al ver que no se animaban a contestarme busque en google y encontre
esto, por favor den su opinion que me interesa al saber de personas
que estan en este grupo y son muy conocedores.
Leen por favor este articulo que encontre:
¿Por qué usar Firebird SQL?
Miércoles, 29 de abril de 2009 Dejar un comentario Ir a comentarios
¿Porqué tan pocos desarrolladores están usando Firebird SQL? Ha sido
la pregunta formulada por Henrique Lobo en su blog iTexto concluyendo
que pensar que no hay muchos desarrolladores es estar en un gran
error, pues hay más desarrolladores que utilizan Firebird de los que
se cree y este número está creciendo rápidamente; los desarrolladores
se están dando cuenta de las ventajas que éste motor tiene frente a
otras bases de datos como MySQL: el principal “competidor”.
A primera vista, pareciera que quienes usan Firebird son los
desarrolldores en Delphi. Aunque el número de desarrolladores usando
este motor va en aumento sigue siendo reducido, ¿por qué no es tan
popular como MySQL o PostgreSQL? Tal vez como se indica en el sitio de
Firebird SQL:
Como probablemente algunos hayan notado, Firebird es más maduro,
tienen más características, no vale ni un centavo y es seguro que está
más preparada para ambientes empresariales. Entonces, ¿por qué no hay
muchas personas que hayan escuchado de este motor?
Las razones son simples:
1. Firebird no tiene una única entidad comercial que gestione el
desarrollo y gane dinero por ello. Hay compañías, pero ninguna de
ellas obtienen ganancias por vender licencias de Firebird (Firebird es
totalmente gratis). Esas empresas venden soporte pero el retorno
económico es mucho menor.
Por lo tanto, no hay nadie que invierta su dinero en mercadeo y
haga un despliegue alrededor de este proyecto. Problemas similar es
plagan a otros proyectos de código abierto como PostgreSQL, por
ejemplo.
2. Cuando fue el boom de los servidores web y las aplicaciones
web, Firebird no estaba listo para ser una base de datos para web.
Como la demanda por almacenamiento de datos creció, la gente estuvo
demandando algo más fácil y rápido que archivos planos del tipo Perl.
MySQL, simplemente estuvo en el lugar correcto en el momento correcto.
Al poco tiempo, cada ISP (Proveedor de internet) tenía soporte para
PHP y MySQL y la plataforma LAMP fue aceptada. Como suele suceder,
esos primeros en un mercado nuevo, rápidamente fueron aceptados, y es
bastante difícil para otros dejar que esa “tajada” de mercado se vaya.
Tal vez sea una situación injusta, pero muchos desarrolladores han
empezado a reconsiderarla. Pero acaso ¿qué características tiene este
motor que merezca la atención de los desarrolladores? Bueno, helas a
continuación:
* Realmente gratuito: contrario a MySQL, Firebird i puede ser
usado en aplicativos comerciales sin ningún tipo de “honorarios” o
problemas legales. (Cabe mencionar que PostgreSQL tiene esa ventaja
también)
* Todas las características básicas de los grandes RDBMS:
Procedimientos almacenados, disparadores o triggers, A.C.I.D., copias
de seguridad en caliente, generadores, integridad referencial, y un
gran etc.
* Bajo consumo de recursos: ¿Alguna vez ha visto una base de datos
embebida? Simplemente sorprendente: en menos de 1 MB se podrá disponer
de todas las características de la base de datos sin “cortarle” nada!
* Bajos requerimientos de hardware: básicamente, si algo realiza
operaciones informáticas, de seguro podrá correr Firebird.
* Disponible en todas las grandes plataformas: Linux, Windows, Mac
OS, Solaris y otras.
* Rendimiento razonable: El rendimiento de Firebird está al igual
del prestado por MySQL y PostgreSQL.
* Proyecto bastante activo: a pesar de su baja popularidad, s un
proyecto bastante activo. Por ejemplo, en abril de 2009, se anunció la
beta de la versión 2.5 del proyecto.
* Bases de datos de tamaño ilimitado: El límite del tamaño de la
base de datos está determinado por el sistema de archivos en el cual
se almacena la base de datos. Pero, por si acaso, la base de datos
excede el límite, siempre es posible dividirla en múltiples archivos.
(La base de datos más grande conocida ocupa más de 980 GB)
* Compatibilidad 100% con el estándar SQL 92
* Conectividad: puede acceder a Firebird SQL a través de cualquier
lenguaje de programación.
Y si hablamos de herramientas para administrar Firebird existen
varias. Tanto así que también existe un programa que sirve para
convertir de MS Access a Firebird.
Aunque es una base de datos para “enamorarse” y usar a diario, a veces
es difícil que un cliente le dé tanta aceptación frente a MySQL o
PostgreSQL. Otras razones que se podrían contemplar por lo que
Firebird es tan impopular son:
* Por ahora, ninguna gran empresa presta soporte como Sun/Oracle o
IBM.
* El sitio oficial (http://www.firebirdsql.org) no luce atractivo
gráficamente, así que la primera impresión no suele ser la mejor.
Cualquiera pensaría que está abandonado. El patrocinador más grande
hoy en hoy en día es IBPhoenix , y su principal negocio es Firebird.
Pero incluso su propio sitio web (el de IBPhoenix) cae en el mismo
problema de diseño gráfico.
* El hecho de que siempre se ha asociado con Delphi desde un
principio ha producido que con la decadencia de Delphi, la popularidad
de Firebird también lucha por mantenerse a flote.
* Documentación escasa. Es difícil encontrar documentación y en
castellano aún más.
Sea como sea, es un proyecto que promete bastante y que considero que
esa racha de “injusticia” pasará y logrará posicionarse y darse a
conocer. Pruébelo usted mismo y muy probablemente diga como yo: “Por
qué no lo conocí antes”.
esto, por favor den su opinion que me interesa al saber de personas
que estan en este grupo y son muy conocedores.
Leen por favor este articulo que encontre:
¿Por qué usar Firebird SQL?
Miércoles, 29 de abril de 2009 Dejar un comentario Ir a comentarios
¿Porqué tan pocos desarrolladores están usando Firebird SQL? Ha sido
la pregunta formulada por Henrique Lobo en su blog iTexto concluyendo
que pensar que no hay muchos desarrolladores es estar en un gran
error, pues hay más desarrolladores que utilizan Firebird de los que
se cree y este número está creciendo rápidamente; los desarrolladores
se están dando cuenta de las ventajas que éste motor tiene frente a
otras bases de datos como MySQL: el principal “competidor”.
A primera vista, pareciera que quienes usan Firebird son los
desarrolldores en Delphi. Aunque el número de desarrolladores usando
este motor va en aumento sigue siendo reducido, ¿por qué no es tan
popular como MySQL o PostgreSQL? Tal vez como se indica en el sitio de
Firebird SQL:
Como probablemente algunos hayan notado, Firebird es más maduro,
tienen más características, no vale ni un centavo y es seguro que está
más preparada para ambientes empresariales. Entonces, ¿por qué no hay
muchas personas que hayan escuchado de este motor?
Las razones son simples:
1. Firebird no tiene una única entidad comercial que gestione el
desarrollo y gane dinero por ello. Hay compañías, pero ninguna de
ellas obtienen ganancias por vender licencias de Firebird (Firebird es
totalmente gratis). Esas empresas venden soporte pero el retorno
económico es mucho menor.
Por lo tanto, no hay nadie que invierta su dinero en mercadeo y
haga un despliegue alrededor de este proyecto. Problemas similar es
plagan a otros proyectos de código abierto como PostgreSQL, por
ejemplo.
2. Cuando fue el boom de los servidores web y las aplicaciones
web, Firebird no estaba listo para ser una base de datos para web.
Como la demanda por almacenamiento de datos creció, la gente estuvo
demandando algo más fácil y rápido que archivos planos del tipo Perl.
MySQL, simplemente estuvo en el lugar correcto en el momento correcto.
Al poco tiempo, cada ISP (Proveedor de internet) tenía soporte para
PHP y MySQL y la plataforma LAMP fue aceptada. Como suele suceder,
esos primeros en un mercado nuevo, rápidamente fueron aceptados, y es
bastante difícil para otros dejar que esa “tajada” de mercado se vaya.
Tal vez sea una situación injusta, pero muchos desarrolladores han
empezado a reconsiderarla. Pero acaso ¿qué características tiene este
motor que merezca la atención de los desarrolladores? Bueno, helas a
continuación:
* Realmente gratuito: contrario a MySQL, Firebird i puede ser
usado en aplicativos comerciales sin ningún tipo de “honorarios” o
problemas legales. (Cabe mencionar que PostgreSQL tiene esa ventaja
también)
* Todas las características básicas de los grandes RDBMS:
Procedimientos almacenados, disparadores o triggers, A.C.I.D., copias
de seguridad en caliente, generadores, integridad referencial, y un
gran etc.
* Bajo consumo de recursos: ¿Alguna vez ha visto una base de datos
embebida? Simplemente sorprendente: en menos de 1 MB se podrá disponer
de todas las características de la base de datos sin “cortarle” nada!
* Bajos requerimientos de hardware: básicamente, si algo realiza
operaciones informáticas, de seguro podrá correr Firebird.
* Disponible en todas las grandes plataformas: Linux, Windows, Mac
OS, Solaris y otras.
* Rendimiento razonable: El rendimiento de Firebird está al igual
del prestado por MySQL y PostgreSQL.
* Proyecto bastante activo: a pesar de su baja popularidad, s un
proyecto bastante activo. Por ejemplo, en abril de 2009, se anunció la
beta de la versión 2.5 del proyecto.
* Bases de datos de tamaño ilimitado: El límite del tamaño de la
base de datos está determinado por el sistema de archivos en el cual
se almacena la base de datos. Pero, por si acaso, la base de datos
excede el límite, siempre es posible dividirla en múltiples archivos.
(La base de datos más grande conocida ocupa más de 980 GB)
* Compatibilidad 100% con el estándar SQL 92
* Conectividad: puede acceder a Firebird SQL a través de cualquier
lenguaje de programación.
Y si hablamos de herramientas para administrar Firebird existen
varias. Tanto así que también existe un programa que sirve para
convertir de MS Access a Firebird.
Aunque es una base de datos para “enamorarse” y usar a diario, a veces
es difícil que un cliente le dé tanta aceptación frente a MySQL o
PostgreSQL. Otras razones que se podrían contemplar por lo que
Firebird es tan impopular son:
* Por ahora, ninguna gran empresa presta soporte como Sun/Oracle o
IBM.
* El sitio oficial (http://www.firebirdsql.org) no luce atractivo
gráficamente, así que la primera impresión no suele ser la mejor.
Cualquiera pensaría que está abandonado. El patrocinador más grande
hoy en hoy en día es IBPhoenix , y su principal negocio es Firebird.
Pero incluso su propio sitio web (el de IBPhoenix) cae en el mismo
problema de diseño gráfico.
* El hecho de que siempre se ha asociado con Delphi desde un
principio ha producido que con la decadencia de Delphi, la popularidad
de Firebird también lucha por mantenerse a flote.
* Documentación escasa. Es difícil encontrar documentación y en
castellano aún más.
Sea como sea, es un proyecto que promete bastante y que considero que
esa racha de “injusticia” pasará y logrará posicionarse y darse a
conocer. Pruébelo usted mismo y muy probablemente diga como yo: “Por
qué no lo conocí antes”.
MiguelAngel
Oct 12, 2010, 10:57:13 AM10/12/10
to Mundo Visual FoxPro
Carlos Miguel FARIAS
Oct 12, 2010, 4:48:06 PM10/12/10
to mundovis...@googlegroups.com
El tema es que si a nivel de proveedores de internet no tiene suficiente difusión, en mi caso, que necesito mantener aplicaciones de escritorio y web, donde comparten datos via web, me veo obligado a trabajar con mysql, aunque posiblemente postgressql sea una mejor opción (herencia, campos array, por mencionar algunas).
En realidad, para aplicaciones de escritorio con no muchos usuarios, hasta las tablas nativas de fox pueden funcionar bien, aplicando la ley de Murphy, o sea, que si tienes previstos backups diarios, sistemas de control de cierre adecuado del sistema cada vez que abris una tabla y demas, tus tablas no se dañaran, en cuanto menguas algunas de esas cosas, seguro empiezan las fallas.
O sea que si Oracle no pisa a mySQL (por no continuar el desarrollo, o cambiar su licencia a honerosa), veo dificil que la gente se vuelque masivamente a firebird, mas allá de las virtudes que se indica que tiene.
Siempre que se migra de un SGBD a otro, hay problemas en la conversión (algo que no esta muy estandarizado por ejemplo es el manejo de fechas).
Saludos: Miguel
En realidad, para aplicaciones de escritorio con no muchos usuarios, hasta las tablas nativas de fox pueden funcionar bien, aplicando la ley de Murphy, o sea, que si tienes previstos backups diarios, sistemas de control de cierre adecuado del sistema cada vez que abris una tabla y demas, tus tablas no se dañaran, en cuanto menguas algunas de esas cosas, seguro empiezan las fallas.
O sea que si Oracle no pisa a mySQL (por no continuar el desarrollo, o cambiar su licencia a honerosa), veo dificil que la gente se vuelque masivamente a firebird, mas allá de las virtudes que se indica que tiene.
Siempre que se migra de un SGBD a otro, hay problemas en la conversión (algo que no esta muy estandarizado por ejemplo es el manejo de fechas).
Saludos: Miguel
--
_______________________________________________________________
Has recibido este mensaje porque estás suscrito al Grupo "Mundo Visual
FoxPro" de Grupos de Google.
Para anular la suscripción a este grupo, envía un mensaje a:
mundovisualfox...@googlegroups.com
tangocaracasivan
Oct 12, 2010, 10:04:11 PM10/12/10
to mundovis...@googlegroups.com
>>> * El sitio oficial (http://www.firebirdsql.org) no luce
>>>atractivo gráficamente, así que la primera impresión no
>>>suele ser la mejor.
>>>atractivo gráficamente, así que la primera impresión no
>>>suele ser la mejor.
No me parecio tan malo el sitio, ni abandonado.
El resto lo vere despues
Ivan Martinez von Halle
>>>-----Mensaje original-----
>>>De: mundovis...@googlegroups.com
>>>[mailto:mundovis...@googlegroups.com] En nombre de MiguelAngel
>>>Enviado el: Martes, 12 de Octubre de 2010 10:25 a.m.
>>>Para: Mundo Visual FoxPro
>>>Asunto: [Mundo Visual FoxPro] Re: Me gustaria saber porque
>>>no usan firebird?
Fcocibaeno
Oct 20, 2010, 9:12:47 AM10/20/10
to Mundo Visual FoxPro
Saludos colegas,
Estoy en proceso de migrar las tablas nativas de mis proyectos en VFP
a un DBMS.
Como muchos, me encuentro en un tremendo dilema, por supuesto que la
primera opcin es MySQL, aunque estoy abierto a cualquier opcion.
He investigado sobre FireBirdSQL, el cual no conocía hasta ayer, y he
visto, que contrario a lo que se comenta, si posee documentacion
en español y bastante, ya me he bajado como 4 manuales.
En el sitio oficial, existe un manual muy bueno en español (aunque
orientado a Delphy), el cual he descargado.
A continuacion el link :
http://infoback.com.ar/buhardilla/firebird/firebird.htm
Ademas de encontrar varios en formato .PDF
Voy a seguir investigando todas las opciones que aparezcan y si alguno
me puede recomendar alguna de la cual les haya dado buen resultado, se
los voy a agradecer
!! Suerte !!
Feliz día
Estoy en proceso de migrar las tablas nativas de mis proyectos en VFP
a un DBMS.
Como muchos, me encuentro en un tremendo dilema, por supuesto que la
primera opcin es MySQL, aunque estoy abierto a cualquier opcion.
He investigado sobre FireBirdSQL, el cual no conocía hasta ayer, y he
visto, que contrario a lo que se comenta, si posee documentacion
en español y bastante, ya me he bajado como 4 manuales.
En el sitio oficial, existe un manual muy bueno en español (aunque
orientado a Delphy), el cual he descargado.
A continuacion el link :
http://infoback.com.ar/buhardilla/firebird/firebird.htm
Ademas de encontrar varios en formato .PDF
Voy a seguir investigando todas las opciones que aparezcan y si alguno
me puede recomendar alguna de la cual les haya dado buen resultado, se
los voy a agradecer
!! Suerte !!
Feliz día
Cristobal
Oct 20, 2010, 9:19:05 AM10/20/10
to mundovis...@googlegroups.com
A mi me ha funcionado muy bien MySQL. Hay bastante ayuda en internet del
tema.
tema.
Te recomiendo dos admnistradores de bases de datos de MySQL:
SQLMaestro
SQLYog
--------------------------------------------------
From: "Fcocibaeno" <fcoci...@gmail.com>
Sent: Wednesday, October 20, 2010 8:12 AM
To: "Mundo Visual FoxPro" <mundovis...@googlegroups.com>
Subject: [Mundo Visual FoxPro] Re: Me gustaria saber porque no usan
firebird?
> Saludos colegas,
> Estoy en proceso de migrar las tablas nativas de mis proyectos en VFP
> a un DBMS.
> Como muchos, me encuentro en un tremendo dilema, por supuesto que la
> primera opcin es MySQL, aunque estoy abierto a cualquier opcion.
> He investigado sobre FireBirdSQL, el cual no conoc�a hasta ayer, y he
> visto, que contrario a lo que se comenta, si posee documentacion
> en espa�ol y bastante, ya me he bajado como 4 manuales.
> En el sitio oficial, existe un manual muy bueno en espa�ol (aunque
> orientado a Delphy), el cual he descargado.
> A continuacion el link :
> http://infoback.com.ar/buhardilla/firebird/firebird.htm
> Ademas de encontrar varios en formato .PDF
> Voy a seguir investigando todas las opciones que aparezcan y si alguno
> me puede recomendar alguna de la cual les haya dado buen resultado, se
> los voy a agradecer
>
> !! Suerte !!
> Feliz d�a
>
> --
> _______________________________________________________________
> Has recibido este mensaje porque est�s suscrito al Grupo "Mundo Visual
> FoxPro" de Grupos de Google.
>
> Para anular la suscripci�n a este grupo, env�a un mensaje a:
> mundovisualfox...@googlegroups.com
>
Miguel Antúnez
Oct 20, 2010, 9:20:33 AM10/20/10
to mundovis...@googlegroups.com
el "SQL EXPRESS 2008 WITH ADVANCED SERVICE". muy completo y gratuito. con posibilidades de crecer a un SQL STANDAR O ENTERPISE SIN MOVER
--
Miguel Angel Antúnez Camones
Especialista en SQL Server
mant...@frenosa.com.pe
mant...@gmail.com
miguel_...@msn.com
Cel. 997914428
Microsoft Active Professional
Membresía FY10-04-0745
--
_______________________________________________________________
Has recibido este mensaje porque estás suscrito al Grupo "Mundo Visual
FoxPro" de Grupos de Google.
Para anular la suscripción a este grupo, envía un mensaje a:
mundovisualfox...@googlegroups.com
--
Miguel Angel Antúnez Camones
Especialista en SQL Server
mant...@frenosa.com.pe
mant...@gmail.com
miguel_...@msn.com
Cel. 997914428
Microsoft Active Professional
Membresía FY10-04-0745
Miguel Antúnez
Oct 20, 2010, 9:21:03 AM10/20/10
to mundovis...@googlegroups.com
El 20 de octubre de 2010 08:20, Miguel Antúnez <mant...@gmail.com> escribió:
el "SQL EXPRESS 2008 WITH ADVANCED SERVICE". muy completo y gratuito. con posibilidades de crecer a un SQL STANDAR O ENTERPISE
sin mover una sola linea de codigo.
saludos.
Carlos Mazariegos
Oct 21, 2010, 1:52:06 PM10/21/10
to mundovis...@googlegroups.com
Hola:
Buenos dias.
Firebird es una muy buena opción. Yo lo he utilizado por mas de 4 años con VFP y hasta el momento no me ha presentado problemas. Actualmente manejo 400 usuarios concurrentes y como 40,000 no concurrentes. Eso si, te funciona mejor con Linux (el servidor de las DB) y los clientes no hay problema con Windows.
Además, tenemos aproximadamente el 30% de la programación en procedimientos y triggers, lo que nos facilitará en futuro la migración de la programación a otro lenguaje.
Esperando que te sirva de algo.
--
_______________________________________________________________
Has recibido este mensaje porque estás suscrito al Grupo "Mundo Visual
FoxPro" de Grupos de Google.
Para anular la suscripción a este grupo, envía un mensaje a:
mundovisualfox...@googlegroups.com
IRCSA Software
Oct 21, 2010, 10:08:38 PM10/21/10
to Mundo Visual FoxPro
Orale Carlos,
4 años y con ese volumen de información debes de tener una buena
experiencia acumulada...
...si tienes manuales, documentos, libros, lincks de interés, etc,
etc, y los puedes mandar te lo agradecería mucho.
Llevo algo de avance pero entre mas documentado mejor.
Saludos desde Cancún México
Arturo Ramos
www.ircsasfotware.com.mx
On 21 oct, 12:52, Carlos Mazariegos <carlosemazarieg...@gmail.com>
wrote:
>
> --
> Carlos Mazariegos
> carlosemazarieg...@gmail.com
> Cesma
> Guatemala, CA
4 años y con ese volumen de información debes de tener una buena
experiencia acumulada...
...si tienes manuales, documentos, libros, lincks de interés, etc,
etc, y los puedes mandar te lo agradecería mucho.
Llevo algo de avance pero entre mas documentado mejor.
Saludos desde Cancún México
Arturo Ramos
www.ircsasfotware.com.mx
On 21 oct, 12:52, Carlos Mazariegos <carlosemazarieg...@gmail.com>
wrote:
> Hola:
>
> Buenos dias.
>
> Firebird es una muy buena opción. Yo lo he utilizado por mas de 4 años con
> VFP y hasta el momento no me ha presentado problemas. Actualmente manejo
> 400 usuarios concurrentes y como 40,000 no concurrentes. Eso si, te
> funciona mejor con Linux (el servidor de las DB) y los clientes no hay
> problema con Windows.
>
> Además, tenemos aproximadamente el 30% de la programación en procedimientos
> y triggers, lo que nos facilitará en futuro la migración de la programación
> a otro lenguaje.
>
> Esperando que te sirva de algo.
>
>
> Buenos dias.
>
> Firebird es una muy buena opción. Yo lo he utilizado por mas de 4 años con
> VFP y hasta el momento no me ha presentado problemas. Actualmente manejo
> 400 usuarios concurrentes y como 40,000 no concurrentes. Eso si, te
> funciona mejor con Linux (el servidor de las DB) y los clientes no hay
> problema con Windows.
>
> Además, tenemos aproximadamente el 30% de la programación en procedimientos
> y triggers, lo que nos facilitará en futuro la migración de la programación
> a otro lenguaje.
>
> Esperando que te sirva de algo.
>
> El 20 de octubre de 2010 07:12, Fcocibaeno <fcociba...@gmail.com> escribió:
>
>
>
> > Saludos colegas,
> > Estoy en proceso de migrar las tablas nativas de mis proyectos en VFP
> > a un DBMS.
> > Como muchos, me encuentro en un tremendo dilema, por supuesto que la
> > primera opcin es MySQL, aunque estoy abierto a cualquier opcion.
> > He investigado sobre FireBirdSQL, el cual no conocía hasta ayer, y he
> > visto, que contrario a lo que se comenta, si posee documentacion
> > en español y bastante, ya me he bajado como 4 manuales.
> > En el sitio oficial, existe un manual muy bueno en español (aunque
> > orientado a Delphy), el cual he descargado.
> > A continuacion el link :
> > http://infoback.com.ar/buhardilla/firebird/firebird.htm
> > Ademas de encontrar varios en formato .PDF
> > Voy a seguir investigando todas las opciones que aparezcan y si alguno
> > me puede recomendar alguna de la cual les haya dado buen resultado, se
> > los voy a agradecer
>
> > !! Suerte !!
> > Feliz día
>
> > --
> > _______________________________________________________________
> > Has recibido este mensaje porque estás suscrito al Grupo "Mundo Visual
> > FoxPro" de Grupos de Google.
>
> > Para anular la suscripción a este grupo, envía un mensaje a:
> > mundovisualfox...@googlegroups.com<mundovisualfoxpro%2Bunsu...@googlegroups.com>
>
>
>
> > Saludos colegas,
> > Estoy en proceso de migrar las tablas nativas de mis proyectos en VFP
> > a un DBMS.
> > Como muchos, me encuentro en un tremendo dilema, por supuesto que la
> > primera opcin es MySQL, aunque estoy abierto a cualquier opcion.
> > He investigado sobre FireBirdSQL, el cual no conocía hasta ayer, y he
> > visto, que contrario a lo que se comenta, si posee documentacion
> > en español y bastante, ya me he bajado como 4 manuales.
> > En el sitio oficial, existe un manual muy bueno en español (aunque
> > orientado a Delphy), el cual he descargado.
> > A continuacion el link :
> > http://infoback.com.ar/buhardilla/firebird/firebird.htm
> > Ademas de encontrar varios en formato .PDF
> > Voy a seguir investigando todas las opciones que aparezcan y si alguno
> > me puede recomendar alguna de la cual les haya dado buen resultado, se
> > los voy a agradecer
>
> > !! Suerte !!
> > Feliz día
>
> > --
> > _______________________________________________________________
> > Has recibido este mensaje porque estás suscrito al Grupo "Mundo Visual
> > FoxPro" de Grupos de Google.
>
> > Para anular la suscripción a este grupo, envía un mensaje a:
>
> --
> Carlos Mazariegos
> carlosemazarieg...@gmail.com
> Cesma
> Guatemala, CA
Carlos Mazariegos
Oct 22, 2010, 11:10:28 AM10/22/10
to mundovis...@googlegroups.com
Bueno, estos links nos han servido de mucho:
Link Oficial: http://www.firebirdsql.org/
Recursos: http://www.ibphoenix.com/
Sitio en español: http://www.firebird.com.mx/
Ademas esta el libro:
The Firebird Book A reference for database developers
Este libro nos ha sido de mucha ayuda. En alguna ocación lo encontre en PDF, no me recuerdo donde lo tengo, pero creo que lo puedes encontrar en internet. Yo tengo el libro en original, por eso perdi el PDF. Este libro esta basado en la versión 1.5, ahora esta la 2.1.? y ya sacaron un complemento, este todavía
no lo he conseguido en PDF.
También en la página de ibphoenix hay muchos manuales de referencia.
Esperando que te sirva esta información
Gerardo
Nov 4, 2010, 6:40:54 AM11/4/10
to Mundo Visual FoxPro
Hola colegas!
yo estoy recién ahora haciendo una pruebas con Firebird para migrar la
DB de Fox8....
mi duda es la siguiente:
Teniendo un sistema multiusuario: ¿Firebird me daría mayor velocidad
de respuestas en las terminales de una red local?
Mi motivación principal por la cuál estoy intentando migrar, es porque
en mi sistema algunas consultas demoran algunos segundos en
desplegarse (no pasa en el servidor), y como la DB de Fox no es
cliente/servidor, imagino que con Firebird voy a optimizar mucho la
respuesta de las consultas. ¿es correcta mi idea?
Gracias por compartir su experiencia
saludos
Gerardo.
yo estoy recién ahora haciendo una pruebas con Firebird para migrar la
DB de Fox8....
mi duda es la siguiente:
Teniendo un sistema multiusuario: ¿Firebird me daría mayor velocidad
de respuestas en las terminales de una red local?
Mi motivación principal por la cuál estoy intentando migrar, es porque
en mi sistema algunas consultas demoran algunos segundos en
desplegarse (no pasa en el servidor), y como la DB de Fox no es
cliente/servidor, imagino que con Firebird voy a optimizar mucho la
respuesta de las consultas. ¿es correcta mi idea?
Gracias por compartir su experiencia
saludos
Gerardo.
Miguel Antúnez
Nov 4, 2010, 9:22:20 AM11/4/10
to mundovis...@googlegroups.com
La velocidad dependerá de que bien estén normalizadas tu DB y optimitizadas tus indices por tabla, y también la creación de tus consultas;
--
el correcto uso de joins, where, no usar select *.
Saludos...
--
_______________________________________________________________
Has recibido este mensaje porque estás suscrito al Grupo "Mundo Visual
FoxPro" de Grupos de Google.
Para anular la suscripción a este grupo, envía un mensaje a:
mundovisualfox...@googlegroups.com
--
Carlos Mazariegos
Nov 4, 2010, 2:01:00 PM11/4/10
to mundovis...@googlegroups.com
Independientemente si se tarda una consulta o no, creo que no es el factor principal para migrar, ya que como lo dice el antecesor, se puede analizar ciertos aspectos.
--
Lo principal es las ventajas que te va dar al migrar:
- Triggers
- Procedimientos almacenados
- UDF's
- Seguridad
- Por tabla
- Por Procedimientos
- Por campos
- Para borrar registros
- Para agregar registros
- Para modificar registros
Tienes que considerar que aunque uses Firebird, tienes que usar con cuidado los select, joins's, procedimientos almacenados, etc. Ya que el uso incorrecto puede afectar el tiempo de respuesta de tu sistema.
Firebird es una buena DB, yo la he utilizado por mas de 4 años en una institución y me ha funcionado bien.
Atentamente
--
_______________________________________________________________
Has recibido este mensaje porque estás suscrito al Grupo "Mundo Visual
FoxPro" de Grupos de Google.
Para anular la suscripción a este grupo, envía un mensaje a:
mundovisualfox...@googlegroups.com
--
Carlos Miguel FARIAS
Nov 4, 2010, 8:52:47 PM11/4/10
to mundovis...@googlegroups.com
De todo lo que mencionas, lo que no tienen en tablas nativas de fox es lo referente a seguridad.
Firebird ademas puede darte mejor escalabilidad cuando tenes muchos usuarios, pero el diseño de la BD es fundamental.
Las reglas de un buen diseño de sistema son basicamente 6
a) Minimizar el Volumen de Datos.
b) Diseñar Teniendo en cuenta Frecuencia y Modo de Uso
c) Considerar si los datos son estáticos o dinámicos
d) Minimizar el tamaño de estructuras de acceso.
e) Minimizar tiempos de acceso
f) Facilidades de programacion.
a) Esto se logra con correcta seleccion de tipos de datos para almacenar los datos y dimensionar correctamente el tamaño de los campos alfanumericos. Y por supuesto Normalizar.
b) Frecuencia hace referencia a cuantas veces se accede (por hora, por dia, por mes) y si el acceso requerido es secuencial o aleatorio. Para procesos secuenciales, puede ser conveniente tener indices que den orden (por ejemplo, leer clientes o productos en orden alfabetico para consultas muy frecuentes (grillas)), pero tener indices permanentes para procesos que se hacen una vez por semana o mas espaciados, es totalmente inoperante, porque por acelerar un proceso de 3 horas a 1 hora, frena todas demas las transacciones, y la suma de tiempos perdidos va a ser mayor.
c) Es muy diferente tratar con datos estaticos (no se modifican, o se modifican esporadicamente) que los que se modifican mucho. En el primer caso, puede hasta ser conveniente de copiar los datos a tablas locales en cada maquina, para que no tener que leerlos a traves de la red, o por ejemplo, fraccionar una tabla grande en forma vertical, por ejemplo la parte descriptiva de articulos (que no se modifica, salva al incorporar nuevos) con la parte de datos volatiles (stock, precio de venta, etc.) la parte menos modificable, tambien puede convenir replicarla en las maquinas locales y los datos dinamicos, mantenerlos en el servidor. Esto ultimo parece un diseño muy redundante, pero es redundancia controlada, que no es malo si se diseña bien y se aprovecha adecuadamente.
d) Los indices deben ser optimizados, para ello hay que tener en cuenta como se almacenan. En fox se usan arboles b+, o sea que el indice se distribuye en una estructura jerarquica donde en cada nodo, ademas de ciertos datos de estructura, se guardan las "entradas" de cada clave en la forma clave+puntero, clave+puntero, ... hasta completar el nodo (registro del indice). Los indices numericos se guardan como campos binarios de 8 bytes, o sea que cada clave de un indice numerico ocupa 8 bytes + 4 bytes del puntero (eso es para todos igual). Entonces si tenemos un indice de 5 digitos (numerico), es mas eficiente guardarlo convertido a caracteres que como numero (en caracteres, cada clave ocupa 5 bytes y el puntero 4, en numero son 8 + 4, o sea 12), como en cada nodo entran tanta claves como "tamaño del nodo / ( clave+puntero)", cuando mas claves entran en un nodo, mas rapido es el indice, porque se transmite y se gestiona por nodos, cuantos mas claves por nodos, menos nodos en el indice, por lo tanto, mas rapido el acceso.
e) Con las capacidades de los equipos actuales, a veces, es conveniente levantar todo un cursor de un solo saque en memoria en un arreglo o cursor local y luego buscar en el y no en las tablas en el servidor. Otra cosa, que a veces no se tiene en cuenta, los datos en fox estan en un archivo (dbf) que es esencialmente un archivo con registros de longitud fija, por lo que el acceso directo por numero de registro (GO RECORD) es muchisimo mas rapido que usando indices.
f) Y al final, buscamos algoritmos que sean faciles, o se codifique poco, para eso esta SQL.
Firebird ademas puede darte mejor escalabilidad cuando tenes muchos usuarios, pero el diseño de la BD es fundamental.
Las reglas de un buen diseño de sistema son basicamente 6
a) Minimizar el Volumen de Datos.
b) Diseñar Teniendo en cuenta Frecuencia y Modo de Uso
c) Considerar si los datos son estáticos o dinámicos
d) Minimizar el tamaño de estructuras de acceso.
e) Minimizar tiempos de acceso
f) Facilidades de programacion.
a) Esto se logra con correcta seleccion de tipos de datos para almacenar los datos y dimensionar correctamente el tamaño de los campos alfanumericos. Y por supuesto Normalizar.
b) Frecuencia hace referencia a cuantas veces se accede (por hora, por dia, por mes) y si el acceso requerido es secuencial o aleatorio. Para procesos secuenciales, puede ser conveniente tener indices que den orden (por ejemplo, leer clientes o productos en orden alfabetico para consultas muy frecuentes (grillas)), pero tener indices permanentes para procesos que se hacen una vez por semana o mas espaciados, es totalmente inoperante, porque por acelerar un proceso de 3 horas a 1 hora, frena todas demas las transacciones, y la suma de tiempos perdidos va a ser mayor.
c) Es muy diferente tratar con datos estaticos (no se modifican, o se modifican esporadicamente) que los que se modifican mucho. En el primer caso, puede hasta ser conveniente de copiar los datos a tablas locales en cada maquina, para que no tener que leerlos a traves de la red, o por ejemplo, fraccionar una tabla grande en forma vertical, por ejemplo la parte descriptiva de articulos (que no se modifica, salva al incorporar nuevos) con la parte de datos volatiles (stock, precio de venta, etc.) la parte menos modificable, tambien puede convenir replicarla en las maquinas locales y los datos dinamicos, mantenerlos en el servidor. Esto ultimo parece un diseño muy redundante, pero es redundancia controlada, que no es malo si se diseña bien y se aprovecha adecuadamente.
d) Los indices deben ser optimizados, para ello hay que tener en cuenta como se almacenan. En fox se usan arboles b+, o sea que el indice se distribuye en una estructura jerarquica donde en cada nodo, ademas de ciertos datos de estructura, se guardan las "entradas" de cada clave en la forma clave+puntero, clave+puntero, ... hasta completar el nodo (registro del indice). Los indices numericos se guardan como campos binarios de 8 bytes, o sea que cada clave de un indice numerico ocupa 8 bytes + 4 bytes del puntero (eso es para todos igual). Entonces si tenemos un indice de 5 digitos (numerico), es mas eficiente guardarlo convertido a caracteres que como numero (en caracteres, cada clave ocupa 5 bytes y el puntero 4, en numero son 8 + 4, o sea 12), como en cada nodo entran tanta claves como "tamaño del nodo / ( clave+puntero)", cuando mas claves entran en un nodo, mas rapido es el indice, porque se transmite y se gestiona por nodos, cuantos mas claves por nodos, menos nodos en el indice, por lo tanto, mas rapido el acceso.
e) Con las capacidades de los equipos actuales, a veces, es conveniente levantar todo un cursor de un solo saque en memoria en un arreglo o cursor local y luego buscar en el y no en las tablas en el servidor. Otra cosa, que a veces no se tiene en cuenta, los datos en fox estan en un archivo (dbf) que es esencialmente un archivo con registros de longitud fija, por lo que el acceso directo por numero de registro (GO RECORD) es muchisimo mas rapido que usando indices.
f) Y al final, buscamos algoritmos que sean faciles, o se codifique poco, para eso esta SQL.
Reply all
Reply to author
Forward
0 new messages