Dr. Hasan Dalmaz

› SELECT inst_id, instance_name, status FROM gv$instance ORDER BY inst_id;

▸ CLÉ

Avec RAC, plusieurs serveurs exécutent ensemble la même base de données ; si l’un tombe en panne, le système reste disponible.

✓ ATOUT

Le choix d’entreprise le plus mature pour la disponibilité continue et la reprise après sinistre (Data Guard).

⚠ LIMITE

Coût de licence élevé et expertise requise ; surdimensionné pour les petits projets.

→ IDÉAL POUR

Grands systèmes d’entreprise qui ne tolèrent aucune interruption : banque, ERP.

› CREATE EXTENSION vector;

▸ CLÉ

Open source ; ses capacités s’étendent grâce aux extensions — données cartographiques ou recherche vectorielle pour l’IA, par exemple.

✓ ATOUT

Gratuit, puissant et conforme aux standards ; gère aussi bien les enregistrements simples que les requêtes complexes.

⚠ LIMITE

Les systèmes avec beaucoup de mises à jour/suppressions nécessitent une maintenance et un réglage réguliers de VACUUM.

→ IDÉAL POUR

Backends d’applications web et mobiles, cartographie (SIG) et projets d’IA.

› CREATE AVAILABILITY GROUP ag_prod;

▸ CLÉ

La base de données de Microsoft ; s’intègre parfaitement à l’univers Windows/.NET et fournit des outils performants (SSMS).

✓ ATOUT

Gère bien à la fois les transactions courantes et le reporting/l’analyse dans un seul système.

⚠ LIMITE

Fonctionne au mieux sous Windows ; la licence de l’édition Enterprise est coûteuse.

→ IDÉAL POUR

Applications .NET d’entreprise et systèmes décisionnels (BI) et de reporting.

› START REPLICA;

▸ CLÉ

La base de données la plus populaire du web ; simple à installer et à utiliser, avec une immense communauté.

✓ ATOUT

Léger et rapide ; monte facilement en charge, notamment pour les sites majoritairement en lecture.

⚠ LIMITE

Moins poussé qu’Oracle/PostgreSQL pour les analyses très complexes et les requêtes avancées.

→ IDÉAL POUR

Sites comme WordPress et applications web à fort trafic, majoritairement en lecture.

› db.orders.find({ status: "paid" })

▸ CLÉ

Stocke les données sous forme de « documents » flexibles (proches du JSON) plutôt qu’en tables ; aucun schéma rigide requis.

✓ ATOUT

Permet un développement rapide, gère bien des données volumineuses et changeantes, et monte facilement en charge horizontalement (sharding).

⚠ LIMITE

Une mauvaise conception peut entraîner duplication et incohérences ; pas le premier choix lorsqu’une intégrité relationnelle stricte est requise.

→ IDÉAL POUR

Catalogues, gestion de contenu et applications aux structures qui évoluent souvent.

› SET session:42 online EX 3600

▸ CLÉ

Conserve les données en mémoire (RAM) plutôt que sur disque, d’où des réponses quasi instantanées.

✓ ATOUT

Extrêmement rapide ; idéal pour le cache, les sessions et les compteurs en temps réel.

⚠ LIMITE

Les données doivent tenir en RAM et la persistance doit être bien configurée, sinon des données peuvent être perdues.

→ IDÉAL POUR

Cache, stockage de sessions, classements et partout où la vitesse compte.

› GET /products/_search?q=laptop

▸ CLÉ

Un moteur conçu pour la recherche textuelle ; son index inversé parcourt des millions de documents et classe les résultats par pertinence.

✓ ATOUT

Recherche très rapide, autocomplétion et logs/analyse (stack ELK) ; monte facilement en charge horizontalement.

⚠ LIMITE

Pas une base de données principale ; fonctionne généralement à côté de la base principale comme couche de recherche/logs.

→ IDÉAL POUR

Recherche sur site et de produits, analyse de logs et observabilité.

› SELECT * FROM orders JOIN users USING (id);

▸ CLÉ

Organise les données dans des tables liées et les interroge en SQL ; un modèle éprouvé depuis des décennies.

✓ ATOUT

Cohérence forte : une transaction s’exécute entièrement ou pas du tout (ACID). Très puissant pour les requêtes complexes.

⚠ LIMITE

Difficile à répartir sur de nombreuses machines (sharding) ; modifier le schéma par la suite demande une planification soigneuse.

→ IDÉAL POUR

Argent, stocks et tout système où l’exactitude est critique.

› { "user": "hd", "roles": ["dba"] }

▸ CLÉ

Utilise des structures flexibles plutôt que des tables rigides (document, clé-valeur…) ; conçu pour la grande échelle.

✓ ATOUT

Se répartit facilement sur de nombreuses machines et absorbe sans peine de fortes charges d’écriture.

⚠ LIMITE

N’offre généralement ni les garanties de cohérence forte du SQL ni les jointures de tables (JOIN).

→ IDÉAL POUR

Web à grande échelle, analyse en temps réel et données à structure flexible.

› BEGIN; UPDATE acct SET bal = bal - 100; COMMIT;

▸ CLÉ

Deux philosophies de cohérence : ACID garantit que chaque transaction se termine intégralement ; BASE assouplit cette exigence au profit de la vitesse et de la disponibilité.

✓ ATOUT

ACID garantit la fiabilité des données critiques comme l’argent ; BASE permet une montée en charge massive et un accès permanent.

⚠ LIMITE

Avec BASE, les données peuvent être brièvement « obsolètes » ; l’application doit en tenir compte.

→ IDÉAL POUR

ACID : systèmes de paiement. BASE : fils d’actualité des réseaux sociaux, compteurs de « j’aime ».

› -- OLTP: point writes · OLAP: aggregate scans

▸ CLÉ

Deux types de charge : l’OLTP, ce sont de nombreuses petites transactions quotidiennes (commandes, paiements) ; l’OLAP, l’analyse de grands volumes de données.

✓ ATOUT

Une bonne séparation accélère les deux : l’un gère l’activité courante, l’autre le reporting.

⚠ LIMITE

Exécuter les deux sur un même système les ralentit, c’est pourquoi on les sépare généralement.

→ IDÉAL POUR

OLTP : commandes/paiements. OLAP : rapports, tableaux de bord et entrepôts de données.