Maîtriser SQL , ca prend combien de temps
Le 17 mai 2023 à 10:46:28 :
La syntaxe SQL n'est pas dure, le langage a été conçu pour des non-programmeurs.La difficulté réside dans la compréhension des BDD, leur structure et comment faire des requêtes propres, plus ou moins complexes et optimisées selon la situation.
Les instructions clé osef, t'auras toujours accès à la documentation technique.
Pour le coup, j’ai mis 30 secondes à comprendre le concept de clôture algébrique sur les bases de données relationnelles, c’est vraiment simple à comprendre.
Le 17 mai 2023 à 10:49:10 :
Le 17 mai 2023 à 10:46:28 :
La syntaxe SQL n'est pas dure, le langage a été conçu pour des non-programmeurs.La difficulté réside dans la compréhension des BDD, leur structure et comment faire des requêtes propres, plus ou moins complexes et optimisées selon la situation.
Les instructions clé osef, t'auras toujours accès à la documentation technique.
Pour le coup, j’ai mis 30 secondes à comprendre le concept de clôture algébrique sur les bases de données relationnelles, c’est vraiment simple à comprendre.
15 secondes grand max le low
Le 17 mai 2023 à 10:49:52 :
Le 17 mai 2023 à 10:49:10 :
Le 17 mai 2023 à 10:46:28 :
La syntaxe SQL n'est pas dure, le langage a été conçu pour des non-programmeurs.La difficulté réside dans la compréhension des BDD, leur structure et comment faire des requêtes propres, plus ou moins complexes et optimisées selon la situation.
Les instructions clé osef, t'auras toujours accès à la documentation technique.
Pour le coup, j’ai mis 30 secondes à comprendre le concept de clôture algébrique sur les bases de données relationnelles, c’est vraiment simple à comprendre.
15 secondes grand max le low
Non mais rien à voir, je ne suis pas brillant, suffit juste de comprendre qu’il ne faut pas mettre de liste dans une BDD et c’est réglé.
Le 17 mai 2023 à 10:51:44 :
Le 17 mai 2023 à 10:49:52 :
Le 17 mai 2023 à 10:49:10 :
Le 17 mai 2023 à 10:46:28 :
La syntaxe SQL n'est pas dure, le langage a été conçu pour des non-programmeurs.La difficulté réside dans la compréhension des BDD, leur structure et comment faire des requêtes propres, plus ou moins complexes et optimisées selon la situation.
Les instructions clé osef, t'auras toujours accès à la documentation technique.
Pour le coup, j’ai mis 30 secondes à comprendre le concept de clôture algébrique sur les bases de données relationnelles, c’est vraiment simple à comprendre.
15 secondes grand max le low
Non mais rien à voir, je ne suis pas brillant, suffit juste de comprendre qu’il ne faut pas mettre de liste dans une BDD et c’est réglé.
Le sujet des DB relationnelles commence à un peu m’intéresser. Pourquoi pas de listes en DB ?
Le 17 mai 2023 à 10:53:06 :
Et pour faire des requêtes rapides, suffit de foutre des index partout.
Ça me paraît un peu approximatif…
Après pour avoir une expertise c'est plus compliqué.
J’ai un collègue qui a vendu une requête SQL à un grand groupe qui avait besoin d’un extract d’info en urgence, c'était 2000 ou 3000 euros la requête. Faut pas se merder à ce niveau là
Le 17 mai 2023 à 10:52:55 :
Le 17 mai 2023 à 10:51:44 :
Le 17 mai 2023 à 10:49:52 :
Le 17 mai 2023 à 10:49:10 :
Le 17 mai 2023 à 10:46:28 :
La syntaxe SQL n'est pas dure, le langage a été conçu pour des non-programmeurs.La difficulté réside dans la compréhension des BDD, leur structure et comment faire des requêtes propres, plus ou moins complexes et optimisées selon la situation.
Les instructions clé osef, t'auras toujours accès à la documentation technique.
Pour le coup, j’ai mis 30 secondes à comprendre le concept de clôture algébrique sur les bases de données relationnelles, c’est vraiment simple à comprendre.
15 secondes grand max le low
Non mais rien à voir, je ne suis pas brillant, suffit juste de comprendre qu’il ne faut pas mettre de liste dans une BDD et c’est réglé.
Le sujet des DB relationnelles commence à un peu m’intéresser. Pourquoi pas de listes en DB ?
Parce que c’est plus efficace de mettre tous les éléments de toutes les listes dans une table à part, notamment parce que ça t’évite d’avoir à modifier la liste à chaque fois pour rajouter un élément.
Quand la donnée est dans la table t’es pas censé la modifier, sauf si c’est pour la corriger.
Si tu veux récupérer une liste, tu la construis à partir de ta table.
Si tu fais des trucs basiques 10 minutes
Si tu fais des trucs ignobles avec exceptions etc.. bonne chance
Doit y avoir une IA pour
Le 17 mai 2023 à 10:55:00 :
Le 17 mai 2023 à 10:52:55 :
Le 17 mai 2023 à 10:51:44 :
Le 17 mai 2023 à 10:49:52 :
Le 17 mai 2023 à 10:49:10 :
> Le 17 mai 2023 à 10:46:28 :
>La syntaxe SQL n'est pas dure, le langage a été conçu pour des non-programmeurs.
>
> La difficulté réside dans la compréhension des BDD, leur structure et comment faire des requêtes propres, plus ou moins complexes et optimisées selon la situation.
>
> Les instructions clé osef, t'auras toujours accès à la documentation technique.
Pour le coup, j’ai mis 30 secondes à comprendre le concept de clôture algébrique sur les bases de données relationnelles, c’est vraiment simple à comprendre.
15 secondes grand max le low
Non mais rien à voir, je ne suis pas brillant, suffit juste de comprendre qu’il ne faut pas mettre de liste dans une BDD et c’est réglé.
Le sujet des DB relationnelles commence à un peu m’intéresser. Pourquoi pas de listes en DB ?
Parce que c’est plus efficace de mettre tous les éléments de toutes les listes dans une table à part, notamment parce que ça t’évite d’avoir à modifier la liste à chaque fois pour rajouter un élément.
Quand la donnée est dans la table t’es pas censé la modifier, sauf si c’est pour la corriger.
Si tu veux récupérer une liste, tu la construis à partir de ta table.
Ah oui effectivement. En NoSQL on fait pas forcément exactement pareil mais je vois l’idée.
Ça me revient. C’est vraiment les fondamentaux en DB relationnelles, non ?
Le 17 mai 2023 à 10:56:29 :
Le 17 mai 2023 à 10:53:06 :
Et pour faire des requêtes rapides, suffit de foutre des index partout.Hash statique ? Dynamique ? B tree ? B+ tree ? Bitmap ? Index secondaire ?
J’imagine que la performance dépend des données, je suis pas un expert dans le domaine, même si je connais les différents types d’index et la manière dont ils fonctionnent.
Le 17 mai 2023 à 10:58:44 :
Le 17 mai 2023 à 10:56:29 :
Le 17 mai 2023 à 10:53:06 :
Et pour faire des requêtes rapides, suffit de foutre des index partout.Hash statique ? Dynamique ? B tree ? B+ tree ? Bitmap ? Index secondaire ?
J’imagine que la performance dépend des données, je suis pas un expert dans le domaine, même si je connais les différents types d’index et la manière dont ils fonctionnent.
Ça dépend des données et de jusqu’à quel point tu tolères le fait d’avoir des indexs qui deviennent totalement énormes.
Le 17 mai 2023 à 10:49:10 :
Le 17 mai 2023 à 10:46:28 :
La syntaxe SQL n'est pas dure, le langage a été conçu pour des non-programmeurs.La difficulté réside dans la compréhension des BDD, leur structure et comment faire des requêtes propres, plus ou moins complexes et optimisées selon la situation.
Les instructions clé osef, t'auras toujours accès à la documentation technique.
Pour le coup, j’ai mis 30 secondes à comprendre le concept de clôture algébrique sur les bases de données relationnelles, c’est vraiment simple à comprendre.
Pourquoi tu veux faire le boug qui écrit complexe alors que tu veux simplement dire supprimer un attribut d'une table et par conséquent (logique) si tu supprimes un attribut A et que deux attributs B C dépendent de A, alors ils seront supprimés aussi.
Le 17 mai 2023 à 10:57:06 :
Le 17 mai 2023 à 10:55:00 :
Le 17 mai 2023 à 10:52:55 :
Le 17 mai 2023 à 10:51:44 :
Le 17 mai 2023 à 10:49:52 :
> Le 17 mai 2023 à 10:49:10 :
>> Le 17 mai 2023 à 10:46:28 :
> >La syntaxe SQL n'est pas dure, le langage a été conçu pour des non-programmeurs.
> >
> > La difficulté réside dans la compréhension des BDD, leur structure et comment faire des requêtes propres, plus ou moins complexes et optimisées selon la situation.
> >
> > Les instructions clé osef, t'auras toujours accès à la documentation technique.
>
> Pour le coup, j’ai mis 30 secondes à comprendre le concept de clôture algébrique sur les bases de données relationnelles, c’est vraiment simple à comprendre.
15 secondes grand max le low
Non mais rien à voir, je ne suis pas brillant, suffit juste de comprendre qu’il ne faut pas mettre de liste dans une BDD et c’est réglé.
Le sujet des DB relationnelles commence à un peu m’intéresser. Pourquoi pas de listes en DB ?
Parce que c’est plus efficace de mettre tous les éléments de toutes les listes dans une table à part, notamment parce que ça t’évite d’avoir à modifier la liste à chaque fois pour rajouter un élément.
Quand la donnée est dans la table t’es pas censé la modifier, sauf si c’est pour la corriger.
Si tu veux récupérer une liste, tu la construis à partir de ta table.Ah oui effectivement. En NoSQL on fait pas forcément exactement pareil mais je vois l’idée.
Ça me revient. C’est vraiment les fondamentaux en DB relationnelles, non ?
Oui c’est la base théorique, en pratique tu vois des trucs qui sont mal fichus, avec des cases vides, des listes…
J’avais un peu bossé sur des bases en NoSQL, c’est plutôt utilisé pour les données non structurées, des datalakes etc. non ?
La vraie difficulté c'est la conception des tables
Le 17 mai 2023 à 10:59:40 :
Simplement pour dire que faire des SELECT WHERE LIKE FROM imbriqués y'a aucune difficulté t'apprends dans la journée.
Mais il y a une très grosse augmentation de difficulté si tu vas plus loin et sur des bases complexes, notamment quand on te demande des informations extrêmement précises
extraire une information extrêmement précise c'est un select quand même. Juste qu'il faut que tu saches où tu extraits ladite information dans ta BDD qui contient des centaines de tables
Données du topic
- Auteur
- Ondinisme56
- Date de création
- 17 mai 2023 à 10:37:20
- Nb. messages archivés
- 80
- Nb. messages JVC
- 80