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

Question

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

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

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

Однако мои опасения связаны сСвернуть:

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

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

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

Заранее спасибо за вашпомощь!

Answer 1

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

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

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

Answer 2

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

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

РЕДАКТИРОВАТЬ: BTW2: модель, которую вы предлагаете, технически не слишком сложна для postgres. Но это, вероятно, больше, чем необходимо для людей.

Answer 3

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

Глубокое вложение не является точкой зрения за или против SQL / NoSQL.

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

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

• Объединяет ли один отчет много данных?Например, он просто агрегирует все records и возвращает их сумму?

• Агрегирует ли он по многим вашим слоям?

• отчет оценивается строго иерархически или он соотносится event1.metric4.record42 с event2.metric18.record50 (или что-то в этом роде)?

• Сколько данных необходимо перенести из БД NoSQL в ваше приложение только для того, чтобы агрегировать их, отбрасывая большинство частей.

• Насколько неструктурированы ваши данные?Ну, кажется, очень структурировано.

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