Поддерживать многоуровневую иерархию таблиц в базе данных
Я должен вести данные списка друзей, которым понравился пост определенной категории. И это может быть на любом уровне. Например,
если друг А, который Б, как разыскиваемый пост. тогда я буду вести учет друзей А и друга Б. В основном мое требование
Если пользователь посещает мой продуктовый сайт, я должен сообщить ему / ей, что вы следуете за другом, который уже посетил то же самое, и они фактически рекомендуют вам использовать это и укрепить уверенность в том, что вы на правильном пути, поскольку ваши друзья также используют его. Я также хочу предложить A, что C, который является другом B, использует этот продукт с этого времени, и C предлагает многим за его использование.
Я знаю, что эта логика уже реализована на хороших сайтах.
Я просто стартер. Поэтому, пожалуйста, предложите мне базу данных для бэкэнда и необходимые вещи для внешнего интерфейса.
Специально этот вопрос заключается в ведении записи в базе данных. Поэтому я спрашиваю базу данных, что я должен использовать, а не как я должен реализовать это будет следующим шагом.
Так как я планирую использовать для этого базу данных Graph. В графе либо bigdata, либо Neo4j.
Ваши идеи приветствуются и будут оценены. Спасибо
Решение
Я надеюсь, что моя логика может сделать вас на несколько шагов вперед
Первоначально мы должны поддерживать общие записи друзей
пример врага
id mut_id
1 2,3,4
Здесь 2,3,4 твои друзья
Далее нам нужно вести записи, кто купил / посетил
prod_id buy_id
1 2,1
Теперь предположим, что 3 id хочет купить или посетить сайт, тогда мы можем показать, что ваш друг уже посетил или купил продукт
Другие решения
Отношения с друзьями — это классическая схема «многие ко многим». Вам нужно две таблицы для реализации этого:
1. Таблица с личными данными, такими как имя, адрес электронной почты и т. Д. (Может быть более сложной, например, отношение личность-свойство)
2. Таблица с данными о дружеских отношениях друзей, обычно она содержит идентификаторы пар друзей, которые представляет отношение, и некоторые данные о самом отношении, такие как категория (друг / семья / одноклассник и т. Д.), Уровень близости (если> 0, это означает положительный результат). связь, <0 негативов типа врагов) и тд. Предположим, что первый идентификатор — это человек, к которому относится это отношение (и может поддерживаться), второй идентификатор — это человек, к которому относится это отношение. Обычно таблицы такого типа ограничены парой идентификаторов, чтобы быть уникальными, поэтому никто не сможет добавить одного и того же человека в друзья дважды
Вот пример:
CREATE TABLE person
(
id INT NOT NULL AUTO_INCREMENT,
name VARCHAR(255),
email VARCHAR(255),
PRIMARY KEY (person_id)
);
CREATE TABLE relationship
(
id_person INT NOT NULL REFERENCES person(id),
id_person_related INT NOT NULL REFERENCES person(id),
id_category INT REFERENCES relcategories(id),
affinity INT,
PRIMARY KEY (id_person, id_person_related)
);
Обратите внимание, что поля affinity и id_category не обязательны, а для последнего требуется таблица relcategories с INT id поле, которое будет создано первым
Визиты одного друга к другому также могут быть сохранены в relationship в отдельном поле