Уже много раз сталкивался с граблями при разделении логики на разные виды.
Например, описали логику проверки корректности вводимых данных в интерфейсной форме (ведь при ошибке надо выдать пользователю предупреждение — значит логика интерфейса). Потом, например, реализуем загрузку тех же данных в пакетном режиме и тоже пишем ту же логику проверок. И после нескольких модификаций наборы правил проверки не полностью совпадают, и у нас труднодиагностируемый глюк в данных…
Много думал.
Попытался «натянуть» варианты #A, #B, #C and #D на ERP системы (ими занимаюсь) — не получилось.
Все варианты не полностью соответствуют задачам.
Больше всего сомнений в месте, где надо располагать логику. Если её писать и на клиенте и на сервере — очень быстро начинаются большие проблемы. В варианте #D вся логика на сервере, но зачем в ERP Peer-to-Peer — не понятно. В остальных вариантах логика и там и там и это может создать сложности.
Хотя если сделать вариант с «синхронизацией» части логики между сервером и клиентом — это может быть интересно. Описываешь всю логику на сервере, но часть из нее (например, первичная проверка данных) автоматом переносится в клиентское приложение и выполняется там…
С локальными DB тоже много вопросов. Выгрузить на клиента тот же справочник номенклатуры, если там сотни тысяч позиций — сомнительный вариант. Выгрузить частично — но тогда что именно выгружать и усложняется логика работы со справочниками.
Можно локально хранить данные об открытом / редактируемом документе, но это обычно небольшой кусок данных, и не очень понятно, насколько хранение таких данных поможет…
Вычисления на клиенте — возможно. Но точно не в самом клиентском приложении, а что то вроде распределенной вычислительной среды вполне можно использовать. Но в ERP потребность в таких вычислениях не очень часто встречается, и при этом обычно надо обрабатывать большие объемы данных — забьется канал.
Потолок для реляционных баз НАМНОГО выше необходимой производительности для бизнес задач.
А вот у нереляционных баз есть большая проблема — с их помощью нельзя или тяжело получать разные показатели на основе сохраненных бизнес транзакций (перемещений товаров, платежей, фин проводок и т.п.).
Вот например абсолютно реальная задача:
«Нам надо расчитать среднее количество дней храния товара на складе в ГородХХХ за 2016 год.
Только материала ПоставщикУУУ.»
Сегодня письмо с запросом получил, стилистика автора полностью сохранена (заменил два слова))).
Как такие вещи считать в RDBMS с помощью SQL — понятно. А как в той же OrientDB — лично мне не очень понятно.
Поэтому мучают меня смутные сомнения — а пригодна ли в принципе OrientDB и Orienteer для реальных учетных задач?
«Так же представители каждой категории ведут себя по-разному: одни ведут себя капризно и заносчиво, неуважительно разговаривают, другие же – слишком общительны, навязчивы и некультурны. Порой различия доходят до негласных конфликтов, что не дает людям заниматься вместе.»
Вы указали, что проблема — конфликты между посетителями.
Вы указали, что основная причина возможных конфликтов — разные поведенческие реакции.
И тут же приводите способ решения проблемы:
«Устранить все негативные ситуации невозможно, но избежать большинство из них – задача выполнимая. К примеру, фитнес-клуб может шить форму для клиентов в одном стиле, сняв мерки перед выдачей абонемента. Таким образом, клиенты не будут знать, кто есть кто до выхода с занятий.»
Вопрос — одинаковая форма ДЕЙСТВИТЕЛЬНО до такой степени меняет поведение клиентов, что количество конфликтов между ними существенно снижается?
Было бы интересно почитать. Это более «универсальный» опыт.
Ведь то, что у вас получилось разработать таким образом вашу систему — это во многом случайность. Структура данных вашего решения хорошо «стыковалась» со структурой данных «большой» закрытой системы. А это бывает далеко не всегда.
В нашей компании тоже стоит, но используется только как хранилище файлов.
Купили его в основном потому, что планировали внедрять MS NAV и использовали офис, и ИТ директор решил, что SharePoint прекрасно со всем интегрируется. Реальность показала, что уровень интеграции сильно преувеличен. И надежды, что SharePoint возьмет и заработает — не оправдались.
Большинство ИТ директоров просто не знают, что SharePoint — это инструмент для создания готовых приложений, и сам по себе для пользователей ценности практически не представляет.
К сожалению, не у всех хорошие способности к математике и не всем она настолько нравится, чтобы выучить на хорошем уровне.
Посмотрел ссылку — может, и «разжевано», только мне это не очень заметно. :)))
А эту статью я понял практически на 100%.
О чем в целом статья? О том, как важно корректно проверять все предположения.
«Устойчивость таких заблуждений лишь демонстрирует, насколько легко ложное представление или идея могут укрепиться в сознании человека. Даже если предположить, что основатели всех этих проектов — не аферисты и действительно верили в свой бизнес, их истории (и в особенности неутешительный итог работы Theranos) — показательный пример того, как опасно игнорировать принципы проведения исследований и не подкреплять громкие заявления реальной научной базой.»
Есть громкое заявление — вакцинация очень безопасна. Ок.
Пытаемся найти подтверждение. И легко находим что то вроде:
http://www.dbmurom.ru/index.php/stati-vrachej/211-reakciinavakcinu.html
Смотрим на количество осложнений и видим очень обнадеживающие цифры — 1 на 40 тысяч, 1 на 600 тысяч. Круто!
Потом беседуешь с каким нибудь педиатром, а она говорит — у меня на 500 деток примерно у 20 после прививок появились хронические заболевания, а еще 20 очень тяжело болели, но вроде полностью выздоровели — пока рецидивов нет.
Противоречие?
Еще раз читаешь, что именно называется осложнением после прививок:
«Появление клинических симптомов после введения вакцины вовсе не означает, что именно вакцина вызвала эти симптомы. Последние могут быть связаны с присоединением какой-либо интеркуррентной инфекции, которая может изменить и утяжелить реакцию организма на прививку, а в ряде случаев способствовать развитию поствакцинальных осложнений.
В таких случаях для доказательства причинной связи между вакцинацией и патологическим синдромом должно быть проведено тщательное расследование.»
И вот тут то и появляется прозрение. К статистике как науке все эти цифры, мягко говоря, имеют слабое отношение. Это просто количество случаев, когда было «проведено тщательное расследование» и доказательства причинно следственной связи были очень убедительными. Другими словами — мы отобрали факты, которые подтверждают нашу теорию, и отбросили все плохие факты. :)))
Начинаешь искать исследования, которые соответствуют научным стандартам — то есть собираются все факты заболеваний по определенной выборке людей за определенный период и данные о прививках тем же людям за тот же период, и дальше с помощью статистических методов находятся связи между прививками и различными заболеваниями. И — не находишь таких исследований. :)))
Может, они есть. Но почему на них так мало ссылок, что их трудно найти? И какие именно цифры указаны в этих исследованиях?
Посмотрел видео по ссылке — ничего нового не услышал. Кстати, в целом со всем согласен. :)
Я писал о другом. Мне как раз и захотелось найти нормальные статистические данные об осложнениях после прививок без субъективных оценок не всегда квалифицированных врачей. Я ожидал, что легко получится найти данные примерно такого типа — выбрали 100 тысяч человек и совместили данные о датах всех перенесенных этими людьми болезней болезней (дата обращения к врачу, диагноз) за 2 года с графиком прививок за тот же период.
Даже если некоторые диагнозы поставлены неверно или некорректно определено наличие / отсутствие связи между прививкой и заболеванием — большая правильно сделанная выборка сгладит эти неточности и покажет реальный уровень риска осложнений.
И я такого исследования найти не смог. Может, разумеется, плохо искал. Но сразу возникает вопрос — почему на сайте того же ВОЗ достаточно много ссылок на разные исследования, опровергающие связь прививок и склероза, артрита и много уверений в безопасности прививок, а ссылки на подобные исследования на видном месте нет?
Так я и слушал врачей. :) И именно врачи в неофициальной беседе предупредили, что опасность от прививок, по их мнению, больше, чем многие думают и чем пытаются нас убедить их производители.
Но вообще ваш аргумент нелогичен. То, что я не разбираюсь в медицине, не значит, что я не разбираюсь в статистике.
Есть огромное количеств фактических данных о историях болезней — кто, когда и чем болел. Также можно найти информацию, кто когда и какой именно вакциной прививался. И сделать анализ этих данных (есть корелляция между этими событиями или нет, и если есть — то какая именно) — не очень сложная и дорогая задача. Более того, я ожидал, что легко найду ссылки на сотни таких исследований с нормальным описанием методики (как формировалась выборка и т.п.) и полученных результатах — тема ведь многих волнует. И удивился, когда нашел данные о всего нескольких исследованиях и при этом даже о них нет (или не смог найти) нормального описания методики формирования выборок. И вот тут то и закрались сомнения — а насколько всё то, что нам рассказывают о прививках, имеет научное обоснование? Пусть даже не механизм действия прививок (как именно работает иммунитет, хорошо разобрались ближе к концу 20 века, а прививки массово начали делать в начале 20 века), но хотя бы статистические доказательства их эффективности и безопасности.
Попробуйте сами потратить немного времени и найти исследования по прививкам, которые соответствуют научным критериям. И после этого обсудим. :)
Пример с вакцинами совсем не так однозначен, как вы пытаетесь показать. Вообще исследований о эффективности вакцин и о возможных негативных последствиях для здоровья — относительно мало, а те, что есть — не все надежны с научной точки зрения.
Попробуйте найти описание исследований с контрольными группами, двойным слепым методом и статистически значимым количеством участников. Таких исследований почему-то намного меньше, чем ожидаешь.
Хотя лично у меня главная претензия к вакцинации (а скорее к бизнесу фармкомпаний по производству вакцин) лежит в немного иной области.
Даже самые горячие сторонники вакцинации признают, что как минимум часть вакцин в отдельных (редких) случаях должна давать негативные последствия для здоровья вакцинируемых людей. Предполагается, что это небольшая цена за то, что прекратились эпидемии.
Но попробуйте найти нормальную статистику о таких случаях, с описанием методик сбора данных. У меня не получилось. Но я ладно, к медицине и фармакологии не имею отношения, но и у знакомых, которые работают врачами и фармацевтами — тоже не получилось найти эти данные. И насколько они знают, просто не существует каких то четких инструкций / процедур / стандартов, согласно которым можно (нужно) связывать проблему со здоровьем с применением вакцины (по крайней мере в России и Украине).
Я лично знаю два случая с моими знакомыми, когда у детей существенные проблемы со здоровьем начались в течении нескольких дней после вакцинации. И их мамы однозначно связывают эти проблемы с вакцинацией. Учитывая, что одна из этих мам — фармацевт, а вторая — врач, эти случаи заставляют задуматься о реальном уровне безопасности вакцин. Ведь если вакцинация очень безопасна, маловероятно, что среди лично знакомых людей столкнешься сразу с двумя случаями. И настораживает, что в этих случаях не только никто не признал, что проблемы возникли вследствии вакцинации (действительно, тут может не быть причинно-следственной связи, хотя короткий временной промежуток настораживает), но и не было ВООБЩЕ никакого расследования, есть связь между вакцинацией и заболеванием в этом случае, или нет. То есть ребенок заболел, его начали лечить, но никто не пытался выяснить, а почему именно он заболел и не связано ли это с вакцинацией.
Еще раз уточняю — речь идет о детях врача и фармацевта (с высшим образованием и работающие по специальности), которых лично знаю.
Поэтому фраза «действительные факты очень часто опережаются ложными, но более привлекательно упакованными данными» применительно к вакцинам звучит достаточно двусмысленно. Ведь создавались тысячи разных вакцин (в том числе и с живыми микроорганизмами, которые не могут быть полностью безопасны по определению) и применялись в сотнях миллионов случаев — и при этом относительно мало надежных данных о эффективности и безопасности этих вакцин.
«есть отдельный этап разработки конкретных бизнес-приложений на этой платформе для конкретного заказчика, который выполняют отдельные люди, хорошо знакомые не только с программированием, платформой и инструментами, но ещё и с предметной областью заказчика. Пользователи же должны лишь пользоваться.»
Нет четкой границы между прикладными программистами и пользователями. Любой «продвинутый пользователь» может добавить в той же 1С дополнительный реквизит в шапку документа. Если при этом не надо никак изменять логику проведения документа — всё прекрасно будет работать. Такие задачи на практике встречаются очень часто. И от того, что человек смог добавить дополнительное поле, программистом его называть не совсем корректно.
«Но тут, не так все просто, тут возникает момент-конфликт логики процесса и логики данных в бд, и как это грамотно совместить, т.к. БД у нас на текущий момент реляционные — структура жесткая(1С, magneto и.т.д.) для обхода этого ограничения используют EAV, вот поэтому в 1C и нет простого доступа к BD, ибо запросы нелогичны, но сейчас BD научились, работать с XML/JSON, тоесть по факту они уже не relation, и тут уже возможно поиграть с совмещением не совмещаемого, но с архитектурной точки зрения не все так просто.»
По моему мнению, именно для бизнес задач не надо ничего изобретать, а надо использовать реляционные БД, которые в основном под эти задачи и создавались. И жесткая структура для бизнес данных является плюсом — иначе будут сложности с анализом. Единственная проблема — «кухарка» не сможет сделать нормальную схему БД (нужны знания по теории БД). Но тут можно в значительной степени решить проблему с помощью библиотеки готовых шаблонов («документ» в конфигурации 1С создает таблички в БД по определенному шаблону) + привлечения нормальных специалистов для рефакторинга базы на более поздних этапах жизненного цикла создаваемого софта, когда структура приложения более менее устоялась.
А в 1С нет доступа к базе по другой причине — они наплодили велосипедов и костылей, и сейчас это всё тяжело поддерживать. Например, у них до сих пор есть своя файловая БД, вот скорее всего из-за неё и не могут сделать нормальный доступ к базе.
Конструктор может поддерживать глубокую доработку UI с помощью стандартных языков. И в таком случае использование конструктора тоже оправданно.
Сделал фактически прототип с помощью конструктора и несколько раз переделал его на основании замечаний пользователя. При этом UI корявый, но как-то работает. А когда все согласились, что вот так всё и должно работать — допиливается UI и всё остальное, что надо допилить. И не обязательно только с помощью инструментов конструктора.
Это, разумеется, идеализированная схема, но часто именно такой вариант является оптимальным.
Почти у каждой компании есть устоявшиеся процессы, которые и составляют 90-98% операционной деятельности, и новые процессы, по которым нет четких правил.
Для новых процессов и нужны конструкторы, которые позволяют с минимальными затратами разработать софт (пусть с не очень удобным UI или немного кривой схемой БД). Главное, чтобы этот софт можно было легко переделывать. Ведь при начале разработки никто не знает, как это должно работать — надо пробовать.
А бизнес модель разработчика конструктора может строиться не на продаже новых копий (их можно отдавать бесплатно), а на сопутствующих услугах.
Например, делается что то вроде фриланс биржи по работе с конструктором, где профи помогают сделать нормальную схему БД, или доработать интерфейс / разработать специфический расчетный модуль, а разработчик конструктора забирает себе процент от оплаты.
Не всегда. Есть целый ряд ситуаций, когда нужен конструктор с возможностью дописывать модули. Например, я не смогу нормально и быстро сделать UI — никогда таким не занимался. А написать небольшой расчетный модуль на SQL или на другом языке — вполне могу. И для меня конструктор очень удобен для некоторых задач.
Быстро набросал некое приложение, которое сразу и заработало. Потом, по мере необходимости, дописываю различные хотелки, часть из которых делаю с помощью модулей на С# или другом языке, а часть средствами конструктора. И то, что есть возможность дописывать на универсальном языке — сильно греет душу. Всегда в крайнем случае можно пригласить другого специалиста, и он в твоем приложении допишет нужный кусочек. И не волнуешься, что конструктор не поддерживает какую-то фичу, которая понадобится, но о которой сейчас даже не подозреваешь. Стандартные языки программирования тем и хороши, что на них можно реализовать всё, что душе угодно (всё, что может делать машина Тьюринга).
Кстати, это (функционал, отсутствующий в конструкторе) один из очень важных вопросов. Когда создатели конструктора начинают считать себя самыми умными и заставляют работать только с помощью инструментов конструктора. Типичный пример 1С — нельзя в самом 1С работать напрямую с базой данных через SQL, нельзя создавать свои структуры данных напрямую в БД и тому подобное.
Таких конструкторов надо по максимуму избегать. Создатель конструктора всё равно не сможет втиснуть в конструктор все возможности СУБД или стандартного языка программирования. И отсутствие возможности использовать «низкоуровневые» средства очень дорого обходится в некоторых случаях. А случаи такие случаются намного чаще, чем многие думают. :)))
Например, описали логику проверки корректности вводимых данных в интерфейсной форме (ведь при ошибке надо выдать пользователю предупреждение — значит логика интерфейса). Потом, например, реализуем загрузку тех же данных в пакетном режиме и тоже пишем ту же логику проверок. И после нескольких модификаций наборы правил проверки не полностью совпадают, и у нас труднодиагностируемый глюк в данных…
Попытался «натянуть» варианты #A, #B, #C and #D на ERP системы (ими занимаюсь) — не получилось.
Все варианты не полностью соответствуют задачам.
Больше всего сомнений в месте, где надо располагать логику. Если её писать и на клиенте и на сервере — очень быстро начинаются большие проблемы. В варианте #D вся логика на сервере, но зачем в ERP Peer-to-Peer — не понятно. В остальных вариантах логика и там и там и это может создать сложности.
Хотя если сделать вариант с «синхронизацией» части логики между сервером и клиентом — это может быть интересно. Описываешь всю логику на сервере, но часть из нее (например, первичная проверка данных) автоматом переносится в клиентское приложение и выполняется там…
С локальными DB тоже много вопросов. Выгрузить на клиента тот же справочник номенклатуры, если там сотни тысяч позиций — сомнительный вариант. Выгрузить частично — но тогда что именно выгружать и усложняется логика работы со справочниками.
Можно локально хранить данные об открытом / редактируемом документе, но это обычно небольшой кусок данных, и не очень понятно, насколько хранение таких данных поможет…
Вычисления на клиенте — возможно. Но точно не в самом клиентском приложении, а что то вроде распределенной вычислительной среды вполне можно использовать. Но в ERP потребность в таких вычислениях не очень часто встречается, и при этом обычно надо обрабатывать большие объемы данных — забьется канал.
А вот у нереляционных баз есть большая проблема — с их помощью нельзя или тяжело получать разные показатели на основе сохраненных бизнес транзакций (перемещений товаров, платежей, фин проводок и т.п.).
Вот например абсолютно реальная задача:
«Нам надо расчитать среднее количество дней храния товара на складе в ГородХХХ за 2016 год.
Только материала ПоставщикУУУ.»
Сегодня письмо с запросом получил, стилистика автора полностью сохранена (заменил два слова))).
Как такие вещи считать в RDBMS с помощью SQL — понятно. А как в той же OrientDB — лично мне не очень понятно.
Поэтому мучают меня смутные сомнения — а пригодна ли в принципе OrientDB и Orienteer для реальных учетных задач?
Вы указали, что проблема — конфликты между посетителями.
Вы указали, что основная причина возможных конфликтов — разные поведенческие реакции.
И тут же приводите способ решения проблемы:
«Устранить все негативные ситуации невозможно, но избежать большинство из них – задача выполнимая. К примеру, фитнес-клуб может шить форму для клиентов в одном стиле, сняв мерки перед выдачей абонемента. Таким образом, клиенты не будут знать, кто есть кто до выхода с занятий.»
Вопрос — одинаковая форма ДЕЙСТВИТЕЛЬНО до такой степени меняет поведение клиентов, что количество конфликтов между ними существенно снижается?
Ведь то, что у вас получилось разработать таким образом вашу систему — это во многом случайность. Структура данных вашего решения хорошо «стыковалась» со структурой данных «большой» закрытой системы. А это бывает далеко не всегда.
Но в первую очередь как иллюстрация цитаты
Уинстон Черчиль
Сперва за много миллионов внедрили закрытую систему, а потом с этим боролись. :)))
Кстати, а были сделаны какие-то шаги, чтобы еще раз не наступить на те же грабли, но уже с новой системой?
Купили его в основном потому, что планировали внедрять MS NAV и использовали офис, и ИТ директор решил, что SharePoint прекрасно со всем интегрируется. Реальность показала, что уровень интеграции сильно преувеличен. И надежды, что SharePoint возьмет и заработает — не оправдались.
Большинство ИТ директоров просто не знают, что SharePoint — это инструмент для создания готовых приложений, и сам по себе для пользователей ценности практически не представляет.
Посмотрел ссылку — может, и «разжевано», только мне это не очень заметно. :)))
А эту статью я понял практически на 100%.
«Устойчивость таких заблуждений лишь демонстрирует, насколько легко ложное представление или идея могут укрепиться в сознании человека. Даже если предположить, что основатели всех этих проектов — не аферисты и действительно верили в свой бизнес, их истории (и в особенности неутешительный итог работы Theranos) — показательный пример того, как опасно игнорировать принципы проведения исследований и не подкреплять громкие заявления реальной научной базой.»
Есть громкое заявление — вакцинация очень безопасна. Ок.
Пытаемся найти подтверждение. И легко находим что то вроде:
http://www.dbmurom.ru/index.php/stati-vrachej/211-reakciinavakcinu.html
Смотрим на количество осложнений и видим очень обнадеживающие цифры — 1 на 40 тысяч, 1 на 600 тысяч. Круто!
Потом беседуешь с каким нибудь педиатром, а она говорит — у меня на 500 деток примерно у 20 после прививок появились хронические заболевания, а еще 20 очень тяжело болели, но вроде полностью выздоровели — пока рецидивов нет.
Противоречие?
Еще раз читаешь, что именно называется осложнением после прививок:
И вот тут то и появляется прозрение. К статистике как науке все эти цифры, мягко говоря, имеют слабое отношение. Это просто количество случаев, когда было «проведено тщательное расследование» и доказательства причинно следственной связи были очень убедительными. Другими словами — мы отобрали факты, которые подтверждают нашу теорию, и отбросили все плохие факты. :)))
Начинаешь искать исследования, которые соответствуют научным стандартам — то есть собираются все факты заболеваний по определенной выборке людей за определенный период и данные о прививках тем же людям за тот же период, и дальше с помощью статистических методов находятся связи между прививками и различными заболеваниями. И — не находишь таких исследований. :)))
Может, они есть. Но почему на них так мало ссылок, что их трудно найти? И какие именно цифры указаны в этих исследованиях?
Я писал о другом. Мне как раз и захотелось найти нормальные статистические данные об осложнениях после прививок без субъективных оценок не всегда квалифицированных врачей. Я ожидал, что легко получится найти данные примерно такого типа — выбрали 100 тысяч человек и совместили данные о датах всех перенесенных этими людьми болезней болезней (дата обращения к врачу, диагноз) за 2 года с графиком прививок за тот же период.
Даже если некоторые диагнозы поставлены неверно или некорректно определено наличие / отсутствие связи между прививкой и заболеванием — большая правильно сделанная выборка сгладит эти неточности и покажет реальный уровень риска осложнений.
И я такого исследования найти не смог. Может, разумеется, плохо искал. Но сразу возникает вопрос — почему на сайте того же ВОЗ достаточно много ссылок на разные исследования, опровергающие связь прививок и склероза, артрита и много уверений в безопасности прививок, а ссылки на подобные исследования на видном месте нет?
Но вообще ваш аргумент нелогичен. То, что я не разбираюсь в медицине, не значит, что я не разбираюсь в статистике.
Есть огромное количеств фактических данных о историях болезней — кто, когда и чем болел. Также можно найти информацию, кто когда и какой именно вакциной прививался. И сделать анализ этих данных (есть корелляция между этими событиями или нет, и если есть — то какая именно) — не очень сложная и дорогая задача. Более того, я ожидал, что легко найду ссылки на сотни таких исследований с нормальным описанием методики (как формировалась выборка и т.п.) и полученных результатах — тема ведь многих волнует. И удивился, когда нашел данные о всего нескольких исследованиях и при этом даже о них нет (или не смог найти) нормального описания методики формирования выборок. И вот тут то и закрались сомнения — а насколько всё то, что нам рассказывают о прививках, имеет научное обоснование? Пусть даже не механизм действия прививок (как именно работает иммунитет, хорошо разобрались ближе к концу 20 века, а прививки массово начали делать в начале 20 века), но хотя бы статистические доказательства их эффективности и безопасности.
Попробуйте сами потратить немного времени и найти исследования по прививкам, которые соответствуют научным критериям. И после этого обсудим. :)
Попробуйте найти описание исследований с контрольными группами, двойным слепым методом и статистически значимым количеством участников. Таких исследований почему-то намного меньше, чем ожидаешь.
Хотя лично у меня главная претензия к вакцинации (а скорее к бизнесу фармкомпаний по производству вакцин) лежит в немного иной области.
Даже самые горячие сторонники вакцинации признают, что как минимум часть вакцин в отдельных (редких) случаях должна давать негативные последствия для здоровья вакцинируемых людей. Предполагается, что это небольшая цена за то, что прекратились эпидемии.
Но попробуйте найти нормальную статистику о таких случаях, с описанием методик сбора данных. У меня не получилось. Но я ладно, к медицине и фармакологии не имею отношения, но и у знакомых, которые работают врачами и фармацевтами — тоже не получилось найти эти данные. И насколько они знают, просто не существует каких то четких инструкций / процедур / стандартов, согласно которым можно (нужно) связывать проблему со здоровьем с применением вакцины (по крайней мере в России и Украине).
Я лично знаю два случая с моими знакомыми, когда у детей существенные проблемы со здоровьем начались в течении нескольких дней после вакцинации. И их мамы однозначно связывают эти проблемы с вакцинацией. Учитывая, что одна из этих мам — фармацевт, а вторая — врач, эти случаи заставляют задуматься о реальном уровне безопасности вакцин. Ведь если вакцинация очень безопасна, маловероятно, что среди лично знакомых людей столкнешься сразу с двумя случаями. И настораживает, что в этих случаях не только никто не признал, что проблемы возникли вследствии вакцинации (действительно, тут может не быть причинно-следственной связи, хотя короткий временной промежуток настораживает), но и не было ВООБЩЕ никакого расследования, есть связь между вакцинацией и заболеванием в этом случае, или нет. То есть ребенок заболел, его начали лечить, но никто не пытался выяснить, а почему именно он заболел и не связано ли это с вакцинацией.
Еще раз уточняю — речь идет о детях врача и фармацевта (с высшим образованием и работающие по специальности), которых лично знаю.
Поэтому фраза «действительные факты очень часто опережаются ложными, но более привлекательно упакованными данными» применительно к вакцинам звучит достаточно двусмысленно. Ведь создавались тысячи разных вакцин (в том числе и с живыми микроорганизмами, которые не могут быть полностью безопасны по определению) и применялись в сотнях миллионов случаев — и при этом относительно мало надежных данных о эффективности и безопасности этих вакцин.
Нет четкой границы между прикладными программистами и пользователями. Любой «продвинутый пользователь» может добавить в той же 1С дополнительный реквизит в шапку документа. Если при этом не надо никак изменять логику проведения документа — всё прекрасно будет работать. Такие задачи на практике встречаются очень часто. И от того, что человек смог добавить дополнительное поле, программистом его называть не совсем корректно.
По моему мнению, именно для бизнес задач не надо ничего изобретать, а надо использовать реляционные БД, которые в основном под эти задачи и создавались. И жесткая структура для бизнес данных является плюсом — иначе будут сложности с анализом. Единственная проблема — «кухарка» не сможет сделать нормальную схему БД (нужны знания по теории БД). Но тут можно в значительной степени решить проблему с помощью библиотеки готовых шаблонов («документ» в конфигурации 1С создает таблички в БД по определенному шаблону) + привлечения нормальных специалистов для рефакторинга базы на более поздних этапах жизненного цикла создаваемого софта, когда структура приложения более менее устоялась.
А в 1С нет доступа к базе по другой причине — они наплодили велосипедов и костылей, и сейчас это всё тяжело поддерживать. Например, у них до сих пор есть своя файловая БД, вот скорее всего из-за неё и не могут сделать нормальный доступ к базе.
Сделал фактически прототип с помощью конструктора и несколько раз переделал его на основании замечаний пользователя. При этом UI корявый, но как-то работает. А когда все согласились, что вот так всё и должно работать — допиливается UI и всё остальное, что надо допилить. И не обязательно только с помощью инструментов конструктора.
Это, разумеется, идеализированная схема, но часто именно такой вариант является оптимальным.
Для новых процессов и нужны конструкторы, которые позволяют с минимальными затратами разработать софт (пусть с не очень удобным UI или немного кривой схемой БД). Главное, чтобы этот софт можно было легко переделывать. Ведь при начале разработки никто не знает, как это должно работать — надо пробовать.
А бизнес модель разработчика конструктора может строиться не на продаже новых копий (их можно отдавать бесплатно), а на сопутствующих услугах.
Например, делается что то вроде фриланс биржи по работе с конструктором, где профи помогают сделать нормальную схему БД, или доработать интерфейс / разработать специфический расчетный модуль, а разработчик конструктора забирает себе процент от оплаты.
Быстро набросал некое приложение, которое сразу и заработало. Потом, по мере необходимости, дописываю различные хотелки, часть из которых делаю с помощью модулей на С# или другом языке, а часть средствами конструктора. И то, что есть возможность дописывать на универсальном языке — сильно греет душу. Всегда в крайнем случае можно пригласить другого специалиста, и он в твоем приложении допишет нужный кусочек. И не волнуешься, что конструктор не поддерживает какую-то фичу, которая понадобится, но о которой сейчас даже не подозреваешь. Стандартные языки программирования тем и хороши, что на них можно реализовать всё, что душе угодно (всё, что может делать машина Тьюринга).
Таких конструкторов надо по максимуму избегать. Создатель конструктора всё равно не сможет втиснуть в конструктор все возможности СУБД или стандартного языка программирования. И отсутствие возможности использовать «низкоуровневые» средства очень дорого обходится в некоторых случаях. А случаи такие случаются намного чаще, чем многие думают. :)))