пример: Мне нужно получить одну строку из `table1`, включая все связанные строки из других таблиц в виде JSON объекта.
Пример одной релевантной строки из таблицы 'relation':
{
id: 'uuid',
table1: 'id_строки_из_table1',
table2: null,
table3: null
table4: 'id_строки_из_table4',
}
в этом конкретном случае мне нужно получить только строку из table4 по id_строки_из_table4. Мне не нужна строка из table1, так как она уже получена (в этой ситуации как материнский объект
про join знаю, но тут же не один столбец со связью. Как правильно сделать? проверять не пуст ли столбец и делать join? Или сделать join для всех? Как сделать так, чтобы joinу не подвергался тот столбец, который связан с таблицей table1? (или с другой, в зависимости от того, из какой таблицы изначально запрос начинается)
добавьте, пожалуйста, к своему ответу информацию о JWT:
JSON Web Token (JWT) позволяет хранить в криптованом виде session id и прочую информацию о сессии в localStorage клиента, вместо того чтобы записывать эти данные где-либо на сервере.
Может кому-то пригодится. Из вашего ответа я это не понял. Вопрос о безопасности я еще изучу, но судя по всему это не глупые люди делали - наверняка все что можно уже предусмотрено.
На сколько я знаю, токен принято хранить в Cookies, чтобы js код веб-приложения не имел доступа к нему. А с JWT, я так понял, токен нужно сохранять в localStorage. Это же XSS уязвимость, верно?
я пока не понял, как работает JWT, но в любом случае, ведь нужно еще идентификатор учетной записи пользователя как-то хранить, чтобы можно было к сохраняемым в бд объектам привязывать "подпись" пользователя, чтобы можно было установить владельца той или иной записи в бд
Благодарю, Сергей!
Так как. все-таки, вот это сделать?)
> **socket.io получает sid и как-то привязывает его к текущему соединению** чтобы далее он прикреплялся ко всем запросам клиента к серверу
Materialized Views не обновляются самостоятельно и судя по приведенному там примеру, комманда REFRESH полностью переделывает указанный Materialized Views вместо того, чтобы обновить только измененные данные. Следовательно данные там будут свежими только после очень тяжелого обновления, следовательно это не то, что мне нужно. Я хочу чтобы при обновлении одного единственного объекта в одной единственной таблице происходило обновление одной единственной строки в той самой сформированной таблице.
Запросы асинхронные, а есть какие-нибудь аргументы в пользу отправки множества запросов вместо одного? Ну кроме того что это зачастую удобнее. Я бы хотел понять, как это можно измерить
romy4: Спасибо, это тот ответ, который мне был нужен. Если я вас правильно понял, то на каждую таблицу нужно делать отдельный select, а затем с помощью алиасов складывать json объект со всеми желаемыми вложенностями. Кроме того, для этого стоит использовать VIEWS. Верно? Я только начал изучать Postgres и sql в целом, хочу избежать как можно больше детских ошибок на старте) Можете привести пример самой обычной команды для получения json объекта в том виде, о котором я писал?
то есть, если ParentTable имеет строку, в которой конкретный столбец имеет связь с двумя строками другой таблицы, то я получаю две строки, в каждой из которых инфа из ParentTable + инфа из одной из связанных строк, вместо того, чтобы получить один json объект, в котором связанные строки были бы внутри одного объекта (строки из родительской таблицы)
Не убедительно, все доводы, которые я привел бы вам в пользу postgres приведены в комментариях. В любом случае, благодарю вас за предоставление альтернативной точки зрения!
ну у меня сходная ситуация - я ем именно суп) У меня почти все типы объектов имеют связи с другими типами объектов. Дублировать инфу в каждом документе просто нет смысла с учетом частых мелких изменений.
Простейший пример: комментарий, у комментария есть текст и есть связь с пользователем, создавшим комментарий, чтобы можно было сформировать ссылку на страницу пользователя прямо из его комментария. У пользователя есть переменные, которые отображаются в каждом комменте - аватар и имя. Следовательно, мне нужно либо создавать связь с пользователем, либо копировать необходимые данные в каждый документ комментария.
То есть, мне нужна реляционность. К тому же, postgres (кажется с версии 9.4) также работает с json объектами, то есть у него есть и преимущества документо-ориентированой бд и реляционной. Если я не правильно это понимаю, пожалуйста, дайте ссылку на подходящую статью/видео на эту тему. Можно на английском.