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