Какую базу данных использовать для такого проекта?

Question

[Анастасия]

В общем делаю проект
Frontend - Vue,
Бекенд - буду пробовать писать на Laravel, до этого все на php делала

И вот такой вопрос какая база данных лучше подойдет для проекта?
Проект с регистрацией и авторизацией
Todo List - список задач и заметок с довольно сложным интерфейсом

Примерно такой интерфейс будет
И ещё когда лучше реляционную и нереляционную использовать?
Желательно с пояснениями почему, какая-то бд сдесь подойдет лучше и т.п.

Answer 1

[Ипатьев]

Ну, на основной вопрос уже ответили, а я освещу отдельную проблему, которая очень часто волнует умы юных падаванов.

когда лучше реляционную и нереляционную использовать?

Ответ на этот вопрос очень простой.
Нереляционная БД - это НЕ база данных.
А узкоспециализированное хранилище, которое может выполнять какую-то одну определенную функцию лучше, чем база данных. Это может быть кэширующий демон, или поисковый движок, или решение для аналитики, или какое-то подсобное хранилище для всякого мусора.

Как только осознаёшь этот простой факт, то всё сразу становится на место:
Если нужна база данных, то и использовать надо базу данных. Реляционную. Какую именно - в вашем случае не принципиально.

Если вдруг проект пройдет стадию "неясные идеи", и выльется во что-то практическое, и даже появится какая-то нагрузка, то можно будет начать думать про использование одного или нескольких подсобных хранилищ в дополнение к базе данных.

Comments

[ClayRing]

Нереляционная БД - это НЕ база данных

Нереляционная база да
анных - это НЕ база данных

Вы сами не видите противоречия в вашем утверждении?

[Ипатьев]

ClayRing, вопрос не ко мне, а к тем кто эти служебные программы причисляет к базам данных.
К их чести сказать, с Редисом и мемкешем такое случается довольно редко

Answer 2

[mayton2019]

Тут подходит любая реляционная SQL БД потому что нет противопоказаний. Реляционку мы выбираем
уже более 30 лет как default вариант и почти не ошибаемся.

Когда задача имеет признаки ярко выраженной high-load системы - мы делаем ей частичную денормализацию
и раскладываем ее в NoSQL Key-Value решение. Но это не про улучшение а это про неизбежность. У нас нет выхода просто.
Иначе мы клиенту не сможем быстро отдать какой-то резуальтат.

Когда задача имеет ярко выраженную документную природу (нет спецификации на values) - мы берем MongoDb/CouchDb.

Когда задача хранит граф и ищет в графе и вообще требует графовых алгоритмов - то мы берем Neo4j или ей подобные.

Когда задача хранит данные измерений (телеметрия) - то предпочтительно взять InfluxDb или ей подобные. Здесь-же мы предполагаем что у нас - не будет joins а будет только измерения в диапазоне времени.

Но в данном ТЗ и на картинке обычная SQL БД (MySQL/Postgres) вполне себе нормально справляется.

Answer 3

[Slava Rozhnev]

Выбирать базу данных по картинке - задача неблагодарная. В вашем случае я не вижу каких-то особых требований к базе, поэтому возьмите ту базу которую вы уже знаете. Если не знаете ни одной - возьмите MySQL (самая популярная база для WEB проектов)

Answer 4

[Константин Б.]

Любая база. MySQL справится на ура.

Answer 5

[Денис Шавалеев]

Думаю в данном случае вполне подойдет Postgres, для более структурированного хранения данных, нежели использование NoSQL СУБД. Там уже продумать структуру таблиц можно спокойно и подготовить миграции в проекте.

Answer 6

[alexalexes]

Любую СУБД, с чем дружит php, и заводится с полточка: mySQL (лучше брать 8+ версию, а не 5.x, так как намучаетесь с реализацией аналогов оконных функций), postgresql и т.д.

И ещё когда лучше реляционную и нереляционную использовать?

Чем структуированнее и связаннее данные вводятся и выводятся в/из систему, тем проще ее сделать в реляционных сущностях.
Различные шедулеры и таск менеджеры в реляционных СУБД на раз расписываются, нужно лишь набитый навык, как функциональную схему и потоки данных переложить на ER-диаграмму.