Comments 23
Последние приобрели большую популярность в силу создания программных продуктов, использующих реляционную модель вместе с языком SQL запросов.
Но другие модели также использовались с меньшей популярностью в обычной пользовательской среде.
В настоящее время развитость информационных технологий, расширение областей применения этих технологий и возросший массовый уровень профессионализма специалистов по информационным технологиям естественно расширили области применения всех моделей данных.
Поэтому, как и указано, решать надо по месту какую модель использовать.
Вот признаки проектов, для которых идеально подойдут SQL-базы:
БД должна выбираться не под проект, а под задачи. Так или иначе, в одном проекте могут использоваться как реляционные БД, так и так называемые NoSQL.
При выборе базы данных первый вопрос не что и как хранить, вы на него потом найдете ответ, а что вам надо с данными делать.
Если вам ничего с ними делать не надо, то и хранить их не надо. База данных не нужна.
Если вам надо посмотреть на них справа, потом сверху, потом посчитать вхождение «этого» в «то», средние, промежуточные итоги — то без SQL это очень затруднительно. Как минимум закончится изобретением миниSQL на коленке.
Если вам надо записать много данных, а потом их просто показать, целиком или кусками — то можно пробовать NoSQL. Но как только у вас появятся дополнительные требования к фильтрованию и связям — то вы постепенно начнете смотреть в сторону SQL — там уже есть ответы на многие ваши ещё не заданные вопросы.
Характерно, что сам вопрос о NoSQL встал на повестку дня когда память стала доступна гигабайтами и не надо заморачиваться быстродействием — положил базу в память и все.
Истина посредине. Для хранилища котиков подойдет NoSQL, т.к. зачастую записей будет больше, чем чтения. При этом взаимосвязи авторов котиков будут храниться в SQL, а сам SQL ещё разделится на горячие и холодные данные.
Кроме этого, NoSQL, как и другие не типизированные средства разработки, выполняет социальную функцию — легкий вход в программирование широких масс населения, оставляя вопросы типов и структур данных для тех, кто прошел идиотентест простых ответов на простейшие вопросы.
Иначе нельзя объяснить «преимущество» NoSQL — «отсутствие жесткой структуры данных». Это как же вы с данными работать будете если не знаете что там? По сути, под каждый кейс данных писать парсер и распознавать содержимое.
сам вопрос о NoSQL встал на повестку дня когда память стала доступна гигабайтами
Вы что-то путаете…
взаимосвязи авторов котиков будут храниться в SQL…
как же вы с данными работать будете если не знаете что там
по вашему, работа с NoSQL базой на уровне приложения это отправка и получение строки?
легкий вход в программирование широких масс населения
все-таки, основной поток это как раз те, кого перестали устраивать текущие решения
Иначе нельзя объяснить «преимущество» NoSQL — «отсутствие жесткой структуры данных». Это как же вы с данными работать будете если не знаете что там?
А зачем хранилищу данных работать с данными? Его дело их получать, хранить и отдавать. Для этого схема не нужна особо, разве что для оптимизаций.
www.youtube.com/watch?v=SzNr5LXvAv0
Там очень хорошо объясняется для чего и где используется SQL и NoSQL БД.
Вообще то под Durability в ACID обычно понимается «надежность».
Как минимум это дополнительные ресурсы (и финансовые, и человеческие), которые средней руки разработчик и оценить-то толком не может (кроме реплики разве что), не говоря о убедительной демонстрации преимуществ бизнесу, чтобы он согласился эти ресурсы тратить.
Мучаются, скорее всего, не из-за информированности (поищите, например, по Хабру OLAP). Либо, как вариант, из-за отсутствия нормальных FOSS инструментов для отчётов по данным из FOSS СУБД, прежде всего MySQL и PostgreSQL. Беглый гуглеж говорит только о теории, либо продуктах Microsoft и Oracle.
В ваших силах, кстати, повысить информированность, написав посто или серию о подобных инструментах :)
ИМХО при идентичных требованиях к данным масштабирование SQL и NOSQL может быть выполнено в равной мере( ограничением станут только блокировки, с ними тоже можно работать, но это значительно повышает требования к квалификации ). Если мы можем расшарить данные по нескольким узлам, мы можем это сделать и там и там. Просто в NOSQL в силу парадигмы данные низкосвязные, а использование SQL как правило приводит к высокой связности данных, но это лишь практика использования не более того( если не считать требования нормализации непреложным законом вселенной ).
Никто не мешает развязать данные и в SQL, но при этом многие плюшки SQL станут вам недоступны( которых собственно говоря в NOSQL просто нет ).
Даже в монге есть агрегированные запросы, на которых можно такого намутить, что плакать хочется.
Некоторые NoSQL базы позволяют исполнять на стороне СУБД полноценные функции на ЯП общего назначения типа JavaScript или Erlang, выдавая в приложение ровно то, что ему нужно без дополнительных агрегаций, соединений и т. п.
О выборе SQL-баз данныхНу в некоторых NoSQL тоже есть и транзакции и структра и джойны с псевдо-SQL, и где тут преимущество у SQL базы? Или называть такие БД как реляционная NoSQL? А вот например в OrientDB есть ссылки, данные могут ссылаться друг на друга, это как раз то что «доктор прописал» для построения реляций, а в SQL БД этого нет. Т.е. OrientDB более реляционен?
Пора уже выбирать базы по фичам, а не делить на 2 лагеря. Да и вообще, хранить таблицами не эффективно для 80% случаев в которых используется SQL субд.
А про индексы, как уже отметили выше, автор бред написал.
SQL или NoSQL — вот в чём вопрос