Cette section illustre comment le DAS Relationnel peut être utilisé pour créer, récupérer, mettre à jour et supprimer des données dans une base de données relationnelle. Plusieurs de ces exemples sont illustrés avec trois tables dans une base de données qui contient "compagnies", "departements" à l'intérieur de ces compagnies et "employes" qui travaillent dans ces départements. Cet exemple est utilisé dans plusieurs places dans la littérature SDO. Voyez la section des exemples de » spécification d'Objets de Service de Données ou la section d'exemples de la documentation de l'extension SDO.
Le DAS Relationnel est construit avec les métadonnées qui définissent la base de données relationnelle et comment il devrait être en relation avec le SDO. La longue section qui suit décrit ces métadonnées et comment construire le DAS Relationnel. Ces exemples qui suivent assument tous que ces métadonnées sont incluses dans un fichier PHP.
Les exemples ci-dessous et les autres peuvent être trouvés dans le dossier Scenarios dans le paquetage DAS Relationnel.
Le DAS Relationnel émet des exceptions dans le cas qu'il trouve des erreurs dans les métadonnées ou des erreurs lors de l'exécution des requêtes SQL à la base de données. Pour rendre les exemples plus concis, ils n'incluent pas les blocs try/catch autour des appels de DAS Relationnel.
Ces exemples diffèrent tous de l'utilisation prévue de SDO dans deux égards importants.
Premièrement, ils montrent toutes les interactions avec la base de données complétés dans un script. Ces scénarios ne sont pas réalistes mais sont choisis dans le but d'illustrer simplement l'utilisation de DAS Relationnel. Il est prévu que les interactions avec la base de données soient séparés dans le temps et le graphique de données linéarisées et délinéarisées dans une session PHP une ou plusieurs fois tant que l'application interagit avec l'utilisateur final.
Deuxièmement, toutes les requêtes exécutées sur la base de données sont figées dans le code sans aucune substitution de variable. Dans ce cas, il est plus sage d'utiliser le simple appel de executeQuery() et c'est ce que montrent les exemples. En pratique, il est peu probable que la requête SQL soit connue entièrement avant son exécution. Afin d'autoriser la substitution sans danger des variables dans les requêtes SQL, sans prendre le risque d'effectuer des injections SQL avec des effets inconnus, il est plus sécuritaire d'utiliser executePreparedQuery() qui prend une requête SQL préparée contenant des paramètres fictifs et une liste des valeurs à être substituées.