Itree подходит для хранения большого количества

элементов 2 уровня ?

Да хранить можно как угодно, вопрос в том, что и зачем (т.е. какая глубина дерева (и дерево ли это на самом деле), какие запросы чаще всего нужны и т.п.).

Грубо говоря для соц сети , хранить по сути нужно так tab users ну по сути дерево user , users.friend , user.dialogs, user.info,

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

А запросы какие (см. выше)? В общем, лучше описать конкретные задачи, а потом послушать тех, кто что-то подобное уже делал. ;) Кстати, можно спросить и в https://t.me/pgsql

Ну по сути я к пришёл в выбору pg я об этом уже говорил

Благодарю

Да, но вы потом и про Itree упомянули, на что и был мой ответ, в том плане, что основные данные хранить проще в обычной субд, а уже потом вот эти все Itree и прочие штуки типа графовых баз данных добавляются на этапе оптимизации, может вам вообще ArangoDB подойдет, а может узкоспециализированные графовые субд, а может тупо кеш запросов. В общем я и вел к тому, что то что вы спрашиваете это уровень оптимизации, а не выбора субд, т.е. когда уже будет реальная картина происходящего и ваш сервер или субд уже не сможет справляться с нагрузкой 😉

Это не дерево

а где тут деревья, это же обычные таблицы по-сути

Я с этим новичок, просто пытаюсь сделать все сам , вот и полез в мало известные мне дебри

я тоже делаю соц сеть)

Фронт и бек для меня не особая прям проблема , а вот как залез в бд так и застрял тут

Viacheslav 🇺🇦 Boiko
ну друзей юзера ты можешь хранить в такой таблице ...

У твоей userFollow не должно быть суррогатного ID, он не нужен

типа PK?

Я не понимаювопрос

что значит, не должно быть сурогатного Ид? не совсем понимаю

То поле что ты сделал, id, оно лишнее, на треть будет больше места таблица занимать

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

Нет, я такого не говорил

ааааа, я кажется начинаю понимать, всё) затупил)

получится так )

Нет , неправильно

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

Всё правильно написал. А теперь напиши правильно определение таблицы

к тому же кейсу, Айтемом будет табличка юзеров же, разве нет? юзер может иметь несколько подписчиков и быть подписан на нескольких людей

не совсем понял здесь, ты сказал, поле айди лишнее, а айди это первичный ключ, что лучше сделать с этим полем? чё-то в тупик загнал)

Это поле удалить. PK сделать составной из двух полей — одного и другого юзера

ааа, я так понял в постгресе первичный ключ может быть не уникальным, или нет?

Нет, не может, ты понял неверно

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

Нет, не может. И почитали бы Вы что-нибудь про основы реляционного моделирования, в самом деле. ;) Как уже написали, в этой таблице не нужен id, а нужен PK(follower_id, following_id). И это "стандартная" схема для many-to-many, кстати.

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

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

Будьте честными, не читали документаций вообще никаких и как строить таблицы тоже не читали 😄

конечно нет)

а что значит как строить таблицы, что почитать по этой теме?

Ну банально связи один к одному, один ко многим, многие ко многим вот это вот такое)

а, это знаю ещё с 1 курса, я думал какие-то там махинации над таблицами)

вы знаете только определение, но не область применения и для чего используется в реальных проектах 😏

Есть немало книг по реляционному проектированию. По идее, их легко найти. ;)

ну я работаю с аутсорс компанией, и зачастую на бэкенде, юзаем MS SQL, думаю я знаю) реальный проект сейчас у нас: Amadeus Hospitality Diagramming

Если бы знали, то не добавляли бы в вариант многие ко многимлишние поле 😏 Я же не спорить с вами пришел, а подсказать)

спасибо, именно это я почему-то и упустил в своём багаже знаний. Но за помощь всегда спасибо)