ca fait plaisir

• [^]RE: ca fait plaisir

  Posté par matiasf () le 06/02/2002 à 16:56. (lien). Évalué à 20.

  Avant l'arrivee de Great Bridge, le developpement avait lieu et sans probleme et avec un haut niveau technique (trigger, language ambarque, transaction, orientation object, etc...).
  
  Pour te rassurer il y a maintenant RedHat d'assez implique dans PostgreSQL.
  
  Et pour rappel, PostgreSQL est moins populaire que MySQL mais c'est un SGBD-R de tres tres haute volee.

  • [^]Re: RE: ca fait plaisir

    Posté par Sylvain Rampacek (Jabber id, page perso, ) le 06/02/2002 à 20:07. (lien). Évalué à 19.

    Et pour rappel, PostgreSQL est moins populaire que MySQL mais c'est un SGBD-R de tres tres haute volee.
    
    ... et surtout qui permet de faire plein de choses que les versions de MySQL stables ne font pas encore (je ne sais pas des bétas).
    
    Comme par exemple les requêtes imbriquées ou encore tout ce qui est gestion des triggers (fonctions qui permettent de gérer directement et en profondeur la cohérence de la base).
    
    Bref, je qualifierai plus de SGBD-R PostgreSQL que MySQL qui lui permet juste de faire une base simple avec des clés hérités mais sans faire de réel contrôle sur celles-ci.

MySQL 4.0 ?

• [^]Re: MySQL 4.0 ?

  Posté par schyzomarijks () le 06/02/2002 à 16:48. (lien). Évalué à 4.

  le dump à chaud ??? Quelqu'un à une chtite explication svp.

  --
  OO watching you !!!

  • [^]Re: MySQL 4.0 ?

    Posté par Foxy (page perso, ) le 07/02/2002 à 10:39. (lien). Évalué à 8.

    "le dump à chaud ???"
    
    Le dump à chaud te permet de faire une backup d'un base de données (des tables en fait) sans à avoir à arrêter le SGBD.
    
    Pour l'instant, sous MySQL 3.xx, ce n'est pas possible. Il faut arrêter le SGBD, dumper la base (faire une backup des tables) et relancer le serveur :-(

    • [^]Re: MySQL 4.0 ?

      Posté par schyzomarijks () le 07/02/2002 à 10:50. (lien). Évalué à 5.

      Ah d'accord, c'est donc une sauvegarde à chaud :-)
      
      En tout cas merci pour l'explication.

      --
      OO watching you !!!

• [^]dump à chaud

  Posté par matiasf () le 06/02/2002 à 16:51. (lien). Évalué à 10.

  Le dump à chaud?
  Mais mysql n'a pas de support de transaction (uniquement sur une table a la foi) ni de support de versionning.
  
  Comment ils font ?

  • [^]Re: dump à chaud

    Posté par MagicNinja (page perso, ) le 06/02/2002 à 16:55. (lien). Évalué à 3.

    >...ni de support de versionning.
    
    euh, tu n'aurais pas un chtit exemple du cékoidonc et commentkonfait avec postgresql s'il te plait ? :-)

    • [^]doc

      Posté par matiasf () le 06/02/2002 à 17:02. (lien). Évalué à 11.

      http://www.ca.postgresql.org/users-lounge/docs/7.1/user/mvcc.html(...)
      
      Doc dump :
      http://www.ca.postgresql.org/users-lounge/docs/7.1/admin/backup.htm(...)
      
      extrait :
      > Dumps created by pg_dump are internally consistent, that is, updates to the database while pg_dump is running will not be in the dump. pg_dump does not block other operations on the database while it is working.

  • [^]Re: dump à chaud

    Posté par Foxy (page perso, ) le 07/02/2002 à 11:05. (lien). Évalué à 4.

    Justement, dans la version 4.0, ils vont inclure le support des transactions par défaut (déjà dispo dans les versions 3.23.x via le support InnoDB). Donc MySQL aura enfin des fonctionnalités plus étendues !!!

• [^]Re: MySQL 4.0 ?

  Posté par laurent Belmonte () le 06/02/2002 à 17:04. (lien). Évalué à 5.

  je pense que tu devrais laisser MySQL de cote et plutot utiliser sapdb ou postgres

  • [^]Re: MySQL 4.0 ?

    Posté par Thomas Cataldo (page perso, ) le 06/02/2002 à 17:06. (lien). Évalué à 13.

    et en plus les licenses postgres et sapdb, elles sont aux même prix que les licenses mysql :-)

  • [^]Re: MySQL 4.0 ?

    Posté par Sylvain Rampacek (Jabber id, page perso, ) le 06/02/2002 à 20:11. (lien). Évalué à 5.

    tout dépend de ce que tu veux faire...
    
    Par ce que pour gérer rapidement ses vidéos et ses CD audios, MySQL suffit amplement.

    • [^]Qui peut le + peut le - ...

      Posté par matiasf () le 06/02/2002 à 23:27. (lien). Évalué à 23.

      MySQL est largement suffisant pour des base simples et avec peu de contraintes.
      
      Cepandant, l'utilisation de PostgreSQL pour les petites bases (je ne parle pas de taille) n'est pas plus compliqué que MySQL et peu fournir, si le besoin se fait sentir, de fonctionnalités interessantes pour ne pas dire indispensables (intégrité référenciel : inutile de locker les tables, view, rules, etc...).
      
      Néanmoins la configuration des protections est plus souple et plus simple avec MySQL qu'avec PostgreSQL.
      Enfin, et c'est un argument de poid, mysql est disponible sur free.fr, etc... et tourne aussi sous windows (partie client uniquement pour PostgreSQL).
      
      Donc MySQL et PostgreSQL sont aussi "cool" pour de petites bases. Mais mysql est plus disponible et sur certains points plus simples.
      
      PostgreSQL donne l'impression d'être plus lent que MySQL. PostgreSQL prévilégie la sécurité par défaut et utilise des appel à fsync() pour garantir l'intégrité de la base mais sur coupure de courant (çà dépend du hard après). On peut désactiver fsync() sur PostgreSQL et avoir le comportement et des performances équivalentes à Mysql).
      
      J'aime beaucoup PostgreSQL pour :
      - la doc
      - un SGBD-R complet, orienté object (le concept est séduisant mais pas facile a exploité), support pour les types utilisateurs (il y a par exemple le type point, cercle, adresse IP, etc...).
      - Un project mené sérieusement (depuis PostgreSQL car avant c'était Postgres95. Très peu de release) et qui existe depuis 1986 (il me semble).
      - Il est maintenant aussi pris en compte par les developpeur que mysql (ce qui n'était pas le cas il y a quelques mois). Par exemple mod_auth_psql, gnucash peu utiliser postgresql, le support pour postgresql est le plus abouti dans gnome-db, etc...
      
      Qu'on ne se trompe pas sur mes propros. Mysql est un bon project et qui a une longue vie, une très longue vie devant lui...
      
      je donnais un avis perso sur PostgreSQL auquel les gens pensent moins que MySQL (quoique que ça change depuis quelques mois).

      • [^]Re: Qui peut le + peut le - ...

        Posté par MagicNinja (page perso, ) le 07/02/2002 à 08:12. (lien). Évalué à 15.

        > PostgreSQL donne l'impression d'être plus lent que MySQL.
        
        Pour ceux qui ont juste fait un chtit test comme ca, il faut donner une precision: a chaque manipulation en ecriture postgresql ouvre une transaction (je ne sais pas comment fonctionne mysql sur ce point...), donc 10 inserts vont donner 10 ouvertures/fermetures de transactions alors qu'il faut faire:
        BEGIN WORK
        INSERT
        INSERT
        ...
        INSERT
        COMMIT
        ca permet de gagner beaucoup de temps

      • [^]petite erreur

        Posté par Antonio Da Silva (page perso, ) le 07/02/2002 à 09:55. (lien). Évalué à 5.

        > Enfin, et c'est un argument de poid, mysql est disponible sur free.fr, etc... et tourne aussi sous windows (partie client uniquement pour PostgreSQL).
        
        Faux, il se trouve que PostgreSQL tourne aussi sous windows ( avec cygwin ), je le sais : je l'ai fait. C'est pas aussi facile que mysql, dans la mesure où il n'y a pas de 'service' postgresql, donc il faut avoir une fenêtre DOS ouverte spécialement pour lui, mais bon, perso ça me dérange pas.
        
        URL : ftp://ftp.fr.postgresql.org/pub/binary/v7.0/NT/(...)
        
        J'utilise une autre version que celle-là créée par une société de services, qui ne la propose plus en téléchargement, mais ça doit être la même chose.

        • [^]RE: petite erreur

          Posté par matiasf () le 07/02/2002 à 11:24. (lien). Évalué à 5.

          Je le savais ...
          
          Neanmoins, le portage sous windows n'est pas une priorite pour les developpeurs (contrairemenet a apache V2 par exemple) et le portage de la partie serveur est recent et demande cygwin. De plus, la version sous windows n'est pas integre aux sources officiels.
          
          Mais t'as raison.
          Desole.

hebergement de db

• [^]Re: hebergement de db

  Posté par kadreg () le 06/02/2002 à 23:55. (lien). Évalué à 7.

  Parce que la partie serveur de mysql tourne aussi sous windows, ce qui permet à Joe Average (qui es tellement average qu'il utilise un OS Microsoft) de se l'installer sur son PC afin de se faire son site PHP/DB hors connection.

• [^]RE: hebergement de db

  Posté par matiasf () le 06/02/2002 à 23:56. (lien). Évalué à 22.

  C'est peut-être une connerie mais bon.
  
  L'organisation des fichiers avec mysql est simple :
  /var/lib/mysql puis
  toto/ : tous les fichiers de la base toto
  titi/ : tous les fichiers de la base titi
  mysql/ : base pour la conf (compte, etc...).
  ...
  
  L'implémentation de quota doit être simple pour un hébergeur.
  
  Sous postgres, les choses sont plus compliquer et moins claire au niveau système de fichier. Le support de transaction peu créer une grosse quantité de donnée (hors du répertoire de la base de donnée en cour).
  
  Afin, pour chaque connection sous un compte différent, progresql utilise un "postmaster" différent par process client. Un exemple pour être plus claire (en imaginant l'utilisation de connection persistante de php ; ce n'est pas un problème avec php en cgi ...) :
  
  Apache établie une connection avec mysql sous le compte titi (lancement d'un process si la connection n'existe pas avec le serveur). Puis une connection avec mysql sous le compte toto (utilisation de la connection précedante). Sous mysql il n'y a, au pire,qu'un process mysql par process httpd.
  
  Sous postgres il y a autant de process attachés à httpd qu'il y a de comptes (postgresql) utilisés (constaté avec PostgreSQL V6.2).
  
  Imaginons maintenant 1000 comptes et un serveur apache qui peut monté à 200 process. Dans la pire des situations, on peut monter théoriquement à 200 000 process ... et le nombre de fichier ouvert doit etre considérable... Enfin, il faut reconfigurer les ipc (dont postgresql est un assez gros consommateur).
  
  Bref, PostgreSQL ne semble pas adapté à l'hébergement d'un gros nombre de base de donnée sous différents comptes.
  
  Il y a certainement des conneries dans ce post... mais j'ai déjà configuré un serveur pour ouvrir plus de 32 000 fichier (16000 n'étant même pas suffisant lors des tests de tenu en charge) car il hébergais plusieurs base de donné (via apache/php et connection persistante).