Проблема проектирования базы данных NoSQL для приложения управления уведомлениями?

Question

Я пытаюсь создать базу данных в NoSQL для целей обучения

Это простое приложение для управления уведомлениями (добавление / редактирование / удаление уведомлений из borad) в PHP.
У меня есть Memcached (на самом деле Membase), где я могу хранить данные в виде пары ключ-значение.

Для добавления уведомления я генерирую уникальный идентификатор {с помощью функции uniqueid ()} и сохраняю в нем детали уведомления. Но проблема в том, 1. Как перечислить все уведомления?

Я также хочу добавить серийный ключ в уведомления. Для этого мне нужно знать серийный ключ последних вставленных данных. 2. Как узнать последнее вставленное Уведомление?

Если этот вопрос окажется неуместным, поскольку это несколько реляционная модель данных (или вы можете сказать, что она должна быть реализована в реляционной базе данных), пожалуйста, дайте мне знать любой сценарий использования, где я могу использовать NoSQL, чтобы узнать больше об этом.

Answer 1

Естественные связи между сущностями являются реляционными, поэтому каждая модель данных хорошо спроектирована с использованием реляционной схемы.Почти каждая схема nosql может быть представлена ​​в реляционной модели данных.

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

MongoDB (http://www.mongodb.org/) является хорошей отправной точкой в ​​данных NoSQL, потому что позволяет смешивать денормализованную схему с (почти) реляционнойdesign.

Хорошим примером использования является реализация модели данных для хранения данных пользовательских форм - где количество полей и тип полей не известны заранее

А о ваших вопросах:

1. Я не очень хорошо знаю мембрану, но если это простое хранилище значений ключей, единственное решение - создать еще один ключ, в котором вы храните список всех идентификаторов - но одновременные обновления представляют большую проблему здесь
2. Вы также можете сохранить последний идентификатор вставки в другом месте (в другом ключе) - здесь одновременные обновления прощео мастер

Answer 2

Первое, что нужно узнать о NoSQL, это то, что существует множество решений NoSQL с различными возможностями.Вам нужно выбрать тот, который наиболее подходит.В этом случае Redis сделает вашу жизнь намного проще с выбранным вами дизайном.

Суть проблемы - теорема CAP .Многие решения NoSQL сознательно выбирают , а не , чтобы гарантировать согласованность.После того, как вы выбросили это, вы не можете гарантировать, что один и тот же идентификатор не будет выдан дважды.Поэтому имеет смысл либо использовать временные метки, либо использовать что-то другое (например, Redis) для генерации уникальных идентификаторов, которые вы можете хранить в любом месте.