Здравствуйте, Sinclair, Вы писали:

S>Ну вот на мой взгляд, подвох NoSQL как раз в том, что его кривая квалификации имеет некоторый провал.
S>То есть чтобы нахипстерить на нём "лендинг паге" нужно в 2-3 раза меньше времени, чем с использованием традиционных SQL. Новичку — вообще может в 10 раз меньше потребоваться, особенно если он изучал только курсы по вёрстке и ангуляру.

И ты где-то наблюдал в достаточном кол-ве у новичков NoSQL?
Там же в основном SQLite или MySQL.

Я наблюдал NoSQL уже явно в неординарных сценариях.


S>И профессионалам допилить NoSQL до амазоновских эпических масштабов тоже существенно дешевле, чем RDBMS.

Так он изначально под такие сценарии и проектировался — для произвольного горизонтального масштабирования простой выборки или для произвольного повышения доступности.


S>А вот в середине этого спектра, где у нас и разработчик имеет хоть какую-то квалификацию, и нагрузка на проект уже выше демо-уровня, но ни мега-гуру ни миллиардов прибыльных транзакций в секунду нет, RDBMS уделывают NoSQL.
S>Потому что в них как раз вложены огромные усилия — в то, чтобы заставить относительно неплохо крутиться схему, спроектированную по учебнику.

С этим никто не спорил.


S>А NoSQL в этом случае отходит в сторонку: "сам написал — сам и трахайся".

NoSQL это вообще просто "кирпичик" дизайна — самодостаточное изолированное хранилище или набор их (грубо таблица или набор несвязанных таблиц).
RDBMS — это согласованный набор хранилищ/таблиц.

Убери такое согласование м/у таблицами в RDBMS, например, убери внешний ключ для целей повышения эффективности, и вот ты уже двигаешься в сторону NoSQL. ))
Я тебе уже описывал некоторые трюки, которые пришлось проворачивать, чтобы РСУБД быстрее пахала.
С разменом на всё больший контроль не ср-вами базы, а внешней обвязкой.
В пределе такие трюки и дают NoSQL.