Version imprimable
Les identifiants SQL ne doivent pas être de plus de 128 caractères parce qu'ils sont en VARCHAR. Cela signifie donc que le type de données de l'identifiant doit bien être du VARCHAR(128).Citation:
Envoyé par SergioMaster
Remarque, Oracle vient de faire passer ses identifiant SQL limités à 30 a 128 dans la version 12c... Enfin !
A +
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.
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.
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 :weird:, 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
Ah ben zut alors.. j'espérais macOS pour être 100% cross-platform.
J'espère que ce n'est qu'une question de temps.
25 ans d'expérience en SQL, je pratique Firebird depuis sa 1ère version et avant, j'ai connu Interbase 6.0
Ayant pratiqué DB2 sur MVS, DB2UDB, Oracle, SQL Serveur, MySQL, Interbase, Firebird et PostGre
Excepté en cas de très gros volumes de données , ma préférence va et de loin à Firebird.
Firebird s'installe en 5 minutes, une configuration "pointue" est rarement nécessaire et si elle l'est elle se fait aisément.
FireBird et Interbase disposent des procédures stockées depuis très très longtemps, bien avant MySQL.
Il est impossible sur Firebird de créer une procédure stockée contenant une erreur SQL (un colonne absente d'une table).
Il est impossible sur Firebird de supprimer par erreur un objet référencé par un autre.
Un backup est rapide , une restauration, tout autant.
J'ai pu comparer les performances sur un même soft entre une version sur MySQL et une version sur Firebird avec les mêmes tables, les mêmes indexes : Firebird l'emporte haut la main jusque des volumes importants avant de se faire dépasser.
Firebird/Interbase est SQL-COMPLIANT a presque 100% : pas de fonctions ou codes "spécifique" qui ne soit pas portable sur un autre SGBD.
Et pour couronner le tout, nous avons des applications qui utilisent des procédures stockées en cascade pour les mise à jour développées initialement sous Firebird 1.0.
La base de données a été migrée au fur et à mesure (aujourd'hui en Firebird 3.4) par un simple backup/restore et aucune modification de code n'a été nécessaire !
En 20 ans d'exploitation 7/7, H24 de dizaines de base de données clientes sous Firebird, nous n'avons jamais connus aucune altération de données !
Et ce, malgré de grosses migrations (d'OS, de version d'OS, de version de Firebird etc...)
Alors que la migration de MySQL 5.6 aux suivantes a été un enfer. Qu'aujourd'hui, une installation form sratch de MySQL et sa configuration n'a rien d'évident et cela change presque à chaque version. Par défaut, une petite base de données MySQL nous fait un processus qui squatte 1Go de RAM (sauf à configurer finement MySQL) tandis que sur Firebird, le process occupe 10 fois moins de mémoire !
Et parlons des outils : MySQL Workbench est une vrai usine à bugs inutilisable sans écran Full HD (des boutons essentiels sont cachés en faible résolution). Alors que Flamerobin ou EMS Firebird font très bien le job sans bugs. Pire, ils contiennent par défaut les outils affichant les dépendances des objects DDL ce que MySQL ne sait pas faire !!! Il faut faire une requête à la main !
Evidement il y a DB2 ou Oracle et Embarcadero Rapid SQL mais là, c'est un autre monde où le ticket d'entrée n'est pas donné pour une PME/TPE.
Je ne reproche que 3 choses à Firebird :
- le peu de fonctions internes disponibles (compensées par la possibilité de développer des fonctions externes en C ou en Pascal)
- les difficultés à débuguer les fonctions externes qu'on a personnalisé.
- le fait que la base de données des utilisateurs soit centralisée.
Bonjour
Totalement d'accord avec toi sauf peut-être pour certains reproches
La version 4 à largement augmenté le panel, à tel point qu'il n'est plus recommandé d'utiliser les UDF . Je trouve un peu "arbitraire" cette recommendation, surtout que les fonctions internes proposées ne couvre peut-être pas forcément tout les besoins. D'un autre côté, une modification dans firebird.conf et les UDF sont à nouveau disponibles, à nous de bien faire attention aux fonctions internes existantes pour ne pas faire du double emploi.Citation:
Envoyé par Christ D
ça, hélas, ce sera toujours le cas. Déjà que le debogage d'une procédure n'est pas vraiment prévu ...Citation:
Envoyé par Christ D
Heu, depuis FB3 la partie sécurité peut être incluse dans la BDD et pas dans la base de données de sécurité (securityx.fdb), ou alors j'ai mal compris le reproche ?Citation:
Envoyé par Christ D
jusqu'à 32 TB quand même, même si je pense que les performances doivent drastiquement chuté pour un volume pareil !Citation:
Excepté en cas de très gros volumes de données
quel est, selon toi, la taille à ne pas dépasser ?
Bonjour,
Exite-t-il nativement des outils de maintenance des bases de données FIREBIRD comme il en existe sur SQL SERVER ou Oracle ?
J'attends par maintenance :
- défragmentation et reconstruction des indexes
- mise à jour des statistiques,
- sauvegarde et restauration,
- purge journaux,
- contrôle d'intégrité
- planification des travaux de maintenance
- shrink base de données
Merci pour votre aide,
Eric
Bonjour et bienvenue,
à part pour la planification de maintenance (je parle des backups, et encore existe-t-il nbackup qui est en quelque sorte une planification) la réponse est oui à tout.
N.B. la version 5 déjà en release apporte peut-être des améliorations, j'avoue ne pas avoir regardé
Merci pour la réponse. Vous me rassurez car quand un éditeur me répond que la maintenance consiste à faire un backup de la base de production et la restaurer sur ce même serveur pour faire de la reconstruction d'indexes par exemple me semblait un peu léger pour un simple DBA que j'étais ...
Votre éditeur à raison car c'est le minimum requis pour avoir une réorganisation et une optimisation de votre base de données.