Discussion :

[Youpyou]

Bonjour

Je développe un site professionnel en JavaEE dont la principale contrainte technique est la volumétrie :

Plus précisément, j'ai besoin de créer des bons a usages uniques (donc avec un code unique a vérifier).
Le système doit pouvoir générer un grande quantité de bons (de l'ordre de plusieurs millions)

Ayant peu d'expérience en structure de BDD, j'aurai tendance a faire au plus simple : une table contenant les bons, dont la clé et le minimum d'informations (quelques dates, un montant ..)

J'ai évidement peur de la durée des recherches pour valider un bon (parcours de la table pour trouver la clé)

- Est ce plus performant de séparer ca en deux table, l'une ne contenant que la clé et un id ? (ca ne réduirai pas la volumétrie puiqu'on aurait une cardinalité 1-1)
- Existe-t-il des architectures plus adaptées a ma contrainte ?

Après pas mal de recherches, je n'ai pas trouvé de site, de cours, de forum pertinent. Tout lien est le bienvenu

Merci de votre aide !

[fsmrel]

avec un code unique a vérifier

Ce code est un numéro incrémenté de 1 en 1 ? Quel est son type exact ?

Comment un bon se présente-t-il structurellement parlant ?

Pourriez-vous présenter la rédaction (en français plutôt qu’en langage de programmation) de requêtes qui vous soucient ? Par exemple Quels sont les bons échus ce jour ? les bons égarés ? etc.)

Utiliserez-vous une base de données SQL ? Des fichiers ?


Quand vous dites plusieurs millions, est-ce en dessous de dix millions ? Cinq millions ?

[Youpyou]

Merci de votre réponse.

Je précise donc :

Ce code est un numéro incrémenté de 1 en 1 ? Quel est son type exact ?

Non ce sera de l'alphanumérique. Donc du VARCHAR2 (?).

Comment un bon se présente-t-il structurellement parlant ?

Pourriez-vous présenter la rédaction (en français plutôt qu’en langage de programmation) de requêtes qui vous soucient ? Par exemple Quels sont les bons échus ce jour ? les bons égarés ? etc.)

Fonctionnellement ce sont des bons de réduction uniques. L'utilisateur entre donc son code pour validation. Pour répondre aux questions
- En plus de la clé de validation, le bon a une date de validité, un montant en euros, sera lié a son émetteur, pourra être lié à un compte client (pour cumuler les bons)
- Ce qui m'ennuie c'est la validation des bons. L'utilisateur saisira sur le site la clé unique de validation pour utiliser son bon. Le site doit pouvoir encaisser une centaine de validation à la minute, sur des millions d'entrées. (Je sous estime peut etre les capacités des SGBD)

Utiliserez-vous une base de données SQL ? Des fichiers ?

Je ne connais que les BDD SQL et n'ai pas envisagé d'autre alternative (vous parlez de BDD XML ?)

Quand vous dites plusieurs millions, est-ce en dessous de dix millions ? Cinq millions ?

Dix millions c'est envisageable. Mettons dix millions max. Y a-t-il une raison précise pour laquelle vous me proposez cinq et dix millions ?

Merci encore

[fsmrel]

Rien de tel que de modéliser un minimum pour y voir plus clair.

Du point de vue fonctionnel, je comprends ceci :

Chaque bon est doté d’une clé de validation (unique) que l’utilisateur doit fournir pour accéder à l’information. Outre cette clé, un bon comporte certaines propriétés telles que sa période de validité, son montant.

Un bon est identifié par sa clé de validation, mais cette clé devient une clé alternative du point de vue de la modélisation. La clé utilisée pour les opérations relationnelles (fondamentalement les opérations de jointure) est une clé contrôlée par le système et reste cachée pour les utilisateurs.

Ainsi, dans la représentation ci-dessous, l’identifiant primaire (primary identifier « <pi> ») de l’entité-type Bon est représenté par l’attribut BonId, tandis que l’attribut CleValidation (symbolisant la clé de validation) est un identifiant alternatif (alternate identifier « <ai> »).

Un compte client possède de 1 à N bons et un bon a été émis exactement par un émetteur.

Pouvez-vous préciser ce qui ne va pas dans ce que je viens de conjecturer ?

Ce code est un numéro incrémenté de 1 en 1 ? Quel est son type exact ?

Non ce sera de l'alphanumérique. Donc du VARCHAR2 (?).

Si ce code représente la clé de validation, le type CHAR devrait suffire. Combien de caractères l’utilisateur doit-il saisir (autrement dit, si on utilise le type CHAR(x), quelle est la valeur de x ?)

Je ne connais que les BDD SQL et n'ai pas envisagé d'autre alternative (vous parlez de BDD XML ?)

Je ne pensais à XML mais à des fichiers plats.

Quel sera votre SGBD ?

Y a-t-il une raison précise pour laquelle vous me proposez cinq et dix millions ?

Ceci conditionne souvent la hauteur de l’arbre en ce qui concerne les index. Par hauteur, on entend le nombre de niveaux d’index et plus cette hauteur est élevée, plus le nombre d’accès au disque est élevé. Ceci est aussi fonction de la taille de la clé (CleValidation), d’où la nécessité de connaître la valeur de x que j'ai mentionnée ci-dessus.

[Youpyou]

Pouvez-vous préciser ce qui ne va pas dans ce que je viens de conjecturer ?

On est d'accord. Sauf que la clé n'est pas forcément cachée a l'utilisateur puisqu'il doit la saisir (c'est ce que je voulais dire par 'entre son code pour validation')

Combien de caractères l’utilisateur doit-il saisir (autrement dit, si on utilise le type CHAR(x), quelle est la valeur de x ?)

La clé doit être unique pour permettre la validation du bon.
Il faut 14 caractères pour avoir 10 millions de combinaisons différentes (Selon mes calculs de dénombrement combinatoire dont je ne suis qu'approximativement surs)

Je ne pensais à XML mais à des fichiers plats.
Quel sera votre SGBD ?

Je n'ai jamais travaillé avec des fichiers plats mais si ca augmente les performances, il faut que j'étudie ca.

Je pense me tourner vers du Oracle pour répondre a la volumétrie.



Pour revenir a la question initiale, je cherche surtout la meilleure solution pour répondre a mes contraintes. Je ne me rends pas compte si une architecture professionnelle peut encaisser une telle volumétrie, ou si il faut que je repense le fonctionnement même de mon système de bons.

[fsmrel]

On est d'accord. Sauf que la clé n'est pas forcément cachée a l'utilisateur puisqu'il doit la saisir (c'est ce que je voulais dire par 'entre son code pour validation')

J’entends bien. Je rappelle ce que j’ai dit, il existe deux clés :
la clé qui sert à utilisateur (attribut CleValidation dans ma représentation graphique) et celle qui sert pour effectuer les jointures et autres opérations relationnelles (attribut BonId, qui reste cachée). BonId est de type INTEGER, représentant un encombrement minimum (4 octets). Pour sa part et pour faire bonne mesure, CleValidation peut être de type CHAR(16).
Comme je l’ai dit, CleValidation et BonId sont des clés au sens SQL, c’est donc le SGBD qui garantit l’unicité de leurs valeurs.

Je n'ai jamais travaillé avec des fichiers plats mais si ca augmente les performances, il faut que j'étudie ca.

Surtout n’en faites rien !

Je pense me tourner vers du Oracle pour répondre a la volumétrie.

Tout comme Oracle, DB2 et SQL Server permettent de traiter des volumes beaucoup plus importants. Une table de 10 millions de lignes est aujourd’hui quelque chose de banal.

Je ne me rends pas compte si une architecture professionnelle peut encaisser une telle volumétrie

J’ai modélisé et utilisé des bases de données (avec DB2 for z/OS) composées de plus de mille tables, certaines d’entre elles dépassant les cent millions de lignes, sans rencontrer de problème particulier (avec des centaines d'utilisateurs connectés). Mais bien sûr, l’organisation suppose une certaine expérience de la mise en œuvre de telles bases, les pièges sont partout et un prototypage des performances s’impose, à partir du top 10 des transactions et traitements de masse prévisibles.

[Youpyou]

Je pense que j'y verrai plus clair une fois le projet avancé et avec des tests de charge.

Merci de votre temps !

[fsmrel]

Je vous en prie.

A titre indicatif, dans le contexte de DB2 for z/OS, pour la requête suivante (Login est supposé être un attribut de la table CompteClient) :

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
SELECT  x.Login 
FROM    CompteClient AS x INNER JOIN Bon AS y 
           ON x.CompteId = y.CompteId 
WHERE   Y.CleValidation= '1234567890123456' ;

le coût mesuré avec l'outil DB2 Estimator est de l'ordre de 50 millisecondes, pour une table CompteClient de un million de lignes et une table Bon de dix millions de lignes. L'index branché sur la table CompteClient comporte 3 niveaux et l'index branché sur la table Bon comporte 4 niveaux.

Si vous avez des problèmes au cours de vos tests, n'hésitez pas, vous connaissez la maison...