#php #mysql #mongodb #webforms
#php #mysql #mongodb #веб-формы
Вопрос:
Я унаследовал поддержку очень больших веб-форм, которые обрабатываются на PHP. Я опытный разработчик PHP, но первоначальные авторы не были. В настоящее время данные сохраняются в реляционной базе данных, но я рассматриваю возможность перехода на базу данных документов (в частности, mongodb), и было бы интересно узнать, подходит ли этот вариант использования для базы данных документов.
==== текущая ситуация ====
Существует около 1400 элементов формы (да, вы правильно прочитали), распределенных по нескольким вкладкам в пользовательском интерфейсе. Имена элементов формы взаимно сопоставляются со столбцами в базе данных. По какой-то причине он распределен по 4 таблицам базы данных. Возможно, у mysql было ограничение на количество столбцов. Я значительно переработал процесс экономии данных, но запрашивать серверную часть — это боль.
Часть варианта использования этой формы заключается в том, что человек заполняет ее каждый год. Когда форма «открыта», данные за предыдущий год копируются вперед. Таким образом, им не нужно повторно вводить вещи, которые остались прежними. Большинству людей требуется только часть полей формы. Существует около 25 мест, где пользователь может загрузить документ вместо непосредственного ввода данных. Эта форма не получает интенсивного трафика.
Одна из самых уродливых вещей в этом — то, как распределяется пространство формы. Если у вас есть 10 элементов foo, у вас есть 10 столбцов в базе данных с именами foo1, foo2 и т.д. Нужен 11-й? Добавьте столбец в базу данных, отредактируйте html и PHP. Кляп. О да, не забудьте сделать то же самое и для версии для печати.
Текущий дизайн не использует отношения. У меня нет проблем с производительностью, но это громоздко в управлении, и просто «кажется неправильным» хранить / извлекать данные подобным образом.
==== отклоненное решение ====
Некоторое время я рассматривал возможность создания надлежащей реляционной таблицы, чтобы у меня мог быть мой 11-й элемент формы ‘foo’ без изменения схемы или формы БД. По мере того, как я это отображал, диаграмма ER стала немного ошеломляющей. Интуиция подсказывала, что это улучшение архитектуры, но должно быть более простое решение.
==== предлагаемое решение ====
Итак, я предлагаю написать скрипт для переноса данных в хранилище mongodb и вместо этого начать запись / чтение из него. В нем по-прежнему будет огромное количество полей, но управление данными кажется более разумным. Если мне нужен 11-й ‘foo’, я просто сохраняю его. Если существует иерархия данных, все это находится в одном месте.
Есть ли здесь подводные камни, о которых я должен знать? Люди рекомендовали бы другие подходы?
Комментарии:
1. Возможно, вы захотите подойти к этому, сначала выяснив, как вам нужно будет обрабатывать данные. Будет ли в нем доступен поиск? Если да, то каким образом? Как с этим можно будет работать? Используются ли эти данные другими системами? Это может помочь вам решить, какой формат и систему баз данных вы захотите использовать.
2. Хорошие моменты, KTF. Я опустил некоторые детали для краткости, но потребности в поиске данных довольно ограничены. Это не будет использоваться в других системах. Это настолько близко к поведению бумажной формы, насколько вы можете получить. Это не совсем «сохранить и забыть», но близко к этому, потому что после сохранения и чтения к нему редко возвращаются.
Ответ №1:
Этот вопрос не имеет ничего общего с СУБД по сравнению с NoSQL — каждый правильно спроектированный внутренний уровень базы данных может справиться с такой проблемой. В мире ORM довольно легко проявлять гибкость при изменении требований к базе данных и сложных схем баз данных. То же самое относится к базам данных NoSQL, хотя они обычно не имеют схемы. В любом случае, к чему вы клоните?
Комментарии:
1. Я думаю, что он просит внести свой вклад в предлагаемое им решение и посмотреть, есть ли у кого-нибудь опыт в том, с чем может быть проще всего работать / поддерживать… однако обычно это зависит от многих факторов и очень специфично для систем, с которыми он может работать…
2. Повторюсь, в рамках заброшенного подхода я начал некоторую работу, используя symfony 1.3 и Doctrine в качестве ORM для его перестройки. У меня есть солидный опыт использования различных инструментов ORM (adodb, pdo, doctrine, propel), и казалось, что я создаю новый вид сложности, идя по нормализованному реляционному маршруту. Я знаю, что СУБД может работать, но поскольку базы данных документов для меня немного новы, мне любопытно, звучит ли мой вариант использования разумно.
3. Я возвращаюсь к этому спустя долгое время и, имея больше опыта в этой ситуации, вижу, что @Blaackmoon прав, что это не имеет отношения к механизму базы данных.