Sound familiar?

Your database has 1000 tables. Nobody knows what half of them do.

Every entity spawns 5-10 tables. Orders, OrderItems, OrderStatuses, OrderHistory, OrderMetadata... New developer joins — takes a month to understand the schema. Change one field — update migrations, DAL, DTOs, mappers. Repeat for every microservice.

Your junior doesn't know SQL. But the project needs a database.

Foreign keys, indexes, normalization, migration scripts... They just want to build features, not become a DBA. But every tutorial assumes you know what a clustered index is.

One entity. 30 tables. 500ms per query.

You need to load a complete Order: customer info, line items, products, categories, discounts, shipping, payment history... The SQL function is 150 lines. It runs half a second. And you need to query thousands of them.

Now multiply this. You have Orders, Invoices, Projects, Contracts — each with its own 30-table assembly function. Each maintained separately. Each breaks when schema changes.

Add a new field? Migration + update assembly function + rebuild indexes. Need an array property (Tags, Attachments)? New table + FK + index + update ALL queries that touch this entity. Every change cascades through the entire stack.

SELECT o.*, c.*, i.*, p.*, cat.*, d.*, s.*, ph.*
FROM Orders o
LEFT JOIN Customers c ON ...
LEFT JOIN OrderItems i ON ...
LEFT JOIN Products p ON ...
LEFT JOIN Categories cat ON ...
LEFT JOIN Discounts d ON ...
LEFT JOIN Shipping s ON ...
LEFT JOIN PaymentHistory ph ON ...
WHERE o.Id = @id
-- 150 lines, 30 JOINs, 500ms

var order = await redb.LoadAsync<Order>(id);
// Single key lookup, one data dump
// Parallel object assembly in memory
// Zero JOINs. 15ms.

Entity → DTO → ViewModel → Response. Four classes for one thing.

Database entity. Business DTO. API response model. Frontend ViewModel. AutoMapper profiles for each direction. Change one field — update four classes and three mappings. Half your bugs are mapping bugs.

Client wants one new field. It takes a week.

Ticket to DBA. Migration script. Code review. Staging deployment. Production deployment window. Rollback plan. All for one nullable string field.

Products need different fields. One table per type? Or 1:1 joins everywhere?

Clothing needs Size and Color. Electronics needs Memory and Processor. Traditional approach: base Products table + ClothingDetails + ElectronicsDetails with 1:1 FK. Or one giant table with 100 nullable columns. Both are maintenance nightmares.

-- Base table
CREATE TABLE Products (Id, Name, Price)

-- 1:1 extension tables
CREATE TABLE ClothingDetails (ProductId FK, Size, Color)
CREATE TABLE ElectronicsDetails (ProductId FK, Memory, CPU)

-- Every query needs JOINs
SELECT p.*, c.*, e.* FROM Products p
LEFT JOIN ClothingDetails c ON ...
LEFT JOIN ElectronicsDetails e ON ...

// Just use C# inheritance
[RedbScheme] public class Product { ... }
[RedbScheme] public class Clothing : Product 
{ 
    public string Size { get; set; }
    public string Color { get; set; }
}
[RedbScheme] public class Electronics : Product 
{ 
    public int Memory { get; set; }
}

// Query polymorphically
var clothes = await redb.Query<Clothing>().ToListAsync();

You need lookup tables. Cities, Colors, Materials. Each with FK, indexes, joins.

Countries → Cities table with FK. Colors table with FK. Materials table with FK. Now Cities needs more data — population, area, coordinates. Extend the lookup table? But Colors don't need that. Add nullable FK to a City entity? What about Materials that also need entity reference? Your lookup tables become a mess of optional FKs.

-- Lookup tables
CREATE TABLE Cities (Id, Name, CountryId FK)
CREATE TABLE Colors (Id, Name, Hex)
CREATE TABLE Materials (Id, Name)

-- Oh wait, Cities need more data...
ALTER TABLE Cities ADD Population, Area, ...
-- Or reference a separate entity?
ALTER TABLE Cities ADD CityEntityId FK NULL
-- Materials too? Another FK column...

-- Filter by lookup?
WHERE CityId IN (SELECT Id FROM Cities WHERE ...)

// Built-in ListItem support
[RedbScheme]
public class Order
{
    public RedbListItem Status { get; set; }
    public RedbListItem City { get; set; }
    public List<RedbListItem> Tags { get; set; }
}

// Filter by value
.Where(p => p.Status.Value == "Active")

// WhereIn
.WhereIn(p => p.Status.Value, ["Active", "Pending"])

// GroupBy works too!
.GroupBy(p => p.City.Value)

"Delete... but not really. And show me progress."

Soft delete. Add `is_deleted` to every table. Remember to filter it in EVERY query. Forget once — users see deleted data. Or worse, deleted data corrupts reports.

Need to actually purge? Manual scripts. Batched deletes. "How many left?" — nobody knows until it's done. Or crashes.

-- Add is_deleted EVERYWHERE
ALTER TABLE Orders ADD is_deleted BIT DEFAULT 0;
ALTER TABLE Customers ADD is_deleted BIT DEFAULT 0;
ALTER TABLE Products ADD is_deleted BIT DEFAULT 0;
-- ... 50 more tables

-- EVERY query needs this:
SELECT * FROM Orders 
WHERE is_deleted = 0  -- Forget this = bug
  AND customer_id IN (
    SELECT id FROM Customers WHERE is_deleted = 0
  );

-- Purge? Good luck:
DECLARE @batch INT = 1000;
WHILE 1=1 BEGIN
    DELETE TOP(@batch) FROM Orders 
    WHERE is_deleted = 1;
    IF @ROWCOUNT = 0 BREAK;
    -- Progress? What progress?
END

// Option 1: Sync delete with real-time progress
var progress = new Progress<PurgeProgress>(p =>
{
    var pct = p.Total > 0 ? p.Deleted * 100 / p.Total : 0;
    Console.WriteLine($"{p.Deleted}/{p.Total} ({pct}%)");
});

await redb.DeleteWithPurgeAsync(ids, batchSize: 100, progress);
// Real-time progress callback. Batched. Safe.

// Option 2: Fire-and-forget background service
var mark = await deletionService.DeleteAsync(ids, user);
// Returns IMMEDIATELY. Purge runs in background.

// Check progress anytime:
var status = await deletionService.GetProgressAsync(mark.TrashId);
// status.Deleted, status.Remaining, status.Status

// Query() auto-filters deleted objects
var orders = await redb.Query<Order>().ToListAsync();
// Only active. No is_deleted. Ever.

// Cluster-safe: survives restarts!

Fire and forget. Objects move to trash container, background service purges in batches. Progress stored in DB — survives restarts. Cluster-safe. No `is_deleted` pollution. Query() filters automatically.

"N+1 again. Third time this sprint."

Forgot an Include? Loop loads 1000 customers one by one. Performance tanks. Add Include — now you load too much data. Balance between eager and lazy loading is a constant battle.

var orders = await context.Orders
    .Include(o => o.Customer)      // forgot this = N+1
    .Include(o => o.Items)
        .ThenInclude(i => i.Product)  // and this
    .Where(o => o.Status == "Active")
    .ToListAsync();
// Miss one Include = performance bug
// Add too many = memory bloat

var orders = await redb.Query<Order>()
    .Where(o => o.Status == "Active")
    .ToListAsync();
// Full object graph. Always. One query.
// No Include chains. No N+1. By design.

"This is MY object. Only I should see it."

Object ownership. Build permissions table. FK everywhere. Complex JOINs in every query. Forget once — data leak.

-- Permissions table
CREATE TABLE ObjectPermissions (
    object_id INT, object_type VARCHAR(50),
    user_id INT, permission VARCHAR(20)
);

-- EVERY query needs this:
SELECT o.* FROM Orders o
JOIN ObjectPermissions p 
  ON p.object_id = o.id 
  AND p.object_type = 'Order'
WHERE p.user_id = @currentUser
  AND p.permission = 'read';
-- Polymorphic FK. No referential integrity.
-- Forget the JOIN = security hole.

// owner_id is built into every RedbObject
var order = new RedbObject<OrderProps>
{
    OwnerId = currentUser.Id,
    Props = new OrderProps { ... }
};

// Filter by owner:
var myOrders = await redb.Query<Order>()
    .WhereRedb(o => o.OwnerId == currentUser.Id)
    .ToListAsync();

// Built-in. Type-safe. No extra tables.