Me equivoqué, quise decir:
... usaría firebird.

Cierto :):o

The v.2.0 Superserver has active protection to make a brute-force attack more difficult. After a few failed attempts to log in, the user and IP address are locked for a few seconds, denying any attempt to log in with that particular user name OR from that particular IP address for a brief period.
No setup or configuration is required for this feature. It is active automatically as soon as the Firebird 2.0 Superserver starts up.



New security database

The new security database is renamed as security2.fdb. Inside, the user authentication table, where user names and passwords are stored, is now called RDB$USERS. There is no longer a table named "users" but a new view over RDB$USERS that is named "USERS". Through this view, users can change their passwords.
For details of the new database, see New security database in the section about authentication later in this chapter.
For instructions on updating previous security databases, refer to the section Dealing with the new security database at the end of this chapter.
Better password encryption

A. Peshkov
Password encryption/decryption now uses a more secure password hash calculation algorithm.
Users can modify their own passwords

A. Peshkov
The SYSDBA remains the keeper of the security database. However, users can now modify their own passwords.
Non-server access to security database is rejected

A. Peshkov
gsec now uses the Services API. The server will refuse any access to security2.fdb except through the Services Manager.
Active protection from brute-force attack

A. Peshkov
Attempts to get access to the server using brute-force techniques on accounts and passwords are now detected and locked out.

• Login with password is required from any remote client.
• Clients making too many wrong login attempts are blocked from further attempts for a period.

Support for brute-force attack protection has been included in both the attachment functions of the Firebird API and the Services API. For more details, see Protection from brute-force hacking.

Así es en la practica. Tu puedes asignarle a un usuario una contraseñas de hasta 64 caracteres, creo. Pero Firebird solo utiliza los primeros 8 caracteres e ignora el resto. Esto no forma parte del diseño de Firebird, sino es un bug que se descubrió relativamente hace poco. Todas las versiones están afectadas, inclusive la última. El equipo de Firebird está desde trabajando en la solución, pero ya llevan casi dos años trabajando en ella. Se han tardado tanto porque no quieren romper la retrocompatibilidad.

Saludos!

Pero, entonces: ¿firebird no permite limitar el acceso según la dirección ip? Con MySQL, por ejemplo, jamás se da acceso a root o cualquier otro usuario con privilegios amplios como no sea desde local. :confused:

// Saludos

¡Ah! Caray. Disculpa pero esto me es difícil de creer. Es decir, sí puedo creer que exista tal bug, pero ni de relajo puedo creer ni que sea difícil de solucionar ni mucho menos que la razón sea por retrocompatibilidad.

// Saludos

Si es algo que causa un poco de "estrés" cuando uno viene de otro motor, pero ya me he adaptado y pues si, a mi me pueden meter en el saco de los fanboys de firebird, creo que son más las cosas buenas que encontré en firebird que en MySQL, empezando por su licencia que siempre ha sido clara mientras que con MySQL da oportunidad de confusión con su licencia dual (y que ahora con Oracle no noto la diferencia con la anterior), ya luego cuando descubrí los procedimientos almacenados y los disparadores ni hablar, en ese momento MySQL no los tenía (y por los comentarios que he ledio ahora no son la gran cosa) y mucho menos Access o Paradox (que eran mis otras opciones de trabajo), el consumo de recursos de firebird me iba muy bien en equipos viejos mientras que instalar un MySQL en un windows 98 con un procesador malo era condenar el equipo a demorarse a arrancar 5 o 6 minutos despues de lo normal y estar expuesto a múltiples bloqueos (y yo tenía y tengo clientes con equipos de de 10 o más años con un solo computador donde hacen todo y tengo clientes con una red de trabajo "grande" con un servidor dedicado montado en un verdadero servidor).

Que yo sepa, la longitud del password no es ningún bug que no hayan querido solucionar, lo hicieron así en su día (interbase de borland) y así ha quedado.
He buscado en los bugs y no lo he encontrado, puede que no lo haya visto.
http://www.firebirdfaq.org/cat7/

Solo un Sueño
 

Parece que los software open source que salen al mercado con mucho exito tiende a ser no mas que un anzuelo de clientes, pero la triste realidad del mercado hace que projectos tan noble como estos donde el lema es "uno para todos y todos para uno" como los tres mosqueteros se conviertan
en "YO les vendo a ustedes y todos me pagan a mi" (Empresa), asi que lo que empezó como algo noble se convirte en algo lucrativo, es decir el mismo producto pasa de una forma de projecto a otra es como si el open source fuera un beta tester del Software y una vez pasada la prueba entonces se realiza el cambio ,parece una buena estrategia de los desarroladores asi como de las compañias, pero a la larga pasará algo inevitable se pierden clientes, y lo considerarán como "daños coraterales" , open source es solo un SUEñO despierten a la realidad y cuando lo hagan se encontraran con una realidad llamada MERCADO

Amigo, disculpa si soy un poco tosco, pero NO TIENES NI IDEA de lo que hablas, infórmate antes, por favor.

No, no me caes mal... pero dejémoslo en que tienes la facilidad de exasperarme. :D
Si hay algo que no me agrada es que venga un tipo que se dice alabar algo pero resulta que se auto apuñalada y busca meter el vardo (problemas para los argentinos) a escondidas.

El sólo hecho de hacer esos llamados a comparación es separar, clasificar... y de decir quien es mejor y cual es el peor.

A ver... estoy de acuerdo en que uno debe aplicar un buen análisis de caso de estudio para decir que es lo más viable. Pero yendo al caso ¿Que es lo que no hace viable a FB en algunos escenarios?

Quieres algo monousuario y liviano: Firebird Embeded; aunque si existe la restricción de que sea multiplataforma allí si hay que mirar más.
Necesitas algo más adecuada para Windows: Firebird SuperServer
Necesitas algo más adecuado a Linux: Firebird Classic o SuperClassic

Necesitas algo grande: Firebird

Si hay algo que tiene FB es que tiene diferentes sabores para adaptarse a varios escenarios. Es lo suficiente flexible y escalable como para ir desde el monosuario a una compleja red.
¿No es eso maravilloso? Pidele lo mismo a MySQL, PostgreSQL o a SQLite a ver que te dicen.

Y saber cuando callar, y hacer una crítica constructiva y cuando permitirse hablar. Hablaste de unas supuestas falencias, viejas, de FB. Te he dicho que FB a mejorado y tu le seguiste dando por algo del pasado; como lo de seguridad.
¿O es que te parece poco y nada el avance de 2.1 a 2.5 y ahora con lo que se viene a 3.0?
Tu tiraste una visión en la que te quedas como en que FB nunca mejorará... y seguirá siendo un juguete que está bajo la sombra de PostgreSQL.
Date cuenta Chris que los aspectos de seguridad, redes, procedimientos almacenados y otras "características" que señalas no son limitaciones, ni hacen de FB un producto inmaduro.

Si realmente quieres hacer una crítica constructiva pongamos a la luz los avances de FB y PostgreSQL desde su concepción ¿Quien avanzó más y más rápido en los años que lleva?
PostgreSQL es el primer proyecto Open Source (corrijanme si me equivoco) y lleva casi 30 años. Firebird por su parte recién cumplió su década.
FB a avanzado en sus 10 años muchísimo más rápido que PostgreSQL en sus 30. Si eso no es para destacar ¿que mierda es?

Naturalmente FB debe seguir madurando, pero ¿pensemos si? Te parece poca cosa lo hecho por el proyecto Firebird? ¿Eso no suma no?

Si FB fuera un juguete, ¿porqué hay empresas que apuestan cada vez más? ¿Porqué ha venido ganando premios en SourceForje como uno de los proyectos más alentadores?

Lees pero no etendés. ¡Parte del equipo de desarrollo de PostgreSQL es quien se pasó a Firebird!
Además cuando dije que MySQL y PostgreSQL le deben favores me refiero justamente a una de las cabezas del equipo de Firebird gentilmente cedió su experiencia y recomendaciones a MySQL y PostgreSQL; si... así es colaboró en dichos proyectos. Lo cierto es que MySQL no sería lo que es sino fuera por la ayuda que brindó Steve Summers. La historia fue más o menos así: "Oye Steve te necesito aquí porque me quedé trabado. ¿Me das una mano? Claro que te pagaré"

Nuevamente... estas volviendo a decir que FB es un juguete.
¡Pero claro, también dices que se moldea!

Vamos Chris... ¿al final es un juguete o un buen producto que sabe calzarse? Anda...

Si claro, como si FB no soportara seguridad, ni procedimientos almacenados. :rolleyes:

Gracias por el sarcasmo :D :p

Tengo entendido que en realidad el uso de los autoincrementales es lo peor que le ha pasado a la historia en las bases de datos. En el estándar SQL se recomienda fervientemente abandonar el concepto de autoincremental y empezar justamente a promocionar el uso de SEQUENCES (término que se impuso y aceptó como válido tras la última revisión allá por 2008) junto con TRIGGERS.

Pues si... en esto coincido. El problema con el BOOLEAN es que es un tipo de dato que ha llevado a unas cuantas discusiones en el estándar SQL. Si bien el estándar lo define, hay detractores que rechazan su puesta. Más que nada se debe a diferencias de opinión respecto a como tratar un BOOLEAN NULL y lo que implica realizar operaciones sobre éste; habiendo diferencias de opinión algunos sugieren que se evite su uso y en su lugar se utilice un "alias" numérico o cadena y dejar en manos del desarrollador de la base de datos como prefiere utilizarlos.

Saludos,

Pues compañeros, me parece que el tema se está poniendo muy tenso y espero que se bajen las ansias y escribamos en este hilo con mas cordura, yo soy un gran FanBoy de Firebird, en este momento FB 2.5 es demasiado bueno y puedo dar testimonio que para llevar la lógica de negocio al motos, no se necesita nada mas que el Standar SQL, la seguridad de Firebid aunque no es excelente, es muy buena, hace ya un mes, hice una prueba de fuerza bruta para el usuario SYSDBA, el programa se me quedaba colgado esperando respuesta, mientras los demás clientes seguían funcionando, lo de la clave de los usuarios es cierto, pero no es tanto problema de FB sino del tipo de hash aplicado, mismo problema que el de windows, sino estoy mal, se puede cambiar por el archivo de configuración de FB (no estoy seguro), pero de lo que si estoy seguo es que las bases de datos expuestas a internet son un fracaso por parte de los analistas que hacen esto, eso es un brutalidad, lo que se debe hacer es proporcionar una capa entre "internet" y "base de datos", por practicas tan tontas como estas es que han hackeado y robado información de muchas empresas multinacionales, que tienen sus servidores en oracle, mssql entre otros, también quiero dejar claro que FB no es un juguete comparado con ninguna otra base de datos, por el contrario, es un "pequeño" gigante que cada vez me llena de gratas sorpresas al usarlo.

Yo creo que más bien es que no toleras una opinión contraria a la tuya. Te dejo esta prueba. Tú dices que para proyectos con una DB local y mono usuario (solo Windows) lo ideal sería Firebird Embeded. Bueno yo digo que es SQLite. ¿Discutimos? :cool:

Nuca he jurado lealtad hacia ningún motor. Y si no criticara los problemas existente, quién lo haría entonces? Acaso no es buena la autocrítica? Crees que los problemas de seguridad se hubieran venido mejorando -aunque sea un poco- si alguién antes no hubiera hecho el llamado a mejorar las cosas?

No quiero pensar que eres de los desarrolladores que para todo tipo de problemas tienen la misma solución. Tal vez digas que Firebird es adecuado para manejar las transacciones de Wall Street. :D

Sé lo que cada uno tiene y que puedo pedirles.
A MySQL, búsquedas de texto completo (no disponibles en Firebird).
A Postgree, Estructuras de datos aptas para geolocalización (no disponibles en Firebird)
A SQLite, Simplicidad y ligereza (mucho mayor que Firebird Embeded).

Necesitas leer el hilo y comprender en el contexto en que lo he dicho.

Sí claro diez u once años. Pero súmale los casi veinte años que tenía Interbase cuando fue liberado. Allí ya no se hace tanta la diferencia.

Porque es un excelente motor de base datos. Nunca he dicho lo contrario. Pero al César lo que es del César.

Entonces este señor Steve habrá diseñado ambos motores desde cero para que le des todos los méritos de lo que son hoy cada uno de ellos.

Creo que si haces una búsqueda en San Google, solo te encontrarás a tí sosteniendo que Firebird es inmensamente superior a Postgree. Por favor! Ambos tienen lo suyo y ambos son un excelentísimo producto. Pero a cómo te dije, al César lo que es del César.

Saludos,
Chris

Sigamos la "guerra" :D
¿Cuáles son los requisitos necesarios?, me gustaría saberlo para poder convencerme.

¿Texto completo?, ¿qué quieres decir con eso?, me pones un ejemplo, por favor.

Cierto, postgresql lo permite.

Y ahora me toca disparar, jejeje :)
Puestos a hablar de "lo malo" que es uno u otro, me he encontrado información que confirma que postgresql es muy malo :D

• He leído que no existe una versión de postgresql "incrustable", "embebida" o como se le llame. De firebird, sí :)
• También he leído, no sé si las últimas versiones lo tienen, que no existen campos calculados en postgresql. En firebird, sí :)

Ejemplo:

Código SQL [-]
CREATE TABLE ejemplo (      
  id  integer not null,    
  campo1  currency not null default 0,      
  campo2  currency not null default 0,      
  total   computed by (campo1 + campo2),   
  primary key (id)
);

Sólo he buscado un poquito, pero seguro que si busco más, encontraré más "fallos" de postgresql :D

Más cosas, he buscado y no lo he encontrado, pero hay algo en firebird que está muy interesante y no sé si lo tiene postgresql:
Los triggers, además de los habituales before/after insert/update/delete también pueden ser creados de una vez para varios eventos, ejemplo:

Código SQL [-]
create trigger t_ejemplo_ active
BEFORE INSERT OR UPDATE OR DELETE POSITION 0
as
begin
  if INSERTING then
    loquesea

  if UPDATING then
    loquesea

  if DELETING then
    loquesea

end

Pero además hay más, a veces es necesario hacer varias cosas distintas en un mismo evento de trigger, o cosas totalmente distintas, o unas cosas antes que otras, pues bien, se puede tener varios triggers, por ejemplo, before insert, se diferencian por la 'position'.
Ejemplos:

Código SQL [-]
create trigger t_ejemplo_ active
before insert POSITION 0

Código SQL [-]
create trigger t_ejemplo_ active
 before insert POSITION 1

Código SQL [-]
create trigger t_ejemplo_ active
 before insert POSITION 2

¿Tiene esa funcionalidad postgresql?

La búsqueda de texto completo en FB si son posible, no por que ya exista una función para ellos, pero si creas una serie de procedimientos almacenados podrás tener esa utilidad, Aquí los scripts y la explicación, también puedes usar una de estas opciones.

Hace un año y medio buscando por Google la palabra Firebird me salian 9 millones de resultados aprox. Para Postgresql me salian mas 10 millones de resultados.

Ahora salen 40 millones para Firebird y 35 millones para Postgresql.

Hay una campaña de los patrocinadores de Firebird llamada MindTheBird que seguro esta dando muy buenos resultados.

N.B en todas las comparativas que he leido entre las dos BDs sale ganando Firebird a Postgresql en velocidad. No sera casualidad.

Recuerdo cuando era joven y discutía con la misma energía que ustedes. ;)

Incrustrada. :)

Lo que puedo sacar en resumen es que las tres bases de datos más mencionadas en este hilo son grandes competidores entre sí, tanto por las características exclusivas que cada una posee, como por su popularidad.

Les propongo que toda esa energía la dediquen a hacer una fría y objetiva comparación, sin apasionamientos, de las tres bases de datos. Estableciendo diferentes entornos y poniendo a prueba las tres bases de datos sobre dichos entornos. No para obtener un ganador absoluto (dudo que eso pueda surgir), sino para contar con una matriz actualizada de las capacidades de cada una y que esa matriz nos sirva para tomar decisiones ante cada proyecto.

Yo seguiré usando Firebird predeterminadamente (me gusta la canija), pero si llego a encontrarme con una limitante crítica que alguna de las otras dos resuelva de buena forma, no dudaré en cambiar, para ese proyecto en específico, el motor de base de datos.

Un abrazo ante la caída del Muro Street.

Al González.

Hola gente hace mucho que no escribia por aca.
Si bien no soy un experto en las BD mencionadas (siendo FB la que menos he usado) las 2 cosas importantes de una BD son robustes y velocidad, ni bien la primera "buena" para cualquier motor el determinante es la segunda.
Cuando empece a usar PostgreSQL la multiplataforma es un desastre comparada con cualquiera de las otras 2, la forma de hacer que funcionara en windows era con librerias de cygwin y otros inventos que hacien que el motor pareciera Frankestein. (por suerte creo que apartir de la version 8 el setup ya hacia todo). Si bien es una BD que tiene muchas cosas interesantes la performance siempre fue el punto flaco (algunas migraciones de datos de servers me han llevado su tiempito), aunque ahora es un poco más veloz nada mejor elegido como simbolo que el elefante
Mysql, es la que más he usado (que la única restricción de usarla es proporcionar el código fuente a mi entender), siempre fue muy sencilla de instalar y muy veloz (sobre todo con las tablas MyISAM, con InnoDB ya cambia un poco). Nada mejor elegido como simbolo que un Delphin. Una pena lo que esta haciendo Oracle ... pero en fin, creo que ya nos lo veiamos venir.
FB lo poco que la he usado me ha resultado bastante grato, si bien los triggers para los automerados es un trabajito más tampoco es para tanto. El que sea tan rápida y facil de usar como MySQL es una gran ventaja.
Creo que cada base tiene cosas muy interesantes para algunos menesteres pero las 3 son muy buenas bases.
Le tengo mucha fe a FB que creo que siempre lo que le falto fue prensa.

Ahora bien:
mightydragonlor tiene toda la , una BD NUNCA debe estar expuesta a Internet, la mayoria de los motores de BD expuestos a Internet han sido hackeados (incluido Oracle).

Saludos

Cuando probé MySQL lo hice sin entender muy bien porque habian tantas arquitecturas, así me fui por MyISAM, me pareció muy rápida y me fue grato, pero yo quería usar integridad referencial y estar listo para cuando salieran los procedimientos almacenados entonces cambie a InnoDB (que en ese momento entendí que debía cambiarme a esta arquitectura para tener estas caracteristicas, no recuerdo bien porque, fácilmente me falto investigar más), en fin cuando hice el cambio ahí se puede decir que tuve una experiencia nueva y poco grata, la velocidad disminuyó notablemente. Al poco tiempo empece a ver muy buenos comentarios de fb en este foro, lo estudie un poco y nuevamente a los pocos meses cambie de motor (nuevamente, antes había pasado de Paradox a MySQL) y fue algo muy bueno sentir nuevamente velocidad.