Ben non, justement, ça ne se comprend pas très bien ! Cette phrase (que vous avez trouvée où ?) fait la confusion entre le besoin d'un "opérateur (externe)" et la fabrication d'une "application".
Une application, c'est des programmes, une interface utilisateur et, éventuellement, une source de données, relationnelles ou non.
Le SQL est complet pour gérer la partie données relationnelles (ou pas relationnelles, d'ailleurs) mais il ne vous permettra pas de faire une jolie interface utilisateur parce que ce n'est pas sa fonction.
Ça m'étonnerait qu'un SGBDOO soit capable de le faire. Ou alors, ce n'est pas seulement un SGBD mais un environnement de développement complet avec un langage de programmation permettant de réaliser l'interface utilisateur.
Le SQL est complet au sens de turing, c'est à dire qu'il est capable d'interroger les données et de les triturer dans tous les sens que vous voulez pour que le programme applicatif se contente de récupérer le jeu de données sans avoir à les retraiter.
Petit exemple simple : vous pouvez récupérer des données de type DATE qui seront au format brut 'AAAA-MM-JJ' puis les transformer avec votre programme applicatif en format 'JJ/MM/AAAA' ou bien transformer les données de type DATE avec le SQL pour envoyer au programme directement le format 'JJ/MM/AAAA'.
Si vous avez un grand nombre de lignes de résultats et que vous voulez les trier par date, ce sera plus rapide de le faire avec le SGBD qu'avec le programme applicatif parce que c'est le boulot du SGBD de traiter les données.
Partager