par
Henri » 19 juin 2007, 09:45
je me suis sûrement mal exprimé.
La base de données est bien sûr parfaitement normalisée : les pays d'exportation sont liés aux entreprises par des relations n-n, de même que les secteurs d'activités et tout le reste.
Je ne parlait que du stockage du filtre. Et là, je me moque de le normaliser parce que les éléments individuels du filtre ne m'intéressent pas. Le filtre est un ensemble de données qui est écrit et lu comme un tout. Je n'ai pas besoin de lire individuellement les éléments du filtre.
De même, les moyens d'accès sont toujours dans le même sens : je lis les filtres d'un utilisateur, puis pour un filtre donné, je lis tous les critères d'un seul coup. Je n'ai pas besoin non plus de trouver tous les filtres posés sur une entreprise ou sur un pays (ou alors c'est tellement anecdotique que cela ne compte pas).
C'est également une question de performances : je lis une chaîne de caractères dans un seul champs dans une seule table.
En PHP, dans cette application, un filtre est un tableau d'un nombre quelconque de critères dont chaque élément peut lui-même être un tableau. Avant l'enregistrement dans la base de données, l'application utilise ce tableau pour faire ses filtrages (pour générer le SQL de lecture des entreprises avec l'application des filtres). Après enregistrement et lecture dans la base de données, l'application utilise ce même tableau. A quoi cela sert-il de décomposer le tableau en valeurs élémentaires pour le stockage sachant que 1) on n'utilise pas individuellement ces valeurs élémentaires 2) on doit les recomposer exactement à l'identique après relecture. Autant stocker la structure d'un seul coup. En plus, cela réduit les risques de bugs en évitant d'écrire du code qui va déstructurer, puis restructurer le tableau.
Je vais faire une analogie : un texte structuré est une sorte de tableau ou plutôt d'arbre. Des chapitres, des sous-chapitres, des paragraphes, des alinéas, ...
Si mon besoin est une application qui puisse manipuler ou gérer ces éléments individuellement (par exemple, une application de génération de contrats d'assurance avec des clauses type), alors il faudra que la structure de ma base de données contienne des tables chapitres, sous-chapitres, ... et qu'il y ait des relations entre les éléments des tables.
En revanche, si mon besoin est que l'utilisateur puisse saisir un texte formatté, le stocker et le relire comme un tout (un message dans un forum ou dans un blog), alors il suffit d'un seul champ texte avec des balises type HTML, SPIP ou bbcode et que l'on stocke dans un seul champ d'une seule table.
Voila, j'espère avoir été un peu plus clair.
je me suis sûrement mal exprimé.
La base de données est bien sûr parfaitement normalisée : les pays d'exportation sont liés aux entreprises par des relations n-n, de même que les secteurs d'activités et tout le reste.
Je ne parlait que du stockage du filtre. Et là, je me moque de le normaliser parce que les éléments individuels du filtre ne m'intéressent pas. Le filtre est un ensemble de données qui est écrit et lu comme un tout. Je n'ai pas besoin de lire individuellement les éléments du filtre.
De même, les moyens d'accès sont toujours dans le même sens : je lis les filtres d'un utilisateur, puis pour un filtre donné, je lis tous les critères d'un seul coup. Je n'ai pas besoin non plus de trouver tous les filtres posés sur une entreprise ou sur un pays (ou alors c'est tellement anecdotique que cela ne compte pas).
C'est également une question de performances : je lis une chaîne de caractères dans un seul champs dans une seule table.
En PHP, dans cette application, un filtre est un tableau d'un nombre quelconque de critères dont chaque élément peut lui-même être un tableau. Avant l'enregistrement dans la base de données, l'application utilise ce tableau pour faire ses filtrages (pour générer le SQL de lecture des entreprises avec l'application des filtres). Après enregistrement et lecture dans la base de données, l'application utilise ce même tableau. A quoi cela sert-il de décomposer le tableau en valeurs élémentaires pour le stockage sachant que 1) on n'utilise pas individuellement ces valeurs élémentaires 2) on doit les recomposer exactement à l'identique après relecture. Autant stocker la structure d'un seul coup. En plus, cela réduit les risques de bugs en évitant d'écrire du code qui va déstructurer, puis restructurer le tableau.
Je vais faire une analogie : un texte structuré est une sorte de tableau ou plutôt d'arbre. Des chapitres, des sous-chapitres, des paragraphes, des alinéas, ...
Si mon besoin est une application qui puisse manipuler ou gérer ces éléments individuellement (par exemple, une application de génération de contrats d'assurance avec des clauses type), alors il faudra que la structure de ma base de données contienne des tables chapitres, sous-chapitres, ... et qu'il y ait des relations entre les éléments des tables.
En revanche, si mon besoin est que l'utilisateur puisse saisir un texte formatté, le stocker et le relire comme un tout (un message dans un forum ou dans un blog), alors il suffit d'un seul champ texte avec des balises type HTML, SPIP ou bbcode et que l'on stocke dans un seul champ d'une seule table.
Voila, j'espère avoir été un peu plus clair.
