SQL vs NOSQL?

Когда управление программой требут многолетнего обучения- что угодно будет лучше.
А NoSQL прекрасно ложится на оо модель БД которая все популярнее с каждым годом.

Когда управление программой требут многолетнего обучения- что угодно будет лучше.

Влажные мечты дефективного менеджера о разработчиках-таджиках за мешок картошки?

Влажные мечты дефективного менеджера о разработчиках-таджиках за мешок картошки?

Это что за норкоманские бредни?

Или это попоболь Оракловского ДБ одмина так похожа на плач норкомана?

Никуда они не ложаться, потому как даже выйти на должный уровень уже лет 30 как не могут из-за очевидных ограничений.

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

Насчет музея - ничем необосновано. А вот то, что NoSQL невозможно использовать в большинстве задач, как показала реальная практика -факт. И «мышление» тут не играет роли. Скорее суть в технической расторопности отдельных специалистов, которые увидев что-то новое и блестящее, не разобравшись в реальных возможностях технологии, бросаются рассуждать на тему «структуры мышления», крутости новых технологий и прочей ерунды. Ну не может трактор быть самолетом, если его самолетом не сделать. Как не крути.

Насчет музея - ничем необосновано.

Произведение искуства должно храниться в музее.

Но практика показывает, что РСУБД не просто произведение иссуства, но настоящая рабочая технология, оправдавшая себя десятилетиями и доказавшая свою полную состоятельность в различных задачах, в отличие от той же NoSQL. Хотя применимость и полезность последней в узком круге вопросов я не умаляю. Так что у каждого решения своя ниша, и большую часть ниш в данном секторе, заслуженно занимают РСУБД, несмотря на то, что разработаны две эти различные технологии были примерно в одно время.

Никуда они не ложаться,

Вы их укладывать не умеете.
Возьмём как пример ZODB поверх MySQL наблюдаемые мной в данный момент.
ZODB хранит в MySQL пары ключ-значение и оперирует обектами на более высоком уровне.
Ну и нахрена здесь SQL?
Поставили-бы любой NoSQL - и работало-бы быстрее и пролем с администрированием было-бы меньше.

потому как даже выйти на должный уровень уже лет 30 как не могут из-за очевидных ограничений.

Общество развивается по спирали, выходя на новый уровень на каждом витке.
Или вы не видите разницы между нереляционными БД 30 летней давности и сегодняшними NoSQL?

РСУБД не просто произведение иссуства, но настоящая рабочая технология, оправдавшая себя десятилетиями и доказавшая свою полную состоятельность в различных задачах, в отличие от той же NoSQL.

Вы цитируете Cobol-программистов когда они смеялись над номодной технологией ООП

РСУБД пространства для маневра несколько больше, в связи с большей степенью возможности работать со сложными структурами. NoSQL тут уступает)))

База данных должна хранить данные а не маневрировать.
Быть простой, быстрой и надёжной.

Современные реляционные БД совсем не простые изза чего возник класс паразитирующих на ней организмов именуемых ДБ одмины.

Да не решают эти прокладки вопросов сложных структур. А если городить для них огород их прокладок NoSQL ничего хорошего в плане производительности и глючности вы не получите. Не умеют нереляционки работыть со сложными структурами данных так, как это делают РСУБД.

PS: За 30 лет РСУБД тоже на месте как бы не стояли.

Не факт что СУБД(не просто база как вы выразились) не должны маневрировать. С чего вы взяли? Напротив-издержки производительности при использовании маневра в СУБД, а не неповоротливом приложении гораздо более оправданы. Для того собственно СУБД и создавались. Так что ах)))

Да не решают эти прокладки вопросов сложных структур.

ZODB вполне себе решает возложенные на неё задачи манипуляции сложными структурами в ОО мире и только реляционные БД до сих пор манипурируют простымии данными и не желают ничего знать о ООП мире выросшем за последние 30 лет в IT

Для того собственно СУБД и создавались. Так что ах)))

Я что-то против СУБД высказал?
Может быть процитируете?
Или просто так пишете?

Для СУБД как нет никакой необходимости манипулировать ООП в сложноструктурных задачах. Потому как издержки на использование ООП будут на порядок выше издержек использования реляционных моделей в сложных схемах хранения и управления данными.

Где вы что увидели про то, что я вас где-то как-то «уличаю» в высказываниях против СУБД?

А что значит аханье?

Для СУБД как нет никакой необходимости манипулировать ООП в сложноструктурных задачах.

Это вы так считаете.
Между тем ОО в ДБ становится всё популярнее

Потому как издержки на использование ООП будут на порядок выше издержек использования реляционных моделей в сложных схемах хранения и управления данными.

Интересно, почему?

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

ну да, mongodb is webscale...

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

Это потому что вы смотрите с точки зрения БД.
Сечас практически все проекты построены на ОО обёртках для реляционных БД.
Поинтересуйтесь как нибудь - Hibernate, RoR, Zope, Entity Framework и многие другие построены на скрытии БД от приложения и вполне успешно с этим справляются.

Да не «практически все», а процентов так 10-15 проектов, не более))) В остальных случаях это не так.

Да не «практически все», а процентов так 10-15 проектов, не более))) В остальных случаях это не так.

Могу примести цитату из рекомедаций по разработке у текущего заказчика, где так и написано - Hibernate/NHibernate.

Российская действительность возможно отличается от североамериканской, но я просто не верю что настолько.

Да, я писал о энтерпарайзе.
В ИТ отделах из полодмина может быть всё что угодно.

В Энтерпрайзе по статистике РСУБД в 90% проектах. В финансовой и банковской сфере-и того более -99% В WEB-почти 100% (ну есть исключения и правил, но как ранее было сказано, это неспецифичные задачи, ди и то в отдельных случаях). Что касаемо какого-то одного заказчика-это малоинтересно. Так что статистика говорит сама за себя.

И как это относится к моему сообщению?

По реляционным СУБД есть книги (в том числе учебники, которые не устарели за 10 лет), есть теория, есть практика. По NoSQL - только практика, т.е. учиться можно только на своих ошибках. Для меня лично это showstopper.