Ну не, не всё так сложно. Вернее, некотрые сложности РСУБД можно избежать.
Классические реляшки опираются на то, что в любой момент есть несколько клиентов, каждый из которых может запустить любую операцию CRUD и каждая операция не должна тормозить. Поэтому приходится выворачиваться на полную катушку со всеми подкапотными хитростями.Для "маленького офиса"(SOHO) мы можем допустить:
1. Клиенты пишут в базу редко и быстро (создание документов, какие-то мелкие логи). Что позволяет блокировать таблицу ДЛЯ ВСЕХ операций без дополнительных трюков. Лок, запись, анлок.
2. Соотв. чтение может ну совсем иногда подтормаживать, но в целом работает быстро - нет никаких "слепков базы", "транзакций чтения" и т.п. Что видит один клиент, видят все.
3. Подразумеваем, что мы работаем в стабильной среде - т.е. есть электричество и никто в середине записи не дёрнет рубильник. Собственно, так и работает ЛЮБОЙ современный сервер - как минимум на UPS, как максимум - на генераторе.
Зная всё это, можно сильно упростить все операции с таблицами и трансформировать работу с реляционной базой - таблицы останутся реляционными, но метод работы с ними будет как у FoxPro - "мануальный": "Считать все записи таблицы", "пройтись по записям, сохранить в переменной все зарплаты", "взять запись, найти записи в другой таблице, зависящие от этой, удалить".
Это просто как пример операций, НО(!) сложные запросы перестанут быть "сложнодекларативными" - они станут ИМПЕРАТИВНЫМИ (что сильно упростит код программиста для алгоритмически тривиальных задач а-ля "найти все города, где люди выше среднего и в музыке любят рок").
