В заметке рассмотрен подход к реализации некоего абстрактного проекта, требования к которому определены, но некоторые, быть может существенные детали нераскрыты. Считаю, что в целом все стартапы и проекты в начале не могут быть описаны достаточно полно, чтобы было возможно построить требуемую архитектуру БД и грамотный код. Идея использования NoSQL—подобного подхода как черновика для проекта экономит силы и средства в условиях постоянно меняющихся требований. Данный подход позволяет получить быстрый результат и построить всю логическую схему проекта. Переход от NoSQl—стиля хранения данных к классической, более-менее нормализованной базе достаточно безболезненный.

Предположим, что имеется некоторая достаточно сырая идея, на основе которой нужно построить некоторый интернет-продукт. С чего можно начать? Года два-три назад, я бы действовал по следующей схеме:

1. На основе идеи спроектировать базу впервом приближении. Для каждой информационной сущности отдельная таблица. Для каждой характеристики отдельное поле.
2. Построить некоторую часть проекта на основе полученной базы. Реализовать логику, отрисовать.
3. Проконсультироваться с заказчиком (или «внутренним заказчиком») и выяснить что надо все менять. Так как сведения, которые у нас были два дня назад устарели, выяснились особенности о которых мы и не подозревали. Такая ситуация очень нередка, т.к. мало кто дает себе труд построить полную схему процесса.
4. Изменить некоторую часть схемы БД — в простейшем случае надо будет добавить/удалить поля. Следом за этим, изменить все SQL
   запросы. И третий необходимый шаг в этом случае — тестирование в новых условиях.

И далее цикл повторяется с пункта b. При этом, оглядываясь на предыдущий опыт и изучая опыт коллег по цеху, видно, что в какой-то момент разработчик устает и дальнейшее перепроектирование системы приводит к неоптимальным решениям.

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

Для себя я нашел оптимальный подход, который позволяет минимизировать трудозатраты на этапе, пока нам не достаточно известны некоторые ключевые для реализации подробности. А они могут быть выяснены только после получения некоторой рабочей модели. Суть подхода состоит в том, что все информационные сущности мы храним в отдельных таблицах, но без разделения полей. В виде JSON массива. Это позволяет хранить объекты сколь угодно большой сложности.

Такой подход позволяет не трогать БД при изменении/добавлении полей и не тратить время на изменение и отладку запросов в новых условиях.Нам остается только изменение в чистой логике и проверки. В дальнейшем, при переходе от хранения JSON—запакованных данных к нормализованной структуре нам потребуется изменять практически только запросы, а логика и проверки остаются без изменений.

Зачем вообще может потребоваться переходить от NoSQL типа хранения к обычным таблицам? Для меня этот вопрос разрешается легко: пока я не могу назвать себя специалистом по MongoDB или чему-то подобному, для коммерческой разработки лучше пользоваться проверенными инструментами. Хотя, если иметь возможность выбора и если у нас в проекте отсутствует штат аналитиков (которые пишут SELECT * к нашей базе) а нашей базой не будут пользоваться сторонние сервисы, то можно все хранение вообще перевести на NoSQL-рельсы.

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

Вот что имею сказать.
Опубликовано также на хабре.