SQL vs NOSQL: что использовать для этой схемы?

У меня есть предстоящий проект, и я не могу решить, следует ли придерживаться SQL или переключиться на NoSQL. Это в основном система отчетности с основным интерфейсом, сообщающим данные, введенные пользователями.

Здесь схема, которую я наметил:

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

Мои проблемы, однако, в два раза:

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

Мой вопрос: Учитывая мои проблемы, считаете ли вы, что эта схема - из-за того, насколько глубоко она вложена, - больше подходит для NoSQL? Если да, то считаете ли вы, что отчетность по "записям" будет сложной?

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

Заранее благодарим за помощь!

Ответ 1

Просто мое мнение:

Я смотрел на диаграмму в течение примерно 3 секунд, это явно реляционное. Преимущества RDBMS значительно перевешивают решение NoSQL. Почему вы хотите использовать NoSQL? Есть ли 100 000 записей (может быть, миллион плюс)? Вам нужна микросекунда/миллисекунда?

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

Ответ 2

Вероятно, вы можете взломать всю иерархию {организация, регион, кампус, событие} в одно иерархическое/древовидное/самореферентное отношение. Может быть, "пользователь" тоже. Это значительно сократило бы количество необходимых таблиц. для примера, пожалуйста, взгляните на эту реализацию: Интересная проблема структуры дерева/иерархической структуры данных (которая на самом деле более сложна, чем ваша).

Кстати: у меня нет ни малейшего представления о том, что означает "метрическая модель". Дюймов? Мили в галлон? Или просто "измерения"? Не могли бы вы объяснить немного больше того, что вы намереваетесь сделать?

EDIT: BTW2: модель, которую вы предлагаете, технически не слишком сложна для postgres. Но это, вероятно, больше, чем необходимо людям.

Ответ 3

Мой вопрос: Учитывая мои проблемы, вы думаете, что эта схема - из-за насколько глубоко он вложен - больше подходит для NoSQL?

Глубокое вложение - это не точка pro или contra SQL/NoSQL.

Если да, считаете ли вы, что отчетность по "записям" будет сложной?

Это переломный момент, и здесь вы не даете нам соответствующей информации: что это за "сообщение" в вашем случае?

Сообщает ли один агрегат много данных?
Э.Г. он просто агрегирует все records и возвращает их сумму?
Содержит ли он совокупность по многим вашим слоям?
Является ли отчет строго иерархическим или он коррелирует event1.metric4.record42 с event2.metric18.record50 (или что-то в этом роде)?
Сколько данных должно быть передано из базы данных NoSQL в ваше приложение только для того, чтобы скомпилировать его в большинстве случаев.
Как неструктурированные данные? Хорошо - очень структурированное впечатление.

Это типичные ситуации/точки, в которых RDBM доказали свою ценность. Если эти предметы не важны в вашем случае, вы можете свободно выбирать.