— how to talk to a database without losing clarity or safety

At some point, every PHP application needs to ask the database a question.
And just like routing, the shape is simple:

• Prepare a query.
• Bind the data.
• Execute.
• Read the result.

Everything else
— ORMs, query builders, abstractions —
is optional.

We’re not teaching SQL, the goal of this page is
to give us the mental model
that lets us collaborate with AI safely and intentionally.

Modern PHP gives us a tool that makes safe queries the default:

PDO with prepared statements.

A safe query always looks like this:

$stmt = $pdo->prepare('SELECT * FROM users WHERE id = :id');
$stmt->execute(['id' => $id]);
$user = $stmt->fetch();

Three steps:

1. Prepare the query
2. Bind the data
3. Execute and fetch

This shape protects us from SQL injection without needing to memorize rules.

When we bind data separately from the SQL, we avoid the classic mistake:

// Unsafe — never do this
$sql = "SELECT * FROM users WHERE id = $id";

AI sometimes generates unsafe SQL if we don’t guide it.
Our literacy lets us say:

“Use prepared statements.”

“Bind parameters.”

“Never interpolate variables into SQL.”

We’re not memorizing syntax
— we’re shaping the conversation.

Let’s say we want to load a user by ID.

We ask AI:

“Give me a simple function to load a user by ID using PDO.”

AI should give us something like:

function findUser(PDO $pdo, string $id): array|false {
    $stmt = $pdo->prepare('SELECT * FROM users WHERE id = :id');
    $stmt->execute(['id' => $id]);
    return $stmt->fetch(PDO::FETCH_ASSOC);
}

This is the entire mental model:

• SQL stays simple
• data stays separate
• the result is predictable

Everything else is refinement.

But as soon as we write more than one query,
we feel the friction:

• repeated SQL
• repeated connection handling
• repeated fetch logic

This is the moment when persistence becomes a concept,
and we give it a home:

class UserRepository {
    public function __construct(private PDO $pdo) {}
 
    public function find(string $id): array|false {
        $stmt = $this->pdo->prepare('SELECT * FROM users WHERE id = :id');
        $stmt->execute(['id' => $id]);
        return $stmt->fetch(PDO::FETCH_ASSOC);
    }
}

Now our domain reads like a story:

$user = $userRepository->find($id);

That’s the whole point.

AI can generate SQL instantly.
But AI does not automatically know:

• our domain
• our constraints
• our safety requirements
• our intention

Without guidance, AI may:

• inline variables into SQL
• skip prepared statements
• mix concerns
• leak persistence logic into controllers
• generate overly complex abstractions

Our literacy keeps the conversation grounded:

“Keep the query simple.”

“Use prepared statements.”

“Put this in a repository.”

“Return associative arrays, not objects.”

“Avoid ORMs for now.”

We’re not fighting AI — we’re steering it.

The moment when we need data, not architecture

Here’s what that moment looks like in practice.

We may start with:

“Load a user by ID.”

AI gives us:

$sql = "SELECT * FROM users WHERE id = $id";

We feel the danger.
We feel the noise.

This is the moment to say:

“Use PDO with prepared statements.
Give me a safe, simple query.”

AI will correct itself.

Then, when we ask for more queries and the code starts repeating, we say:

“Move all database logic into a UserRepository.”

This is the literacy we’re learning:

• When we need one piece of data, we ask for a simple prepared query.
• When we need many, we ask for a Repository.

A safe query is a small, predictable conversation with the database.
Prepared statements keep it honest.
Repositories keep it organized.

Once we see this shape, we can collaborate with AI on any database layer
— from a tiny script to a full application — without losing clarity or safety.

_{Tony de Araujo —New York}

• Top↑
• Back to Topic ↔
• Home←