Дизайн базы данных для пользовательских данных

Question

Я на ранних стадиях нового проекта.Поскольку мы разрабатываем итеративно и относительно быстро (проектируя продукт по ходу дела), иногда может быть немного сложнее выбрать «правильный» дизайн для чего-то заранее.Мы склонны выбирать что-то и пересматривать всякий раз, когда это необходимо.

Сейчас я работаю над моделью для пользовательских данных.Мой подход заключается в том, чтобы иметь по существу две таблицы: одну с необходимыми данными типа входа (имя пользователя, дата создания, учетные данные и т. Д.), А другую таблицу для хранения ключей, данных значений, которые нам нужны для пользователей.

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

Это также шаблон, который я использовал ранее.

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

Answer 1

Вопросы, которые вы должны задать:

• Можем ли мы предсказать все Ключи при разработке приложения?
• По-разному ли наше приложение обрабатывает разные Ключи (т.е. у вас есть эквивалент?if (Key=="something") где-нибудь в вашем коде)?

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

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

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

Answer 2

Как вы сами сказали:

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

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

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

В общем, реляционная модель имеет свои сильные стороны, иуправление большими наборами «псевдополей» значения ключа не является одним из них.Для этого вы можете перейти к продуктам NOSQL, может быть.