Accéder au contenu.
Menu Sympa

fr - Re: [sympa-fr] Type de données pour bounce_score_subscriber

Objet : Pour les administrateurs de serveurs de listes utilisant le logiciel Sympa

Archives de la liste

Chronologique Discussions  
  • From: Olivier Salaün - CRU <adresse@cachée>
  • To: Sylvain Amrani <adresse@cachée>
  • Cc: adresse@cachée
  • Subject: Re: [sympa-fr] Type de données pour bounce_score_subscriber
  • Date: Fri, 20 May 2005 10:19:46 +0200

Bonjour,

Sylvain Amrani wrote:
N'hésitez pas à nous signaler ce genre de limitations ; nous ferons les modifs nécessaires dans les prochaines version.

Il faut nous indiquer quels champs sont concernés, quelle doit être la nouvelle taille. Si vous pouvez justifier ces besoins, c'est mieux.
    
J'ai un domaine en gendarmerie.defense.gouv.fr. Si je doit mettre devant le nom de villes françaises, j'ai plus de 250 adresses qui dépassent les 50 caractères. Et je devrais encore ajouter des qualificatifs et autoriser les recipient delimiters '+' pour éviter de multiplier des boites...
  
Vous faites référence aux champs de type email de la base ?
Rencontrez-vous des limitations avec d'autres champs ?
Mais paye-t-on vraiment la longueur des VARCHAR avec mysql ? J'imaginais qu'il n'y a pas de différences en terme de performances entre un VARCHAR(50) et un VARCHAR(255). Concernant les indexes, on peut jouer sur les partial indexes si l'espace disque est compté.
  
Effectivement, en basant l'index sur une partie des champs, on n'a que des avantages à étendre la taille des varchar à 255. Nous allons faire cette modification dans la prochaine versions de Sympa.
En fait et au fond, pourquoi sympa réinitialise-t-il son schéma de bdd ?
Et s'il doit vraiment le faire, ne pourrait-on ressortir le schéma du code pour le mettre en config ? Excusez ces questions naïves, mais je débute en sympa ;-)
  
Le changement automatique de la base est destiné à simplifier la vie des administrateurs. Je pense que c'est une fonctionnalité très utile.
Par contre nous pouvons ajouter un paramètre global permettant de désactiver cette fonctionnalité, afin de respecter des personnalisations éventuelles.
Par ailleurs, les clés utilisées sont du genre (user,list) et (list,user) sur du littéral et non des id, et je suis assez inquiet pour les gros volumes que je vais être amené à créer...
  
Pouvez-vous préciser vos craintes et vos volumes.
A titre d'exemple, notre serveur gère 150 000 abonnés sans pb.
Nous connaissons des sites utilisant sympa pour des listes de 700 000 abonnés, d'autres 20 000 listes.
En conclusion pour moi les 2 champs décrivant les listes et les utilisateurs sont trop limités, mais vraiment je préfèrerais être maître de mon schéma :-)
  
Nous vous transmettrons un patch lorsque nous aurons ajouté le paramètre précité.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature




Archives gérées par MHonArc 2.6.19+.

Haut de le page