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

[Sylvain Amrani <adresse@cachée>]

Olivier Salaün - CRU a écrit :

> Bonjour,
>
> 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...

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é.

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 ;-)

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...

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 :-)

Sylvain

>> Olivier Salaün - CRU a écrit :
>>
>>> Oui sympa.pl est capable de corriger automatiquement la structure de
>>> sa base de données, lorsqu'il est utilisé avec MySQL.
>>
>>
>> J'ai du à cause de cela modifier les sources, car certaines tailles
>> étaient trop limitées pour notre organisation (le VARCHAR(50) de
>> admin_table:list_admin en particulier). Les valeurs utilisées sont
>> inférieures aux limites fixées par les normes, non ?
>>
>> Je crains maintenant une future montée de version...
>
>
>