Dr. Hasan Dalmaz

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

▸ KEY

With RAC, several servers run the same database together; if one fails, the system stays up.

✓ STRENGTH

The most mature enterprise choice for non-stop uptime and disaster recovery (Data Guard).

⚠ CAVEAT

High licensing cost and demands expertise; overkill for small projects.

→ BEST FOR

Large enterprise systems that can’t tolerate downtime: banking, ERP.

› CREATE EXTENSION vector;

▸ KEY

Open source; its capabilities can be extended with extensions — like map data or vector search for AI.

✓ STRENGTH

Free, powerful and standards-based; handles everything from simple records to complex queries.

⚠ CAVEAT

Systems with heavy updates/deletes need regular VACUUM maintenance and tuning.

→ BEST FOR

Web and mobile app backends, mapping (GIS) and AI projects.

› CREATE AVAILABILITY GROUP ag_prod;

▸ KEY

Microsoft’s database; works seamlessly with the Windows/.NET world and ships strong tools (SSMS).

✓ STRENGTH

Handles both day-to-day transactions and reporting/analytics well in one system.

⚠ CAVEAT

Runs best on Windows; the enterprise edition license is expensive.

→ BEST FOR

Enterprise .NET applications and business-intelligence/reporting systems.

› START REPLICA;

▸ KEY

The web’s most popular database; easy to set up and use, with a huge community.

✓ STRENGTH

Lightweight and fast; scales easily, especially for read-heavy sites.

⚠ CAVEAT

Not as deep as Oracle/PostgreSQL for very complex analysis and advanced queries.

→ BEST FOR

Sites like WordPress and high-traffic, read-heavy web apps.

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

▸ KEY

Stores data as flexible “documents” (JSON-like) instead of tables; no rigid schema required.

✓ STRENGTH

Enables fast development, works well with large, frequently changing data and scales out easily (sharding).

⚠ CAVEAT

Poor design can cause duplication and inconsistency; not the first choice where strict relational integrity is required.

→ BEST FOR

Catalogs, content management and apps with frequently changing structures.

› SET session:42 online EX 3600

▸ KEY

Keeps data in memory (RAM) rather than on disk, so it answers almost instantly.

✓ STRENGTH

Incredibly fast; perfect for caching, sessions and real-time counters.

⚠ CAVEAT

Data must fit in RAM and persistence must be set up right, or data can be lost.

→ BEST FOR

Caching, session storage, leaderboards and anywhere speed matters.

› GET /products/_search?q=laptop

▸ KEY

An engine built for text search; its inverted index searches millions of documents and ranks results by relevance.

✓ STRENGTH

Very fast search, autocomplete and log/analytics (ELK stack); scales out easily.

⚠ CAVEAT

Not a primary database; usually runs alongside your main database as a search/log layer.

→ BEST FOR

Site and product search, log analysis and observability.

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

▸ KEY

Keeps data tidy in linked tables and queries it with SQL; a model proven over decades.

✓ STRENGTH

Strong consistency: a transaction fully happens or not at all (ACID). Very powerful for complex queries.

⚠ CAVEAT

Hard to spread across many machines (sharding); changing the schema later takes careful planning.

→ BEST FOR

Money, inventory and any system where correctness is critical.

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

▸ KEY

Uses flexible structures instead of rigid tables (document, key-value…); built for large scale.

✓ STRENGTH

Spreads across many machines easily and handles heavy write loads comfortably.

⚠ CAVEAT

Usually lacks SQL’s strong consistency guarantees and table joins (JOIN).

→ BEST FOR

Large-scale web, real-time analytics and flexible-structured data.

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

▸ KEY

Two consistency philosophies: ACID guarantees every transaction completes intact; BASE relaxes that for speed and availability.

✓ STRENGTH

ACID gives trust for critical data like money; BASE enables massive scale and constant access.

⚠ CAVEAT

With BASE, data may be briefly “out of date”; the app has to account for that.

→ BEST FOR

ACID: payment systems. BASE: social media feeds, like counts.

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

▸ KEY

Two kinds of work: OLTP is many small daily transactions (orders, payments); OLAP is analysis over big data.

✓ STRENGTH

The right split speeds up both: one handles daily work, the other reporting.

⚠ CAVEAT

Running both on one system slows each down, so they’re usually separated.

→ BEST FOR

OLTP: orders/payments. OLAP: reports, dashboards and data warehouses.