Современные информационные технологии (ИТ) недоступны для повседневного использования каждым по своей надобности без обращения к специалистам и не обеспечивают интеграции данных в концепции общего информационного пространства. Однако, если кого это и огорчает, то явно не специалистов ИТ.
А не огорчает их потому, что знание средств и умение преодолевать существующие проблемы в ИТ является специфической сложностью профессиональной деятельности специалистов ИТ и обеспечивает ей высокий статус. К тому же наличие проблем создаёт широкое поле деятельности по разработке средств их преодоления, которые вливаются в объём необходимой компетенции, заставляя специалистов постоянно повышать свой уровень. Сейчас это наиболее востребованный аспект деятельности фирм предлагающих услуги ИТ.
Разных моделей ЭВМ (иногда секретных) было разработано много, и у каждой свой набор программных кодов. Поэтому озаботились разработкой единого языка высокого уровня. Сначала Фортрана, а потом более продвинутого Алгола. А потом ещё и ещё (сейчас их десятки, не считая "диалектов", и увеличивается) – всё более продвинутых, вплоть до языков объектно-ориентированного программирования (ООП), либо и вовсе функциональных.
А в языках ООП важно знать иерархию классов объектов, структуру, свойства и методы объектов – ибо даже одинаковые операторы языка могут работать с объектами по-разному. И вот, даже зная, что надо делать и зная язык – без изучения применяемых в каждой прикладной сфере объектов и специфических методов, вы ничего не сможете.
Тем более, что в разных сферах применения принято использовать разные языки. А для каждой задачи даже в одной отрасли разными разработчиками придумываются разные классы объектов, так что воспользоваться в одной задаче объектами другой, особенно если эти задачи разрабатывались в разных организациях, довольно сложно, ибо требует документированного согласования и может даже совместной разработки средств обмена данными.
Если сравнить программирование с вождением автомобиля, то раньше в любом городском районе можно было ездить на любом автомобиле и было везде понятно как рулить, но в разных автомобилях были разные рычаги и кнопки. А теперь в каждом квартале города свои дорожные правила, и в каждом районе надо пересаживаться на другой автомобиль.
Поэтому в области ИТ существует объективная тенденция к монополизации сфер информационной деятельности, где не последнюю роль играют языки, как например 1С, почти безраздельно занявший нишу бухгалтерии. Да и требование установки определённых платформ среды исполнения тоже привязывает к разработчику программного обеспечения (ПО). Если задача губернского или государственного уровня, то применяется и адмресурс, устраняющий независимых разработчиков, хотя сплошь и рядом ПО устанавливаемое "сверху" гораздо хуже.
Последовательность обработки всех данных задаётся в процессе исполнения главной ведущей программы. При появлении данных нового вида необходимо в ведущей программе обеспечить их создание, условия и способ их использования другими программами.
Даже в масштабах предприятия число классов (таблиц или структур, содержащих данные) бывает до тысяч. Вряд ли там найдутся специалисты, знающие, что, где и как во всех них хранится. Тем более, что на другом предприятии то же самое может быть организовано в других структурах.
В технологиях ООП часто легче добавить новую надстройку над объектами старых классов под новые особенности применения, чем разбираться в алгоритмах методов и структуре данных. И так неоднократно за время эксплуатации ПО. Со временем в базах данных (БД) накапливается "мусор" из забытых уже старых структур, который может быть подхвачен при выполнении запроса.
Конечно технологии развиваются. Разрабатываются системы модификации баз данных "на лету", протоколы обмена сообщениями, кроссплатформенные магистрали (шины) обмена данными и пр. И все эти средства ПО обновляются по несколько раз за год. В итоге всё больше сил и средств затрачивается только для поддержания систем в работоспособном состоянии, которые становятся всё более монопольными и всё менее обозримыми.
По мере прогресса и расширения цифровых технологий все эти проблемы только усугубляются. Вплоть даже до того, что оригинальные исходные коды оказываются погребены под напластованием модернизаций, из-за чего ревизовать и очистить программы от ошибок уже невозможно, ибо слишком дорого.
Вот, в частности и об этом, мнение профессионала:
«Не нужно быть гением, чтобы писать быстрые программы. Здесь нет какой-то магии. Единственное, что требуется, — это не строить софт на базе огромной кучи дерьма, которую поставляют современные инструменты». См. ссылку "Разочарование в софте".
Мы явно перешли порог, когда выигрыш от очередного развития ИТ меньше, чем затраты на это самое развитие.
Решить вышеназванные проблемы можно только пересмотром самой парадигмы ИТ. Подобно тому, как в живой природе существует единая технология оперирования генетическим кодом на основе которого формируются популяции животных (аналог цифровых "объектов") различных видов, в информационном пространстве должна существовать единая система структурной организации, позволяющая формировать объекты (документы) самого разнообразного вида.
Должны быть разработаны общеупотребительные единые принципы организации и структурирования данных в базах независимо от специфики прикладных задач.
Достаточно подробное описание структур данных и алгоритмов децентрализованной параллельной потоковой их обработки содержится в статьях раздела "Информационные технологии", см. http://proza.ru/avtor/cardiac&book=5#5.
Причём появление новых алгоритмов не отменяет работу старых, какой-либо операционной системы не требуется, универсальный язык программирования гарантирует полную совместимость ПО, а унифицированная база данных отменяет файловую систему
Любой специалист в своей профессиональной деятельности легко оперирует бумажными документами, а при необходимости заводит новые. Он также может сделать выписки из требуемых сопутствующих документов. Однако в электронном формате для создания новых документов пока необходимо прибегать к услугам программистов или администраторов баз данных.
Естественно, появились предложения от разработчиков предлагающих пользователям средства лёгкого конструирования баз данных адекватно своим потребностям и понятиям, что в корне противоречит объективной и насущной общественной необходимости интеграции данных.
Обычная реляционная база данных (БД) состоит из комплекса таблиц, каждая из которых имеет такую же структуру, какая была бы и у бумажного документа, который она заменяет. С тем отличием, что на страничке бумажного документа относящейся к одному объекту, разные данные обычно размещены в разных строках, а в таблицах БД они размещаются в различных полях (столбцах) одной строки.
Таким образом, в таблице БД каждая строка содержит все данные одного документа, а в каждом столбце содержатся однотипные данные разных экземпляров одинаковых документов.
И когда она была в 70-х изобретена британским учёным Эдгаром Коддом, все сказали: "Это хорошо!". Но увы, каждый разработчик волен по-разному размещать данные в таблицах и совершенно произвольно именовать реквизиты (поля и таблицы) своей БД. Поэтому, когда жизнь заставит их как-то учитывать совместную деятельность и планы, воспользоваться данными друг друга будет им весьма затруднительно.
Вот если бы Э.Кодд поразмыслил бы ещё с недельку и предложил унифицированную БД – вот это было бы "отлично"! А Дон Чемберлен, соавтор Рея Бойса в разработке языка запросов SQL, «верил, что пользователи компьютеров будут в состоянии работать на уровне, более приближенном к естественному языку, и не будут отвлекаться на подробности того, где и как данные хранятся».
А это уже совсем не хорошо! Приходится вспоминать в какой последовательности следует сочетать эти английские словеса, и надо ли в этой версии языка SQL вписывать "AS" перед переименованием, и какие опции есть ещё. И это вместо того, чтобы просто написать логические выражения для условий выборки. И как раз таки важно знать, как данные хранятся.
Далее http://proza.ru/2024/10/08/1488