У меня тупой вопрос возник по архитектуре: надо на каждого

клиента завести список где указывать к каким курсам он имеет доступ. Думаю что лучше: пихать список прямо в структуру клиента или ссылкой на строку в бд где список или еще как?

Зависит от ситуации, смотря сколько курсов, меняется их полный список или нет, насколько большая структура у описания курса кол-во на одного пользователя и проч например всего 3 курса их можно прям в коде константами задать, но такое крайне редко из ситуации в большинстве случаев хранение отдельно будет правильнее

Составьте список юзкейсов для этих данных и оттуда уже исходите.

бд обязательно, а вот какое - уже вопрос, возьмите для начала sqlite, а там перейдете уже перед продом на нормальную бд, если вообще будете релизить когда-нибудь))

+много. Прежде чем выбирать какой-то вариант хранения данных надо определиться что с ними будут делать

уже использую sqlite но задача поменялась и теперь надо норм бд. думаю cocroach (кластер хорошо делается) или пострес (ради json)

Ничего себе у вас замашки с sqlite на кластер 🤣 Вы б еще кластер от Оракл выбрали за дофигилион бабла))) https://t.me/dba_ru Вот вам чатик, там помогут выбрать бд под ваши требования, только нужно их хоть чучуть развернуть эти требования. Потому что судя по всему я бы вам посоветовал PostgreSQL, но нивкоем случае не советовал json, потому что намаетесь с ним, но опять же, не понятна ни задача, ни лимиты, ничего, приглашаю в тот чатик обсудить бд 😏

ради эксперимента хочу не обращаться к бд удаленно а поставить вторую копию и чтобы она работала в режиме синхронизации т.е. кластер. если бы не это я бы поставил любую Nosql типа couch

Какой в этом практический смысл? Ох уж эти хипстеры, нальют им в уши про noSql они и радуются, а разобраться надо им это или не надо, какие требования к продакшену - пофигу 🤦

а как вы будете добавлять информацию для которой полей нет в бд?

Смотря какую информацию, смотря каких полей нет и почему нет, смотря что с этой информацией нужно будет делать потом и т.д. очень много неизвестных 😊

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

Ну т.е. заранее известно, какого рода данные прийдут и какой классификации, так почему же тогда говорите нет полей, если стоит их просто добавить, а в некоторых ситуациях не полями решается, а доп таблицами 😉 Опять же, я не исключаю, что нужна и NoSQL, но какая?)) Их же несметное множество, может вам вообще нужен полнотекстовый поиск, а может графовая бд. Но пока что все что вы описываете все еще ложится в реляционную базу запросто)

например как в sql базе на клиента записывать какие курсы есть у него? список курсов меняется и у него и в системе

Вот, коллега выше описал решение)) Вы бы почитали немного про реляционные базы и то, как в них строить таблицы - узнали бы много нового, а не бежали сразу за noSQL по поводу и без 😁

так я вас спросил вы же разбираетесь да)

Так если коллега про мени то мени написал правильно и про то, что это делается доп таблицей с полями айдишниками, связывающими сущности)

понятно что таблицами т.к. больше нечем но это же гемор по сравнению с nosql

а в чем проблема. user_id, course_id - foreighn keys. primary составной из user_id и course_id. Захотели получить всех пользователей записаных на один курс - изи, получить все курсы для пользака - изи

Это гемор, пока вам выборки не нужно делать и аналитику, чего в noSQL уже так просто не сделаешь. А в реляционных бд вот этот вот гемор, о котором вы переживаете в виде доп таблицы, сослужит вам нереальную дружбу, особенно, если вам нужно будет посчитать и проанализировать юзеров купивших конкретный курс

Плюс вы поменяли курс или юзера как вам захотелось, но так как эта доп страница привязана чисто айдишником, то никто ничего не заметил)) А в noSQL вам прийдетсякак-то за этим следить и обновлять эту инфу. Опять же, эти проблемы частично решают графовые бд, но судя по всему, они у вас не в приоритете, да и связей не так много, чтобы получить профит по сравнению с релиционными, а значит вы склонитесь в сторону документно ориентированных субд, у которых выборки данных точечные идут на ура, но как только появляются связи между объектами - просадка по перфомансу