Товарищи, подскажите, научите, плиз.
Я прочитал информацию по MongoDB, даже учебник нашёл и буду там черпать инфу, но у меня, скорее, идеологический вопрос!
Вот как правильно организовывать и хранить в ней данные, именно идейно правильно. Я видел рассуждения на СтекОверФлоу, но вот пока не складывается и реляционная модель плотно сидит в голове. Можно ли на каком-то примере связанных таблих и о том, как это хранить в Монге?
Допустим у нас есть какой-нибудь продукт и связанная с ним картинка
Связь будет просто по айдишникам.
product:
{
_id : ObjectId('1'),
name : "randomproduct",
resources: [
ObjectId(2),ObjectId(3)
]
}
resource:
{
_id:ObjectId('2"),
name:"url1"
},
{
_id:ObjectId(3),
name:"url2"
}
А если ещё и магазины ... вот раньше я бы делал отдельную таблицу для магазинов и связывал бы магазины с продуктами через ключ, а тут как лучше?
Здесь есть несколько подходов. Самый тупой - как я показал в комменте выше, то есть добавлять продукты в магазины напрямую.
Можно делать сущность product_list, где будешь хранить собственно список айдишников продуктов в массиве, а уже айдишник этого продуктлиста хранить в сущности магазина. получается в аналогии к реляционным связь многие ко многим.
Еще есть подход для скорости работы (потому что составные индексы на массивы монги не всегда хорошая штука) это заводить реляционную базу с индексами. То есть данные по продукту а ля какого цвета и какая стоимость хранишь в монге. а вот поисковые данные а ля партномер, скуй или категория хранишь в sql с привязкой к монговым айдишникам. но это потребует какой-то транзакционности.
По поводу проектирования могу дать совет, что отталкивайся от типичных запросов и юз-кейсов. Как только выпишешь эти запросы, то сразу становятся понятнее точки оптимизации и на какой сущности сосредоточиться.
если что на Пикабу много разных баз используется, и Cassandra, Redis, Aerospike, ElasticSearch, Sphinx и прочие. Оcновная rdbms конечно же MySQL. Но связей между таблицами нет
каждая БД в нашем стеке выполняет свою роль. Большая часть данных дублируется, т.е. данные пользователя могут быть размазаны на 3-4 БД. Например, Aerospike - это rvdb с хранением на дисках, т.е. мы в нем храним то, что в памяти дорого хранить. REdis - kvdb для хранения в памяти, т.е. временные данные только. ElasticSearch - поиски и некоторые сложные выборки по датам. Sphinx - только для выпадающих список тегов, удобен тем, что мы индекс целиком можем пересоздавать раз в N минут. И так далее.
Разное назначение бд как минимум. Что-то реляционное, что-то полнотекстовый движок, что-то кэш.
если совсем в наивном варианте:
post:
{ _id, text, author }
comments :
{_id, text, author,
post: ObjectId(),
parent_comment: ObjectId()}
Полноценный вариант надо сидеть и проектировать довольно долго =)
Лига программистов
2.3K постов12K подписчиков
Правила сообщества
- Будьте взаимовежливы, аргументируйте критику
- Приветствуются любые посты по тематике программирования
- Если ваш пост содержит ссылки на внешние ресурсы - он должен быть самодостаточным. Вариации на тему "далее читайте в моей телеге" будут удаляться из сообщества