Здесь рассмотрен подход, который может облегчить начало работ над интернет-проектом, требования к которому может и определены, но некоторые, возможно существенные, детали нераскрыты. Считаю, что в целом все стартапы и проекты по началу редко когда могут быть описаны достаточно полно, чтобы было возможно построить требуемую архитектуру БД и грамотный код. На начальном этапе проектирование структуры БД, основанное на идее использования NoSQL-подобного подхода как черновика для проекта экономит силы и средства в условиях постоянно меняющихся требований. Данный подход позволяет получить быстрый результат и построить всю логическую схему проекта. Этот подход дает выигрыш в скорости и упрощает дело на самом бурном начальном этапе, если нам придется перекраивать архитектуру довольно часто и глубоко. При этом переход к классической, более-менее нормализованной базе достаточно безболезненный.
Предположим, что имеется некоторая достаточно сырая идея, на основе которой нужно построить некоторый интернет-продукт. С чего можно начать? Или если идея сырая, то вовсе ничего не следует делать в плане реализации? Однако это не всегда возможно. Вернее, для разработчика сложно понять являются ли текущие требования окончательными или завтра все поменяется самым существенным образом. И мы пребывая в твердой убежденности, что рамки определились, приступаем к работе. Если все идет хорошо, результат будет хороший и код проекта будет достаточно красив (с точность до навыков программиста). Однако не всегда все идет хорошо. И тогда, в общем случае, проект двигается так:
И далее цикл повторяется с пункта 2. Думаю, что здесь слишком много дел и притом довольно кропотливых. Исходя из того, что я видел, оглядываясь на себя и изучая опыт коллег по цеху, видно, что в какой-то момент разработчик устает и дальнейшее перепроектирование системы приводит к неоптимальным решениям.
С одной стороны, отсутствие внятной (для программиста) картины процесса это плохо и казалось бы в такой ситуации не приходится ждать хороших результатов. С другой — это вполне жизненная ситуация, которая может быть объяснена не только особенностями заказчика, но и объективными причинами. Действительно, имея на руках хоть в какой-то степени готовый и живой продукт, где реализована логика и построены взаимосвязи сразу же всплывают те вопросы, которые не были и не могли быть продуманы заранее.
Для себя я нашел отличный выход, который позволяет минимизировать трудозатраты на этапе, пока нам не достаточно известны некоторые ключевые для реализации подробности. А они могут быть выяснены только после получения некоторой рабочей модели. Суть подхода состоит в том, что все информационные сущности мы храним в отдельных таблицах, но без разделения полей. В виде JSON массива. Это позволяет хранить объекты сколь угодно большой сложности.
Такой подход позволяет не трогать БД при изменении/добавлении полей и не тратить время на изменение и отладку запросов в новых условиях.Нам остается только изменение в чистой логике и проверки. В дальнейшем, при переходе от хранения JSON-запакованных данных к нормализованной структуре нам потребуется изменять практически только запросы, а логика и проверки остаются без изменений.
Зачем вообще может потребоваться переходить от NoSQL типа хранения к обычным таблицам? Для меня этот вопрос разрешается легко: пока я не могу назвать себя специалистом по MongoDB или чему-то подобному, для коммерческой разработки лучше пользоваться проверенными инструментами. Хотя, если иметь возможность выбора и если у нас в проекте отсутствует штат аналитиков (которые пишут SELECT * к нашей базе) а нашей базой не будут пользоваться сторонние сервисы, то можно все хранение вообще перевести на NoSQL-рельсы.
Итак, проектируя для начала всю структуру в стиле JSON-строк мы экономим время на отладке и значительно раньше можем получить некоторый законченный результат, имея который будут решены все необходимые вопросы для построения в достаточной степени законченной и разумной архитектуры.
Вот что имею сказать.
Предположим, что имеется некоторая достаточно сырая идея, на основе которой нужно построить некоторый интернет-продукт. С чего можно начать? Или если идея сырая, то вовсе ничего не следует делать в плане реализации? Однако это не всегда возможно. Вернее, для разработчика сложно понять являются ли текущие требования окончательными или завтра все поменяется самым существенным образом. И мы пребывая в твердой убежденности, что рамки определились, приступаем к работе. Если все идет хорошо, результат будет хороший и код проекта будет достаточно красив (с точность до навыков программиста). Однако не всегда все идет хорошо. И тогда, в общем случае, проект двигается так:
- На основе идеи спроектирована база — как потом окажется в первом приближении. Для каждой информационной сущности отдельная таблица. Для каждой характеристики отдельное поле.
- Построена некоторая часть проекта на основе полученной базы. Реализована логика, натянута верстка.
- Консультация с заказчиком (или «внутренним заказчиком»). Тут-то выясняется, что надо все менять. Так как сведения, которые у нас были два дня назад устарели, выяснились особенности о которых мы и не подозревали. Такая ситуация очень нередка, т.к. мало кто дает себе труд построить полную схему процесса.
- Изменить некоторую часть схемы БД — в простейшем случае надо будет добавить/удалить поля. Следом за этим, изменить все SQL-запросы. И третий необходимый шаг в этом случае — тестирование в новых условиях.
И далее цикл повторяется с пункта 2. Думаю, что здесь слишком много дел и притом довольно кропотливых. Исходя из того, что я видел, оглядываясь на себя и изучая опыт коллег по цеху, видно, что в какой-то момент разработчик устает и дальнейшее перепроектирование системы приводит к неоптимальным решениям.
С одной стороны, отсутствие внятной (для программиста) картины процесса это плохо и казалось бы в такой ситуации не приходится ждать хороших результатов. С другой — это вполне жизненная ситуация, которая может быть объяснена не только особенностями заказчика, но и объективными причинами. Действительно, имея на руках хоть в какой-то степени готовый и живой продукт, где реализована логика и построены взаимосвязи сразу же всплывают те вопросы, которые не были и не могли быть продуманы заранее.
Для себя я нашел отличный выход, который позволяет минимизировать трудозатраты на этапе, пока нам не достаточно известны некоторые ключевые для реализации подробности. А они могут быть выяснены только после получения некоторой рабочей модели. Суть подхода состоит в том, что все информационные сущности мы храним в отдельных таблицах, но без разделения полей. В виде JSON массива. Это позволяет хранить объекты сколь угодно большой сложности.
Такой подход позволяет не трогать БД при изменении/добавлении полей и не тратить время на изменение и отладку запросов в новых условиях.Нам остается только изменение в чистой логике и проверки. В дальнейшем, при переходе от хранения JSON-запакованных данных к нормализованной структуре нам потребуется изменять практически только запросы, а логика и проверки остаются без изменений.
Зачем вообще может потребоваться переходить от NoSQL типа хранения к обычным таблицам? Для меня этот вопрос разрешается легко: пока я не могу назвать себя специалистом по MongoDB или чему-то подобному, для коммерческой разработки лучше пользоваться проверенными инструментами. Хотя, если иметь возможность выбора и если у нас в проекте отсутствует штат аналитиков (которые пишут SELECT * к нашей базе) а нашей базой не будут пользоваться сторонние сервисы, то можно все хранение вообще перевести на NoSQL-рельсы.
Итак, проектируя для начала всю структуру в стиле JSON-строк мы экономим время на отладке и значительно раньше можем получить некоторый законченный результат, имея который будут решены все необходимые вопросы для построения в достаточной степени законченной и разумной архитектуры.
Вот что имею сказать.
