При моделировании данных, как лучше всего моделировать таблицу, которая растет, скажем, 1000 раз за год для каждого добавляемого пользователя?

Question

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

Answer 1

Я не понимаю, о чем ты спрашиваешь?Если я прав, у вас есть две таблицы с отношением один ко многим ([USER TABLE] -< [DATA TABLE]).Или вы хотите иметь отдельную таблицу для данных каждого пользователя.

Если у вас всего две таблицы, тогда дизайн правильный, но если я вас неправильно понял, пожалуйста, уточните.

Answer 2

Реальный вопрос, должны ли большие данные помещаться в SQL в первую очередь.

Вам нужны какие-либо функции базы данных для этих больших данных?

• Структурированные запросы?Какие-либо вычисления для набора данных или просто поиск?
• Реляционная функциональность помимо ввода данных пользователя?
• ACID гарантирует (атомарность, согласованность, изоляция, долговечность) в отношении хранения и поиска данных
• Уровень допустимой потери дополнительных данных?Это звучит грубо, но на одном сайте социальной сети, над которым я работал, мы фактически решили (и это было разумное деловое решение) принять риск того, что иногда, очень редко, данные на самом деле могут потеряться потеря - мы отправилиэто к зеркальному кластеру и никогда не ждал подтверждения, если он действительно пошел туда.

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

Answer 3

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