Why database choice affects architecture in Deno - The Real Reasons

The Big Idea

Discover how picking the right database can make or break your app's future!

The Scenario

Imagine building a web app where you store user info in a simple text file. As more users join, you try to find and update their data by reading and rewriting the whole file every time.

The Problem

This manual way is slow and messy. It's easy to lose data or make mistakes when many users try to update at once. Your app might freeze or crash because it can't handle the load.

The Solution

Choosing the right database helps your app organize, find, and update data quickly and safely. Databases are designed to handle many users and complex data without breaking.

Before vs After

✗ Before

open file; read all lines; find user; update info; write all lines back

✓ After

db.query('UPDATE users SET info = ? WHERE id = ?')

What It Enables

With the right database, your app can grow smoothly, handle many users, and keep data safe and easy to manage.

Real Life Example

Think of a social media app where millions post and update profiles. Without a good database, it would be impossible to keep everything fast and reliable.

Key Takeaways

Manual data handling is slow and error-prone for growing apps.

Databases provide fast, safe, and organized data management.

Choosing the right database shapes how your app works and scales.

Practice

1. Why does the choice of database affect the architecture of a Deno application?

easy

A. Because Deno only supports one type of database

B. Because all databases use the same query language

C. Because different databases require different data models and query methods

D. Because database choice does not affect application design

Solution

1. Step 1: Understand database types

   SQL databases use structured tables, while NoSQL databases use flexible document or key-value models.

2. Step 2: Connect database type to app design

   The app must use different data models and queries depending on the database type chosen.

3. Final Answer:

   Because different databases require different data models and query methods -> Option C

4. Quick Check:

   Database type affects data model = D [OK]

Hint: Database type changes data structure and queries [OK]

Common Mistakes:

• Thinking all databases use the same query language
• Assuming database choice doesn't affect app design
• Believing Deno supports only one database type

2. Which of the following is the correct way to import a SQL client library in a Deno project?

easy

A. require('postgres');

B. import { Client } from "https://deno.land/x/postgres@v0.17.0/mod.ts";

C. import Client from 'postgres';

D. const Client = import('postgres');

Solution

1. Step 1: Recall Deno import syntax

   Deno uses ES module syntax with URL imports, not CommonJS require.

2. Step 2: Identify correct import statement

   import { Client } from "https://deno.land/x/postgres@v0.17.0/mod.ts"; uses correct ES module import with a URL and named import.

3. Final Answer:

   import { Client } from "https://deno.land/x/postgres@v0.17.0/mod.ts"; -> Option B

4. Quick Check:

   Deno uses ES module imports = A [OK]

Hint: Deno imports use URLs and ES module syntax [OK]

Common Mistakes:

• Using CommonJS require syntax
• Using bare module names without URLs
• Using default import when named import is required

3. Given this Deno code snippet using a NoSQL database client, what will be the output?

const db = new NoSQLClient();
await db.insert({ id: 1, name: "Alice" });
const user = await db.find({ id: 1 });
console.log(user.name);

medium

A. Alice

B. undefined

C. Error: insert method not found

D. null

Solution

1. Step 1: Understand NoSQL insert and find

   The insert method adds a document; find retrieves it by query.

2. Step 2: Trace code execution

   Insert adds user with id 1 and name Alice; find returns that user; console logs 'Alice'.

3. Final Answer:

   Alice -> Option A

4. Quick Check:

   Inserted user found and logged = Alice [OK]

Hint: Insert then find returns inserted data [OK]

Common Mistakes:

• Assuming find returns undefined if no await
• Confusing insert with update method
• Expecting error due to missing await

4. This Deno code tries to query a SQL database but throws an error. What is the likely cause?

const client = new Client();
await client.connect();
const result = await client.query('SELECT * FROM users WHERE id = $1', [1]);
console.log(result.rows[0].name);

medium

A. The console.log statement is incorrect

B. The query syntax is invalid for SQL

C. The query method does not support parameters

D. The Client constructor needs connection options

Solution

1. Step 1: Check Client initialization

   SQL clients in Deno require connection details (host, user, password) in constructor.

2. Step 2: Analyze error cause

   Without connection options, client.connect() fails, causing query error.

3. Final Answer:

   The Client constructor needs connection options -> Option D

4. Quick Check:

   Missing connection info causes error = A [OK]

Hint: SQL clients need connection info on creation [OK]

Common Mistakes:

• Assuming query syntax is wrong
• Thinking parameters are unsupported
• Blaming console.log for error

5. You want to build a Deno app that handles complex transactions and relationships between data. Which database choice best fits this need and why?

hard

A. SQL database, because it supports ACID transactions and relational data

B. In-memory database, because it is fastest for all data types

C. NoSQL database, because it handles flexible schemas well

D. Flat file storage, because it is simplest to implement

Solution

1. Step 1: Identify app requirements

   Complex transactions and relationships require strong data integrity and relations.

2. Step 2: Match database features

   SQL databases support ACID transactions and relational models, ideal for this need.

3. Final Answer:

   SQL database, because it supports ACID transactions and relational data -> Option A

4. Quick Check:

   Complex relations need SQL ACID support = C [OK]

Hint: Use SQL for complex transactions and relations [OK]

Common Mistakes:

• Choosing NoSQL for complex relational data
• Assuming in-memory is best for persistence
• Using flat files for transactional integrity