En plus je sens bien le truc venir de la liste des choses indispensables a connaitre...
Rien de tout cela, à mon avis.
Je suis assez d'accord avec lui quand il dit qu'au départ, les bases de données sont un sujet qui a l'air rébarbatif aux jeunes programmeurs. C'est même un problème quand ça dure dans le temps, au point d'avoir un chef qui se sent obligé d'expliquer leur métier à tous les développeurs mais qui met un point d'honneur à dire que les bases de données ne sont pas dans son périmètre, justifiant ainsi ses soi-disant domaines d'expertise (en fait, ses centres d'intérêts, qui sont bien souvent les mêmes que tout le monde. Et, oui, tout le monde aura compris que c'est là encore un exemple vécu.)
L'ennui avec les DB, c'est qu'on les enseigne bien souvent avec le traditionnel annuaire ou la base de données clients (nom, prénom, adresse, numéro de client, liste des produits achetés, etc.). Déjà rien de folichon en soi mais, en général, on doit aussi construire et surtout remplir la base soi-même. Donc, des heures de insert à recommencer sans arrêt pour se retrouver au final avec une base de cinq clients et trois commandes. :-\ Il est beaucoup plus intéressant, à mon avis, de se faire les dents sur une base déjà faite et bien remplie, avec un schéma visuel et bien explicite, surtout que cela ne pose aucune difficulté technique : il est tout-à-fait possible d'accorder des droits en lecture seule sur la base à un profil donné et de lui conférer en plus la possibilité de créer les siennes dans un tablespace bien défini, avec bien sûr les contraintes d'intégrité qui s'imposent. Personnellement, j'ai totalement pris goût au SQL lorsque j'ai commencé à travailler sur la base de gènes qui m'a occupé pendant six ans. Donc en faisant des requêtes dans une base avec beaucoup de tables, énormément de données (des millions d'enregistrements par table sur une base Sybase de l'époque).
et que c'est une humilitation d'un ignorer une. Eviter la honte est plutot une mauvaise motivation d'apprentissage.
Non plus. C'est plutôt que ces notions sont intimement liées aux SGBDR et en fait, c'est même pour elles qu'ils ont été conçus ! Sinon, ils n'apportent pas grand chose de plus que de simples fichiers. Au passage, on rappelle qu'initialement, un « fichier », c'est une boîte à fiches. Et c'est bien pour faire ce genre de traitement qu'ils ont été inventés sur les ordinateurs. Comme depuis le départ, un fichier est implémenté comme une suite continue de données, on les utilise majoritairement cette fin : sauvegarder une séquence d'octets continue quelle qu'elle soit, et c'est très bien comme ça. Mais ça explique pourquoi les appels comme fread() permettent de préciser la longueur d'un enregistrement ET le nombre d'enregistrements à lire, et pourquoi un certain nombre de langages définissent les champs destinés aux fichiers comme étant de taille fixe et comblés par des espaces.
En plus, ce n'est pas forcément difficile. C'est plutôt une bonne habitude à prendre depuis le départ. Et très vite, dresser un schéma bien léché devient un plaisir de fin gourmet.
Alors naturellement, il ne s'agit pas de faire de tout un chacun un expert base de données mais en revanche, la façon dont tu poses la question laisse penser qu'en effet, pour un certain nombre de personnes, une base MySQL serait un peu l'équivalent d'une base de registre Windows. Si c'est le cas, et qu'en plus c'est en toute bonne foi, alors c'est peut-être, en effet, quelque chose à surveiller puisque l'on tenait cela pour acquis depuis longtemps.
En plus, c'est réellement important qu'il est extrêmement difficile de gérer « à la main » les contraintes d'intégrité dès lors qu'on dépasse deux ou trois tables. Il n'y a qu'à comptabiliser le nombre de fois que l'on s'est vu opposer une erreur par le SGBD au départ pour se rendre compte que chacune d'elle était en fait une catastrophe potentielle évitée. C'est un peu comme les segfaults quand on fait du langage C ou autre langage compilé en langage machine. Il faut se souvenir que même sur PC, on a attendu le 286 et surtout le 386 pour avoir un mode protégé et que même avec eux, le DOS n'a réellement pris sa retraite qu'avec les années 2000. Cela veut aussi dire qu'en fin de compte, ça ne fait qu'une petite quinzaine d'années que l'informatique grand public est proprement sécurisée de ce côté. :)
[^] # Re: Beaucoup de dev ne savent pas faire du SQL
Posté par Obsidian . En réponse au journal Optimisez votre code !. Évalué à 3.
Rien de tout cela, à mon avis.
Je suis assez d'accord avec lui quand il dit qu'au départ, les bases de données sont un sujet qui a l'air rébarbatif aux jeunes programmeurs. C'est même un problème quand ça dure dans le temps, au point d'avoir un chef qui se sent obligé d'expliquer leur métier à tous les développeurs mais qui met un point d'honneur à dire que les bases de données ne sont pas dans son périmètre, justifiant ainsi ses soi-disant domaines d'expertise (en fait, ses centres d'intérêts, qui sont bien souvent les mêmes que tout le monde. Et, oui, tout le monde aura compris que c'est là encore un exemple vécu.)
L'ennui avec les DB, c'est qu'on les enseigne bien souvent avec le traditionnel annuaire ou la base de données clients (nom, prénom, adresse, numéro de client, liste des produits achetés, etc.). Déjà rien de folichon en soi mais, en général, on doit aussi construire et surtout remplir la base soi-même. Donc, des heures de insert à recommencer sans arrêt pour se retrouver au final avec une base de cinq clients et trois commandes. :-\ Il est beaucoup plus intéressant, à mon avis, de se faire les dents sur une base déjà faite et bien remplie, avec un schéma visuel et bien explicite, surtout que cela ne pose aucune difficulté technique : il est tout-à-fait possible d'accorder des droits en lecture seule sur la base à un profil donné et de lui conférer en plus la possibilité de créer les siennes dans un tablespace bien défini, avec bien sûr les contraintes d'intégrité qui s'imposent. Personnellement, j'ai totalement pris goût au SQL lorsque j'ai commencé à travailler sur la base de gènes qui m'a occupé pendant six ans. Donc en faisant des requêtes dans une base avec beaucoup de tables, énormément de données (des millions d'enregistrements par table sur une base Sybase de l'époque).
Non plus. C'est plutôt que ces notions sont intimement liées aux SGBDR et en fait, c'est même pour elles qu'ils ont été conçus ! Sinon, ils n'apportent pas grand chose de plus que de simples fichiers. Au passage, on rappelle qu'initialement, un « fichier », c'est une boîte à fiches. Et c'est bien pour faire ce genre de traitement qu'ils ont été inventés sur les ordinateurs. Comme depuis le départ, un fichier est implémenté comme une suite continue de données, on les utilise majoritairement cette fin : sauvegarder une séquence d'octets continue quelle qu'elle soit, et c'est très bien comme ça. Mais ça explique pourquoi les appels comme fread() permettent de préciser la longueur d'un enregistrement ET le nombre d'enregistrements à lire, et pourquoi un certain nombre de langages définissent les champs destinés aux fichiers comme étant de taille fixe et comblés par des espaces.
En plus, ce n'est pas forcément difficile. C'est plutôt une bonne habitude à prendre depuis le départ. Et très vite, dresser un schéma bien léché devient un plaisir de fin gourmet.
Alors naturellement, il ne s'agit pas de faire de tout un chacun un expert base de données mais en revanche, la façon dont tu poses la question laisse penser qu'en effet, pour un certain nombre de personnes, une base MySQL serait un peu l'équivalent d'une base de registre Windows. Si c'est le cas, et qu'en plus c'est en toute bonne foi, alors c'est peut-être, en effet, quelque chose à surveiller puisque l'on tenait cela pour acquis depuis longtemps.
En plus, c'est réellement important qu'il est extrêmement difficile de gérer « à la main » les contraintes d'intégrité dès lors qu'on dépasse deux ou trois tables. Il n'y a qu'à comptabiliser le nombre de fois que l'on s'est vu opposer une erreur par le SGBD au départ pour se rendre compte que chacune d'elle était en fait une catastrophe potentielle évitée. C'est un peu comme les segfaults quand on fait du langage C ou autre langage compilé en langage machine. Il faut se souvenir que même sur PC, on a attendu le 286 et surtout le 386 pour avoir un mode protégé et que même avec eux, le DOS n'a réellement pris sa retraite qu'avec les années 2000. Cela veut aussi dire qu'en fin de compte, ça ne fait qu'une petite quinzaine d'années que l'informatique grand public est proprement sécurisée de ce côté. :)