Необходимо сделать приложение (nodejs, mongodb), поддерживающее регистрацию нескольких пользователей. Как создавать юзера, модели, выполнять авторизацию, проверку кукис и т.п. - это все я знаю. Т.е. я могу создать юзера или нескольких, но каждому такому юзеру, условно говоря, будет доступна вся бд. Загвоздка именно в создании множества юзеров с одними и теми же названиями коллекций mongodb, но разными документами в них (у каждого юзера свои документы).
Например, приложение для систематизации библиотеки. В бд есть коллекции - authors, genres, publishers, books и т.д. Регистрируется user_1, логинится и создает свои записи книг, авторов, жанров... И они доступны только ему. Регистрируется user_2 - и всё аналогично.
Это, в общем-то, вопрос проектирования бд. Как это должно выглядеть?
Создается отдельная бд для каждого юзера?
Или бд одна, но внутри как-то разделена по юзерам?
Или бд одна, и там вообще всё в кучу, и связи юзеров и их коллекций делаются через Schema.Types.ObjectId?
Что можно почитать, посмотреть, чтобы понять, как делать такие вещи?
Я подозреваю, что для подобных вещей лучше бы использовать что-нибудь sql-образное, но тем не менее, хочется понять, как решить задачу в контексте документоориентированной бд.
Разве что (вполне допускаю, что пытаюсь заняться ерундой) такие вещи вообще крайне глупо делать на mongodb, независимо от степени сложности самого приложения. Если так, по возможности, объясните, почему именно глупо.
Например, приложение для систематизации библиотеки. В бд есть коллекции - authors, genres, publishers, books и т.д. Регистрируется user_1, логинится и создает свои записи книг, авторов, жанров... И они доступны только ему. Регистрируется user_2 - и всё аналогично.
Каждому автору, книге и тд. присваиваете userId его хозяина. Потом просто достаёте нужные данные по этому айди для определённого пользователя.
Или бд одна, и там вообще всё в кучу, и связи юзеров и их коллекций делаются через Schema.Types.ObjectId
Да.
Как особый вид извращения можно реализовать multitenancy через создание отдельных коллекций вида authors_<user_id> )
но реляционные БД тут подходят лучше (как и в подавляющем большинстве случаев, учитывая что многие из них поддерживают, например, json поля)
Простой
Простой