Les créateurs du SQL : "Le SQL c'était fait pour les newbies à la base"
45 messages
Mise à jour: il y a 5 mois
Torino
il y a 5 mois
DROP TABLE jvc
IHATEMODELS
il y a 5 mois
c'est chaud le SQL ? de ce que j'en vois ça a l'air assez basique
Zzzzzzzzooooooo
il y a 5 mois
c'est chaud le SQL ? de ce que j'en vois ça a l'air assez basique
Ça dépend ce que tu veux faire. Mais tant que tu gères pas une quantité de données faramineuse, t'es tranquille.
LeVideurDeFleur
il y a 5 mois
c'est chaud le SQL ? de ce que j'en vois ça a l'air assez basique
Ca peut etre tendue si tu dois faire des requetes qui requierent beaucoup de jointures. La requete devient rapidement dense et relativement difficile a lire.
Licker2Slibard2
il y a 5 mois
C'est pas bien compliqué le sql, à la limite créer une bdd et l'optimiser ok mais la requête et le PL c'est ultra simple
FionMignon
il y a 5 mois
Ca peut etre tendue si tu dois faire des requetes qui requierent beaucoup de jointures. La requete devient rapidement dense et relativement difficile a lire.
Ca réveille des traumas là :feldup_trauma_ckienfait:
Prob3corps2
il y a 5 mois
oui, en gros c'est un excel bis. utilité c'est qd meme pour extracter et réorganiser les données en tables.
IHATEMODELS
il y a 5 mois
c'est pas le genre de truc dans lequel chatGPT pourrait exceller ?
Sasa452
il y a 5 mois
SELECT
IMPORT
UPDATE
DELETE
4 commandes, tu demandes quoi de plus pour simplifier?
QiED24
il y a 5 mois
[19:29:23] <Prob3corps2>
oui, en gros c'est un excel bis. utilité c'est qd meme pour extracter et réorganiser les données en tables.
Oui mais bien plus pratique pour dev car c'est conçu pour
FirstJesus
il y a 5 mois
Bordel vous y connaissez rien c'est affligeant
QiED24
il y a 5 mois
[19:31:51] <Sasa452>
SELECT
IMPORT
UPDATE
DELETE4 commandes, tu demandes quoi de plus pour simplifier?
Et DROP alors ?
CompteEfemaire
il y a 5 mois
Mais c'est pas tres compliqué SQL, mais pour faire des choses assez complexe .
Quasi tout les informaticien on sql sur leur cv
Trajanus
il y a 5 mois
Easy le SQL.
Sauf quand tu dois créer de fausses tables temporaires avec des fausses data pour ne pas passer de "Janvier à Mars" parce que Février a eu 0 entrée.
fiondegerminal
il y a 5 mois
ils ont réussi, le sql est extrêmement puissant et pourtant assez simple
LeVideurDeFleur
il y a 5 mois
Et DROP alors ?
Moi je trouve ca simple comme syntaxe. T'as 10 types d'actions differentes et basta. C'est juste les implementations qui ont des Views, les Index et autres conneries qui rendent tout ca plus compliques
[0]GermanQueen
il y a 5 mois
[19:32:35] <QiED24>
Et DROP alors ?
INSERT INTO aussi
CityOfTheDead
il y a 5 mois
Faire des requêtes imbriquées
Jamais compris LEFT JOIN, RIGHT JOIN, OUTER JOIN
LitDeChloe
il y a 5 mois
Faire du sql basique c'est simple
Faire des requêtes complexes avec des sous tables et des jointures de partout ça devient vite la merde
Et le EXPLAIN ANALYZE c'est aussi bien la merde pour comprendre par moment
JVChiottard
il y a 5 mois
C'est pas la faute au SQL mais au gens qui dev mal les APIs et qui filtre pas les request
Mais même avec un filtre, il y a 300 000 façons d'arriver à tes fins. Avec des format strings, en utilisant certaines fonctions de facçon redoutable, en jouant avec les espaces et les caractères unicode, en parsemant de l'hexa ici et là, en exploitant des alias, en faisant des blond requests, etc, etc.
C'est pas le niveau des devs le vrai problème. Le problème c'est la syntaxe trop permissive et le nombre incroyable de fonctions disponibles et qui n'ont rien à foutre dans un langage destiné à faire des requêtes pour récupérer les lignes d'un tableau en gros.
Depuis les requêtes préparées les vieux trucs comme ' or 1=1-- ne fonctionnent plus Dieu merci
Mais c'est toujours possible de remplir des tables avec des données de merde et de faire une "injection d'injection" et là filtre ou pas tu es owned.
Ce sera toujours 1000 fois plus safe de faire une requête tout bête sans filtre ni quoi que ce soit, et de filtrer programmatiquement ton itérateur derrière
var r = requeteSQLQuiFaitCeciCela(db, table);
var r_filtre = from truc in r
select machin(truc)
where bidule;
foreach( var ligne in r_filtre )
faireDuCaca(ligne);
KarukHarak
il y a 5 mois
En soit c'est pas du tout compliqué mais juste CHIANT a mourir et les gens en ont peur pour je ne sais quel raison.
Mais tant mieux, ca permet de mieux négocier pendant l'entretien
4P3X
il y a 5 mois
Et c'est totalement le cas, à moins d'être un low tu maîtrise 60% du truc en une journée, et c'est ce dont la majorité à besoin le reste ça s'apprend vite et c'est inutile
FionMignon
il y a 5 mois
SELECT
IMPORT
UPDATE
DELETE4 commandes, tu demandes quoi de plus pour simplifier?
Imagine utiliser du SQL sans utiliser JOIN
massacram
il y a 5 mois
les requêtes poussées de SQL ça peut être une galère mais heureusement que ChatGPT existe
JVChiottard
il y a 5 mois
Vite interdisons le SQL
Putain t'as rien compris tu prends le problème à l'envers
Lis mes posts suivants, je ne prends rien à l'envers du tout et je n'ai jamais parlé d'interdire quoi que ce soit
Je dénonce simplement le travers qui consiste à tout faire dans une requête foireuse SQL et d'y injecter par dessus le marché des user inputs.
Selon moi et de nombreux kheys sur ce topic, SQL ne devrait rien proposer d'autre que des opérations de base et rester un langage pour low IQ ; plutôt que de fédérer les golems qui veulent se faire mousser avec des union, des join externes, à gauche et à droite et dans mon cul. Au lieu de simplement faire deux requêtes asynchrones basiques et de les filtrer dans leur code. Et ne me parle pas de vitesse d'éxecution, c'est bien la dernière chose à optimiser
LitDeChloe
il y a 5 mois
Lis mes posts suivants, je ne prends rien à l'envers du tout et je n'ai jamais parlé d'interdire quoi que ce soit
Je dénonce simplement le travers qui consiste à tout faire dans une requête foireuse SQL et d'y injecter par dessus le marché des user inputs.
Selon moi et de nombreux kheys sur ce topic, SQL ne devrait rien proposer d'autre que des opérations de base et rester un langage pour low IQ ; plutôt que de fédérer les golems qui veulent se faire mousser avec des union, des join externes, à gauche et à droite et dans mon cul. Au lieu de simplement faire deux requêtes asynchrones basiques et de les filtrer dans leur code. Et ne me parle pas de vitesse d'éxecution, c'est bien la dernière chose à optimiser
Oui oui on va faire 2 requêtes pour récup un user par id parce qu un low qi à peur d'utiliser les query params
D'abord on va fetch toute la table avec des millions de lignes potentiels et faire un vieux filter derrière, niveau perf on tiens un génie ahi
souil51
il y a 5 mois
Lis mes posts suivants, je ne prends rien à l'envers du tout et je n'ai jamais parlé d'interdire quoi que ce soit
Je dénonce simplement le travers qui consiste à tout faire dans une requête foireuse SQL et d'y injecter par dessus le marché des user inputs.
Selon moi et de nombreux kheys sur ce topic, SQL ne devrait rien proposer d'autre que des opérations de base et rester un langage pour low IQ ; plutôt que de fédérer les golems qui veulent se faire mousser avec des union, des join externes, à gauche et à droite et dans mon cul. Au lieu de simplement faire deux requêtes asynchrones basiques et de les filtrer dans leur code. Et ne me parle pas de vitesse d'éxecution, c'est bien la dernière chose à optimiser
Une requête SQL peut trier et filtrer des centaines de milliers voire des millions de lignes en moins de 100ms. Essaie de faire pareil dans n'importe quel langage on va bien rigoler.
JVChiottard
il y a 5 mois
Une requête SQL peut trier et filtrer des centaines de milliers voire des millions de lignes en moins de 100ms. Essaie de faire pareil dans n'importe quel langage on va bien rigoler.
Oui oui bien sûr, c'est tous les jours que tu filtres des millions de lignes dans une seule table
Quant à l'olibrius qui me parle de QI, il se désigne lui même et fait apparaitre aux yeux de tous son incompétence.
Qu'est ce qui est le plus sûr, facile à documenter, à comprendre, et à tester entre
- dix requêtes indépendantes qu'on fait logiquement coopérer manuellement
- une seule requête avec des colonnes de plus de 65 caractères, 9 joins, des unions, des group by, des flatten, le tout avec des fonctions difficiles à debugger qui génèrent des strings à partir d'un input soi-disant neutralisé de l'utilisateur ?
Quel ingénieur un minimum intelligent en a quelque chose à foutre que ta reqûete fasse 500ms au lieu de 100ms dans le pire des cas.
T'es le genre de mec qui écrit a^= b ^= a ^= b au lieu de swap(a,b) ou a,b = b,a ?
Ou le genre de mec qui importe systématiquement jquery dans ses userscripts tous pourris alors qu'un querySelector ou document.getElementById fait largement le taf ?
Ou le mec qui croit que a *= b; a += c est plus rapide que a = a * b + c et ignore que la plupart des processeurs ont des instructions muladd ?
SonicGlisseur
il y a 5 mois