Почему вы никогда не должны говорить «никогда»

Привел я их исключительно чтобы вы понимали, что прогресс РСУБД не остановился во времена когда Кодд придумал реляционную алгебру.

Буду считать, что Вы шутите. Во второй раз.

Давайте я Вам объясню. Тут никто не спорит с Вами о том, что SQL хорошо и реляционные базы — лучше.

Мы тут говорим, что и другие подходы имеют место быть. По задаче.
Как пример — топик посвящен МонгоДБ, «документной» базе, которую я никогда не использовал и, надеюсь, не скоро буду (дело не в ней, кстати — надеюсь, просто, что такие простые задачи, для которых она эффективна отвлекать, пока, не будут). Но кто-то — будет. И в Вашем переводе — не говорится о том, что Монго плохая сама по себе, это только в мультфильмах бывают персонажы с титулом «мистер Зло» (умные, но идиоты, обычно). Речь о том, что нужно думать и выбирать не по «вере», а по ограничениям.
Надеюсь Вы понимаете, что никто реляционные базы данных у Вас (и у нас) отбирать не пытается. Пусть расцветут, как говорил…

Ну так вернемся. Вот у Монго для некоторых задач есть преимущество, по сравнению с Оракл 12С, например. А тех, кто будет говорить, что она подходит для всего и ответит за все — гоните.

Какие преимущества? Поставить по инструкции не сложно. Настраивать не нужно. Лишних хитростей нет. Простому сайту — простая база. Ведь замечательно! Возможно вы сможете меня убедить, что для современного «социального блога» нужна RDBMS, по лицензии на ядро… Но зачем?

Я не вижу объективных оснований применять знания теории графов и алгоритмы на графах в текущей задаче.

Вы про что, кстати? Про задачу Коммивояжера? Или про фракталы?
Или, все-таки, про способ выражения отношения множеств через графы?
Про индексы и btree, про которые Вы, оказывается, пытались мне объяснять (!) (спасибо!).
Не понимаю.
Я так понимаю статистические базы данных должны применять в своей работе исключительно статистику, а геоинформационные — геоинформацию?

Я знаю, звучит бредово. Мы же тут про «графовые базы».

Но давайте будем конкретными. Вот у OrientDB — одно отношение к «graph database», у Фейсбука другое, у Гугла третье. Почитайте, врага надо знать в лицо. Кстати, если прочитав про Фейсбук вы вскрикнете «ага, в MySQL же персистентность» — лучше Вам мое лицо не видеть.

Кстати, почитайте, почему в IBM так долго тянули с публикацией DB2, и если Вы специалист, вспомните, что тот же DB2 оказалась фактически первой _приемлимой_ современной «object relational» БД.

И не забывайте, что мы говорим о конкретной задаче — фотографии в альбоме.

Да. Я надеюсь уже понятно, что пинать «графовые базы», это как пытаться проткнуть туман.
Поэтому давайте про конкретное, снова.
Почему для больших и богатых «графовый» подход пригодился мы там наверху почитали.
Теперь, если мы говорим про тот же ОриентДБ — вот вам приблизительное описание задачи:

Мы делаем сервис хранения фотографий для жителей небольшой страны с населением в 6 миллионов. Самые частые обращения — пользователя на запись — к своим альбомам, в которых лежат свои фотографии. Иногда пользователь может «отправить» фотографию другу или родственнику и тогда она тоже будет «лежать» у него в альбоме. Страна, хоть и редконаселенная, но по размерам почти соответствует Германии, Австрии и Венгрии вместе взятым. Связь между населенными пунктами не самая быстрая, каналы загружены, интернет популярен исключительно мобильный.

Альбомы у нас хитрые — вкладываются друг в друга. Ну как папки «виндовса». Почему? Потому что пользователю так удобно. Сортировать. Понятно, что структура папок и глубина вложенности у каждого своя. Фотки у нас электронные, так что написать им на обратной стороне разные данные — не проблема. Какие? А какие попросит. Мы ему даже подскажем, семантика у нас — ого-го. И растет по запросам и классам доменов (даты; возраст ребенка, в годах; стоимость блюда на фото или, даже, расстояние в метрах от дома).

Люди в этой стране устроены так, что живут, в основном, большими семьями. Три колена в соседних домах одной деревни. Фоток у них много, особенно со свадеб. Ну и машины свои любят, очень.
Еще, как следствие — плевать им на селфи хаброводов и неизвестных виртуальных друзей, но родственник для них — это не только мама с папой, но еще и восемнадцать троюродных дядь, у каждого из которых не меньше трех сыновей и дочерей столько, сколько нужно, чтобы три сына накопилось (но минимум три девочки, иначе кто за сопляками присматривать будет?). Понятное дело, что в первую очередь они хотят видеть 400 фоток очередной свадьбы каждого ближайшего родственника в обратной пропорциональности к степени убывания родства, а во вторую — прямопропорционально «весу» родственника в обществе.

Сервис, кстати, используется не просто так, как Вы понимаете, а многофункционально. Запросы типа покажи мне все фото детей дочерей брата бабушки по маме — достаточно частые и формироваться могут произвольно, практически на человеческом языке (язык в той стране, благо, подходящий).

И это, конечно, не все условия. Заказ нам пришел государственный, от министерства Морали и благополучия. Денег у министерства мало, но в первый год, первый сервер (железный) руководство купить готово. Программу тоже, но только вместе с «железкой», иначе что завхоз на баланс не примет. Что такое Оракл они не знают (некоторые, работники, которые социальными плакатами занимаются — думают, что это бумага такая самоклеящаяся, «оракал» называется). Объяснить им, что этот Оракл стоить будет как тот компьютер — нет никакого желания. Потому что, самое для нас с вами невероятное, и специалистов — помощников Пророку в той стране нет, ни дорогих, ни, тем более, дешевых. Зато у министерства есть мальчик, толковый, с хорошими способностями к шахматам (у этой игры тут статус национальной) и быстрой памятью на стандартные комбинации.

Да, и еще — если все получится — министерство готово на следующий год заложить в бюджет покупку других серверов. По одному в каждую из восьми областей (ну или два в столицу, а за три года и остальным, по остаточным фондам). Связь-то между регионами слабовата (география такая).


Знаю, Вы ждали от меня Теорий, мне они _тут_ не интересны, лучше порыться в SIGMOD имени Кодда, пожалуй. Зато ТЗ можете расписать по этому брифу сами.

Но суть проста. На выбор решения влияет не только Ваше объективное мнение, но и чужие, непрактичные ограничения. А иногда и простое желание двигать что-нибудь дальше.