Простите, пропал на месяц. Несколько раз начинал писать, но чета ничего не получалось, в итоге написал вот этот (довольно тривиальный) текст
Сейчас будет база для более скилловых разрабов и тех, кто работал на гигантских проектах, но для меня это открытие, которое я сделал для себя всего несколько месяцев назад. С базами данных очень много - даже не приземлённых, а концептуальных проблем: по своей сути классические реляционные базы данных очень геморные.
1️⃣ Для взаимодействия с БД используется SQL, который предназначен для ручного ввода и пытается выглядеть естесственным языком. Популярных, настолько же поддерживаемых (а значит и лёгких в использовании вследствие массовости), но более читаемых для ПО языков запросов в БД не существует.
2️⃣ Это одна из причин появления ORM-подхода. При этом почти все реализации ORM весьма ограничены функционально и не позволяют использовать базы данных полностью (например, индексы) - БД часто используются как простые хранилища с четырмя базовыми действиями(CRUD), к которым добавляют простенькую фильтрацию и сортировку.
3️⃣ При этом базы данных до сих пор не умеют делать некоторые простейшие вещи быстро - тот же OFFSET во всех популярных реляционных БД - плохой подход для пагинации, потому что при его использовании подгружаются не только N записей после OFFSET, но и все записи до него. Чем дальше мы идём в табличку, тем медленнее будет осуществляться запрос. Или JOIN-подгрузка, которая быстрее работает с большими наборами данных: в целях оптимизации её так и используют вместо того, чтобы использовать её там, где это уместно.
4️⃣ Сложные составные SQL-запросы на больших проектах могут просто упереться в ограничение по длине, что усложняет аналитику или даже продуктовые запросы в БД.
5️⃣ У SQL сложный синтаксис, и его сложно учить и даже помнить. Это обавляет неудобств разработчикам. Если для хранения информации нужен функционал, которого нет в ORM, то его ещё и приходится защищать от инъекций.
6️⃣ Существуют альтернативные БД, и не только нереляционные - NoSQL, конечно, круто, но нетабличная структура часто неудобна и не подходит под информационную модель проекта. Есть проекты реляционных баз данных, типа Gel, но они малоизвестные, и с ними джуну работать труднее, чем с тем же postgres, на котором Gel и основан.
В общем, реляционные базы данных реально проблемные инструменты, и хочется, чтобы появились и развились альтернативные проекты.
Пишите в комментах, что думаете и как решаете вышеописанные проблемы в своих проектах
P.S. И надо сабнуться на тгк: https://t.me/dmkjfss
Top comments (0)