Блог

Допустим, я хочу создать похожую службу, которая поддерживает несколько привлекательных объектов: фотографии, комментарии, пользователи или что-то еще. Список является открытым. Я не чувствую уверенности в этом вопросе, и мои вопросы:

1) Как движки реляционных баз данных удовлетворяют мои потребности? У меня был бы один общий объект like (like_id, user_id) и несколько сводных объектов: like_photo (id, like_id, photo_id), like_video (id, like_id, video_id), где поле like_id в сводных таблицах является внешним ключом, который ссылается на общую таблицу like, позволяющую идентифицировать пользователя, которому понравилосьи, возможно, другая информация, такая как временная метка и т. Д.

2) Я предпочитаю использовать для этой цели какую-то базу данных nosql (у меня вообще нет опыта работы с nosql)?

2.1) Возможно ли иметь надежную ссылку на кросс-базу данных (RMDBS — база данных nosql)

Вы даете нам очень мало для продолжения — и этот вопрос может вызвать споры и мнения.

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

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

 users
----------
userID
....


Objects
----------
objectID
URL
objectType
....


Likes
----------
UserID
ObjectID
  

Вам, конечно, может потребоваться хранить больше информации о ваших «объектах». Вот где вы, вероятно, столкнетесь с проблемой — реляционная база данных не является элегантной, если вам нужно хранить полиморфные типы данных. Вы можете использовать Google (я видел и ответил на несколько вопросов по этому поводу в SO).

Является ли NoSQL «лучше» здесь, зависит исключительно от вариантов использования, которые вы собираетесь поддерживать. Вам нужно будет предоставить больше контекста.