Технологии — это постоянно развивающийся котел, полный появляющихся чудес. С таким количеством языков, фреймворков и систем трудно выбрать лучший. Таким образом, использование определенного программного обеспечения или API часто обусловлено скорее «крутым» фактором, чем реальной оценкой вариантов наилучшего решения. Часто одно-два слова технического гуру стоят больше, чем реальный полевой опыт. Глядя на базы данных, нет никаких исключений из правила: добро пожаловать в битву NoSQL против OldSQL.
Когда базы данных NoSQL стали популярными, многие люди ухватились за них, потому что это была современная технология. Представьте, что вы стартап, готовый представить свою идею инвестору с глубокими кошельками. Хотели бы вы, чтобы они увидели, как вы носите RDMBS на публике? Конечно нет, вы скоро станете новым Facebook, а не старым корпоративным динозавром.
Заправь свое оружие!
Если и есть что-то, что любят разработчики программного обеспечения, так это настоящая технологическая война. Следовательно (и в данном случае), разработчикам пришлось выбирать сторону в этой могучей битве. Многие дебаты начались о функциях (или их отсутствии), таких как согласованность данных, транзакции и бессхемность. Излишне говорить, что теперь вы можете найти множество аргументов в пользу того, почему одно решение лучше другого.
Даже сегодня, если поспрашивать окружающих, можно услышать, как люди говорят: «О, NoSQL? Да, да, вы можете хранить «Кошек» и «Машины» в одной таблице, но как насчет «консистентности в конечном итоге»?» или «Я никак не мог разработать эту штуку с РСУБД. Кого волнуют транзакции?».
Но что подпитывало все эти споры? Основная причина заключалась в фундаментальной ошибке попытки найти универсальное решение.
А что, если…?
Но почему это должно быть именно так? Вы носите пальто круглый год, потому что оно согревает вас зимой, а летом вам просто нужно немного попотеть? Вы используете молоток только для гвоздей и шурупов, потому что «вверните это, в конце концов, результат будет одинаковым»?
Нет, это не так. Вы ищете конкретные решения, инструменты, способные выполнить конкретную работу, технологии, которые могут помочь вам решить ваши проблемы наилучшим образом. Вы держите все свои аппараты в своем ящике с инструментами, каждый для лучшей работы.
Теперь, если вы ненадолго вернетесь назад и примените эту точку зрения к спору о NoSQL и OldSQL, возможно, вы измените свое мнение. Новая технология не обязательно заменяет другую, и они могут даже работать вместе. Это то, что часто называют «настойчивостью полиглота».
Если вам нужна мощная транзакционная система (поскольку эта логика слишком сложна или дорога для реализации в вашем приложении): придерживайтесь СУБД, которая может гарантировать ограничения ACID. В то же время вам нужно кэшировать часть ваших данных, потому что большая часть трафика указывает на одни и те же ресурсы? Что ж, вы можете использовать хранилище Key Value «в памяти».
Вы являетесь архитектором своего программного обеспечения, и вы должны найти наилучшее сочетание инструментов для решения проблемы. Разработка программного обеспечения будет продолжать развиваться, вам следует приложить столько же усилий к выбору базы данных для вашего проекта, сколько вы вкладываете в архитектуру остальной части вашего приложения.
Здесь, в Mobile Jazz, мы всегда используем наиболее подходящие и эффективные инструменты для развития ваших идей и превращения их в потрясающие продукты. Мы стремимся быть в курсе того, что происходит в сфере технологий, цифрового маркетинга и дизайна. Мы всегда учимся и экспериментируем с последними тенденциями, чтобы оставаться впереди всех. Вот почему мы можем дать вам конкурентное преимущество на рынке. Не стесняйтесь, напишите нам, и мы сделаем ваш проект на шаг впереди!
Если вам понравился этот пост, посетите наш блог, чтобы узнать больше.
