Я пишу это, но как спор к ответу Рекса.
Я оспариваю идею о том, что nosql не имеет отношения и является нечетким.
Я работал с CODASYL много лет назад с C и Cobol - отношения между сущностями в CODASYL очень тесные.
Напротив, системы реляционных баз данных имеют очень либеральную политику в отношении отношений. Пока вы можете идентифицировать внешний ключ, вы можете сформировать отношения adhoc.
Часто считается само собой разумеющимся, что SQL является синонимом СУБД, но люди пишут драйверы SQL для CODASYL, XML, инвертированных наборов и т. Д.
СУБД / SQL не равны точности данных или отношений. Фактически, СУБД является постоянной причиной неточности и неправильного восприятия отношений. Я не понимаю, как СУБД предлагают лучшую целостность данных и отношений, чем, например, hadoop. Поставьте слой JDO - и мы сможем построить сеть хороших и чистых отношений между сущностями в hadoop.
Однако мне нравится работать с SQL, потому что он дает мне возможность писать сценарии adhoc, хотя я понимаю, что adhoc отношения являются постоянной причиной фальсификации отношений и проблем.
Имея возможность работать со статистическим анализом бизнес-процессов и процессов, SQL дал мне возможность исследовать отношения, в которых ранее не было никаких связей. Возможность работы со статистическим анализом дала мне понимание того, что обычно не приходит на ум программистам SQL.
Например, вы должны разработать и нормализовать вашу схему, чтобы отразить набор процессов. То, что вы можете не осознавать, это то, что отношения со временем меняются. Статистические характеристики показали бы, что схема больше не может быть «должным образом нормализована», как это было раньше. Что основные компоненты процессов мутировали со временем. Но нестатистические программисты не понимают этого и продолжают рекламировать RDBMS как идеальное решение для обеспечения целостности данных и точности взаимосвязей.
Однако в базе данных, связывающей отношения, вы можете связывать сущности в отношениях по мере их появления. Когда отношения изменяются, связь естественно мутирует с данными. Отношения и их мутация документируются в системе базы данных без дорогостоящей необходимости перенормировки схемы. В этот момент RDBMS хороша только как временная база данных.
Но тогда вы можете возразить, что СУБД также позволяет гибко изменять ваши отношения, поскольку именно в этом SQL работает лучше всего. Правда, очень верно - пока вы выполняете BCNF или даже 4NF. В противном случае вы начнете видеть, что ваши запросы и загрузчики данных выполняют реплицированные операции. Но затем, благодаря многолетнему опыту работы с RDBMS, вы, по крайней мере, поняли, что BCNF очень дорогой и неэффективный в работе, и что мы постоянно виновны в 2,5 NFing в наших схемах.
Сказать, что СУБД и SQL поддерживают целостность данных и отношений, является грубым заблуждением. Либо вы работаете в такой маленькой компании, либо не оставались на своих должностях более двух лет - вы не увидите объем данных или информационную мутацию, а также проблемы, вызванные СУБД. Злоупотребление СУБД является причиной того, что руководители ограничивают представление компьютерных приложений, и причиной финансовых неудач компаний, которые не видят изменений в поведении рынка, потому что их взгляды были ограничены программистами, чьи взгляды были ограничены их почитанием своих любимых. Схемы СУБД.
Вот почему программисты SQL не понимают, почему статистика вашей компании отказывается использовать ваше приложение, которое вы тщательно разработали, но они наняли стажера колледжа для написания SQL-кода для загрузки данных на свои личные серверы, и руководители вашей компании учатся доверять бухгалтерамэлектронные таблицы «статистиков», а не ваши элегантные многоуровневые приложения из-за неспособности ваших приложений мутировать с процессами.
Это может быть невозможно, но я все же призываю вас приобрести некоторое статистическое понимание, чтобы понять, как процессымутируйте с течением времени, чтобы вы могли принять правильное технологическое решение.
Причина, по которой люди не переходят на использование SQL-запросов, заключается в отсутствии хорошей среды сценариев, такой как SQL, для выполнения анализа отношений adhoc.Не потому, что технологии без SQL недостаточно точны или целостны.Анализ отношений adhoc очень важен в наше время из-за быстрых и гибких подходов и стратегий разработки приложений, которые мы имеем в настоящее время.