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.

[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

[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 +

[alassanediakite]

Salut
Ce que tu qualifie de sauvegarde binaire n'est qu'une subterfuge visant faire une copie des fichiers de la base par le moteur.
Certes cette copie par le moteur est censé être plus efficace: moins d'outils à utiliser, moins de tâche par l'administrateur, moins de risque de fausse manip, une sauvegarde plus sûr.
A mon humble avis, le jour où PostgreSQL pourra gérer les journaux de transactions par base (et non par instance) les sauvegardes se faciliterons d'avantage.
@+

[SQLpro]

Salut
Ce que tu qualifie de sauvegarde binaire n'est qu'une subterfuge visant faire une copie des fichiers de la base par le moteur.

Absolument pas... Je voit que tu ne connais pas le fonctionnement d'une sauvegarde binaire....

Certes cette copie par le moteur est censé être plus efficace: moins d'outils à utiliser, moins de tâche par l'administrateur, moins de risque de fausse manip, une sauvegarde plus sûr.
A mon humble avis, le jour où PostgreSQL pourra gérer les journaux de transactions par base (et non par instance) les sauvegardes se faciliterons d'avantage.
@+

C'est bien un problème et une des limites majeures de PG....

A +

[alassanediakite]

Salut
Dans le monde de l'informatique on ne connait que deux types de fichiers: binaire et texte.
Un dump sql est un fichier texte. Les fichiers de la base sont en binaire. Une copie des fichiers (par pages ou blocs c'est pareil) est une copie binaire.

[FOCUS77]

Bonjour à tous,

J'utilisais deux versions firebird :2.5.7 32bits / 2.5.6 64bits,
pour faire tourner mon application conçu avec lazarus sur mon PC(W7 64bits) et sur d'éventuels PCs.

J'hésitais toujours à les remplacer par la ver:3.0 (car une fois je n'ai pas réussi à l'installer)
je me suis dit quelle est l'utilité de remplacer une version FB par une autre du moment qu'elle fonctionne?

Mais aujourd'hui j'ai installé la ver:4.0 32bits et restauré ma BDD.

Avant:

1.Phase conception: quand j'exécutais le fichier source, puis je ferme l'exécutable un message d'erreur apparaît.

2.Phase exécution: dès fois j'étais obligé de cliquer plusieurs fois sur l'application pour qu'elle s'ouvre
et sur le gestionnaire des tâches/processus il ya ouverture de plusieurs instances de l'application,
et dès fois j'étais obligé de passer par cet outil pour fermer ces instances.

Mais avec la ver:4.0 et après une multitude d'essais...

plus de plantages, plus de messages d'erreurs et plus d'anomalies c'est parfait!

Cela est dû sûrement au progrès, et à la correction de bugs dont connait la ver:4.0

merci à l'équipe FireBird.
et merci de votre interrêt.

[freud]

Bonsoir tout le monde,

plus de plantages, plus de messages d'erreurs et plus d'anomalies c'est parfait!
Cela est dû sûrement au progrès, et à la correction de bugs dont connait la ver:4.0

Et vous utilisez la version 4 en mode production ?

[FOCUS77]

Bonsoir à tous,

Et vous utilisez la version 4 en mode production ?

Oui, depuis quelques mois et pour le moment je n'ai rencontré aucun problème.

[freud]

Bonjour,

Merci pour l'info FOCUS77
A propos, tu n'utilise pas par hasard les compos d'UIB avec FB4 ?

[FOCUS77]

Bonsoir,

A propos, tu n'utilise pas par hasard les compos d'UIB avec FB4 ?

Je développe avec Lazarus1.8 et j'utilise les composants natifs de firebird.

Je confirme qu'il y'a une nette différence entre la version FireBird 4.0 et les versions précédences.
Avec cette version plus de plantages, c'est comme si elle fonctionne dans un environnement indépendant au imperfections du système d'exploitation.
bien sûr je ne peux pas expliquer ça, je l'ai remarqué seulement.

[freud]

bien sûr je ne peux pas expliquer ça, je l'ai remarqué seulement.

Ah oui y a l'intuition qui jour aussi

En tout cas merci pour les infos.

[SergioMaster]

Je développe avec Lazarus1.8 et j'utilise les composants natifs de firebird.

Qu'est-ce que vous entendez par composants natifs de Firebird ? à ma connaissance la bibliothèque des API est en C

[FOCUS77]

Bonjour,

Qu'est-ce que vous entendez par composants natifs de Firebird ? à ma connaissance la bibliothèque des API est en C

Je ne sais pas comment dois-je appeler ça, mais j'utilise:
SqlQuery, IBConnection, SqlTransaction de Lazarus.

[SergioMaster]

Bonjour,

donc ce ne sont pas des composants "natifs" firebird mais tout simplement ceux proposés avec lazarus (et à mon avis pas de toute première jeunesse puisque compatibles Interbase !)

Je confirme qu'il y'a une nette différence entre la version FireBird 4.0 et les versions précédences.

je crains que cette confirmation soit plus qu'empirique.
Si je compare les releases notes ce qu'il eut été intéressant de vérifier ce sont les points forts commencé avec Firebird 3 et amélioré avec Firebird 4 comme les fonctions de fenêtrage
ou les nouveautés plus intrinsèques de firebird 4 concernant les rôles et les temps limités des transactions.

Avec cette version plus de plantages, c'est comme si elle fonctionne dans un environnement indépendant aux imperfections du système d'exploitation

quels "types de plantages", des exemples ?

[FOCUS77]

Bonsoir à tous,

quels "types de plantages", des exemples ?

voici un message d'erreurs apparaît avec Firebird 2.5.7 32b, à la fermeture de l'application.
Il est à noter que ce messages n’apparait pas à chaque fois, mais avec le tempérament de FireBird 2.5.7