Большие базы данных и документы хорошо подходят? - PullRequest
1 голос
/ 19 апреля 2011

Я унаследовал поддержку очень большой веб-формы, которая обрабатывается на PHP.Я опытный в разработке PHP, но авторы не были.В настоящее время данные хранятся в реляционной базе данных, но я подумываю о переходе на базу данных документов (в частности, mongodb), и было бы интересно узнать, звучит ли этот вариант использования как хорошее соответствие для базы данных документов.

==== текущая ситуация ====

Существует около 1400 элементов формы (да, вы правильно прочитали), которые расположены на нескольких вкладках пользовательского интерфейса.Имена элементов формы отображаются один в один со столбцами в базе данных.По некоторым причинам он охватывает 4 таблицы базы данных.Возможно, MySQL имеет ограничение на количество столбцов.Я значительно изменил сохранение данных, но запросить серверную часть - это боль.

Частью варианта использования этой формы является то, что человек заполняет ее каждый год.Когда форма «открыта», данные за предыдущий год копируются вперед.Таким образом, им не нужно повторно вводить вещи, которые остались прежними.Для большинства людей им нужна только часть полей формы.Есть около 25 мест, где человек может загрузить документ вместо непосредственного ввода данных.Эта форма не получает интенсивного трафика.

Одна из самых уродливых вещей в этом - то, как распределено пространство формы.Если у вас есть 10 элементов 'foo', у вас есть 10 столбцов в базе данных с именами foo1, foo2 и т. Д. Нужен одиннадцатый?Добавить столбец в БД, редактировать HTML и PHP.Gag.О да, обязательно сделайте то же самое для версии для печати. ​​

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

==== выброшенное решение ====

Некоторое время я думал о том, чтобы создать правильную реляционную таблицу, чтобы иметь свой 11-й элемент формы 'foo' без изменения схемы или формы БД.Когда я наметил это, диаграмма ER стала немного подавляющей.Моя интуиция сказала, что это улучшение архитектуры, но должно быть более простое решение.

==== предлагаемое решение ====

Итак, я предлагаю написать скрипт для портаданные в хранилище mongodb и вместо этого начните запись / чтение из него.У него все еще будет огромное количество полей, но управление данными кажется более разумным.Если я хочу одиннадцатый 'foo', я просто храню его.Если существует иерархия данных, все это в одном месте.

Есть ли здесь подводные камни, о которых мне следует знать?Будут ли люди рекомендовать другие подходы?

1 Ответ

1 голос
/ 19 апреля 2011

Этот вопрос не имеет ничего общего с RDBMS по сравнению с NoSQL - каждый правильно спроектированный уровень базы данных может справиться с такой проблемой. В мире ORM довольно легко быть гибким с изменяющимися требованиями к базе данных и сложными схемами базы данных. То же самое относится к базам данных NoSQL - хотя они обычно не имеют схемы. В любом случае, в чем ваша точка зрения?

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...