Знакомо?

В вашей базе 1000 таблиц. Никто не знает, зачем половина из них.

Каждая сущность порождает 5-10 таблиц. Orders, OrderItems, OrderStatuses, OrderHistory, OrderMetadata... Новый разработчик выходит — месяц на понимание схемы. Изменить одно поле — обновить миграции, DAL, DTO, маппер. Повторить для каждого микросервиса.

Ваш джуниор не знает SQL. Но проекту нужна база данных.

Внешние ключи, индексы, нормализация, скрипты миграций... Он просто хочет писать фичи, а не становиться DBA. Но каждый туториал предполагает, что вы знаете, что такое кластерный индекс.

Одна сущность. 30 таблиц. 500мс на запрос.

Нужно загрузить полный Order: информация о клиенте, позиции, товары, категории, скидки, доставка, история платежей... SQL-функция на 150 строк. Выполняется полсекунды. А вам нужно запросить тысячи таких.

А теперь умножьте. У вас Orders, Invoices, Projects, Contracts — у каждого своя функция сборки из 30 таблиц. Каждая поддерживается отдельно. Каждая ломается при изменении схемы.

Добавить новое поле? Миграция + обновить функцию сборки + перестроить индексы. Нужно свойство-массив (Tags, Attachments)? Новая таблица + FK + индекс + обновить ВСЕ запросы, которые трогают эту сущность. Каждое изменение каскадом проходит через весь стек.

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 строк, 30 JOIN-ов, 500мс

var order = await redb.LoadAsync<Order>(id);
// Один поиск по ключу, один дамп данных
// Параллельная сборка объектов в памяти
// Ноль JOIN-ов. 15мс.

Entity → DTO → ViewModel → Response. Четыре класса для одного и того же.

Сущность базы данных. Бизнес-DTO. Модель ответа API. ViewModel для фронтенда. Профили AutoMapper для каждого направления. Изменить одно поле — обновить четыре класса и три маппинга. Половина ваших багов — баги маппинга.

Клиент хочет одно новое поле. Это занимает неделю.

Тикет DBA. Скрипт миграции. Код-ревью. Деплой на стейджинг. Окно деплоя на продакшн. План отката. И всё это ради одного nullable string-поля.

Товарам нужны разные поля. Одна таблица на тип? Или 1:1 JOIN-ы повсюду?

Одежде нужны Size и Color. Электронике нужны Memory и Processor. Традиционный подход: базовая таблица Products + ClothingDetails + ElectronicsDetails с 1:1 FK. Или одна гигантская таблица со 100 nullable-колонками. Оба варианта — кошмар поддержки.

-- Базовая таблица
CREATE TABLE Products (Id, Name, Price)

-- 1:1 таблицы расширения
CREATE TABLE ClothingDetails (ProductId FK, Size, Color)
CREATE TABLE ElectronicsDetails (ProductId FK, Memory, CPU)

-- Каждый запрос требует JOIN-ов
SELECT p.*, c.*, e.* FROM Products p
LEFT JOIN ClothingDetails c ON ...
LEFT JOIN ElectronicsDetails e ON ...

// Просто используйте наследование C#
[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; }
}

// Полиморфный запрос
var clothes = await redb.Query<Clothing>().ToListAsync();

Нужны справочные таблицы. Города, Цвета, Материалы. У каждой FK, индексы, JOIN-ы.

Countries → таблица Cities с FK. Таблица Colors с FK. Таблица Materials с FK. А потом Cities нужны дополнительные данные — население, площадь, координаты. Расширить справочную таблицу? Но Colors этого не требуют. Добавить nullable FK на сущность City? А как насчёт Materials, которым тоже нужна ссылка? Ваши справочные таблицы превращаются в месиво из опциональных FK.

-- Справочные таблицы
CREATE TABLE Cities (Id, Name, CountryId FK)
CREATE TABLE Colors (Id, Name, Hex)
CREATE TABLE Materials (Id, Name)

-- Ой, Cities нужны дополнительные данные...
ALTER TABLE Cities ADD Population, Area, ...
-- Или сослаться на отдельную сущность?
ALTER TABLE Cities ADD CityEntityId FK NULL
-- Materials тоже? Ещё одна FK-колонка...

-- Фильтр по справочнику?
WHERE CityId IN (SELECT Id FROM Cities WHERE ...)

// Встроенная поддержка ListItem
[RedbScheme]
public class Order
{
    public RedbListItem Status { get; set; }
    public RedbListItem City { get; set; }
    public List<RedbListItem> Tags { get; set; }
}

// Фильтр по значению
.Where(p => p.Status.Value == "Active")

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

// GroupBy тоже работает!
.GroupBy(p => p.City.Value)

«Удалить... но не совсем. И показать прогресс.»

Мягкое удаление. Добавьте `is_deleted` в каждую таблицу. Не забудьте фильтровать его в КАЖДОМ запросе. Забыли один раз — пользователи видят удалённые данные. Или хуже — удалённые данные портят отчёты.

Нужно реально удалить? Ручные скрипты. Пакетное удаление. «Сколько осталось?» — никто не знает, пока не закончится. Или не упадёт.

-- Добавить is_deleted ВЕЗДЕ
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 таблиц

-- КАЖДЫЙ запрос требует это:
SELECT * FROM Orders 
WHERE is_deleted = 0  -- Забудете = баг
  AND customer_id IN (
    SELECT id FROM Customers WHERE is_deleted = 0
  );

-- Очистить? Удачи:
DECLARE @batch INT = 1000;
WHILE 1=1 BEGIN
    DELETE TOP(@batch) FROM Orders 
    WHERE is_deleted = 1;
    IF @ROWCOUNT = 0 BREAK;
    -- Прогресс? Какой прогресс?
END

// Вариант 1: Синхронное удаление с прогрессом в реальном времени
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);
// Прогресс в реальном времени. Пакетно. Безопасно.

// Вариант 2: Фоновый сервис «запустил и забыл»
var mark = await deletionService.DeleteAsync(ids, user);
// Возвращается СРАЗУ. Очистка идёт в фоне.

// Проверить прогресс в любой момент:
var status = await deletionService.GetProgressAsync(mark.TrashId);
// status.Deleted, status.Remaining, status.Status

// Query() автоматически фильтрует удалённые
var orders = await redb.Query<Order>().ToListAsync();
// Только активные. Никакого is_deleted. Никогда.

// Кластер-безопасно: переживает рестарты!

Запустил и забыл. Объекты перемещаются в контейнер-корзину, фоновый сервис очищает пакетами. Прогресс хранится в БД — переживает рестарты. Кластер-безопасно. Никакого засорения `is_deleted`. Query() фильтрует автоматически.

«Опять N+1. Третий раз за спринт.»

Забыли Include? Цикл загружает 1000 клиентов по одному. Производительность падает. Добавили Include — теперь грузите слишком много данных. Баланс между eager и lazy loading — вечная битва.

var orders = await context.Orders
    .Include(o => o.Customer)      // забыли = N+1
    .Include(o => o.Items)
        .ThenInclude(i => i.Product)  // и это тоже
    .Where(o => o.Status == "Active")
    .ToListAsync();
// Пропустили один Include = баг производительности
// Добавили слишком много = раздувание памяти

var orders = await redb.Query<Order>()
    .Where(o => o.Status == "Active")
    .ToListAsync();
// Полный граф объектов. Всегда. Один запрос.
// Никаких цепочек Include. Никаких N+1. По дизайну.

«Это МОЙ объект. Только я должен его видеть.»

Владение объектами. Создайте таблицу прав доступа. FK повсюду. Сложные JOIN-ы в каждом запросе. Забыли один раз — утечка данных.

-- Таблица прав доступа
CREATE TABLE ObjectPermissions (
    object_id INT, object_type VARCHAR(50),
    user_id INT, permission VARCHAR(20)
);

-- КАЖДЫЙ запрос требует это:
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';
-- Полиморфный FK. Нет ссылочной целостности.
-- Забыли JOIN = дыра в безопасности.

// owner_id встроен в каждый RedbObject
var order = new RedbObject<OrderProps>
{
    OwnerId = currentUser.Id,
    Props = new OrderProps { ... }
};

// Фильтр по владельцу:
var myOrders = await redb.Query<Order>()
    .WhereRedb(o => o.OwnerId == currentUser.Id)
    .ToListAsync();

// Встроено. Типобезопасно. Без лишних таблиц.