Экономическая эффективность ООП

Это уже обычная практика, когда бизнес-логика приложения пишется на объектно-ориентированном языке (например, Java, C++), а все что связано с хранением в базе данных — на необъектном SQL.

К чему это приводит, с точки зрения денег? Прежде всего, очевидно, что программист «со знанием Java+SQL» обойдется дороже, чем программист просто «со знанием Java». Выделять отдельных программистов Java и SQL — во первых, раздувать штаты, а во вторых иметь проблемы с координацией их совместной работы.

Для координации может понадобиться начальник, но это решение влечет за собой также рост расходов на зарплату. Вдобавок, начальник также должен быть «со знанием Java+SQL» (т.е. недешевым быть), вот почему так дороги ERP...

Итак, напрашивается вывод — чтобы сэкономить на зарплате программистов нужно избегать гремучей смеси «ООП+SQL». Этим и объясняется бурный рост числа проектов по «объектно-реляционному отображению». Мнения разделились. Один подход в том , что нужно развивать объектные свойства СУБД, например, хранить объекты в базе. Другие же считают, что необходимо все переводить в один, объектный мир. Язык ООП должен позволять в рамках одной концепции сохранять объекты, да так, чтобы программист и не забивал себе голову файлами, базами и т.д.

Но почему именно ООП, а не SQL?

А вот это и будет изложено в последующих публикациях.