Discussion :

[Michael Guilloux]

Firebird 4.0 : la première version Alpha est disponible pour les tests
quelles sont les fonctionnalités de la prochaine version majeure du SGBDR ?

Le projet Firebird a récemment annoncé la première version Alpha de Firebird 4.0 (la prochaine version majeure de la base de données relationnelle Firebird) qui est maintenant disponible pour les tests. Le développement de Firebird 4.0 a débuté en mars 2016, juste avant la sortie de Firebird 3.0. Cette version Alpha 1 donne un premier aperçu des fonctionnalités et des améliorations en cours de développement par l'équipe Firebird, ainsi que d'innombrables correctifs de bogues.

Pour le développement de Firebird 4.0, il existe des fonctionnalités obligatoires et des fonctionnalités optionnelles. Les fonctionnalités obligatoires sont celles sans lesquelles cette version ne peut être publiée. Elles sont développées avec la plus haute priorité, leur préversion est attendue dans les versions Alpha et leur implémentation doit être terminée avant la phase Bêta. Les fonctionnalités optionnelles sont quant à elles développées après les premières et peuvent être programmées aussi bien pour les versions Alpha que les Bêta. Elles peuvent être reportées si leur finalisation n'est pas possible avant la date de publication de la version stable.

Pour les fonctionnalités obligatoires de Firebird 4.0, on peut citer entre autres :

• le support de noms d'objets de plus de 31 caractères (terminée) : comme d'autres SGBDR, un développeur estimait nécessaire que Firebird prenne en charge des noms d'objets plus longs. L'équipe de développement a donc décidé d'augmenter la longueur maximale des noms d'objets à 63 caractères. Si avoir des identifiants plus longs peut être utile, cela pourrait toutefois avoir une incidence sur la portabilité de la base de données. Il faut noter par exemple qu'Oracle impose une limite de 30 caractères pour les identifiants ;
  
  
• timeouts pour les instructions, transactions et les connexions (terminée) : il s'agissait de permettre aux développeurs de définir des délais d'attente (timeout) dans différentes situations. Par exemple pour arrêter automatiquement l'exécution d'une instruction SQL lorsqu'elle est plus longue que prévu, ou encore fermer automatiquement la connexion de l'utilisateur après une période d'inactivité ;
  
  
• réplication intégrée (en cours) : tous les grands projets et projets d'entreprise ont besoin d'un service de réplication. C'est d'ailleurs l'un des critères à vérifier lorsqu'un architecte logiciel doit choisir une base de données pour son prochain projet. Certes, il existe des outils tiers pour faire cela dans Firebird, mais le SGBDR n'a pas de fonctionnalité de réplication intégrée. Certains développeurs ont rapporté que la réplication était le principal problème rencontré avec Firebird et que pour cette raison beaucoup de clients sont passés de Firebird à des alternatives comme MySQL, même si celles-ci n'étaient pas forcément meilleures ;
  
  
• variables numériques avec précision de plus de 18 chiffres, calculs intermédiaires améliorés pour des numériques plus courts (en cours) : l'objectif est d'améliorer la précision des calculs avec des variables NUMERIC/DECIMAL. D'après le développeur qui a rapporté le problème, la façon dont Firebird gère actuellement la précision des résultats des calculs impliquant de multiples arguments peut facilement provoquer des débordements, lorsque la précision du résultat dépend de la précision des arguments.

Parmi les fonctionnalités optionnelles, on peut noter, entre autres, un support élargi des fonctions de fenêtrage, la prise en charge de la commande TRUNCATE TABLE ou encore la possibilité d'attribuer un rôle à un autre rôle afin qu'il hérite des privilèges du premier.

Ce ne sont que quelques-unes des principales fonctionnalités (obligatoires comme optionnelles). Il faut rappeler que les versions Alpha ne sont pas encouragées pour une utilisation en production ou pour d'autres objectifs nécessitant un système stable. Elles sont cependant recommandées pour les utilisateurs qui veulent aider à identifier les problèmes et bogues, ce qui permet de progresser plus rapidement des étapes Bêta/RC vers la version finale.

Pour les versions stables, ce sont Firebird 2.5.x (initialement publié en 2010) et Firebird 3.0.x (publié en 2016) qui sont actuellement pris en charge.

Tester Firebird 4.0 Alpha 1

Sources : Annonce de Firebird 4.0 Alpha 1, Fonctionnalités prévues

Et vous ?

Utilisez-vous le SGBDR open source Firebird ? Comment le jugez-vous ?
Que pensez-vous des nouveautés prévues pour la prochaine version ? Lesquelles attendiez-vous ?

Voir aussi :

Rubrique Firebird (Actualités, Cours et tutoriels, FAQ, Forums)

[SQLpro]

Firebird 4.0 : la première version Alpha est disponible pour les tests
quelles sont les fonctionnalités de la prochaine version majeure du SGBDR ?

[...]

Pour les fonctionnalités obligatoires de Firebird 4.0, on peut citer entre autres :

• le support de noms d'objets de plus de 31 caractères (terminée) : comme d'autres SGBDR, un développeur estimait nécessaire que Firebird prenne en charge des noms d'objets plus longs. L'équipe de développement a donc décidé d'augmenter la longueur maximale des noms d'objets à 63 caractères. Si avoir des identifiants plus longs peut être utile, cela pourrait toutefois avoir une incidence sur la portabilité de la base de données. Il faut noter par exemple qu'Oracle impose une limite de 30 caractères pour les identifiants ;

Curieux !!!! la norme impose 128 caractères, ce que respecte DB2, Sybase, SQL Server et j'en passe !!!

• variables numériques avec précision de plus de 18 chiffres, calculs intermédiaires améliorés pour des numériques plus courts (en cours) : l'objectif est d'améliorer la précision des calculs avec des variables NUMERIC/DECIMAL. D'après le développeur qui a rapporté le problème, la façon dont Firebird gère actuellement la précision des résultats des calculs impliquant de multiples arguments peut facilement provoquer des débordements, lorsque la précision du résultat dépend de la précision des arguments.

C'est pas trop tôt. l'AMF préconise 12 décimales dans les calculs financiers; Avec une limite de 18 on ne peut pas stocker des grandeurs financières supérieurs à 999999,999999999999, soit moins de 1 million !!!

Et vous ?

Utilisez-vous le SGBDR open source Firebird ? Comment le jugez-vous ?

Trop limité, peu performant par rapport à postGreSQL par exemple... je ne parle même pas par rapport à un SQL Server on l'on est à des années lumières : pas de XML, pas de spatial, pas de JSON, pas de graphe...

Que pensez-vous des nouveautés prévues pour la prochaine version ? Lesquelles attendiez-vous ?

Encore beaucoup de boulot, mais ça ressemble fortement au tonneau des danaïdes !

Voir aussi :

Rubrique Firebird (Actualités, Cours et tutoriels, FAQ, Forums)

[vanquish]

Je respecte beaucoup vos compétences qui sont à des années lumière des miennes en terme de SQL et SGBD : mais votre commentaire est quelque peu hors de propos.

C'est comme dire qu'une Clio n'est pas une vrai voiture parce qu'elle n'a pas de grand coffre ni de boite automatique de la dernière BMW X7 (voir d'un Autocar).
Pourtant, allez savoir pourquoi, la Clio reste le choix de centaines de milliers de personnes.

On ne montera pas un Datacenter avec Firebird, c'est une évidence.
Sur le plan fonctionnel Firebird est en retrait par rapport aux bases que vous citez : c'est un fait.
Je ne le conseillerais pas de façon aveugle pour tous les usages - d'ailleurs pour un usage interne auquel je fais référence plus bas, j'ai beaucoup hésité.

Mais quand on déploie un logiciel dans des centaines de PME qui n'ont pas de service informatique, sa légèreté est un atout en terme de coût, de facilité de déploiement, de maintenance et de sauvegardes.

Dans ce cadre, son mode de licence est aussi intéressant : il n'y en a qu'une seule et elle est ultra-permissive.
Ca reste un vrai système SQL client-serveur tout en ayant une architecture simplissime (ça se déploie d'un zip et d'un instsvc).
Sur des volumes raisonnables, un mode de sauvegarde permet une copie à chaud du fichier de bases de données qui pourra être remonté par simple xcopy.

on a des centaines de copies qui tournent. On a jamais perdu un octet.
On a jamais eu a passer d'un modèle de licence à l'autre le jour où il y a eu un utilisateur ou un octet de trop ( pour un usage interne j'ai une base - en lecture seule - de 33 To ).

Coté perf brute : j'ai des déploiement (anciens) en mySQL/InnoDB et d'autres (plus récents) en Firebird.
Je ne sais pas ce que diraient des benchmark, mais à l'usage on ne voit pas réellement de différences.

A priori, Firebird 4.0 garde la même structure binaire que la 3.0 : si c'est le prix à payer pour ne pas respecter la norme de 128 caractères, je l'accepte sans hésiter.

Bref : pour notre usage qui rejoint celui de pas mal d'autres éditeurs de logiciels (je les croise sur certains sites), Firebird présente quelques avantages sur d'autres SGBD pourtant plus puissant.
Si en plus il permet la réplication, je suis très preneur (c'est à vrai dire la seule amélioration que j’attends vraiment avec impatience).

A chaque fois qu'il est question d'un SGBD léger, on a ce genre de commentaire de votre part.
Mais parfois (et pour rester dans l'analogie automobile) "Light is Right" - Colin Chapman (Lotus - les voitures, pas les logiciels).

Amicalement
PS : le pouce en bas n'est pas de moi - je n'en met jamais - cela manque d'arguments.

[SQLpro]

Mais quand on déploie un logiciel dans des centaines de PME qui n'ont pas de service informatique, sa légèreté est un atout en terme de coût, de facilité de déploiement, de maintenance et de sauvegardes.

À ce niveau je ne voit pas de différences avec PostGreSQL... À un autre niveau, celui des fonctionnalités, je voit une grande différence.

Sur des volumes raisonnables, un mode de sauvegarde permet une copie à chaud du fichier de bases de données qui pourra être remonté par simple xcopy.

Une sauvegarde est par définition une opération effectuée à chaud permettant de restaurer une base de données dans son état initial. Sauvegarde à chaud ne veut donc rien dire. Une copie des fichiers d'une base n'est pas une sauvegarde, de même qu'un dump (obtenu par extraction des données) ne l'est pas non plus. Tous les SGBDR de bonne qualité savent faire des sauvegardes depuis des lustres... Sauf MySQLmerde...

Bref : pour notre usage qui rejoint celui de pas mal d'autres éditeurs de logiciels (je les croise sur certains sites), Firebird présente quelques avantages sur d'autres SGBD pourtant plus puissant.

Mais beaucoup d'inconvénients, surtout pour des éditeurs :

• un manque flagrant de documentation (aucun livre paru sur le sujet en particulier...)
• peu d'informaticien le maitrisant
• une confidentialité qui rime avec pauvreté des fonctionnalités

...

Si en plus il permet la réplication, je suis très preneur (c'est à vrai dire la seule amélioration que j’attends vraiment avec impatience).

La réplication existe depuis plus de 20 ans chez la plupart des autres...

A chaque fois qu'il est question d'un SGBD léger, on a ce genre de commentaire de votre part.

Je préfère de très loin PostGreSQL...

Mais parfois (et pour rester dans l'analogie automobile) "Light is Right" - Colin Chapman (Lotus - les voitures, pas les logiciels).

Légèreté n'est pas synonyme de manque de performance chez Lotus... Mais chez Firebird, hélas oui !

Amicalement
PS : le pouce en bas n'est pas de moi - je n'en met jamais - cela manque d'arguments.

Je suis habitué aux critiques. Je les suscite. Si elle sont constructives elles m'intéressent bien plus que les commentaires flatteurs dans le sens du poil. SI elles sont juste dialectiques, je m'en moque éperdument !

A +

[alassanediakite]

Salut

...
Une copie des fichiers d'une base n'est pas une sauvegarde, de même qu'un dump (obtenu par extraction des données) ne l'est pas non plus.

Si tel est le cas alors même PostgreSQL ne fait pas de sauvegarde. Car à la date d'aujourd'hui ce sont seulement ces deux modes qu'il accepte.
Mais puisque pour toi "il y a le SGBDR SQL SERVER et les autres" donc on comprend que tout ce qui n'est comme SQL SEVER n'est pas bon.
@+

[SQLpro]

Salut

Si tel est le cas alors même PostgreSQL ne fait pas de sauvegarde. Car à la date d'aujourd'hui ce sont seulement ces deux modes qu'il accepte.

À proprement parler non, sauf pour la sauvegarde PITR qui ne contient que les transactions.
Il serait souhaitable à terme d'avoir pour PG une sauvegarde digne de ce nom...

Pour info, Sybase, Oracle et DB2 font bien des sauvegarde binaires sans aucun problème... Il n'y a donc pas que SQL Server !

A +

[DarkVenoM]

Firebird présente quelques avantages sur d'autres SGBD pourtant plus puissant.

Est-ce que vous voyez d'autres avantages de Firebird par rapport à des SGBD "plus puissants" ?

[marc.collin]

Est-ce que vous voyez d'autres avantages de Firebird par rapport à des SGBD "plus puissants" ?

facile a mettre en oeuvre et à administrer, possibilité de l'embarquer dans une application

[VLDG]

Firebird n'est ni SQL Server ni Oracle mais c'est une très bonne base de données qui rend services à beaucoup de développeurs et qui à beaucoup de qualités

[vadim]

Oui, c'est aussi avec grand plaisir que je vois Firebird 4.0 venir.
Pour moi c'est une excellente base. Performante, extrêmement pratique et facile à transporter ou migrer sans s'embêter avec moultes fichiers dispersés.
Pour la réplication, il y avait déjà IbReplicator qui marche très bien depuis des années.

Vadim

[Bruno]

La première version admissible de Firebird 4.0 est disponible avec la syntaxe du SQL standard pour les décalages de fuseau horaire,
et des corrections de bogues

Les responsables du projet Firebird annoncent la première version admissible, la première release candidate (RC1), de Firebird 4.0. Cette version du SGBDR (Système de Gestion des Bases de Données Relationnelles) Firebird est maintenant disponible pour des tests sur les plateformes Windows et Linux.

En février de l’année dernière, plus d'un an après la sortie de la version Alpha 1, les responsables du projet Firebird ont annoncé la disponibilité de la version bêta 1 de Firebird 4.0. La version admissible annoncée le 1^er février de cette année apporte des nouvelles fonctionnalités et corrige des bogues. Dans un document intitulé « Firebird 4.0 Release Notes, for Firebird 4.0 Release Candidate 1 », les développeurs principaux de Firebird, Helen Borrie et Dmitry Yemanov ont passé en revue toutes les améliorations. Voici ci-dessous un aperçu de quelques-unes de ces améliorations.

Les nouveautés

Syntaxe du SQL standard pour les décalages de fuseau horaire : le décalage du fuseau horaire dans l'horodatage, CAST, SET TIME ZONE et AT TIME ZONE suit désormais uniquement la syntaxe du SQL standard.

Instruction ALTER SESSION RESET : une nouvelle commande pour réinitialiser l'environnement de session utilisateur à son état initial. Elle peut être utile pour la réutilisation de la session par une application cliente. Pour pouvoir réutiliser une session, toutes les variables du contexte utilisateur et le contenu des tables temporaires doivent être effacés et tous les paramètres au niveau de la session doivent être réinitialisés à leurs valeurs par défaut. La syntaxe pour y parvenir est : ALTER SESSION RESET.

Nouvelle table virtuelle RDB$CONFIG : une table virtuelle énumérant les paramètres de configuration actuels pour la base de données active. La table RDB$CONFIG est alimenté à partir des structures en mémoire sur demande et son instance est préservée pour la durée de vie de la requête SQL. Pour des raisons de sécurité, l'accès à cette table est uniquement autorisé à SYSDBA/OWNER. Les utilisateurs non privilégiés ne voient aucune ligne dans cette table et aucune erreur n'est signalée.

Possibilité de récupérer l'identifiant de la pièce jointe et de l’instruction suivante : les compteurs représentant l'identifiant de la pièce jointe suivant et l'identifiant de l’instruction suivante sont accessibles via la Table MON$DATABASE et appel de l'API Attachment::getInfo().

Meilleur rapport d'erreur pour les commandes de gestion des utilisateurs : un message explicite concernant le mot de passe manquant est maintenant généré pour les instructions CREATE [OR ALTER] USER.

Compatibilité avec les anciennes versions

• Dépréciation de l'ancien dialecte SQL 1 : les développeurs de Firebird indiquent qu’à partir de Firebird 4, le dialecte 1 est déclaré obsolète. Son support sera supprimé à l'avenir et le dialecte 3 deviendra le seul dialecte pris en charge ;
• Cohérence de lecture pour les transactions READ COMMITTED utilisées par défaut : Firebird 4 introduit non seulement la cohérence de lecture pour les déclarations dans les transactions validées en lecture, mais en fait également un mode par défaut pour toutes les transactions READ COMMITTED, indépendamment des propriétés RECORD VERSION ou NO RECORD VERSION ;
• Dépréciation des fonctions externes définies par l'utilisateur (UDF) : les fonctions externes (UDF) sont obsolètes et ne sont plus prises en charge dans Firebird 4. Les UDF ne peuvent plus être utilisées avec la configuration par défaut, où le paramètre UdfAccess dans firebird.conf est réglé sur None et les librairies UDF ib_udf et fbudf sont retirées de la distribution ;
• Changements dans les DDL et DML : la prise en charge des fuseaux horaires introduit certains changements dans les DDL (Data Definition Language ou langage de définition de données) et DML (Data Manipulation Language ou langage de manipulation de données) qui pourraient affecter la compatibilité avec les bases de données et les applications existantes ;
• Modification des types de données TIMESTAMP et TIME : la syntaxe pour déclarer les types de données TIMESTAMP et TIME a été étendue pour inclure des arguments définir si la colonne, le domaine, le paramètre ou la variable doivent être définis avec ou sans les ajustements de fuseau horaire, c'est-à-dire : TIME [ { WITHOUT | WITH } TIME ZONE ], TIMESTAMP [ { WITHOUT | WITH } TIME ZONE ]. Dans les deux cas, la valeur par défaut est WITHOUT TIME ZONE ;
• Valeur de départ des séquences : avant Firebird 4.0, une séquence était créée avec sa valeur en cours fixée à sa valeur de départ (ou zéro par défaut). Maintenant, une séquence est créée avec sa valeur en cours définie sur sa valeur de départ moins l’incrément.

Corrections de bogues

Voici quelques corrections de bogues qui ont été apportées depuis la version bêta 2 :

• fuite de mémoire lors de l'exécution de EXECUTE STATEMENT avec des paramètres nommés ;
• ordre d'octet erroné pour les UUID déclarés par le GSTAT et les tables de suivi ;
• le plugin Srp maintient la connexion après la suppression de la base de données pendant environ 10 secondes ;
• les espaces comme séparateur de date entraînent une erreur de conversion ;
• le paramètre dans les fonctions LAG, LEAD, NTH_VALUE nécessite un cast explicite en BIGINT ou INTEGER ;
• la troncature des chaînes de caractères à mettre dans les tables MON$ ne fonctionne pas correctement ;
• le jeu de caractères est utilisé et la valeur par défaut est plus longue que la longueur de la colonne ;
• l'erreur "expected length N, actual M" contient une valeur incorrecte de M lorsque le jeu de caractères UTF-8 est utilisé dans la déclaration de champ.

Selon les auteurs de cette note, les versions admissibles sont généralement considérées comme suffisamment stables et peuvent être recommandées pour des tests dans des environnements proches des environnements de production. Les responsables du projet open source Firebird invitent les utilisateurs à faire des tests et à partager leur retour d'expérience dans les listes de diffusion.

Source : Firebird

Et vous ?

Utilisez-vous le SGBDR open source Firebird ?

Que pensez-vous des améliorations apportées au SGBDR Firebird ?

Voir aussi

Firebird 4.0 : la première version Alpha est disponible pour les tests, quelles sont les fonctionnalités de la prochaine version majeure du SGBDR ?

La Bêta 1 du SGBDR Firebird 4.0 est disponible pour les tests, toutes les fonctionnalités obligatoires pour cette version majeure sont finalisées

La version 3.0 du SGBDR open source Firebird disponible : architecture unifiée et support amélioré pour SMP et les plateformes multicœurs

France : quels sont les logiciels libres que l'État recommande en 2019 ? La liste des logiciels conseillés publiée officiellement avec le SILL 2019

[Delphiste]

Firebird n'a qu'un défaut, se faire désinstaller à chaque mise à jour majeur de Windows 10.

[SergioMaster]

Firebird n'a qu'un défaut, se faire désinstaller à chaque mise à jour majeure de Windows 10.

J'ai un w10 depuis sa sortie ou presque, j'ai même changé d'un version Home à une version entreprise, Firebird n'a jamais été désinstallé par une mise à jour de W10 et dieu sait que j'en ai subi

[Delphiste]

Ah bon ? Pour moi et nos clients c'est systématique, à chaque mise à jour.
Firebird est installé comment, par l'installateur Firebird en tant que service, qu'application, ou c'est une installation "maison" ?

[SergioMaster]

Via l'installateur, le superclassique, en tant que service

[Artemus24]

Salut à tous.

Firebird n'a qu'un défaut, se faire désinstaller à chaque mise à jour majeur de Windows 10.

Es tu certain de cela ?
Car j'ai firebird sur mon ordinateur windows 10, et il ne s'est jamais désinstallé durant une mise à jour de windows.

@+

[Sandra Coret]

Firebird 4.0, la dernière version majeure de la base de données relationnelle Firebird, est disponible

Le projet Firebird est heureux d'annoncer la disponibilité générale de Firebird 4.0 – la dernière version majeure de la base de données relationnelle Firebird.

Pour rappel, Firebird est un fork open source d'Interbase, la base de données serveur SQL de Borland acquise suite à l'acquisition d'Ashton-Tate, l'éditeur de dBase.
Firebird se positionne un peu dans son offre comme PosgreSQL, mais sans avoir autant de notoriété. Le plus gros des utilisateurs d'Interbase ou de Firebird sont généralement des développeurs Delphi.

Firebird 4.0 introduit de nouveaux types de données et de nombreuses améliorations sans changer radicalement l'architecture ou le fonctionnement. Les plus importantes sont :

• Réplication logique intégrée ;
  
• Longueur étendue des identifiants de métadonnées (jusqu'à 63 caractères) ;
  
• Nouveaux types de données INT128 et DECFLOAT, précision accrue pour les types de données NUMERIC/DECIMAL ;
  
• Prise en charge des fuseaux horaires internationaux ;
  
• Délais d'attente configurables pour les connexions et les déclarations ;
  
• Mise en commun des connexions externes ;
  
• Opérations par lots dans l'API ;
  
• Fonctions cryptographiques intégrées ;
  
• Nouvel ODS (version 13) avec de nouvelles tables système et de surveillance ;
  
• Taille maximale des pages augmentée à 32KB.
  

Consultez les notes de mise à jour pour obtenir la liste complète des modifications

La référence complète du langage est également disponible.

Des kits binaires pour les plateformes Windows, Linux et Android (32 et 64 bits) sont immédiatement disponibles en téléchargement.

Source : Firebirdsql

Et vous ?

Qu'en pensez-vous ?
Pourquoi avez-vous fait le choix de Firebird au lieu d'une autre base de données, par exemple PostgreSQL ?

Voir aussi :

La première version admissible de Firebird 4.0 est disponible avec la syntaxe du SQL standard pour les décalages de fuseau horaire, et des corrections de bogues

[Invité]

Plusieurs de nos clients avaient des problèmes avec SQL Server Express, au comportement erratique. On leur a proposé une migration de leurs outils vers Firebird, et ils en sont très satisfaits.

[Pierre Louis Chevalier]

Le gros avantage de Firebird, en sus de sa gratuité, c'est qu'il est assez "léger" pour être distribué facilement avec des applications, et que d'autre part il ne demande pas spécialement de maintenance.

Donc très bien en base de donnée embarquée dans des applications.

[SergioMaster]

De mon côté, je suis en train de tester la version Firebird 4.0 pour Android suivant cet article
https://sourceforge.net/p/zeoslib/wi...0on%20Android/
malheureusement je bute à la connection , un problème de déploiement probable

@Pierre Louis Chevalier Il y a aussi le fait que ce soit un vrai open source, c'est loin d'être négligeable