Discussion :

[Pierre Fauconnier]

En fait SQL ne vous appartient pas et vous n'avez pas à imposer les règles métier de gestion à l'ensemble des développeurs SQL....

Je pense qu'il ne faut pas mélanger les concepts. Ici, on parle d'intégrité, et de la (non)pertinence à la mettre via des FK sur le moteur de données ou plutôt par code. On ne parle pas (on ne devrait pas parler) du fait de mettre ou pas l'intégrité référentielle.

En ce qui me concerne, je suis ouvert (et demandeur...) d'exemples issus d'autres métiers que ceux de la gestion, et il me semble qu'un sujet comme celui-ci (vu son titre) permet l'ouverture à d'autres (non)dogmes, nonobstant le caractère parfois "brut de coffrage" de certaines interventions péremptoires qui n'appartiennent qu'à leur(s) auteur(s)...

Cela dit, même en gestion, il est parfois intéressant de ne pas avoir l'intégrité référentielle (via FK ou via du code, d'ailleurs). C'est le cas, notamment, des lignes de détails de factures (non)liées à la table des articles...

On peut en tout cas développer des exemples qui montrent la pertinence de ne pas mettre l'intégrité.

Cela étant, je suis conforté dans l'idée que, s'il faut de l'intégrité, alors, qu'on la place via des FK plutôt qu'avec du code...

[Jester]

Comme toujours ça dépend du contexte.

En même il est aussi logique que des gens spécialisé dans les SGBD ne soient pas passionnés par des applications des SGBD où il n'y a pas persistance ni accès simultané.

[Invité]

Je suis assez content que vous fassiez preuve d'ouverture, merci donc

J'ai travaillé en gestion aussi mais pas seulement. Dans un environnement de gestion , on a une notion de responsabilité et des règles plus ou moins validées.

J'ai du faire le conception de logiciels où rien ne semblait plus incongru que l'utilisation d'un SGBD. Mais la France est le seul pays où on considère la BDD comme une discipline "à part". Non seulement les ingés formé à l'industrie sont ignorants de sql mais en plus ils n'adressent pas la parole aux gens de la gestion, coté gestion c'est pareil et ça ne facilite pas les choses.

La dernière fois que j'ai dû défendre l'usage de sql, il a fallu que je retrace son histoire, pourquoi les BDD sont plus aptes à gérer des clefs uniques, l'avantage qu'on retire de la persistance dans la cinématique même quand celle ci est très rapide (scrolling, animation, ..) la possibilité de changer la spec à postériori, l'indépendance par rapport à l'ordre des évènements... Je rencontre des gens qui utilisent la sérialisation XML sur des listes chainées...

Je vous laisse deviner le nombre de lignes de C# qu'il faut pour émuler un GROUP BY .. HAVING avec plusieurs récursions souvent plus de 100 lignes fragiles qui buguent dés qu'on change le type d'un champ !

Pour reprendre l'exemple des contrôleurs aériens, bien sûr, chaque echo radar est inséré dans la base avec ses caractéristiques, amplitude, doppler.. mais au prochain balayage radar, ce ne sera peut-être qu'un parasite. D'autre part l'antenne radar tourne en 1 seconde et il n'est pas question de "rater" un tour ! donc il faut aller vite, effectuer les dérivées pour tracker l'origine d'un parasite plusieurs secondes après son apparition, etc.. Sans SQL , c'est l'enfer ! et bien sûr si la compta gère de grosses sommes d'argent , le controle aérien gère des vies humaines en pagaille , une seconde de retard peut couter des centaines de vies ! les enjeux sont donc importants de part et d'autre.

Mais les erreurs sont sans commune mesure . Vous dites être spécialiste de SGBD, moi aussi ! 4 versions Oracle, t-sql, mySql, odbc, adodb, ado.net sqlite.. mais les foreign keys ne m'empèchent pas de dormir et les contraintes d'intégrité semblent d'un autre monde. Trop lent , trop aveugle, suppose de rattrapper toutes les erreurs serveur que l'utilisateur ne veut en aucun cas voir sur son écran... c'est simplement à coté de la plaque !

[pmithrandir]

Le problème est que 99% des développeurs oublient que normalement toute application BD devrait être exclusivement attaquée par des vues et non directement sur les tables de la base. C'est la notion de modèle externe. Si tout le monde la respectait, les développements seraient triviaux, simple et sans redondance aucune !

Bonjour

Est ce que vous pourriez expliciter cette idée ?

Je fais partie de ces 99% et j'avoue ne pas bien saisir l'idée des vues qui serait mieux que les tables originales pour récupérer les données.

N'est ce pas un ajout inutile de travail ?

Concernant le sujet principal, j'ai eu un exemple dernièrement que l'on peut interpreter de 2 façons.

Lors d'une mise a jour du programme, un if a été mal place dans le code et a donc inclu une partie de code qu'il ne fallait pas. Moralité, tous les posts etaient insérés sans langage.(enfin, language = 0)

Nous avions donc des données inconsistentes insérées en BDD, ce qui nous posait des problèmes dans les stats, et dans pas mal de requetes, mais ca restait mineur.
La direction a pris la décision de faire un correctif global plus tard en laissant sciement le bug dans le logiciel. Lors de la misea jour nous avons remplacé tous les 0 par l'anglais, langue par defaut de notree logiciel.

Aucun client ne s'est plaint a ma connaissance, etant donné que c'est une fonction très secondaire.

En revanche, si nous avions eu une contrainte, nous n'aurions plus eu la possibilité d'insérer un post, notre coeur de métier, nous aurions eu affaire a un bug bloquant avec mise a jour immédiate requise.(on l'aurait surement detecté avant la MAJ dans les tests cela dit) Les clients auraient vu le problème et ca aurait emmerder tout le monde.

Donc, contrainte, foreign key, etc... oui, mais parfois c'est bien pratique d'avoir une BDD incohérente d'un point de vue satisfaction client immédiate.

[SQLpro]

Bonjour

Est ce que vous pourriez expliciter cette idée ?

Lisez la règle 6 de Codd et les exemples détaillés que j'ai donné dans cet article : http://sqlpro.developpez.com/SGBDR/ReglesCodd/

Je fais partie de ces 99% et j'avoue ne pas bien saisir l'idée des vues qui serait mieux que les tables originales pour récupérer les données.

N'est ce pas un ajout inutile de travail ?

Si vous considérez que réduire la durée d'un projet et minimiser le nombre de ligne de code, donc de bug, est un travail inutile....

Concernant le sujet principal, j'ai eu un exemple dernièrement que l'on peut interpreter de 2 façons.

Lors d'une mise a jour du programme, un if a été mal place dans le code et a donc inclu une partie de code qu'il ne fallait pas. Moralité, tous les posts etaient insérés sans langage.(enfin, language = 0)

Nous avions donc des données inconsistentes insérées en BDD, ce qui nous posait des problèmes dans les stats, et dans pas mal de requetes, mais ca restait mineur.
La direction a pris la décision de faire un correctif global plus tard en laissant sciement le bug dans le logiciel. Lors de la misea jour nous avons remplacé tous les 0 par l'anglais, langue par defaut de notree logiciel.

Aucun client ne s'est plaint a ma connaissance, etant donné que c'est une fonction très secondaire.

En revanche, si nous avions eu une contrainte, nous n'aurions plus eu la possibilité d'insérer un post, notre coeur de métier, nous aurions eu affaire a un bug bloquant avec mise a jour immédiate requise.(on l'aurait surement detecté avant la MAJ dans les tests cela dit) Les clients auraient vu le problème et ca aurait emmerder tout le monde.

[/quote]Mais comme vous le dite, vous auriiez vu le bug au premier essais et donc éviter de perdre du temps en reprise de bug après installation !!!

Donc, contrainte, foreign key, etc... oui, mais parfois c'est bien pratique d'avoir une BDD incohérente d'un point de vue satisfaction client immédiate.

A +

[pmithrandir]

Lisez la règle 6 de Codd et les exemples détaillés que j'ai donné dans cet article : http://sqlpro.developpez.com/SGBDR/ReglesCodd/
Si vous considérez que réduire la durée d'un projet et minimiser le nombre de ligne de code, donc de bug, est un travail inutile....

En fait, cette rêgle ne dit pas ce que vous pretendez, enfin, je ne la comprend pas comme cela. Pour moi, elle dit que le SGBD doit etre capable de faire des vue et de proposer des insertion / update dessus. En revanche elle ne dit rien sur un accés au données uniquement par ces vues.

Regle 6 : Toutes les vues qui sont théoriquement modifiables peuvent être mises à jour par le
système.

Quand à moi, malgré les exemples, j'ai beaucoup de mal à voir un quelconque avantage a utiliser des vues au lieu de table. (je veux bien croire que ca soit utile mais je ne trouve pas).
En général, les opérations consistent à aller chercher des données avec une requête dans une table.

Cette table sera toujours à jour naturellement.
De la même facon, on peut insérer et implicitement la table sera encore a jour.

Dans vos exemples, vous ajoutez une surcouche qui programme la mise a jour, l'insertion et la selection depuis les vues qui redirige vers les tables... que gagnez vous avec ce code suplémentaire ?

Ex :
J'ai une table personnes, je veux récuperer l'email de Pierre Bonneau et son ID est 543. En quoi passer par une vue est necessaire ou utile ?

[CinePhil]

Ex :
J'ai une table personnes, je veux récuperer l'email de Pierre Bonneau et son ID est 543. En quoi passer par une vue est necessaire ou utile ?

Si tu ne veux récupérer que des attributs d'une seule table, la vue n'est pas forcément très utile... sauf si certaines des colonnes de cette tables doivent rester confidentielles, y compris pour les programmeurs qui utilisent la BDD.
La vue permet alors de limiter l'accès aux colonnes nécessaires au programmeur et surtout au compte utilisé par l'appli grâce à la gestion des privilèges sur la vue et sur la table.

Autre exemple où la vue est intéressante : quand les données à ramener proviennent de multiples tables et nécessiteraient de multiples jointures à programmer par le développeur alors qu'il ne connais pas forcément toute la structure de la BDD.
Il exprime son besoin (nom, prénom, matricule, adrel, nom du service où il travaille, date d'entrée dans la société, fonction...) et le DBA lui fournit la vue adéquate. Le programmeur n'a plus alors qu'à interroger cette vue comme une seule table et c'est le SGBD qui se débrouille pour faire les jointures nécessaires.

[Oishiiii]

Dans la théorie relationnelle il y a deux principes très important (parmi bien d'autres).

L'indépendance physique des données.
Si on effectue une mise à jour de la structure physique de la base de données, il ne doit y avoir strictement aucun impact sur la base de données à un niveau logique (le code SQL en gros), donc aucun impact sur l'application.
Par exemple: Si on supprime un index ou que l'on ajoute un index à une table, si on déplace les données d'un disque dur à un autre, si ont compresse les données, si l'optimiseur utilise un nouvel algorithme, etc... tout cela est transparent est n'a aucun impact sur la base et donc sur l'application.
C'est le SGBDR qui doit mettre en application ce principe.

(Ce principe est relativement bien respecté par nos SGBDR, on s'en rend compte facilement)

L'indépendance logique des données.
Si on effectue une modification de la structure des tables, il ne doit y avoir strictement aucun impact sur l'application. Il ne doit pas être nécessaire de modifier les requêtes (disons SQL).
Pour assurer ce principe il faut utiliser les vues.
Les vues sont une "sur-couche" par dessus les tables.
Il est en effet très simple de modifier la requête de définition d'une vue, lorsque les tables participant à celle-ci sont modifiées, pour retrouver la structure (colonnes et contenu) initiale.

Malheureusement le sujet de la mise à jour des vues est complexe est n'est pas très bien gérer par nos SGBDR. C'est pourquoi SQLPro propose une solution à base de Trigger instead of, lui permettant de manipuler les données uniquement à travers les vues.


Au delà de cette aspect "sur-couche" des vues (appelé souvent "schéma externe") sont extrêmement utiles dans la gestion des privilèges, pour la sécurité. SQLPro pourra certainement détailler ce point si ce n'est déjà fait.


Bien entendu comme l'explique CinePhil, les vues simples (non matérialisées) peuvent aussi être considérées comme de simples "alias" de requêtes SELECT. Cela peut aider dans le dialogue entre l'utilisateur et la base de données.

[pmithrandir]

Merci pour ces réponses. J'en apprends tout les jour et j'adore le fait d'arriver sur la discussion et de me dire : "oh oui mais bien sur, c'est super interessant ce truc"

En résumé, les vues sont interessantes quand :
- on peut imaginer d'avoir des données confidentielles
- on a une équipe nulle en SQL qui ne sait pas faire une jointure ou un shéma relationnel.
- on a une structure de table qui change beaucoup(ce qui m'etonne un peu dans nombre d'application)

Mais elles restent a un état experimental ou imparfait dans de nombreux SGBD, ce qui entraine des soucis que l'on doit résoudre / émuler à la main. Ce code étant potentiellement source de bug très impactant, il faut donc bien peser le pour et le contre(peu interressant pour un blog de 4 tables, indispensable pour une application médicale de 400 tables)

Existe t'il des méthodes plus simple créée depuis la parution de l'article de SQL Pro ? Ou des méthodes peut être différentes de régler ce problème ?

PS : je crois que je fais digresser le sujet, peut etre serait il mieux de scinder cette discussion pour créér un autre sujet spécifique aux vues. Si un modérateur passe par la...

[SQLpro]

Dans vos exemples, vous ajoutez une surcouche qui programme la mise a jour, l'insertion et la selection depuis les vues qui redirige vers les tables... que gagnez vous avec ce code suplémentaire ?

Tout simplement l'indépendance entre la structure physique et les IHM. Si la structure de la table doit être changée, cela impacte directement les IHM. En passant systématiquement par des vues, aucune modification d'IHM est nécessaire. La simple modification de la vue suffit !

Ex :
J'ai une table personnes, je veux récuperer l'email de Pierre Bonneau et son ID est 543. En quoi passer par une vue est necessaire ou utile ?

Votre exemple est excellent, parce que dans ce cas vous avez visiblement un problème de modélisation. En effet mettre les mails des personnes directement dans la table des personnes est une hérésie, parce que les personnes peuvent avoir plusieurs e-mail ! Ce qui conduirait à email1, email2, email3... et si vous avez besoin d'un xeme email que faire ?
Alors que si vous aviez fait une table des emails et une vue de synthèse associant personnes et mails, cela se serait bien passé !!!*

Bref, vous avez encore beaucoup à apprendre des bases de données !!!

Mon livre comme mon site web peuvent vous y aider...

A +

[SQLpro]

Mais elles restent a un état experimental ou imparfait dans de nombreux SGBD, ce qui entraine des soucis que l'on doit résoudre / émuler à la main.

Jene peut pas vous laisser dire cela. Les vues existent depuis la naissance de SQL et leurt "misajourabuilité" mis en évidence par Codd le père fondateur des SGBDR avant même que le premier SGBD commercial ne voit le jour !!!!!

Alors expérimentel.. depuis plus de 30 ans !!! Sauf si vous en êtes resté à cet ersatz de SGBDR qui est MySQL !!!!!!

Ce code étant potentiellement source de bug très impactant, il faut donc bien peser le pour et le contre(peu interressant pour un blog de 4 tables, indispensable pour une application médicale de 400 tables)

Je ne peut pas non plus vous laisser dire de telles inepties... EN effet le code des SGBDR est généralement 4 fois plus compact que tout code équivalent dans un langage itératif... 4 fois moins de lignes, c'est 4 fois moins de bugs..... En sus il est beaucoup plus rapide de vérifier par des jeux d'essais les traitements SQL que par l'intermédiaire des IHM !


A +

[pmithrandir]

Je suis tout a fait d'accord avec vous que notre système ne permet pas d'ajouter un autre email. Nous passerions sûrement à une table différente si nous avions ce besoin, mais j'hérite d'une base de donnée crée sans la moindre recherche au fil de l'eau par des développeur pas du tout calé en SQL.

L'email étant notre login, il est par définition unique dailleur.(comportement assez courant sur les sites web)

Pour moi, un bon développement est toujours une balance entre plusieurs techniques et plusieurs talents. Dans le cas présent, pas de besoin = pas de budget pour implémenter d'autres email = une structure pour l'email est inclu dans la table User.

Pour ce qui est de mon commentaire sur les vues, il est directement inspiré de votre exemple dans les règles de codd. La mécanique mise en place pour synchroniser les vues et les tables est beaucoup plus complexe que tous les algorithmes de notre application. Je pense donc qu'elle peut être source de bug, car la complexité est aussi un facteur d'ajout de bug, ainsi que la nouveauté, l'expérience inexistante du développeur, etc..

De plus, quand je regarde ca depuis l'extérieur, vous semblez expliquer que les BDD devrait implémenter cette fonction nativement, mais que comme ce n'est pas le cas il faut utiliser d'autres solution dont celle des triggers que vous présentez. Pour moi, c'est ce que j'appelle une solution expérimentale puisque je dois ajouter du code pour que mon outil fasse son travail. Après, n'y voyez aucune critique, c'était plus une remarque qu'une affirmation.

Dailleur, je vais profiter de votre argument du code SQL 4 fois moins verbeux que le code normal, et donc mathématiquement 4 fois moins bugggés.... Cela parait séduisant comme extrapolation, mais je n'ai pas le souvenir que le code SQL soit le plus simple qui existe ou le plus logique, par rapport d'un point de vue objet.
Votre argument reviendrait dailleur a dire : le code itératif est moins verbeux que le code objet, il est donc moins buggé... Ce qui est largement faux puisque le code objet est plus aisé a comprendre et donc à développer ou à modifier.
La verbosité peut êtes un argument en faveur de la lecture, donc de la compréhension et donc de la qualité.


Mais ne vous inquiétez pas, j'apprends de jour en jour et j'essaye de comprendre le pourquoi des affirmation pour mieux les mettre en balance dans mes prochains développements et faire en sorte de produire des BDD plus robuste.
Dans le projet que je développe avec un collègue, nous allons prendre en compte beaucoup de vos conseils dailleur. Nous essayons juste de faire la balance entre coût immédiat en pleine phase d'investissement et de création ou l'argent manque, et coût pour plus tard hypothétique(notre produit ne marchera peut etre pas) ou l'argent sera moins problématique puisque si le produit marche, nous aurons des moyens. Même si cela nous coûte plus cher, dépenser 1000 euros est une énorme dépense maintenant, dépenser 10 000 n'en sera pas une dans 6 mois si ca marche.

Merci en tout cas pour vos commentaires qui me permette toujours d'avancer un peu plus dans mon apprentissage et ma reflexion.

PS : sur votre blog de cours, la rubrique exercice renvoie une erreur 403.

[SQLpro]

La mécanique mise en place pour synchroniser les vues et les tables est beaucoup plus complexe que tous les algorithmes de notre application. Je pense donc qu'elle peut être source de bug, car la complexité est aussi un facteur d'ajout de bug, ainsi que la nouveauté, l'expérience inexistante du développeur, etc..

Elle n'est pas plus complexe que du code itératif ou des couches d'ORM. C'est simplement une question de connaissance et hélas force est de constater (et vous en êtes un exemple) que la formation en matières de technique sur les SGBDR est plus que faible. Et croyez moi, je sais de quoi je parle car j'enseigne aux ingénieurs de 5e année dans deux écoles d'ingénieurs ainsi qu' Arts & Métiers et je donne des cours conférence dans à l'université de Toulouse....

De plus, quand je regarde ca depuis l'extérieur, vous semblez expliquer que les BDD devrait implémenter cette fonction nativement,

C'est bien le cas puisque les triggers INSTEAD OF existe depuis de nombreuses années (10 à 15 ans) dans les bons SGBDR

mais que comme ce n'est pas le cas il faut utiliser d'autres solution dont celle des triggers que vous présentez.

Je n'ai jamais dit cela, vous avez mal lu. J'ai dit qu'il serait intéressant d'avoir des ORM capable de faire cela tout seul, ce qui serait intelligent. Mais les ORM présentent un nivellement vers le bas afin de s'adapter aux plus médiocres SGBDR transformant ainsi le SGBDR en simple outil de stockage, ce qui, bien évidemment, en tue les performances !!!

Pour moi, c'est ce que j'appelle une solution expérimentale puisque je dois ajouter du code pour que mon outil fasse son travail. Après, n'y voyez aucune critique, c'était plus une remarque qu'une affirmation.

Dailleur, je vais profiter de votre argument du code SQL 4 fois moins verbeux que le code normal, et donc mathématiquement 4 fois moins bugggés.... Cela parait séduisant comme extrapolation, mais je n'ai pas le souvenir que le code SQL soit le plus simple qui existe ou le plus logique, par rapport d'un point de vue objet.

lisez les travaux de Paul Dorsey sur l'URL que j'ai cité dans mon papier :
http://www.dulcian.com/Articles/Thic...ited_final.htm
en particulier le tableau 2

Votre argument reviendrait dailleur a dire : le code itératif est moins verbeux que le code objet, il est donc moins buggé... Ce qui est largement faux puisque le code objet est plus aisé a comprendre et donc à développer ou à modifier.

contrairement à ce que vous pensez c'est tout à fait vrai.... dans la production de code, à fonctionnel identique...
Autrement dit le nombre de bug est directement proportionel au nombre de lignes écrite.
Cependant vous oublier que les codes itératifs écrits depuis très longtemps ont été corrigés depuis très longtemps....
Les métriques dans le génie logiciel sont claires et simple : plus de ligne = plus de bug, quelque soit la façon dont vous prenez la chose !!!!

La verbosité peut êtes un argument en faveur de la lecture, donc de la compréhension et donc de la qualité.

Mais ne vous inquiétez pas, j'apprends de jour en jour et j'essaye de comprendre le pourquoi des affirmation pour mieux les mettre en balance dans mes prochains développements et faire en sorte de produire des BDD plus robuste.
Dans le projet que je développe avec un collègue, nous allons prendre en compte beaucoup de vos conseils dailleur. Nous essayons juste de faire la balance entre coût immédiat en pleine phase d'investissement et de création ou l'argent manque, et coût pour plus tard hypothétique(notre produit ne marchera peut etre pas) ou l'argent sera moins problématique puisque si le produit marche, nous aurons des moyens. Même si cela nous coûte plus cher, dépenser 1000 euros est une énorme dépense maintenant, dépenser 10 000 n'en sera pas une dans 6 mois si ca marche.

tout ce que vous ne ferez pas à la base, c'est à dire dans les fondements (les fondations) de votre application, vous péterons au nez tôt ou tard. Cela peut d'ailleurs ne jamais se faire si l'appli se cantonne toujours à 3 utilisateur et quelques Mo de données.
Mais lisez les artile que j'ai écrit sur l'optimisation des SGBDR. Cela a été écrit pour SQL Server, mais les rermarques sont valable quelque soit le SQGBDR.
http://sqlpro.developpez.com/optimisation/
Enfin sachez qu'il ne coute pas plus cher, ni en temps ni en argent de bien faire dès le départ. Seulement les chefs de projet et plus encore les clients sont obnubilés par le fait d'avoir à montrer rapidement des écrans, dons au détriment de la modélisation et de l'écriture de procédures stockées qui n'ont rien de sexy à montrer !

Bref, il fut commencer par se former à la modélisation des données et respecter à la lettre au minima les 3 premières formes normales, bien choisir ses types de données, etc...

Merci en tout cas pour vos commentaires qui me permette toujours d'avancer un peu plus dans mon apprentissage et ma reflexion.

PS : sur votre blog de cours, la rubrique exercice renvoie une erreur 403.

QUelle url ???

A +

[Pierre Fauconnier]

...
Votre exemple est excellent, parce que dans ce cas vous avez visiblement un problème de modélisation. En effet mettre les mails des personnes directement dans la table des personnes est une hérésie, parce que les personnes peuvent avoir plusieurs e-mail ! Ce qui conduirait à email1, email2, email3... et si vous avez besoin d'un xeme email que faire ?
Alors que si vous aviez fait une table des emails et une vue de synthèse associant personnes et mails, cela se serait bien passé !!!*...

Je ne suis pas du tout d'accord. Tout dépend de la finalité du développement. Dans le cas de la gestion de personnes se connectant à Internet, l'adresse électronique est souvent l'identifiant de la personne qui se connecte, donc il ne sert à rien de prévoir x courriels, et il est donc normal que le courriel soit présent dans la table, et je ne vois rien d'hérétique là-dedans...

[_skip]

J'ajouterai que l'on pourrait aussi vouloir stocker un seul email qui sert à contacter ce client, on s'intéresse pas forcément à ses 15 autres adresses? Jamais un site ne m'a demandé de saisir plus d'une adresse email pour ma part.

[SQLpro]

Lorsque vous aurez, comme moi, des clients dont le mail sert à identifier l'internaute, mais avec un volume de pus de 30 millions de mails, alors vous comprendrez hélas trop tard quel est l'intérêt d'avoir une table spécifique pour les emails, et non une colonne "mail" noyée dans une table de 50 colonnes !

A +

[Jester]

Lorsque vous aurez, comme moi, des clients dont le mail sert à identifier l'internaute, mais avec un volume de pus de 30 millions de mails, alors vous comprendrez hélas trop tard quel est l'intérêt d'avoir une table spécifique pour les emails, et non une colonne "mail" noyée dans une table de 50 colonnes !

Vous devez avoir un problème ailleurs parce que cela fonctionne très bien même avec plus de 30 millions.
Je doutes d'ailleurs que vous croyiez vraiment à cette phrase, vous n'avez pas du vous relire ou alors SQL Server ne permet pas de faire ce que je pense qui n'est quand même pas compliqué. Et même, pensez juste au nombre de colones qu'il faut parser pour afficher une page de profil ou autre (dans plusieurs tables si vous voulez), 50 ne me semble pas énorme.

Et croyez moi, je sais de quoi je parle car j'ai enseigné aussi les bases de données aux Arts et Métier (comme si ça prouvait quoi que ce soit de notre compétence).

Enfin sachez qu'il ne coute pas plus cher, ni en temps ni en argent de bien faire dès le départ. Seulement les chefs de projet et plus encore les clients sont obnubilés par le fait d'avoir à montrer rapidement des écrans, dons au détriment de la modélisation et de l'écriture de procédures stockées qui n'ont rien de sexy à montrer !

Sauf qu'une application buggée mais opérationelle rapporte tandis qu'une application qui n'est pas encore opérationnelle mais qui sera sans bug n'en rapporte pas, le coût sera peut-être le même, mais pas la rentabilité.

De plus les bugs logiciels c'est pas le plus gros du problème. Je connais plusieurs logiciels avec un coût supérieur à 1 millions qui ont des bugs au bas mot critique car mal testés, mal codés. Je ne connais pas de logiciels exécutés dans les règles de l'art.
Les vrais problèmes sont ceux fonctionnels (mal pensés, n'adressant pas la bonne cible, ...) et ça le developpement n'y peut rien.


Je ne dis pas qu'il faut bâcler les développements, mais il faut faire preuve de réalisme.

[Pierre Fauconnier]

Lorsque vous aurez, comme moi, des clients dont le mail sert à identifier l'internaute, mais avec un volume de pus de 30 millions de mails, alors vous comprendrez hélas trop tard quel est l'intérêt d'avoir une table spécifique pour les emails, et non une colonne "mail" noyée dans une table de 50 colonnes !

A +

Je ne vois vraiment pas où se situe un problème, même avec 30 millions de lignes, et je ne vois pas en quoi le fait de créer une table pour les emails permet de retrouver plus facilement l'internaute. il va falloir deux tables en jointures pour récupérer les autres données de l'internaute, là où un champ "Mail" dans la table des internautes permet la manipulation d'une seule table. Ce serait bien d'expliquer en détails cette "vérité"...

Créer une table des mails n'est utile que si un internaute a plusieurs mails et que tu dois gérer cela (règle des 0, 1 ou infini)...

Si je dois gérer les membres d'une association et que je souhaite pouvoir leur envoyer des courriels, un champ Mail dans la table des membres me suffit largement, je me fous de savoir qu'ils ont 15 autres adresses. Ils me donnent une adresse, je la stocke dans le champ Mail de la table, et mon appli fonctionne très bien.

Donc, d'accord avec toi pour dire que si l'on doit gérer plusieurs adresses pour un contact, on crée une table des adresses, mais si on ne doit gérer qu'une adresse, cette architecture n'a absolument aucun sens, sur 50 lignes ou sur 30 millions de lignes.

[pmithrandir]

Alors, tant que ses tutos sont frais dans ma teete je vais tenter d'expliquer ce que j'en ai ressorti.

Un des avantages d'avoir une table email est que l'on peut alors séparer l'identifiant du dns... on a donc une table avec

id | monpseudo | idDNS

et une autre avec
id | hotmail.com

De la on a un gain qui peut se reveler important puisque l'on remplace une chaine de caractères par un identifiant. On peut alors rechercher aussi tous les mail hotmail pour une action précise(renvoyer un email parce que l'on a eu un bug juste avec ceux ci la veille) et cela de facon très facile.

Un autree avantage est aussi que l'on peut imaginer d'avoir en plus du pseudo un hash, en général plus court et plus facilement indexable.

on a donc :
id | hash | pseudo | idDNS

Quand on reflechit, on voit que ces solutions apportent plusieurs choses :
- gain de place en général
- indexation plus facile et plus rapide

Après, leur complexité fait que si toutes les données seront organisée a l'optimum, ca sera super chiant a utiliser en l'état pour un developpeur. Trop de jointure et de boulot pour juste récupérer un email.
C'est la que les vues rentre en compte puisqu'au final on aura une vue qui contiendra l'adresse email entière a coté d'un nom, d'un prénom(qui en base est un identifiant pour gagner de la place) etc...

Bref, ce n'est pas absurde, mais c'est clairement pas intuitif et donc pour moi c'st source de bug si l'on a pas un DBA qui fournit ls vues qui vont bien aux developpeurs.

De plus, je ne sais pas si le fait de multiplier les vues peut avoir un quelconque impact sur les performances du serveur ou si c'est transparent pour celui ci.

Il reste que je pense que la première version d'un site dont on a pas la moindre idée de son succés devrait rester simple, et qu'il est presque toujours possible d'interrompre le service pour passer a une version 2.0 et changer l'organisation des tables plus tard pour s'adapter aux nouvelles fonctions et aux nouvelles contraintes. (je ne dit pas de le faire toutes les semaines, mais un fois tous les 2 ans...)
Peu de système ont réeellement le besoin d'une disponibilité 24h/24. Même ma banque me prévient souvent une semaine a l'avance pour mee dire que leur services seront innaccesible pendant 4h la semaine suivante.

[Pierre Fauconnier]

Pierre,

Je vais te dire franchement ce que je pense de ton idée de table pour les emails avec le dns et tout ce que tu expliques...

Je n'ai JAMAIS eu besoin de ce genre de découpage dans les applications que j'ai développées. Pour moi, faire cela, c'est essayer de "coller" à des dogmes tels que ceux que sqlpro délivre lorsqu'il dit qu'il faut une table uniquement pour les emails.

Si la conception amène à devoir traiter plusieurs emails pour un contact, alors oui, on crée une relation m:n avec une table des emails (loi du 0, 1 ou infini). Mais je n'ai encore jamais rencontré de cas où on devait isoler les adresses électroniques par domaine. Donc, le découpage de cette table en plusieurs champs est pour moi un non-sens, dans la plupart des cas. Bien entendu, si tu dois pouvoir isoler rapidement (et souvent) les adresses par domaine, alors, tu peux t'orienter vers une architecture plus complexe, mais c'est souvent du quadricapillodécoupage, à mon sens.

Quand bien même on devrait le faire, il y a des fonctions SQL qui permettent de le faire sur base d'une adresse complète.

Pour moi, l'hérésie, puisque le mot a été employé, réside à vouloir appliquer à tout prix un dogme qui n'a aucun sens sur le plan conceptuel.

Ce n'est pas une attaque personnelle, comprends-le bien! C'est juste un avertissement: Pas de masturbation intellectuelle parce qu'un gourou a dit qu'il fallait une table pour les adresses. Ce genre d'architecture de bd n'a de sens que ci cela colle avec les besoins.

Si tu traites une seule adresse par contact, crée un champ "mail" dans la table des contacts, cela fonctionnera très bien!