Блог

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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