Les identifiants dans la base de données sont justement pour permettre à SOGo d'aller se connecter à d'autres base de données pour son fonctionnement.
Par exemple, vous pourriez avoir 10 000 utilisateurs sur une base de données et 10 000 autres sur une autre. Ceci est pratique dans des grands déploiements où il y a une base de données par emplacement géographique et que les liens interconnectant le tout ne sont pas très rapides...
Pour la structure des tables, elle est très simple en fait. Il y a une table "quick" où l'on conserve certains éléments extraits des événements / tâches / contacts. Cette table est réservée aux consultations "rapides" - comme l'afficage des vues calendriers, la liste des événements, etc. Associée à la table "quick", il y a une table de contenu où l'on conserve la l'événement / tâche / contact _original_ - tel que reçu par SOGo donc nous évitons toutes transformations qui pourraient causer une perte d'informations.
Au niveau du nombre de tables, des systèmes comme PostgreSQL, Oracle et même MySQL n'ont aucun problème à en gérer plusieurs milliers, en autant bien entendu que la configuration soit bien adaptée au déploiement.
[^] # Re: Mise à l'échelle de la solution SOGo
Posté par Ludovic Marcotte . En réponse à la dépêche Sortie de SOGo 1.3.0. Évalué à 4.
Par exemple, vous pourriez avoir 10 000 utilisateurs sur une base de données et 10 000 autres sur une autre. Ceci est pratique dans des grands déploiements où il y a une base de données par emplacement géographique et que les liens interconnectant le tout ne sont pas très rapides...
Pour la structure des tables, elle est très simple en fait. Il y a une table "quick" où l'on conserve certains éléments extraits des événements / tâches / contacts. Cette table est réservée aux consultations "rapides" - comme l'afficage des vues calendriers, la liste des événements, etc. Associée à la table "quick", il y a une table de contenu où l'on conserve la l'événement / tâche / contact _original_ - tel que reçu par SOGo donc nous évitons toutes transformations qui pourraient causer une perte d'informations.
Au niveau du nombre de tables, des systèmes comme PostgreSQL, Oracle et même MySQL n'ont aucun problème à en gérer plusieurs milliers, en autant bien entendu que la configuration soit bien adaptée au déploiement.