Discussion :

[gotax]

Bonjour tout le monde,

Voila je n'arrive pas a créer une table en MySQL sur PhpMyAdmin : j'ai toujours l'erreur 1064 a la fin. Je ne comprends pas d'où elle vient.
Voici les instructions:

Code SQL :

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

1
2
3
4
5
6
7
8
CREATE TABLE produit(
    id INT PRIMARY KEY AUTO_INCREMENT,
    nom VARCHAR,
    description TEXT,
    categorie INT,
    prix FLOAT,
    CONSTRAINT FOREIGN KEY (categorie) REFERENCES categorie(id)
    );

MySQL a répondu :

Documentation
#1064 - Erreur de syntaxe près de '
    description TEXT,
    categorie INT,
    prix FLOAT,
    CONSTRAINT ...' à la ligne 3

Comment puis-je résoudre le problème ?

Merci d'avance.

[Obsidian]

Bonjour,

Le type VARCHAR attend nécessairement une taille maximum même si la longueur de chaîne que le champ va contenir peut être variable. Par exemple, pour une longueur maximale de 64 caractères, il faut écrire VARCHAR(64).

Plus généralement, pour t'aider à déboguer tes futures requêtes, examine bien le message d'erreur et vois ce qu'il te dit.

Erreur de syntaxe près de '
description TEXT,
categorie INT,

Il s'agit d'une « erreur de syntaxe », donc d'une clause incompréhensible par l'analyseur lexical (parser) et donc mal écrite. Ensuite, il est dit que cela commence à partir « de « description TEXT… ». Donc a priori, c'est à partir de la ligne où tu définis le champ « description » que le problème se pose, mais il arrive souvent également (et c'est le cas ici) que l'expression qui précède soit incomplète. L'analyseur attend donc gentiment la suite sans se plaindre mais si tu lui passes tout de suite l'expression suivante, même si celle-ci est correcte en elle-même, il va considérer que c'est la suite de la précédente et l'expression n'a alors aucun sens dans ce contexte, d'où l'erreur.

Donc le premier réflexe à avoir est de regarder la où l'analyseur syntaxique nous envoie puis, si on ne trouve rien de particulier à cet endroit, de remonter quelques lignes en amont pour vérifier si l'erreur n'est pas provoquée indirectement par un autre changement.

[gotax]

Ah d'accord, je te remercie pour ces excellents conseils! Je suis entrain de reprendre le SQL de zero pour combler mes lacunes. Certains me disent que c'est de la perte de temps puisqu'il y a les ORM maintenant. Qu'en pensez vous?

[Séb.]

Avec un ORM tu ne pourras jamais exploiter les nombreuses possibilités offertes par SQL, ou alors ça revient à singer SQL.

[gotax]

D'accord je vois. Mais a t-on si souvent que ca besoin d'utiliser vraiment toutes les options du SQL? Il me semble qu'il y a generalement une dizaines de query qui reviennent tous le temps, a moins d'etre un administrateur de BD.

[Obsidian]

Certains me disent que c'est de la perte de temps puisqu'il y a les ORM maintenant. Qu'en pensez vous?

Que c'est infondé.

Le SQL est un des rares langages qui étaient déjà enseignés dans les facs même dans les années 1980 (et à cette époque, l'informatique n'était pas encore répandue qu'elle l'est aujourd'hui, et les ressources disponibles étaient autrement plus restreintes) et qui soient toujours largement utilisés aujourd'hui. Pratiquement tous les SGBD l'ont adopté et avec la mise à disposition des systèmes légers tels que SQLite, on utilise des bases de données même pour les petites applications là où on utilisait encore de simples fichiers. Ça a été notamment le cas de Firefox (même si cela fait un moment que la migration a eu lieu), qui gérait les bookmarks dans un fichier à plat et qui est passé à SQLite pour le faire. Rien que pour cela, ça vaut le coup de savoir parcourir un fichier SQLite pour ses applications quotidiennes.

Les ORM, maintenant, sont une solution qui s'est imposée d'elle-même pour enregistrer les instances des objets déclarés dans les langages orientés objet. Si l'on considère qu'un objet, abstraction faite de l'héritage et du polymorphisme, n'est en fin de compte qu'une liste de propriétés prédéfinies, alors cela en fait un n-uplet et ils peuvent tout-à-fait être représentés par une entrée dans une table de base de données. Mais les ORM servent surtout à enregistrer et relire facilement ces objets sans avoir à réécrire cent fois les mêmes requêtes, lesquelles se résumeraient — pour faire simple — à de simples INSERT ou SELECT, mais à condition d'avoir une table par classe et de passer à chaque fois la liste des champs exacts de cette classe et pas une autre.

Par contre, très peu d'ORM sont capables de gérer efficacement le côté relationnel des bases de données et de te permettre d'écrire des « requêtes » au sens propre : c'est-à-dire d'interroger la base de données de façon élaborée pour avoir une réponse à une question précise. Rien que faire une jointure devient une plaie si l'ORM n'est pas prévu pour.

On se rend compte d'ailleurs qu'en partant de ce type d'architecture et en essayant de le faire évoluer pour répondre aux besoins du dernier paragraphe, on aboutit à des choses comme Lavarel et in fine, à faire du SQL déguisé. Donc autant maîtriser le vrai dès le départ.

[gotax]

Alors justement c'est très interessant ce que tu dis la à propos de Laravel (Eloquent) car je l'a utilisé très peu durant un bref stage... Je l'ai trouvé très verbeux et assez mal foutu comparé a LINQ et Entity Framework qui permettent a mon avis une meilleure interaction et une meilleure interrogation de la B.D. Qu'en penses tu?

[Séb.]

D'accord je vois. Mais a t-on si souvent que ca besoin d'utiliser vraiment toutes les options du SQL? Il me semble qu'il y a generalement une dizaines de query qui reviennent tous le temps, a moins d'etre un administrateur de BD.

Pour un usage basique un ORM peut suffire, en effet. Wordpress et autres CMS aussi d'ailleurs. Mais veut-on vraiment ne se cantonner qu'à cela ?

Pour LINQ, pas d'avis car inconnu au bataillon.

Concernant Eloquent / Laravel, tout dépend comment ils ont été utilisé. L'intérêt est d'utiliser au maximum les facilités offertes par le couple, comme les route model binding.

[Obsidian]

En réalité, j'ai très peu (voire pas du tout) utilisé les frameworks de haut niveau. L'ennui avec ces frameworks, spécialement ceux dédiés au web (ce qui n'est pas le cas ici) est que d'un côté, on s'aperçoit que pour le moindre projet :

• on est quasiment obligé de ré-écrire son propre framework lorsque l'on décide de s'en passer et ce n'est vraiment pas tenable, surtout si on souhaite conduire plusieurs projets à terme ;
• De l'autre côté : on est pratiquement obligé de se spécialiser sur un de ces frameworks parce que le projet doit s'appuyer dessus et ça devient pratiquement de la programmation système. Or, non seulement cela nous éloigne de fait d'autres technologies potentielles mais ça limite les plateformes utilisables, c'est très gourmand en ressource et surtout, on ne sait pas à l'avance si le framework va tenir ses promesses ou s'il va souffrir des mêmes tares que le projet initial, justement parce qu'il est né dans les mêmes conditions.

Sur ce dernier point en particulier, on s'aperçoit souvent que bon nombre de frameworks libres, quand on consulte leur historique, étaient initialement des frameworks maison, développés en interne pour les besoins de la compagnie. Et comme ceux-ci doivent naturellement être maintenus et stabilisés suffisamment longtemps pour que les produits qu'ils sont censés soutenir fonctionnent, ils arrivent en général à la maturité nécessaire pour les rendre publics.

Je l'ai trouvé très verbeux et assez mal foutu comparé a LINQ et Entity Framework qui permettent a mon avis une meilleure interaction et une meilleure interrogation de la B.D. Qu'en penses tu?

Pour Laravel en particulier, je n'en ai vu que quelques posts sur certains forums. Ce qui était intéressant, c'est le fait de pouvoir ajouter des clauses à une instance d'un objet en plusieurs appels et éventuellement dans le désordre, ce qui est pratique pour faire des requêtes conditionnelles, le framework reconstituant la requête entière au moment de l'appel. Ça permet d'utiliser des « if » sans avoir à tripoter la chaîne de caractères qui contient la requête elle-même pour rajouter des prédicats et/ou des jointures. Pour le reste, en revanche, on s'aperçoit que les primitives sont très proches de celles du SQL lui-même, ce qui est volontaire. Donc, on suppose que l'utilisateur connaît déjà le SQL et s'appuie sur le framework pour bénéficier de ces facilités, plutôt qu'être un développeur spécialisé dans cette plateforme en particulier.

Par ailleurs, il faut garder à l'esprit qu'à la fin du traitement, c'est bien une requête SQL qui est envoyée au serveur. Donc, lorsque on reprend les logs serveur pour vérifier ce qui a été retourné en cas de bug, il vaut mieux savoir les lire là aussi.

Pour répondre à une autre question, on n'est pas forcément obligé de connaître l'intégralité du SQL par cœur pour pratiquer mais il vaut mieux apprendre dès le départ à faire une jointure propre car dans les faits, cela va former la majorité du travail.

Je ne peux que te conseiller le cours légendaire de SQLPro, disponible ici :
https://sqlpro.developpez.com/

[gotax]

@Obsidian:

Oui effectivement avec les frameworks "web" il faut obligatoirement les utiliser et de se spécialiser la dedans. Limite y a plus le statut de "developpeur X" mais de "Operateur X" genre "Operateur React ou Laravel"... Mais il parait que c'est le futur et que c'est a la mode donc... Pour le SQL je suis d'accord qu'il faille le maitriser, c'est quand meme la base pour un dev back end, au moins pour etre autonome et ne pas etre perdu quand il n y a pas l'ORM de service.

Merci pour le lien!

@Seb:
LINQ c'est l'ORM du .NET framework de Microsoft (avec EF Core). Effectivement cantonné au dev .NET. Après pour la question si on veut se cantonner à un usage de base du SQL ou non, moi je suis partisan du minimum, si ca suffit c'est bon.

[Obsidian]

Mais il parait que c'est le futur et que c'est a la mode donc...

Effectivement : « le futur et à la mode » …jusqu'à la prochaine !

Je veux bien que le lot des développeurs (comme pas mal d'autres métiers) soit de se former en permanence, mais il y a une limite à tout parce qu'autrement, on ne peut pas monter en compétence sur la technologie actuelle. Et si on se spécialise trop sur cette technologie actuelle, on risque de tout perdre et de devoir repartir de zéro quand elle deviendra obsolète.

Pour le SQL je suis d'accord qu'il faille le maitriser, c'est quand meme la base pour un dev back end,

Oui, mais comme tu le sous-entendais, c'est toujours une bonne chose d'avoir le plus de cordes à son arc, tout l'enjeu étant de savoir où est-ce que l'on pose « l'horizon ». Et pour répondre à ta question initiale, donc : oui, on peut dire que le SQL est une technologie qui mérite l'investissement qu'on s'apprête à lui consacrer. À la fois sur la longévité et sur sa transversalité.

au moins pour etre autonome et ne pas etre perdu quand il n y a pas l'ORM de service.

Là encore, c'est important de faire la précision : les ORM ne « remplaceront » jamais le SQL, ne serait-ce que parce qu'ils omettent justement le côté « requête » de la chose, qui est censé être l'âme-même du langage (Structured Query Language). Ils sont utiles pour faire la correspondance entre la base de données et les instances volatiles d'un programme orienté objet en cours d'exécution mais pas pour interroger la base. Et lorsqu'ils le sont, on finit par retomber sur quelque chose qui est au moins aussi volubile que le SQL et qui lui ressemble beaucoup.

Ce dernier point n'est d'ailleurs pas un hasard. Le SQL lui-même s'appuie sur les travaux du Dr Codd et sur l'algèbre relationnelle (la page Wikipédia donne d'ailleurs l'équivalent SQL des opérateurs).

Si je te dis par exemple « trouvez-moi la liste de tous les acteurs qui ont soit joué dans un film de Pedro Almodovar, soit dans au moins trois films connus de la base », ça s'écrit en une seule requête en SQL mais c'est très compliqué à expliquer à l'ORM. Même chose avec les fonctions d'agrégation et les regroupements. A contrario, on n'a pas forcément envie, dans ce cas précis, d'instancier tous les objets « films » qui y correspondent. Le nom et l'ID peuvent suffire.

Après pour la question si on veut se cantonner à un usage de base du SQL ou non, moi je suis partisan du minimum, si ca suffit c'est bon.

Ça aussi, ça mérite qu'on s'y attarde : c'est aussi ma philosophie quand il s'agit de faire des « choix ». Mais par « minimum », j'entends « le minimum de dépendances possibles ». J'éprouve une certaine satisfaction quand un projet ou un script fonctionne avec le seul tronc commun d'un langage (core ou vanilla) sans avoir à trop réinventer la roue. S'il s'agit juste de faire une fonction de trim ou de formatage d'une date, en général je la réécris pour éviter de se trimbaler une dépendance juste pour cela. Et quand ça finit par devenir vraiment compliqué, là j'envisage soit une norme récente, soit une bibliothèque donnée et une fois l'effet de seuil déclenché, je me l'autorise entièrement. J'essaie donc de la choisir de façon à ce qu'elle soit suffisamment riche pour ne pas avoir à franchir de nouveaux paliers trop souvent.

Par contre, ça a l'air d'être à l'opposé de la tendance dans le développement web où soit on utilise une pléthore de packages NPM pour la moindre fonction, soit des imports à répétition, tendance d'autant plus accentuée avant les versions récentes d'EcmaScript où les lacunes des langages de scripts poussaient à l'emploi d'environnements comme JQuery ou autre.

[gotax]

Je veux bien que le lot des développeurs (comme pas mal d'autres métiers) soit de se former en permanence, mais il y a une limite à tout parce qu'autrement, on ne peut pas monter en compétence sur la technologie actuelle. Et si on se spécialise trop sur cette technologie actuelle, on risque de tout perdre et de devoir repartir de zéro quand elle deviendra obsolète.

J'avoue que cela me fait peur... et je trouve que c'est particulièrement vrai dans le dev web, ca fini un peu par peser sur le long terme. D'ailleurs on parle souvent de gens qui entament des reconversions dans le developpement web a cause du "manque de main d'oeuvre (merci les youtubeurs qui oublient de preciser que pour les juniors c'est une jungle, pas mieux qu'un autre secteur) mais on parle jamais du nombre de devs qui quittent le domaine a cause de la charge de travail et de la pression liée.

Par contre, ça a l'air d'être à l'opposé de la tendance dans le développement web où soit on utilise une pléthore de packages NPM pour la moindre fonction, soit des imports à répétition, tendance d'autant plus accentuée avant les versions récentes d'EcmaScript où les lacunes des langages de scripts poussaient à l'emploi d'environnements comme JQuery ou autre.

C'est exactement ca, c'est peut etre du a un effet tendance, ou je ne sais quoi mais en tout cas ca pèse sur long terme a mon avis. C'est bien pour ca que je m'oriente vers le developpement d'ERP en .NET, le package est clair et stable depuis 10 ans au moins. Ca fait le travail et c'est tout aussi gratifiant.