Среди комменатриев к предыдущей заметке автору довелось услышать следующий: «А почему, собственно, такое внимание к базам данных»? Вопрос закономерный, и сейчас мы попробуем на него ответить.
Дело в том, что некоторые теоретики, работающие над вопросами развития общества, выдвинули лозунг: «Бросить все силы на изучение SQL»! (SQL - Structured Query Language - язык работы с реляционными базами данных). Обосновывается этот посыл следующими соображениями:
- Коренной проблемой сознательного преобразования общества является проблема преодоления товарности.
- Одним из путей преодоления товарности является создание общегосударственной автоматизированной системы учёта и обработки информации (ОГАС ак. Глушкова и развитие его идей).
- Данные в ОГАС следует хранить в реляционных СУБД.
- Для работы с реляционными СУБД нужен язык SQL.
- Следовательно, для сознательного преобразования общества все преобразователи должны изучить SQL.
И если первые два пункта вопросов не вызывают, то вот переход от ОГАС к реляционным СУБД выглядит как попытка скрестить ужа с ежом. В качестве обоснования такого перехода в лучшем случае основываются на частном опыте: попытке решения прикладных задач текстологии при помощи реляционных баз.
В худшем случае звучат совершенно фееричные утверждения (сохранена орфография автора): «О каких данных идет речь при обсуждении процесса коренной смены общественных отношений? О данных относящихся к учету и контролю производства, другими словами, о данных связанных с информационно-учётным аспектом коллективного труда. И эти данные являются структурированными, так как только в структурированной и целостной (в смысле корректности) форме эти данные можно использовать.»
Вот уж воистину «диалектика»: в качестве доказательства приводим тезис, который сам нуждается в доказательстве.
Так почему же с завидной регулярностью всплывают подобные смелые утверждения? Как нам кажется (и об этом, собственно, была первая заметка), причина заключается в нарочитом пренебрежении к «ползучему болоту эмпиризма», а проще говоря — в незнании достижений человеческой практики.
Например, одним из таких достижений является выстраданная десятилетиями методология разработки информационных продуктов. Как правило, выделяют несколько этапов:
- Постановка задачи
- Формализация задачи
- Проектирование
- Алгоритмирование
- Программирование
- Тестирование и отладка
Постановка задачи — это когда от заказчика мучительно пытаются добиться ответа: а чего же он собственно хочет. Ведь, как правило, требования заказчика поначалу выражены просто: сделайте мне хорошо, чего тут неясно-то?! В нашем случае постановка задачи о преодолении товарности также недалеко пока ушла от заветного желания Cталкера: «…счастье для всех. Даром, и пусть никто не уйдет обиженный».
Кстати, на этом же этапе принимают решения о декомпозиции задачи, то есть дробят один большой проект на связанные подпроекты.
На этапе формализации задачу «переводят» с языка заказчика на язык технического задания, где четко определено что, как, в какой последовательности должен производить итоговый продукт. В нашем случае до этого этапа теоретики не добрались.
Этап третий: проектирование. На этом этапе разрабатывается архитектура будущего продукта и, в том числе, определяются типы и способы обработки входных и выходных данных. Очевидно, данный шаг теоретиками опущен.
На следующей стадии, помимо прочего, как раз и происходит выбор технических решений для реализации требований проекта. Например выбирается та или иная СУБД для хранения данных. Вот тут наши преобразователи уверенно декламируют: будем использовать реляционные СУБД! Проект, какой такой проект? Мы пару лабораторных по информатике в школе делали, мы уверены в выборе!
И только после этого наступает этап непосредственно программирования: команда разработчиков пишет код на требуемом языке, будь то Python или SQL. И венчает все этап тестирования, на котором, между прочим, могут вылезти ошибки не только кода, но и всех предыдущих этапов, вплоть до постановки задачи.
Нетрудно заметить, что указанные этапы характерны не только для разработки ИТ-продуктов. Эта методология носит универсальный характер и встречается (с известными поправками) в любой области производства, от строительства дачного туалета до ракеты «Starship». Просто потому, что любую идею так или иначе придется реализовывать в конечном материале. А реализация в конечном материале требует опосредующего движения для учета особенностей этого самого материала.
Что же предлагают нам теоретики, выдвигая лозунг изучения SQL? Да просто безосновательно уверовать в будущность ОГАС на реляционных СУБД. Ведь опосредующего движения от идеи (находящейся пока на стадии благого пожелания) до способов реализации у них нет. Поэтому способ реализации выбран наугад, «прыжком веры», хотя и обставлен густой, a-la гегелевской фразеологией.
Вот только прыжки веры не имеют ничего общего с сознательным преобразованием общества к лучшему.
Комментарии
Отправить комментарий