Комментарии 19
лично для меня уровень абстракции в статье зашкаливает — неплохо бы какой-нибудь конкретный пример наглядно показывающий как упрощает жизнь то что предлагается в этой статье
Пережевываются идеи полувековой давности, от которых отказались лет 20 как. :-)
В ИТ нет ничего нового. Ибо вообще нет ничего нового. (с) дядька гораздо умнее меня.
Я бы предложил человеку
- Написать и выложить эту СУБД
- Написать ряд обучающих статей для вправления мозгов специалистов разных видов и к ним мощный набор обучающих и проверочных тестов, дабы каждый мог сравнить решения типовых задач и выяснить, что и где он не понимает.
Ибо что-то в высказанном есть, но большинство сведет все к знакомым концепциям (RDB+MVC, 1С, например) и скажет, что этим микроскопом неудобно забивать привычные гвозди.
Написать ряд обучающих статей … дабы каждый мог сравнить решения типовых задач и выяснить, что и где он не понимает.Если будет проявлена конкретная заинтересованность, то да, так примерно и будем действовать, дабы определить уровни применимости в конкретных аспектах соответственно затратам и возможностям.
Написать и выложить эту СУБДИ это логично сделать при ещё более конкретном интересе. А вообще-то решений может быть множество, но различной степени гибкости и стройности. И реализация может быть не только в модели реляционных таблиц.
Для mad_nazgul
Как смогли отказаться от того, что ни разу даже не попробовали? Если вы имеете в виду концепции Dataflow в режиме машинных команд сопоставляемых каждому очередному вычисленному данному, то соглашусь — сложность исполнения себя не окупила. Но предлагается нечто иное, основанное не на архитектуре процессоров, а на разделении потоков данных, которые могут обрабатываться параллельно.
Как смогли отказаться от того, что ни разу даже не попробовали? Если вы имеете в виду концепции Dataflow в режиме машинных команд сопоставляемых каждому очередному вычисленному данному, то соглашусь — сложность исполнения себя не окупила. Но предлагается нечто иное, основанное не на архитектуре процессоров, а на разделении потоков данных, которые могут обрабатываться параллельно.
Для ssurrokk
Упрощает жизнь то, что не надо писать код программы, в которой указывать всю последовательность создания и обработки всех предшествующих данных, чтобы получить требуемые. Вместо этого просто указываете условия их получения из уже существующих в базе. Поскольку такое же будет указано и для предшествующих исходных для затребованных данных, все они будут сформированы по мере и в последовательности их создания. Алгоритм получения каждого указывается в метаданных. Т.е. ведущая прога не нужна, а значит процессы полностью децентрализованы. Любой пользователь, благодаря информации в метаданных, сможет «прицепиться сбоку» к любым наборам данных без включения его требований в ведущую программу – таковой просто нет.
Упрощает жизнь то, что не надо писать код программы, в которой указывать всю последовательность создания и обработки всех предшествующих данных, чтобы получить требуемые. Вместо этого просто указываете условия их получения из уже существующих в базе. Поскольку такое же будет указано и для предшествующих исходных для затребованных данных, все они будут сформированы по мере и в последовательности их создания. Алгоритм получения каждого указывается в метаданных. Т.е. ведущая прога не нужна, а значит процессы полностью децентрализованы. Любой пользователь, благодаря информации в метаданных, сможет «прицепиться сбоку» к любым наборам данных без включения его требований в ведущую программу – таковой просто нет.
Вместо этого просто указываете условия их получения из уже существующих в базе.
… а потом выясняется, что "уже существующие в базе" — не те.
Поскольку такое же будет указано и для предшествующих исходных для затребованных данных, все они будут сформированы по мере и в последовательности их создания.
То есть пользователь получит свой результат неизвестно когда (и неизвестно какой, потому что в любой момент времени правила для "предшествующих" данных могут быть изменены).
без включения его требований в ведущую программу – таковой просто нет.
Зато есть его собственная маленькая программа, которая неявно зависит от графа чужих маленьких программ.
Для lair
Выбор данных должен основываться на метаданных документа. Если есть документ и он устраивает, значит выбираться будет из того, что нужно. Конечно, правообладатель может, в принципе, изменить состав метаданных (и тем самым документ), но тогда у наследующих запрос не сработает. И они уже сами создадут устраивающий их документ из более предшествующих данных. Вопрос: а какая тогда разница с принятой стратегией описания в проге получения всех нужных данных с самого начала? Отвечаю: в том, что уже обычно есть промежуточные данные (документы описанные в метаданных), которыми просто можно воспользоваться.
… а потом выясняется, что «уже существующие в базе» — не те.
Выбор данных должен основываться на метаданных документа. Если есть документ и он устраивает, значит выбираться будет из того, что нужно. Конечно, правообладатель может, в принципе, изменить состав метаданных (и тем самым документ), но тогда у наследующих запрос не сработает. И они уже сами создадут устраивающий их документ из более предшествующих данных. Вопрос: а какая тогда разница с принятой стратегией описания в проге получения всех нужных данных с самого начала? Отвечаю: в том, что уже обычно есть промежуточные данные (документы описанные в метаданных), которыми просто можно воспользоваться.
Выбор данных должен основываться на метаданных документа.
… которые кто-то должен поддерживать. И которые должны быть достаточно детализированными, чтобы ответить на все вопросы о данных, что, в какой-то момент, делает их, фактически, описанием алгоритма сборки этих самых данных.
тогда у наследующих запрос не сработает. И они уже сами создадут устраивающий их документ из более предшествующих данных.
В современных системах это называется "сломали то, что работает в продакшне". И так делать не надо от слова совсем.
Вопрос: а какая тогда разница с принятой стратегией описания в проге получения всех нужных данных с самого начала?
На самом деле, нет такой "принятой стратегии". Промежуточные расчеты используются, и весьма обширно.
Да, совершенно верно. Именно доступное и понятное описание документа позволит его грамотно использовать. Если конечно будут предоставлены права.Выбор данных должен основываться на метаданных документа.… которые кто-то должен поддерживать. И которые должны быть достаточно детализированными, чтобы ответить на все вопросы о данных
Именно доступное и понятное описание документа позволит его грамотно использовать.
Как вы удачно опустили следующую часть фразы.
Ну вот не уверен, что способ получения данных для документа должен быть обозрим и тем более доступен для изменения. Тут мы касаемся уже темы сертификатов, лицензий и пр. Пока тема не в той стадии разработки, чтобы уже над этим думать. Сейчас решения есть, полагаю многое будет применимо и в проекте, или будут предложены приемлемые.
Сломать сможет только тот, кто и создавал.тогда у наследующих запрос не сработает. И они уже сами создадут устраивающий их документ из более предшествующих данных.В современных системах это называется «сломали то, что работает в продакшне».
Для lair
Можно в фоновом режиме создавать список пользователей использующих конкретный документ. Можно создать прогу (демона), которая автоматически уведомит их всех при изменении метаданных документа (или запретит изменения). Это можно, поскольку работа с метаданными управляется блок-схемой процессов, для которой заявки на создание и модернизацию метаданных просто данные он-лайн поступающие от клиентов.
Т.е. определённая инфраструктура должна быть создана перед запуском системы в эксплуатацию.
То есть пользователь получит свой результат неизвестно когда (и неизвестно какой, потому что в любой момент времени правила для «предшествующих» данных могут быть изменены).Обычно получение документа (отчёта) приурочено к календарному сроку или к наступлению какого либо события. Эти данные обстановки могут быть включены в метаданные, т.е. в запрос на условие создания документа.
Можно в фоновом режиме создавать список пользователей использующих конкретный документ. Можно создать прогу (демона), которая автоматически уведомит их всех при изменении метаданных документа (или запретит изменения). Это можно, поскольку работа с метаданными управляется блок-схемой процессов, для которой заявки на создание и модернизацию метаданных просто данные он-лайн поступающие от клиентов.
Т.е. определённая инфраструктура должна быть создана перед запуском системы в эксплуатацию.
Обычно получение документа (отчёта) приурочено к календарному сроку или к наступлению какого либо события.
Откуда у вас такое "обычно" для информационных систем в общем?
Т.е. определённая инфраструктура должна быть создана перед запуском системы в эксплуатацию.
И, внезапно, сложность этой инфраструктуры — которая должна учитывать все возможные общие и пограничные случаи — оказывается существенно выше, чем сложность программы, которая просто выполняет алгоритм.
Отчёты о содержании и успехах деятельности обычно и формируются согласно календарных сроков.
И, внезапно, сложность этой инфраструктуры — которая должна учитывать...Отнюдь. При «просто» исполнении программы, которая как вы отметили, вполне может использовать промежуточные данные, возникают те же проблемы их актуальности. Только решаются они хуже и не автоматически, ибо нет никаких метаданных. Клиент может вообще не узнать, что случилось.
Отчёты о содержании и успехах деятельности обычно и формируются согласно календарных сроков.
… и это все, чем занимается информационная система в общем случае?
Отнюдь.
"Отнюдь" что? "Отнюдь", не должна учитывать? Тогда у вас будут все описанные проблемы.
возникают те же проблемы их актуальности.
Могут возникать.
Только решаются они хуже и не автоматически, ибо нет никаких метаданных.
Могут решаться хуже, могут решаться не автоматически, и может не быть метаданных.
А может все быть наоборот, и, поскольку общий случай решать не надо, весьма эффективно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как миновать мины информационных технологий