Réponses:
Je pense que vous essayez de vivre dans le monde de rêve de Joe Celko où vous ne pouvez utiliser que du SQL standard et au cours d'une semaine donnée, vous devrez peut-être porter tout votre code de SQL Server vers Oracle, puis Oracle vers DB2, puis de nouveau vers SQL Server . Deux fois.
Bien que les aspects fondamentaux et fondamentaux du SQL standard vous aideront n'importe où, essayer de vous limiter à cet ensemble de langage par peur d'un portage futur (ou simplement par principe) n'est pas une voie que je recommanderais. Personnellement, je m'en tiens aux choses standard ANSI quand je le peux (par exemple <> vs! =, COALESCE vs ISNULL, CURRENT_TIMESTAMP vs GETDATE (), etc.), mais je n'ai pas non plus peur d'utiliser le SQL Server spécifique des trucs qui facilitent mon travail.
Il est important de comprendre comment fonctionne SQL en général; il est tout aussi important de comprendre le fonctionnement du langage dans vos SGBDR - y compris les écarts par rapport à la norme, les écarts par rapport à la manière dont un autre SGBDR aurait pu implémenter le même concept et les extensions propriétaires qui n'existent pas ailleurs.
SQL Server, par exemple, couvre une bonne partie de la norme et se rapproche de la pleine conformité avec chaque nouvelle version. Sera-t-il jamais couvert à 100%? Très douteux. Va-t-il continuer à ajouter des extensions propriétaires qui ne figurent pas dans la norme? Certainement. Si tout le monde couvrait la norme et que personne n'en sortait, il n'y aurait aucun avantage à choisir une plate-forme plutôt qu'une autre, et nous utiliserions tous la même chose.
Aucun d'entre eux. Vous pouvez apprendre le SQL standard (-ish) pour n'importe quel SGBDR.
SQL standard n'est pas utilisé dans le monde réel pour payer des emplois sur des projets réussis ...
Cela dit, MySQL est un bon point de départ et voici un tutoriel
constructive guidance incroyablement hypocrite. Où est votre guide constructif ici pour que gbn améliore sa réponse?
Tous les principaux SGBDR prennent en charge les différentes versions de la spécification SQL à différents degrés, les anciennes versions de la spécification étant mieux prises en charge. Tous ne prennent pas la conformité également au sérieux (par exemple, Oracle a commencé à prendre en charge les `` jointures ansi '' en 2001, près d'une décennie après SQL-92 ), et comme @gbn l'a déjà dit, dans la pratique, vous devez connaître la saveur de SQL utilisée par chaque produit. tu utilises.
Postgres est une exception dans la mesure où il "se targue de la conformité aux normes" . Pour "des fins d'apprentissage et de référence", vous avez besoin d'une pratique pratique avec une base de données, pas seulement des connaissances d'un livre ou d'un standard, et postgres est une plate-forme idéale pour apprendre les cordes avec car:
D'accord avec Jack et gbn, il n'y a pas de standard et vous devez faire un choix. Pour faire ce choix, vous devez d'abord sélectionner RDBMS. Je recommanderais de penser aux choses suivantes: 1) voulez-vous être développeur DB ou DBA? 2) Avec quel (s) système (s) d'exploitation voulez-vous travailler? Je suis d'accord, cette question est un peu étrange, mais quand je parle avec les étudiants, ils disent que c'est important.
Par exemple (juste un exemple, je me trompe peut-être) si vous voulez être un DBA et ne voulez pas travailler avec Windows, vous n'avez pas besoin de penser à MSSQL. Et si vous voulez être DBA et que vous aimez travailler avec des chaînes de commandes et des fichiers de configuration - peut-être qu'Oracle est ce dont vous avez besoin. Si vous voulez être développeur et que vous souhaitez utiliser vos connaissances dans des projets indépendants, vous avez peut-être besoin de MySQL?