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.

[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]

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?

[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/