История изменений

Если я захочу создать международную корпорацию и поработить человечество, мне SAP или Odoo поможет плотить нологи и зарплаты в каждой стране индивидуально без найма армии бухгалтеров и юристов?

Если ты создашь международную корпорацию, то армия бухгалетров и юристов будет меньшей из твоих проблем. Особенно если ты используешь SAP, готовые расчеты налогов в которой тебе обойдутся намного дороже, чем собственная разработка.

Или сложные структуры данных и сложные внутренние схемы это последствия индусни и прочего аутсорса?

Следствие бездумного следования мейнстриму. SQL и реляционные СУБД прежде всего, были созданы с единственной целью — создать язык, который бы давал возможность строить запросы к БД независимо от фактической формы хранения данных. Причем, этот язык не обязывал хранить данные в виде соотношений столбец или строк, но обязывал отвечать на запросы в такой форме. А форма это весьма и весьма куцая (ку́цый — с коротким, обрезанным хвостом), особенно в ее первозданном виде, которая без внешнего программирования не позволяла ничего сложнее простых агрегаций без порядка внутри группы и простых соединений таблиц. Из-за чего возникли расширения слияния таблиц от оракла, CTE для рекурсивных и иерархических запросов, и вообще отдельный язык MDX для многомерных запросов, которые совсем никак не влезают в реляционную модель, но крайне важны в аналитике.

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

Если я захочу создать международную корпорацию и поработить человечество, мне SAP или Odoo поможет плотить нологи и зарплаты в каждой стране индивидуально без найма армии бухгалтеров и юристов?

Если ты создашь международную корпорацию, то армия бухгалетров и юристов будет меньшей из твоих проблем. Особенно если ты используешь SAP, готовые расчеты налогов в которой тебе обойдутся намного дороже, чем собственная разработка.

Или сложные структуры данных и сложные внутренние схемы это последствия индусни и прочего аутсорса?

Следствие бездумного следования мейнстриму. SQL и реляционные СУБД прежде всего, были созданы с единственной целью — создать язык, который бы давал возможность строить запросы к БД независимо от фактической формы хранения данных. Причем, этот язык не обязывал хранить данные в виде соотношений столбец или строк, но обязывал отвечать на запросы в такой форме. А форма это весьма и весьма куцая (ку́цый — с коротким, обрезанным хвостом), особенно в ее первозданном виде, которая без внешнего программирования не позволяла ничего сложнее простых агрегаций без порядка внутри группы и простых соединений таблиц. Из-за чего возникли расширения слияния таблиц от оракла, CTE для рекурсивных и иерархических запросов, и вообще отдельный язык MDX для многомерных запросов, которые совсем никак не влезают в реляционную модель, но крайне важны в аналитике. В качестве совсем иного ответвления развития СУБД можно вспомнить NoSQL, которые, в свою очередь, призваны исправить тот факт, что SQL запросы в общем виде нельзя эффективно реализовать на распределенной системе.

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