Discussion :

[Sodium]

Oh oui, merci Sodium du partage de tes avis si doux, de tes connaissances si complètes, de ta capacité à ne jamais dire du mal des autres ou des technos que tu ne connais pas, de tes avis si pondérés et modérés, et de cette faculté à faire discuter sereinement tous les intervenants des topics où tu interviens. Et pleins de bisous au popotin surtout..

De rien, ce fut un plaisir

[vertex.3F]

Encore heureux qu'on puisse donner son avis sur le SQL quand on le connait. L'inverse est beaucoup moins vrai.

salut blbird,

désolé je n'ai pas su m'exprimer;
lorsque' j'écris "C'est logique car - en caricaturant - on peut faire du SQL sans rien connaitre au développement informatique moderne des entreprises et du coup on peut donner son avis sur le SQL." je veux dire que, sur ce fil, il y a la possibilité que des gens qui connaissent très bien SQL uniquement puissent formuler leur avis sur les ORM ! Du coup il faut avoir ce recul et garder son "zen" en lisant.

Sans vouloir remettre de l'huile sur le feu, je ne fais que reprendre un peu "ton" idée (enfin... "l'idée que tu as exprimée" serait la formulation que je préfère) dans ce commentaire :
https://www.developpez.net/forums/d1.../#post11127492

... pour pouvoir comparer A et B jusqu'au point de dire que ... encore faut-il un minimum connaître A ET B ...

sinon merci pour l'humour, on n'est pas là, sur ce forum, pour s'étriper !

[rawsrc]

Et pleins de bisous au popotin surtout.

Fallait s'y attendre avec un sujet comme celui-là
Ça y est on passe sous la ceinture

Comme toujours, c'est celui qui a la plus grosse (mauvaise foi dans notre cas )

[Sodium]

Quel que soit le sujet, quand des "experts" arrivent pour hurler qu'il ne faut JAMAIS faire quelque chose, c'est qu'ils ont généralement une vision très limitée du domaine.

C'est bien beau d'être calé en bases de données, mais quand on n'a aucune connaissance de la réalité du développement et de la maintenance d'applications, je ne vois pas bien l'intérêt.

[vertex.3F]

Ok, et chacune de tes méthodes, elles s'écrivent toutes seules ?

Salut
oui sur le principe de la généricité et grâce aux conventions la plupart des méthodes "standard" vont s'écrire "toutes seules", tu n'as qu'à coder la signature de la méthode dans l'interface (pas besoin d'implémentation dans une classe concrete !!)

exemple avec SPRING DATA JPA en java :

tu écris simplement ton object où tu précises les particularités (ID, jointure avec autre object, contraintes, ...) par annotations :
https://jmdoudoux.developpez.com/cou...ap-jpa.php#jpa

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
 
package com.jmdoudoux.test.jpa;
 
import java.io.Serializable;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.Id;
 
@Entity
public class Personne implements Serializable {
 
@Id
@GeneratedValue
private int id;
 
private String prenom;
 
private String nom;
 
/* Serializable */ 
private static final long serialVersionUID = 1L;
 
/* getters setters */
 
public Personne() { super(); }
 
public int getId() { return this.id; }
 
public void setId(int id) { this.id = id; }
 
public String getPrenom() { return this.prenom; }
 
public void setPrenom(String prenom) { this.prenom = prenom; }
 
public String getNom() { return this.nom; }
 
public void setNom(String nom) { this.nom = nom; }
 
}

ensuite voici ce qui est disponible "de base" sur toute entité, avec clé simple ou multiple, sans devoir coder :
https://docs.spring.io/spring-data/j....core-concepts

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
public interface CrudRepository<T, ID extends Serializable>
  extends Repository<T, ID> {
 
  <S extends T> S save(S entity);      
 
  Optional<T> findById(ID primaryKey); 
 
  Iterable<T> findAll();               
 
  long count();                        
 
  void delete(T entity);               
 
  boolean existsById(ID primaryKey);   
 
  // … more functionality omitted.
}

et si on veut récupérer la liste des personnes par le nom :
https://docs.spring.io/spring-data/j....query-methods

Code :

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

1
2
3
4
 
interface PersonRepository extends Repository<Person, Long> {
  List<Person> findByLastname(String lastname);
}

si on veut trier :
https://docs.spring.io/spring-data/j...t-query-result

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
User findFirstByOrderByLastnameAsc();
 
User findTopByOrderByAgeDesc();
 
Page<User> queryFirst10ByLastname(String lastname, Pageable pageable);
 
Slice<User> findTop3ByLastname(String lastname, Pageable pageable);
 
List<User> findFirst10ByLastname(String lastname, Sort sort);
 
List<User> findTop10ByLastname(String lastname, Pageable pageable);

pas de code java (hormis la signature de méthode dans l'interface) ni SQL jusqu'à présent

Si la longueur des pieds est déduite de la taille moyenne des chausses achetées sur les 12 derniers mois, ça va ressemble à quoi ?

là précisément tu peux avoir besoin de coder le nom de la méthode et une requête spécifique associée :

• en langage d'abstraction JPQL (très proche du SQL et portable quel que soit le sgbd pris en charge : oracle postgres mysql ...)
• directement en SQL natif (portable seulement si tu sais coder en SQL portable)

pour le JPQL voir ici : https://docs.spring.io/spring-data/j....query-methods

Code :

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

1
2
3
4
5
6
 
public interface UserRepository extends JpaRepository<User, Long> {
 
  @Query("select u from User u where u.emailAddress = ?1")
  User findByEmailAddress(String emailAddress);
}

JPQL c'est simple et efficace la plupart du temps, tu peux visualiser le SQL qui sera généré pour rectifier ton code,
si tu n'arrives pas à tes fins, tu passes au SQL, toujours sans besoin de coder la méthode !!

Code :

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

1
2
3
4
5
6
 
public interface UserRepository extends JpaRepository<User, Long> {
 
  @Query(value = "SELECT * FROM USERS WHERE EMAIL_ADDRESS = ?1", nativeQuery = true)
  User findByEmailAddress(String emailAddress);
}

s'appuyant sur des conventions de noms, l'API de SPRING exploite les annotations, l'introspection, l'injection des dépendances, l'AOP, etc. et, bien sûr, le SQL.

les Objects retournés par les Queries sont directement utilisables dans le code java (pas besoin de chercher les valeurs des colonnes, les objects sont valorisés)

si tu veux paginer tes écrans c'est prévu !! (voir "Example 59" https://docs.spring.io/spring-data/j...thods.at-query )

Code :

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

1
2
3
4
5
6
7
8
 
public interface UserRepository extends JpaRepository<User, Long> {
 
  @Query(value = "SELECT * FROM USERS WHERE LASTNAME = ?1",
    countQuery = "SELECT count(*) FROM USERS WHERE LASTNAME = ?1",
    nativeQuery = true)
  Page<User> findByLastname(String lastname, Pageable pageable);
}

T'as pas 500 vues, t'as 500 méthodes dans 500 classes, je suis pas certain que ce soit mieux.

Et le jour où ton chef te demande une autre application, sur une autre techno, qui doit manipuler la même base de données et y refaire les mêmes traitements et requêtes, 100% de ton code est à réécrire, sans aucune garantie que tu feras pareil… Et le jour où la base évolue, ouais, là tu vas commencer à pleurer car t'as toutes tes applications à modifier à cause d'une connerie de table de jointure qui s'est glissé entre deux tables utilisées dans 80% de tes traitements… je te plains réellement ce jour là.

... ben non justement (c'est l'un des buts des ORM : éviter du travail considéré inutile)

[escartefigue]

Quel que soit le sujet, quand des "experts" arrivent pour hurler qu'il ne faut JAMAIS faire quelque chose, c'est qu'ils ont généralement une vision très limitée du domaine.

C'est bien beau d'être calé en bases de données, mais quand on n'a aucune connaissance de la réalité du développement et de la maintenance d'applications, je ne vois pas bien l'intérêt.

Que savez-vous de la connaissance des uns et des autres sur le développement et la maintenance

[vertex.3F]

[Sodium]

Ils l'ont assez prouvé par leur propos. Quand ils disent que pour chaque besoin, il suffit de créer une nouvelle vue, c'est qu'ils n'ont clairement aucune connaissance des réalités du développement d'applications

[blbird]

Ils l'ont assez prouvé par leur propos. Quand ils disent que pour chaque besoin, il suffit de créer une nouvelle vue, c'est qu'ils n'ont clairement aucune connaissance des réalités du développement d'applications

Par définition, on ne peut pas faire changer d'avis des gens qui ont une position dogmatique sur un sujet

Et il continu, encore et encore. Ce sketch, sérieusement.

@Sodium : Tes participations sont exactement du même acabit : les SQL c'est pourri, mais je n'y connais rien. Même pas foutu de t'appliquer à toi-même les critiques que tu fais aux autres.

[vertex.3F]

[Sodium]

Je ne reviendrai pas sur le sujet, SQL est un langage primitif, verbeux, inélégant, déconnecté de la programmation objet et difficile à générer par programmation. C'est un langage très vieux et qui a très peu évolué au contraire des autres langages qui se sont grandement modernisés. C'est un peu comme si on programmation en basic en 2019.

Il est également très difficile à debugger. Quand une requête SQL contient une erreur, le message va généralement être "y a un truc qui va pas entre les caractères 10 et 320, démerde-toi avec ça lol".

[rawsrc]

Arrête-toi Sodium, la cour est pleine.
Tu sais le proverbe : vieux pots meilleur soupe...

Et pour ce qui est du débogage, cela fait belle lurette que quasiment tous les moteurs SQL proposent des solutions de débogage pas à pas avec des points d'arrêts et moult possibilités de voir/modifier les valeurs manuellement à l'exécution.
Tu te méprends sur le monde SQL, crois-moi.

[escartefigue]

Il est également très difficile à debugger. Quand une requête SQL contient une erreur, le message va généralement être "y a un truc qui va pas entre les caractères 10 et 320, démerde-toi avec ça lol".

Ca fait combien de siècles que vous n'avez pas fait de SQL

[vertex.3F]

je suis d'accord lorsque le contexte d'execution est la ligne de commande sous un éditeur tq SQLDEVELOPER alors les détails des erreurs sont fournis et l'analyse grandement facilitée.

en revanche (c'est mon expérience) lorsque le contexte d'exécution est celui d'une appli qui appelle un driver de SGBD alors j'ai constaté que les messages d'erreurs remontés sont plutôt "courts", on doit rejouer le SQL unitairement en ligne de cmd pour obtenir les détails

[escartefigue]

Il est malheureusement très fréquent que l'application ne restitue qu'une petite partie du diagnostic fourni par le SGBD alors que ce diagnostic est très fin et bien documenté, il est ainsi en partie perdu du point de vue de l'application
Bon, heureusement, le journal de transaction permet de retrouver ses petits, mais c'est quand même ballot

[StringBuilder]

Il est malheureusement très fréquent que l'application ne restitue qu'une petite partie du diagnostic fourni par le SGBD alors que ce diagnostic est très fin et bien documenté, il est ainsi en partie perdu du point de vue de l'application

En même temps, déjà qu'un ORM ne sait pas écrire une requête correcte de plus de deux jointures, c'est pas étonnant qu'il n'arrive pas à comprendre la réponse du SGBD

[SQLpro]

Je ne reviendrai pas sur le sujet, SQL est un langage primitif, verbeux, inélégant, déconnecté de la programmation objet et difficile à générer par programmation.

C'est sans doute pour cela que les vieux cons de chez Google, une boite antique, dinosaurienne et tout et tout..., à finalement opté pour SQL en le rebaptisant New SQL pour la plupart de ses moteurs de bases de données...
https://fr.wikipedia.org/wiki/BigQuery

C'est un langage très vieux

Oui, le HTML aussi, donc c'est une grosse merde que l'on ne doit surtout pas utiliser... !

et qui a très peu évolué

FAKE NEWS ! Là comme vous n'y connaissez rien, je laisse juste les chiffres parler d'eux même :
Pour le cœur SQL, il y a juste eu ces évolutions là :
SQL-86 (or SQL-87) is the ISO 9075:1987 standard of 1987
SQL-89 is the ISO/IEC 9075:1989 standard of 1989
SQL-92 is the ISO/IEC 9075:1992 standard of 1992
SQL:1999 is the ISO/IEC 9075:1999 standard of 1999
SQL:2003 is the ISO/IEC 9075:2003 standard of 2003
SQL:2006 is the ISO/IEC 9075:2006 standard of 2006
SQL:2008 is the ISO/IEC 9075:2008 standard of 2008
SQL:2011 is the ISO/IEC 9075:2011 standard of 2011
SQL:2016 is the ISO/IEC 9075:2016 standard of 2016

Il y a aussi les normes ISO/IEC 13249 (40 versions) et en ce moment en cours de travail, l'intégration de JSON dans les SGBDR :
https://www.iso.org/standard/76588.html

Il est également très difficile à debugger. Quand une requête SQL contient une erreur, le message va généralement être "y a un truc qui va pas entre les caractères 10 et 320, démerde-toi avec ça lol".

Ça c'est du MySQmerde... SGBD qui n'est même pas relationnel.
A lire : https://sqlpro.developpez.com/tutori...mysql-mariadb/
Dans tous les autres SGBD réellement relationnel non seulement l'information est précise mais il vous montre la ligne du SQL ou se situe l'erreur !

Et dans certains (Microsoft SQL Server) il y a même l'autocomplétion pour l'écriture des requêtes...

Sans compter qu'il y a des débogueurs dans tous les bons SGBD réellement relationnel.


Donc en définitive vous émettez des avis tranchés sans avoir la moindre connaissance des produits existants et vous répandez des fake news....

Je ne sais pas qui vous a embauché, mais je serais votre boss, je vous virerais...

A +

[SQLpro]

...
Logique recusive, mise en cache, gestion des exptions, utilisation de lib tierce, api tierce, gestion des logs, threads, il y a enormement de chose qui manquent ou sont ingerables pour un dev moyen cote bdd. Un dba va sans doute pouvoir le faire, mais a quel prix financier.

Je voit pas ou est la difficulté de la logique récursive dans l'écriture des requêtes... Elle diffère par ce que c'est un monde ensembliste, mais une fois que l'on a mis le doigt sur la théorie des ensemble, elle devient triviale... Le cache c'est le SGBD qui le gère tout seul (donc cout ZERO)... idem pour les exceptions avec les bloc TRY CATCH par exemple (donc, strictement identique au code itératif). idem pour librairie tierce (EXTERNAL PROC/FUNCTION/TRIGGER...), idem pour les logs, ça peut être juste une table et la plupart des SGBDR ont des outils de logs intégrés (donc cout ZERO). Pour les threads MS SQL Server fait tu parallélisme tout seul (donc cout ZERO)....

Donc, recycle toi !

[Sodium]

C'est sans doute pour cela que les vieux cons de chez Google, une boite antique, dinosaurienne et tout et tout..., à finalement opté pour SQL en le rebaptisant New SQL pour la plupart de ses moteurs de bases de données...
https://fr.wikipedia.org/wiki/BigQuery

Quand on a un peu de logique (et pour programmeur ce n'est pas mal d'en avoir), on ne confonds pas l'omniprésence d'une technologie avec une qualité intrinsèque à celle-ci.

Tiens d'ailleurs, on utilise le charbon depuis des siècles (j'ai la flemme d'aller vérifier le chiffre exact), c'est sûrement qu'il s'agit d'une technologie d'avenir !

[StringBuilder]