Sortie du SGBD Firebird en version 1.0 finale

Posté par  (site web personnel) . Modéré par Benoît Sibaud.
Étiquettes : aucune
0
25
avr.
2002
Technologie
Firebird est une base de données relationnelle implémentant en grande partie la norme ANSI SQL-92. Il fonctionne sur Linux, Windows, MacOS-X et une variété de plateformes d'Unix (Solaris,*BSD, etc..).

Le projet Firebird a en fait le but, d'étendre et d'améliorer les sources d'Interbase 6 fournis par Borland.
Interbase a été employé dans des systèmes de production, sous une variété de noms depuis 1981.

C'est un SGBD très intéressant, complet, fiable et assez simple d'utilisation, à essayer si votre base de donnée PostgreSQL vient encore de corrompre ses indexes :)

Note du modérateur : disponible sous licence « Interbase Public License », une variante de la « Mozilla Public License ». L'avis du rédacteur sur PostgreSQL n'engage que lui, et de toute façon il a largement le choix en SGBD libres.

Aller plus loin

  • # Justement...

    Posté par  (site web personnel) . Évalué à 10.

    Merci pour cet article qui intervient le lendemain d'une interrogation (légère) au sujet du devenir d'interbase depuis que ce SGBD était passé dans le domaine du libre...

    Je pense que je vais migrer doucement mes site de MySQL/PostgreSQL vers Firebird si celui-ci s'avère assi prometteur que prévu.
    • [^] # Re: Justement...

      Posté par  . Évalué à 6.

      Si c'est une MPL (sans double licence), ce n'est pas aussi libre que MySQL / pgSQL...
      • [^] # Re: Justement...

        Posté par  (site web personnel) . Évalué à 6.

        En précisant un peu... j'ai du mal à comprendre "sans double licence"... et comme je suis pas le meilleur lecteur de licence (j'ai du mal avec les aspect purement juridiques, je l'avoue :cb)...
        Si tu pouvais m'en dire plus... ce serait sympa. Sinon, comme on dit si bien : RTFM... je me pencherais sur le texte officiel.

        ----------------------------------------------
        NO PASARAN! Le 5 mai votez escroc, pas facho!
        ----------------------------------------------
        • [^] # Re: Justement...

          Posté par  . Évalué à -10.

          (hors sujet)

          "Le 5 mai votez escroc, pas facho!"

          Pas très malin ce genre de slogan, c'est comme ça qu'on apporte de l'eau au moulin de Le Pen, qui se prétend "propre" (ce qui est faux bien entendu) et les autres pourris.
          De plus Le Pen est intéressé par l'argent, ce qui n'est pas le cas de Chirac (même s'il a un rapport à l'argent pas toujours parfait). Le Pen a été condamné (entre autres) pour captation d'héritage.
        • [^] # Re: Justement...

          Posté par  . Évalué à 2.

          Certains logiciels sont publiés sous une double licence. GPL + MPL... MPL tout court, c'est très limitatif. Mozilla est en triple licence GPL/LGPL/MPL.

          Pour ton slogan final, pour ma part je ne prendrais qu'un petit papier avant d'entrer dans l'isoloir. Nous avons en effet affaire à deux escrocs mais l'un des deux est anti-démocratique, et si nous devons passer à une VIème république, autant que cela soit fait par des républicains.
          • [^] # Re: Justement...

            Posté par  (site web personnel) . Évalué à -1.

            (Hors sujet)

            Tout à fait d'accord, j'avoue avoir collé cette remarque un peu vite... c vrai que les deux sont des escrocs... ce qui ne n'arrange pas l'effet de flou.

            Pour la correction, je vais le faire plus clair :
            Le 5 mai 2002, voter Mr. Chirac, au risque de vous sentir pas super bien dans vos pompes au moment de mettre l'enveloppe dans l'urne... Ne votez pas Mr. Le Pen... juste pour garder un espoir de voir les hommes considérés en tant que tels... histoire de garder ce concept de démocratie qui, même s'il n'est pas parfait, semble être le meilleur inventé pour le moment.

            Voilà, c un peu long... mais bon... ;c)
            Allez, au 5 mai ! :cb

            BeTa
            • [^] # Re: Justement...

              Posté par  . Évalué à -2.

              (hors-sujet toujours mais j'ai des commentaires "en-sujet" ailleurs pour compenser ;-)
              (vu la période électorale, je me permets pour une fois de revenir sur le sujet)

              Waou, j'ai eu 10 votes et 10 "-1" à mon message d'hier 15:09 (celui où je te faisais ma remarque) ! J'ai comme l'impression que Chirac est mal vu ici :-/ (je dis ça l'air naïf mais ça ne me surprend pas...) Pourtant j'y tenais des propos tout à fait modérés et je n'ai pas parlé d'idéologie.

              Je prends bonne note de ta correction, mais c'est dommage, tu en remets quand même une couche : "c vrai que les deux sont des escrocs"...
              "escroc", le mot est fort quand même.

              Sans parler des opinions politiques, j'aimerais savoir en quoi Chirac est un escroc ? Surtout que les histoires où on aimerait avoir son témoignage ne concernent pas un enrichissement personnel mais un financement de parti, et là il n'est pas le seul, tous les camps politiques sont touchés. Ce n'est pas parce que les Guignols, à force de tout caricaturer/simplifier, de marteler que Chirac est un "escroc", qu'il faut gober ça sans réfléchir.
              Attention, je n'ai pas dit que Chirac n'avait rien à se reprocher (note très personnelle : je n'ai pas voté pour lui au 1er tour)
            • [^] # Re: Justement...

              Posté par  . Évalué à -1.

              voter Mr. Chirac, au risque de vous sentir pas super bien dans vos pompes au moment de mettre l'enveloppe dans l'urne...
              Il ne parait pas forcément évident à tout le monde que voter pour un autre parti politique que le PS soit de nature à "se rendre malade".

              (Hors sujet)

              Je crois en effet que tes convictions politiques n'ont rien à faire ici !
              • [^] # Re: Justement...

                Posté par  . Évalué à 1.

                Il ne parait pas forcément évident à tout le monde que voter pour un autre parti politique que le PS soit de nature à "se rendre malade".

                C'est ce que je me disais aussi, on est au moins 2 ! :-)

                En fait on est beaucoup plus vu que 84 % des votants ont choisi autrement dimanche dernier...

                PS: je sens que je vais encore perdre quelques XP avec ce commentaire ;-)
                PPS: Ca me déçoit quand même parce que je ne mets pas "-1" à ceux qui n'ont pas les mêmes opinions que moi. D'ailleurs je mets rarement "-1".
                • [^] # Re: Justement...

                  Posté par  . Évalué à -1.

                  En tout cas tout le monde est d'accord pour dire que la politique n'a rien a faire ici.
                  • [^] # Re: Justement...

                    Posté par  (site web personnel) . Évalué à -2.

                    C vrai que ça commence à faire bcp ici...

                    Cependant, tu ne peux pas parler d'une voix "universelle" quand ton jugement ne l'est pas. Pour te donner un exemple, le sondage fait sur ce site [ http://www.linuxfr.org/poll/index.php3(...) ] demandant afin de déterminer si un nouveau logo poussant au vote serait le bienvenu... 5% des votant répondent non la question "Nouveau logo ?
                    Un logo qui pousse à aller voter ?"... ceux là, on les laisse de côté... 45% ne veulent pas de politique sur LinuxFr contre 50% qui sont pour.

                    Je suis désolé d'avoir à le dénoncer mais tu ne peux pas considérer un avis comme universel lorsque 50% des personnes n'ont pas le même que toi. (S'il n'y avait ne serait-ce que 5%, ça serait presque pareil !)

                    [-1 pour avoir continué le débat]
  • # indexes corrompus ?

    Posté par  . Évalué à 10.

    à essayer si votre base de donnée PostgreSQL vient encore de corrompre ses indexes :)

    heu nous on en fait tourner plusieurs des bases postrgesql ça et là, mais on a jamais eu de problèmes... ceux qui en rencontrés c'était avec quelle versions, quel OS avec quel système de fichiers, au bout de combien de temps ????
    • [^] # Re: indexes corrompus ?

      Posté par  (site web personnel) . Évalué à 0.

      sature la partoche ou tu as tes datas : BOOOM
      • [^] # Re: indexes corrompus ?

        Posté par  (site web personnel) . Évalué à -7.

        C'etait juste un trait d'humour, j'utilise postgreSQL aussi :)
      • [^] # Re: indexes corrompus ?

        Posté par  . Évalué à 10.

        sature la partoche ou tu as tes datas : BOOOM

        Tu devrais préciser, ainsi que le demandait "anonyme512", de quelle version de Postgres il s'agit, et éventuellement la version de l'OS, et le système de fichiers utilisé.

        C'etait juste un trait d'humour, j'utilise postgreSQL aussi :)

        Vas-y mollo avec ce genre d'humour parce que j'utilise moi aussi Postgres et je préfère savoir si c'est un problème qui peut arriver vraiment et sous quelles conditions, ou non.
        J'ai déjà saturé (avec pgbench d'ailleurs) la partition sur laquelle je faisais tourner Postgres, partition qui contenait une vingtaine de bases, et à ma connaissance les index ont tenu le coup. Le programme (pgbench) qui remplissait la base s'est arrêté comme un grand en erreur.

        J'aimerais savoir ce qu'il se passe avec d'autres bases, quand on sature la partition sur laquelle ça tourne.
        • [^] # Re: indexes corrompus ?

          Posté par  (site web personnel) . Évalué à -1.

          c'est un prob super connu, si l'espace du HD est starué la base explose
          sur toutes les versions de postgres
          • [^] # Re: indexes corrompus ?

            Posté par  . Évalué à 8.

            J'utilise PostgreSQL depuis 1998, j'ai eu chroniquement des problèmes d'espace disque, et je n'ai jamais eu besoin d'aller chercher les données dans mes sauvegardes.

            Trouve-t'on quelque part des comparatifs de fonctionnalités de ces différentes bases ?
            • [^] # Re: indexes corrompus ?

              Posté par  (site web personnel) . Évalué à 6.

              Désolé tu te trompe :


              13.1. Disk Filled

              A filled data disk may result in subsequent corruption of database indexes, but not of the fundamental data tables. If the WAL files are on the same disk (as is the case for a default configuration) then a filled disk during database initialization may result in corrupted or incomplete WAL files. This failure condition is detected and the database will refuse to start up. You must free up additional space on the disk (or move the WAL area to another disk; see Section 11.3) and then restart the postmaster to recover from this condition.


              c'est pas mois c'est la doc de postgres : www.postgresql.org/idocs/index.php?failu
              • [^] # Re: indexes corrompus ?

                Posté par  . Évalué à 5.

                Merci d'avoir fait la recherche dans la doc.

                Que dit la doc dans le cas de saturation :

                1. Que les données ne sont pas corrompus
                2. Que les indexes deviennent faux
                3. Que la base refuse de re-démarrer tant qu'il n'y a pas suffisement de place pour reconstruire correctement les indexes (ce qui est logique)

                Donc il n'y a pas de perte de données, il suffit de libérer suffisement de place pour repartir.
                • [^] # Re: indexes corrompus ?

                  Posté par  (site web personnel) . Évalué à 0.

                  oui mais c'est pas systématique, si tu as le cache en ecriture activé tu a de bonne chance de pas pouvoir repartir, enfin c'est pas si grave que ca :)
                  • [^] # Re: indexes corrompus ?

                    Posté par  . Évalué à 2.

                    C'est effectivement pas très grave, activer un cache en écriture sur une base de donnée ne mérite qu'une chose: la porte.

                    Le principe d'une base de donnée, c'est de valider des transactions, si la base réponds OK lorsqu'on fait un COMMIT, alors on a l'assurance que les données sont effectivement sur le disque, si on veut bricoler, c'est possible, mais il ne faut pas s'étonner ensuite si ça ne se passe pas bien.

                    La recherche de performances est moins importante que l'intégrité des données.
                    • [^] # Re: indexes corrompus ?

                      Posté par  (site web personnel) . Évalué à 4.

                      ne pas mettre la cache en ecriture reduit les perf par ~10
                      l'integrité est conservé, sauf crash hard/soft

                      si tu a un serveur stable c'est plutot conseillé ( par ex: interbase l'active par defaut sous unix mais pas sous NT .. ils sont pas fou)

                      tu l'active pas si tu n'as pas d'onduleur ou un serveur à gros risque

                      enfin dire que ne pas l'activer c'est 'la porte' c'est tres pretencieux et montre bien que tu sais pas de quoi tu parle :




                      FSYNC (boolean)


                      If this option is on, the PostgreSQL backend will use the fsync() system call in several places to make sure that updates are physically written to disk and do not hang around in the kernel buffer cache. This increases the chance by a large amount that a database installation will still be usable after an operating system or hardware crash. (Crashes of the database server itself do not affect this consideration.)

                      However, this operation slows down PostgreSQL, because at all those points it has to block and wait for the operating system to flush the buffers. Without fsync, the operating system is allowed to do its best in buffering, sorting, and delaying writes, which can make for a considerable performance increase. However, if the system crashes, the results of the last few committed transactions may be lost in part or whole; in the worst case, unrecoverable data corruption may occur.

                      This option is the subject of an eternal debate in the PostgreSQL user and developer communities. Some always leave it off, some turn it off only for bulk loads, where there is a clear restart point if something goes wrong, some leave it on just to be on the safe side. Because it is the safe side, on is also the default. If you trust your operating system, your hardware, and your utility company (or better your UPS), you might want to disable fsync.

                      It should be noted that the performance penalty from doing fsyncs is considerably less in PostgreSQL version 7.1 than it was in prior releases. If you previously suppressed fsyncs because of performance problems, you may wish to reconsider your choice.


                      en gros je prend le risque de revenir a un backup d'au max vieux d'une heure si j'ai un crash HARD vraiment mechant pendant une ecriture
                      et je gange ~10x de perf en ecriture en contrepartie.

                      Ce n'est pas un choix idiot, juste savoir etudier un risque.
                      • [^] # Re: indexes corrompus ?

                        Posté par  (site web personnel) . Évalué à -1.

                        sauf que le risque n'est pas le meme avec postgres puisque ca une implcation (apparement) lors de la saturation de l'espace.

                        m'enfin c'est mon serveur qui explose si j'active FSYNC :(
          • [^] # Re: indexes corrompus ?

            Posté par  . Évalué à 4.

            c'est un prob super connu, si l'espace du HD est saturé la base explose sur toutes les versions de postgres

            C'est fort cette histoire, ils ne vérifient pas les valeurs de retour de write() ou quoi ?!
            Si c'est connu depuis longtemps ça ne devrait pas être dur à corriger quand même...
            • [^] # Re: indexes corrompus ?

              Posté par  (site web personnel) . Évalué à -1.

              je sais pas pourquoi, ca doit etre un choix au niveau perf

              faut que je demande un jour sur la mailling liste par curiosité mais bon je pense pas que ca soit un prob de mauvaise volonté
          • [^] # Re: indexes corrompus ?

            Posté par  (site web personnel) . Évalué à 10.

            La critique que tu fais de PostgreSQL m'indigne sur plusieurs points

            * Le pb d'index corrompus

            Tu ne précises pas la version de PostgreSQL ni les détails de la machine sur laquelle ce problème peut intervenir. J'aimerais que tu nous précise tout cela. Je me demande aussi si tu as personnellement eu ce problème, ou si tu relates juste cela comme ça...

            D'ailleurs, qui a eu ce problème, et en quelles circonstances?...

            En 3 années d'utilisation intensive de PostgreSQL, cela ne m'est jamais arrivé personnellement. Pas meme chez les clients ou j'installe et administre les bases PG.

            * la partoche remplie: boom Pg explose

            C'est complètement faux. PostgreSQL s'arrête tout simplement. Il faut alors déplacer les fichiers de la bdd et la restarter, un processus de recovery se met alors en marche et remet les choses d'aplomb...

            * la partoche remplie:

            AMHA, si tu en arrives là c'est que tu ne sais pas administrer une base de données. Le manque d'espace disque est néfaste à tout système de base de données pas seulement PostgreSQL. Quand cela arrive, c'est caractéristique d'une installation non pensée à l'avance et surtout pas suivie comme il se doit.

            J'aurais aimé avoir donc l'avis d'un vrai DBA sur Firebird, plutot que le tien.

            * Interbase Public License

            Tu parles d'une license! Pas la peine de rajouter à ce qui est dit dans les autres commentaires que ton post malheureux a suscité...

            Du bon FUD en gros, et un total irrespect des contributeurs PG qui font un travail formidable et qui ont fait tant évoluer PG ces deux dernières années.
            • [^] # Re: indexes corrompus ?

              Posté par  (site web personnel) . Évalué à 0.

              oula on se calme

              les 2 produit sont biens ca depend des gouts

              postgresql a des chti prob de de faillure quand la place est pleinne :




              13.1. Disk Filled

              A filled data disk may result in subsequent corruption of database indexes, but not of the fundamental data tables. If the WAL files are on the same disk (as is the case for a default configuration) then a filled disk during database initialization may result in corrupted or incomplete WAL files. This failure condition is detected and the database will refuse to start up. You must free up additional space on the disk (or move the WAL area to another disk; see Section 11.3) and then restart the postmaster to recover from this condition.



              c'est pas mois c'est la doc de postgres : http://www.postgresql.org/idocs/index.php?failure.html(...)

              postgres a ses defauts et ses qualités, l'equipe de dev de postgres est tres claire sur les petit prob de postgres (c'est comme pour les vaccums)
              Firebird c'est pas la pannacée non plus

              c'est la vie

              et puis avant de crier au FUD tu aurais mieux fais d'ouvrir la doc de postgres...


              pour le :

              AMHA, si tu en arrives là c'est que tu ne sais pas administrer une base de données. Le manque d'espace disque est néfaste à tout système de base de données pas seulement PostgreSQL. Quand cela arrive, c'est caractéristique d'une installation non pensée à l'avance et surtout pas suivie comme il se doit.


              ca arrive tres souvent de remplire une base (bug dans un generateur qui par en boucle, un mauvais dimensionnement, etc..)

              oracle par exemple d'envoie un paquet de message d'erruer se met a rammer mais ne s'arrete pas comme le fait postgres, tes donnée sont consultable mais des insert ne marche pas, tes update ramme ou partent en erreur.
            • [^] # Re: indexes corrompus ?

              Posté par  (site web personnel) . Évalué à -1.

              le truc vicieux est que le recover ne marche pas systematiquement
              ca me le fait un coup sur trois
              j'ai mis à jour le kernel & postgres plusieur fois c'est toujours pareil.

              j'ai fais des test ca ne le fait pas si on desasctive le cache en ecriture

              enfin je fais gaffe c'est pas la mort :)
              j'ai une copie de la base qui a explosé si vous voulez ca doit faire 1G / 200M zippé (à la louche)
    • [^] # Re: indexes corrompus ?

      Posté par  . Évalué à -3.

      postgres 7.1.3
      linux 2.2.19
      intel p3 500
    • [^] # Re: indexes corrompus ?

      Posté par  (site web personnel) . Évalué à 0.

      Jamais eu de problèmes avec PostgreSQL.
      Quelque soit la version du soft ou du système.
      Bref PostgreSQL roulaize !...
      J'ajoute que la qualité des softs de Borland est en baisse depuis pas mal d'années.
      • [^] # Re: indexes corrompus ?

        Posté par  (site web personnel) . Évalué à 2.

        c'est surtout qu'il n'évolue pas trop :(
        delphi c'était novateur, ca s'éssoufle un peu, ca manque de nouvautés (avis perso)

        par contre il y a un truc qui me traumatise c'est borland c'est paradox pour windows, j'ai eu que des problemes avec, d'autre personne on eu le meme genre de gout amer avec paradox (window car sous dos ca roxait :D)?
  • # Datas et fond de commerce...

    Posté par  . Évalué à 10.

    Je fais des choses avec mon ordinateur.
    Pleins de choses.
    J'ai pleins de données dans quelques bases Mysql(la pluspart) et PostgreSQL(pour voir, une seule).

    Ces 2 SGDB sont fiables, assez intensement débuggés, en développement actif, libres. En plus, Mysql est disponible chez la pluspart des hébergeurs, donc c'est tout benef.

    Le site de l'oiseau de feu, là, il dit en gros: (tiens, je me suis crû sous X, là, et justement le copier/coller au clic ne fonctionne pas, naze ce truc), en gros, disais-je:
    "Firebird is a relational database offering many ANSI SQL-92 features that runs on Linux, Windows, and a variety of Unix platforms. Firebird offers excellent concurrency, high performance, and powerful language support for stored procedures and triggers."
    Many ca veut dire certains, mais pas tous.
    High performance, ca veut dire mieux ou moins bien que les projets libres ? Faut que ca vaille la peine de porter, mon temps est pas moins précieux que celui d'un autre.


    Enfin, juste la phrase d'après, le ponpon:
    "Firebird is a commercially independent project"
    Là je dis non. J'ai assez de mes babases libres à moi que j'aime et qui fonctionnent bien, sans contribuer (par le debuggage, car je n'ai pas la disponibilité pour me plonger dans le source pour un patch, ce n'est plus mon métier) à un projet commercial qui tente de tirer la couverture du libre (et ses brillants jeunes zélés developpeurs si chers à payer à l'année, que si ils sont assez nombreusement cons pour bosser à l'oeil dans un projet commercial sans en avoir de contrepartie...), bref, qui tente de forker yet another SGBD qui révolutionne vraissemblablement rien, mais qui pourra en enrichir certains.

    Les SGBD et SGBDR libres me vont. Merci

    Cet avis considérable comme péremptoire ne regarde que moa, mais ca va mieux de le dire.
    -1 parceque c'est un jugement de valeur personnel.
    • [^] # Re: Datas et fond de commerce...

      Posté par  (site web personnel) . Évalué à 10.

      Ne pas confondre commercial et propriétaire. J'ai rappelé les licences dans la dépêche pour justement éviter cela.
      • [^] # Commercial/proprietaire

        Posté par  . Évalué à 0.

        Je ne confonds pas.
        Je pense que les exemples de passages au libre par l'adoption de la GPL existent.
        Les licenses pseudo libres m'insupportent car elles ont une nette tendance à phagocyter de l'énergie qui pourrait être dédiée à des projets GPL (surtoutsi ceux çi sont plus avancés).

        L'hypocrisie de certaines licenses me hérisse le poil.

        GPL forever.
        Gnomemeeting rulez
        • [^] # Re: Commercial/proprietaire

          Posté par  (site web personnel) . Évalué à 3.

          pseudo libre ?
          même la FSF la reconnait comme une licence libre.

          Ca n'est pas de la GPL, ca n'est pas compatible avec la GPL mais c'est libre.

          Surtout que si cette licence rajoute des contraintes sur les softs qu'on lie dynamiquement au programme, la GPL en fait autant.

          Libre ne veut pas dire GPL. La GPL est une des licence libre, pas la seule (et AMHA pas forcément la meilleure)

          Que lui reproches tu exactement ? (j'avoue que j'ai commencé à lire le résumé de gnu sur cette licence et je n'ai rien à lui reprocher, j'ai bien essayé la licence elle meme mais au premier passage j'ai des points qui sont assez flous a cause de ma compréhension de l'anglais plutot moyenne quand on sort du technique).
  • # Question de non-informaticien

    Posté par  . Évalué à 6.

    On parle de la norme ANSI SQL-92, il existe plusieurs normes SQL ?
    Si oui quels sont les différences dans les grandes lignes (suis pas informaticien moa) ?
    Quels sont les avantages/inconvénients de telle ou telle norme ?

    Juste par curiosité :-)
    • [^] # Re: Question de non-informaticien

      Posté par  . Évalué à 5.

      Ben réponse d'informaticien ?!...
      Il y a je crois les normes SQL-92, SQL-89, SQL-3 (qui sont parmis les plus connues). Si je me souviens bien, ces normes précisent entre autres les fonctionnalités que doit apporter le SGBD. Dans une norme, on trouvera la possibilité de faire un 'outer', dans une autre la notion de relationnel, etc. Je n'ai pas tous les détails, mais il doit y avoir moyen de les retrouver en cherchant avec un moteur de recherche sur le waibe. Entre nous (je veux dire, entre informaticien et non-informaticien, of course), pour l'utilisateur, ça ne change pas grand chose. Il suffit de savoir ce que tu peux faire (ou non) avec ton SGBD(R)(O) et de te débrouiller avec. De toutes façons, il me semble que pas un seul n'est à 100% conforme à l'une de ces normes. PostgreSQL (SGBDRO que j'utilise au quotidien avec plaisir) ne l'est pas par exemple. Tout est fait pour y arriver (merci l'équipe de dev), mais les extentions qu'ils rajouttent sont hors-norme (et pourtant tellement pratiques !). Voilà.
    • [^] # Re: Question de non-informaticien

      Posté par  . Évalué à 2.

      Et oui... il y a malheureusement autant de normes SQL que de SGBD existants :-(
      Chaque editeur n'en fait qu'à sa guise et j'ai malheureusement l'impression que malgré les efforts fournis (SQL 3 n'est pas sensé arranger ca ?), chacun continue de son côté...
    • [^] # Re: Question de non-informaticien

      Posté par  . Évalué à 2.

      Merci au 2 pour les réponses.

      Si j'ai bien compris (pas sure) ces normes définissent les fonctinnalités que doit supporter un SGBD et non pas le langage SQL en lui-même qui lui, pour une fonction identique sur 2 SGBD de normes différentes, aura la même syntaxe ?
      • [^] # Re: Question de non-informaticien

        Posté par  . Évalué à 5.

        C'est exactement le contraire :-)

        Chaque SQL est un peu différent d'un autre, et
        chacun y est allé de sa sauce pour ajouter une
        fonctionnalité qui lui paraissait bien mais pas
        encore définie.

        SQL-3 devrait (au conditionnel) améliorer
        sensiblement les choses, mais on n'y est pas
        encore.

        Les très grosses différences sont surtout au
        niveau DDL (Data Description Language, càd
        CREATE bidule, DROP machin, etc.) plus que sur
        les DML (Data Manipulation Language, SELECT,
        UPDATE etc.) qui eux se stabilisent.

        Les types de données et les noms de fonctions
        aussi sont assez diversifiés...

        Quand aux langages procéduraux, n'en parlons pas !

        Mes deux cents

        DBA Oracle converti à PostgeSQL :)
  • # SGBDO libre ?

    Posté par  . Évalué à 7.

    C'est un peu hors-sujet, mais je profite de la news pour soumettre une question que je me pose depuis longtemps : on a de très bonnes SGBDR, mais existe-t-il une bonne base de données objet (SGBDO) libre ?
    • [^] # Re: SGBDO libre ?

      Posté par  . Évalué à 4.

      Je ne sais pas ce que doit founir un SGBDO complet, mais postgresql comporte deja une notion d'heritage de table.

      Tu peux detailler ce que doit fournir un SGBDO complet ?
    • [^] # Re: SGBDO libre ?

      Posté par  . Évalué à 5.

      C'est pire que ça : à ma connaissance, il n'y
      avait que O2 (propriétaire) comme SGBDO méritant
      réellement ce qualificatif au monde et il a
      disparu...

      Pg a une ébauche d'objet, mais c'est encore très
      limité.

      Oracle a fait des chose, mais comme d'hab, dans
      son coin
    • [^] # Re: SGBDO libre ?

      Posté par  (site web personnel) . Évalué à 7.

      Un Système de Gestion de Base de Donnée Objet-Relationnel est sencé proposer un certain nombre de services.

      - Procédures stockées attachées à des tables
      - Héritages entre tables
      - Pointeurs d'enregistrement (permettant d'inclure un enregistrement dans un enregistrement d'une autre table dans avoir à faire de jointure).
      - Tables dans des tables (NESTED TABLE)
      - etc... le reste, j'ai un peu oublié.

      Bref, bcp de choses qui sont encore en cours de spécification. La norme sera SQL3 (normalement, je l'ai juste entendu par une source sûr, j'ai pas vérifié)...

      A côté de cela, Oracle propose des choses comme les procédures affectées à des tables, les pointeurs, les nested table... mais ne connaît pas encore l'héritage. On peut donc difficilement parler d'objet relationnel pour Oracle.

      Il me semble que DB2 (non vérifié là non plus, ce n'est pas ma spécialité) est plus avancé dans ce domaine... pour le reste, je vous laisse à vos recherches, vous vous y connaîtrez mieux que moi, sûrement ! ;c)

      D'avis personnel, je ne trouve pas que ce concept soit encore suffisament au point pour être vraiment appliqué au niveau productif. D'autant que je ne connaîs pas les performances que proposent les SGBD proposant une approche objet-relationnel.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.