Firebird: otro caso de estudio
 

Technical details

Our largest installation of the Firebird SQL has these attributes:

• Database size: ~70 GB
• Average daily database increase: ~80 MB
• Connection with economic systems (SAP, …)
• Connection with attendance systems
• Terminals connected in manufacture:
  • Number of terminals with text-mode emulation: 32
  • Number of graphical terminals: 8
• Number of terminals in quality control centre: 12
• Number of online connections with database: 43
• Average number of transactions per second: ~3.4
• Average number of transactions per day: ~290 thousand
• Server: MS Windows Server 2008 R2 64 bit
• Database engine: Firebird 2.5.2-64 in SuperClassic mode with UDF usage
• Operating time: 24 x 7

http://www.firebirdsql.org/en/case-studies-catalog/masa---statistical-analysis-and-plan-optimization-solution-for-industrial-plants-53264/

^\||/^\||/^\||/

¡¡¡¿¿¿PERDÓN???!!! ¡Increíble!

mmm como que 80mb es muy poca carga transaccional para ser un caso de estudio interesante. Pero bueno supongo que para una base de datos como firebird lo es.

Pues yo no sé, pero a mi me parece una cantidad importante de transacciones para la base de datos que uds. me digan.
Creo que porque al menos yo no he administrado una BD mas grande (de hecho nada cercano a esta base de datos), se me hacen números impresionantes.
Saludos.

Lo son :)

El problema de mirar numeros sin contexto.... lo es? Si fuera un numero mas grande.. es eso mejor? Si la BD es mas o menos normalizada, como esten los indices, se sube o baja todo eso.

Me fui al link y las razones basicamente son : Usamos Delphi, Conocemos FB, Facil de operar.

Pero como eso conecta con los numeros y el resto de los requerimientos no es claro.

Si yo no supiera nada de FB no veo como me ayuda un "caso de estudio" como este. No hay nada que estudiar!

P.D: Estoy criticando el estilo tipico de estos "casos de estudios", no a FB.

Entiendo que por sí solos 80 MB de datos en un día parezcan mucho pero en realidad no lo son amigo en realidad es una cantidad irrisoria de datos y me explico por qué. Entre lo que lista nos dice que se generan en promedio 80mb de datos lo que nos da un promedio de 0.12 mb por minuto en un periodo transaccional de 12 horas. Nada que cualquier base de datos no soporte, vaya algo así hasta dbase lo soporta.


mmmm, supongo que para los sistemas que manejas lo son pero cuando se mira un poquito más allá te encuentras con que no es así.


Ahora bien, un entorno transaccional como el que pinta el siguiente caso de estudio sí que es sumamente interesante:

Case Study: Oracle E-Business Suite with Data Guard Across a Wide Area Network
“Data Guard 10g is a complete, reliable, DR solution for the mission critical 7TB database that supports Oracle’s global business operations. High transaction rates, 7,000 concurrent users, and 1,000 miles separating the production and disaster recovery site – not a problem for Data Guard.”

http://www.oracle.com/au/products/da...e-1-131821.pdf


Aquí más casos de estudio de Oracle.

http://www.oracle.com/technetwork/da...es-098033.html

¿Cuántos millones dices que cuesta eso?, ¿cuántas personas de oracle dices que te montan eso en tu empresa y te lo mantienen y te cobran?, ¿cuánto hardware necesitas para mover todo y cuánto cuesta?

Compara con: Vas a firebirdsql.org, ... descargas ... instalas ... a trabajar.

Hola poliburro.
Eso es indiscutible desde todo punto de vista .

Pero si queremos hacer una comparación mas ecuánime, también tendríamos que poner en la balanza este factor: Oracle Global List Pricing

Saludos :)

Claro, con dbase o access también se puede hacer eso .Supongo que en los sistemas que administras no se necesita más que eso.

Desde que te has convertido en un trol en clubdelphi, estás insoportable, ni tus amigos te soportan, ¿por qué no haces de trol en tus foros?

¿Saben tus compañeros y amigos que te dedicas a hacer de trol en clubdelphi? ¿Te da vergüenza que conozcan esa faceta tuya?

Como VMP de Embarcadero, ¿saben en Embarcadero que te dedicas a hacer de trol en clubdelphi?

Interbase, como prima-hermana de firebird, y de Embarcadero, si tiras por los suelos a Firebird, estás tirando también a Interbase, ¿saben en Embarcadero, que tú como VMP de Embarcadero, opinas de esa forma de su base de datos?

Si te gusta hacer de trol, hazlo en tus foros, verás cómo se alegran tus amigos de conocer esa faceta tuya tan divertida.

¿Trol? ¿Solo por que digo lo que pienso de firebird con argumentos por supuesto y no con diatribas? No casimiro, no caigo en eso. Jamás a diferencia de ti he dicho algo sobre firebird sin sostenerlo con información que respalda lo que digo, que tú nunca estes de acuerdo no me hace trol ni mucho menos.

Respecto a si lo saben, no lo se, puedes preguntarles. A mi lo que me apasiona es Delphi no firebird ni interbase.


ahh y respecto a que en DA no digo lo que pienso sobre Firebird pues mira:
http://www.delphiaccess.com/forum/no...ares-del-mundo

No, no se puede hacer eso con DBase o Access. Eso es indiscutible desde cualquier punto de vista.

Respeto tu derecho a sentir aversión por Firebird, pero la misma nubla tu criterio. Además de no ser libres, DBase o Access están muy lejos por detrás de Firebird.

Bueno, eso tampoco es totalmente cierto... Comparar Firebird con Access o DBase es una argumentación errónea y una clara diatriba contra Firebird y sus usuarios.

Saludos :)

Sí, trol, eres un trol, en este hilo y en casi todos en los que has participado desde hace tiempo. No te hagas el inocente, que no sabes disimularlo.

Entiendo lo que dices compañero y es muy cierto lo que dices, creo que en ello he errado y si por eso los he ofendido sinceramente te pido una disculpa. Ahora bien si me lo permites me explicaré por qué la comparación. Desde hace mucho he visto que firebird es usado en entornos cliente servidor solventando algunas de sus deficiencias con código delphi lo cual le quita de entrada la característcia de robustes que muchos como postgresql, oracle o mssql server poseen. ¿qué deficiencias? como la comunicación en firebird entre distintas bases de datos en un entorno multidb o la comunicación entre distintas instancias de firebird. Para que puedas leer dos tablas desde distintas instancias de firebird solo puedes hacerlo si bien he leido con código delphi. ¿Qué acarrea eso? que incrustes código sql en las aplicaciones y esa es precisamente una terrible prática heredada de los tiempos de dbase cuando no se podía colocar código sql en la base de datos. De ello la comparación que hago y que entiendo consideran como un insulto. De ello me disculpo contigo.

?

Si Oracle aguanta mucho mas que FB, entonces a quien lo necesite ese precio lo vale o no. Demás esta decir que Oracle es a FB lo que un Mainframe a un servidor: un mercado diferente. Seria absurdo decir que si un servidor PC tipico es mas barato que un mainframe, estúpido el que compra el mainframe (estupido es el que compra un mainframe, cuando realmente necesita un servidor, pero bueno eso es otra cosa...).

Ademas, se puede malinterpretar el que como no hay un argumento que diga: mira que FB puede tragar mas datos que Oracle, cambiemos el tema al $...

No creo que sea nada controversial reconocer que Oracle barre con FB en cuanto a funcionalidad, confiabilidad & desempeño.

Lo mismo se podría decir (en términos generales, *ojo*) de Postgres, DB2 & Sql Server. Quizas se puede argumentar que FB barre con MySql, excepto que MySql se puede montar en un array de Balanceo de cargas trivialmente, y que (tal vez?) sea mas rapido en lecturas. Creo que siempre ha sido claro cual es la posicion de FB, incluso desde quienes la hacen.

Así que en cuanto a desempeño raso, que es lo que apuntan los números de este thread? No seria nada sorprendente decir que otras BD pueden ser mejores.. De hecho el problema que le veo a este caso de estudio es que no hace un argumento muy convincente: No saca ventaja de los puntos fuertes de FB, y da mucho espacio a # que para cualquier conocedor del tema pueden ser *ok* pero no *descrestantes*.

No se ve FB muy seguido en ninguno de los sitios que hablan de temas de escalabilidad (ej: en http://highscalability.com/ no sale ni 1 vez), ni nunca he sabido de un startup que use FB... que es muy triste, si usan *gasp* MongoDb!, asi que no se escucha de casos de uso donde la gente diga: Whoa! que impresionante. Se habla, por ejemplo, que Mongo lo usan tal y cual app/sitio... tiene miles de usuarios, MongoDb debe ser *la leche encarnada*, y así es como se rego ese adefesio.

----

Ahora, no malinterpreten. Recuerden que realmente *soy todo un fan* del underdog.

El angulo de FB va mas por la facilidad de uso, zero-admin, despliegues flexibles desde embebido a cliente/servidor, confiabilidad y creo yo el punto mas fuerte, ser capaz tanto como BD tipo olap como transaccional. En todo eso FB barre a todo el mundo, y es en lo que se deben enfocar los que la promueven. No se deben sacar # que sean desfavorables (o parezcan, o no refuerzen el angulo) y en cambio se deben enfatizar donde FB es fuerte.

Asi que si hacen un caso de estudio, yo diria que este seria el formato:

- Que es firebird
- Un listado de empresas muy conocidas que lo usen (tipo: Lo usan MS, Apple, bla bla.)
- Resumen de la empresa/gente de la cual se va a enfocar el caso, cuales son sus retos
- Reiterar uno o varios de los puntos fuertes
- Contrastar contra otras soluciones en donde esos puntos les son desfavorables. Que hace a FB realmente una mejor solucion que otras? La simple familiaridad no es argumento.
- Si se presentan números? Por ejemplo yo enfocaria como sirve para OLAP/OLTP y mostrar eso contra el primero que le salga peor ;) (ej: Si por casualidad Oracle sale mas lento, PG medio, entonces se usa Oracle).

Si realmente se esta sub-utilizando las capacidades del motor (ej: No siendo un experto en FB, tambien me pareció que los # presentados deben estar muy por debajo de lo que FB aguanta), entonces hay que poner el # que si destaque. Por ejemplo: NNN dias sin tunear, administrar la BD.

- Mostrar la confiabilidad, escasez de administración manual, etc
- Resumen

En cuanto a precio? Eso solo es un problema para los pequeños. Una startup solida y una empresa que le saque la leche a un motor se rien de los precios. Obvio no les choca algo mas barato, como a todo el mundo, pero el que sea *gratis* es una contra mas que un punto a favor A MENOS que este claro a quien se debe $$$$ por soporte. Quienquiera que realmente vaya a usar seriamente algo, le interesa sobremanera tener como $$$$ a quien lo saque de apuros.

---
Tambien desde hace mucho me parece que FB, al igual que FreePascal & Delphi sufren enormente por falta de un buen enfoque de marketing (del bueno) y de saber presentarlo.

---
Ahora eso es un caso de estudio pa una empresa/cliente. Para gente como nosotros? Hace falta algo mas. Yo he visto información muy descrestante sobre PG (por ejemplo) con números, detalles técnicos, bechmarks, etc muy bien logrados. Hay algo asi sobre FB?

No?

Entonces que tal hacer eso?

Absolutamente de acuerdo contigo. Valdría la pena desarrollar un caso de estudio así pero para ello creo que se necesitaría alguien que sea experto en ese motor y que garantice sacarle el máximo jugo a las características que tiene. Sería grandioso ver un estudio de ese calibre para evaluar desde una mejor posición lo que firebird puede o no hacer, especialmente para quienes como yo lo vemos con malos ojos, tal vez inmerecido, pero así lo vemos.

Firebird: otro caso de estudio

Evidentemente, esos no son "casos de estudio", se ve que son personas que trabajan en ciertas empresas y que han puesto una pequeña definición de su sistema informático.
Pero no por ello hay que desvirtuar el hilo sobre lo bueno o no tan bueno que pueda ser firebird, mongo o cualquier otra base de datos.

Si tienen algo que comentar, comenten, pero por favor, trols abstenerse.

Bueno supongo que decir algo que no les guste o vaya contra lo que creen y no poder argumentar contra ello solo les da para adjetivarme de esa forma. Ok entiendo eso.

1) Argumento mi posición una carga de un promedio de 0.12 mb por minuto en un periodo transaccional de 12 horas la soporta casi cualqueir base de datos. En tiempos de dbase algo así o más era lo que generaba un sistema de supermercado.

2) Reafirmar como lo hizo casimiro sin respaldar lo que dice diciendo que son efectivamente son números impresionantes es erróneo a menos que no se haya visto un sistema con mayor carga que esa.

3) Si revisamos los hilos en que se ha atacado al software privado muchos son práticamente de nivel troll.

punto final.

Opino que es valido que se tengan visiones distintas de algo.

Esta bien que sea un Club Delphi, pero no un Fans Club Delphi.

Por otra parte, Firebird sigue y seguira siendo una maravilla :p

^\||/^\||/^\||/

Hola.

Mas allá de hacer una comparativa, creo que cualquier herramienta es buena en la medida que se aplique a una determinada taréa y la desempeñe bién y eso Firebird lo hace sin problemas.

Tengo en claro que para determinadas situaciones Firebird no da la talla y para eso existen opciones como Oracle que sí lo hacen. No hay dudas de que Oracle es muy superior en prestaciones a Firebird y diría sin temor a equivocarme que a toda la competencia.

Mis clientes no son grandes corporaciones y a una gran parte Firebird hasta les "queda grande". Tengo sistemas funcionando excelentemente hace años y que no han requerido mantenimiento de la bd, hasta el momento Firebird cubierto perfectamente mis espectativas. Tal vez en un tiempo tenga que decir: "Firebird no me alcanzó para esto" pero por ahora no he tenido la suerte de tomar un trabajo de ese tipo.

Ví que no me expliqué (o no se interpretó) la idea de mi mensaje anterior, a ver si ejemplificando lo pongo mas claro: No aconsejaría al dueño de un servicio de mensajería, que dotara a cada uno de sus cadetes con camiones de u$s 80.000 cuando puede desarrollar perfectamente sus actividades con ciclomotores de u$s 250 (o bicicletas).

Saludos :)

1. Si troleas y lo haces porque no te gusta Firebird y dices cosas que no son, arranquemos porque la capacidad máxima de un archivo de DBase es (o era) de 2G nada más con este dato se cae todo lo que has dicho, DBase y Access no pueden hacer lo que se hace en este caso de estudio porque simple y llanamente no pueden pasar de estos tamaños y sus tablas no púeden pasar de de 1G, pero bueno sigamos, para poder tener una base de datos como la que se muestra en este caso de estudio una carga transaccional de 0,12 mb por minuto necesita o estar muy mal hecha para que 20 o 30 usuarios simultáneos (los limites de access y DBase) creen tanta información por minuto en tan solo datos o necesita mucho más de esa cantidad de usuarios simultáneos (cosa que dudo que ocurra en un supermercado por muy grande que sea como otro ejemplo que has puesto)

2. Quieres comparar un caso de estudio con uno de los más grandes de Oracle, siendo esta base de datos tal vez la más famosa y popular en las grandes aplicaciones mundiales (creo que la base de datos más grande del mundo es soportada por Oracle), y la comparas con Firebird, una base de datos que casi está amarrada a los usuarios de Delphi por la cercanía que tiene esta con dicha herramienta, curiosamente en este estudio no dicen "hey mira, somos mejores que Oracle porque tenemos un usuario que tiene estas capacidades", pero tu al poner tu comparación la centras de una forma tal que pareciera que fuera este el caso cunado no lo es, llegar a los niveles de información que se ha llegado en Oracle para firebird son muy difícil porque simplemente es difícil encontrar una empresa grande (de las grandes del mundo) que no tenga ya su sistema de información montado (muy probablemente en Oracle o en otra grande) y las empresas que estan pasando a ser grandes van a elegir algo similar porque ya esta probado, Firebird con este caso de estudio va ganando visibilidad (tal vez muy poca o casi nada) en algo que antes no lo veían y ese esa es la finalidad del estudio y si son datos realmente buenos, que hay mejores en otras empresa nadie lo ha negado o lo ha sugerido en este estudio... En fin esta forma de argumentar tuya acá es una falacia (la cual no recuerdo el nombre).

3. Osea que haces esto para reivindicar el software privado por las veces que alguien haya dicho algo en contra de él?

¿Quien sabe modificar firebird?
 

Yo ando buscando gente que conozca firebird y pude hacer modificaciones. al codigo fuente y poder hacer mejoras.

No le termino de entender a al codigo lo leo y no comprendo.

Ejemplo de un cambio interesante . seria poder conectar a la base de datos sin tener que poner la ruta fisica.

solo la ip y el nombre de la base de datos, como mysql o postgresql.

Puedes usar alias.

si.. Casimiro Notevi ,, pero la idea es modificar el codigo fuente. ir haciendo cambios.
arreglo de bugs y nuevas caracteristicas,

Gracias

¿Y eso qué tiene que ver?
Has preguntado sobre cómo conectar sin poner la ruta. En el fichero de configuración añades la ruta y un alias. En el cliente pones el alias nada más.