Когда умирал мой папа от рака, ему диагноз рак в больнице так и не поставили. Кто сказал, что смертность от ковид такая? Надо сравнить смертность от ковид с графиками смертности от рака, заболеваний сердца и гриппа. Ну м.б. добавить статистику смертей в автоавариях. Правда, сомневаюсь, что есть общедоступные данные об этом. А еще лучше, если сравнить данные и в доковидном периоде. Думаю, что приписки смертей от ковид налицо, чтобы объявить пандемию.
Есть небольшое отличие точки зрения автора от моей. Автор рассматривает nexus, как нечто прошлое. Я же рассматриваю его, как будущее. Может быть далекое, но будущее. Потому что вижу дорогу, по которой надо идти. Например, если привязать @@spid к схеме, то получится отличное разделение индивидуального от общественного. Каждый пользователь работает в своей схеме и со своими таблицами detailed etc. Процесс обобществления, конечно, есть. Но, это отдельная тема. Работа выполняется через слой view, которые несут в себе нагрузку метаданных для разных языков "человеков". Я уже не говорю про поисковые возможности класса иерархий без перемещения инфы в таблицах. Конечно, непривычно и на первых порах сложно, но это путь не к учетной системе, а прототипу искусственного интеллекта, который не есть чтото центральное и всеобъемлющее, а компактное. То есть nexus клиент + локальная база, к которой, если надо может подключиться другой клиент. Это путь к автоклассификации объектов с последовательным усложнением их свойств и поведенческих процедур.
В общем да, не волнует. Считаю этот момент коммерческим понятием, типа professional, enterprize, home, office для вытягивания денег с клиента. Смотришь клиент толстый — вот тебе полный пакет.
Когда строишь дом, неважно какого размера, фундамент должен быть. Он, конечно, зависит от веса дома, почвы и пр. Но все это лишь параметры фундамента, а не какая-то фундаментальная характеристика «масштабируемость». Собственно, как и время, которую возвели в ранг чуть ли не измерения, а на самом деле, это всего лишь характеристика движения.
Я както такими вопросами не парюсь. Есть сервер, который куплен априори. Я его могу загрузить и на 30 и на 90 и на все 100%, управляя количеством своих фоновых процессов. Я же пишу программу в конце концов. И только в последнем случае, когда сервер работает со 100% нагрузкой несколько дней подряд, я начинаю анализировать ботлнек. Зачастую, это неверный запрос, или ограничение дискового пространства. Если не нахожу, то эскалирую проблему выше на закупку новой техники. Где тут масштабирование?
Ни во сколько. Процессоры сервера всегда не дорабатывают или просто простаивают. Распараллель (запуск в отдельных фоновых процессах) вот и будет счастье. MIMD рулит в рамках sql.
На данный момент никак. Он написан на С++. На самом деле он тонкий клиент или браузер в рамках базы данных и все хранит на сервере баз данных. Нагрузка сервера БД зависит от запросов и их количества. В чем же экономия, если запросы верные и оптимизированы?
Это основной плюс nexus — он масштабируем. Поддерживать его действительно трудно поскольку в исходном варианте требуется вручную писать sql скрипты и полностью отсутствует работа с метаданными. Первое, что я сделал — это написал класс по генерации простого класса, потом класса посложнее, потом класса по выполнению динамического sql запроса. На самом деле надо писать полноценный конфигуратор, как в 1С. Поддержка — это всегда программист. Например, я — 1С программист. И чем я занимаюсь? По большому счету пишу код, который в конечном счете превращается в sql запрос. И чем мощее этот запрос, тем эффективнее код. Nexus работает с sql кодом только, и других программистов, кроме sql не надо. Вот в чем основная фишка. Все программисты и их технологии тоже, работающие на сервер приложений, в принципе не нужны.
Тонкий клиент 1С целиком и полностью копирует основную идею ultima or nexus резалтсет запроса хранить на сервере. Правда при этом программирование усложняется на порядок так как необходимо обеспечивать разделение программного текста на серверный и клиентский. Кстати через nexus можно совершенно спокойно рассматривать метаданные 1с или любых других mssql систем. У меня был опыт сопровождения биллинговой системы BillOnLine, в которую я внедрил nexus скрипт и тем самым обеспечил альтернативный интерфейс над таблицами системы. В силу того, что зачастую в современных системах база рассматривается как набор таблиц, хранящих данные и не более, а nexus работает с хранимыми процедурами, то на сегодняшний момент nexus — это единственная технология внедрения в любую учетную систему на базе mssql. Это я проделывал с базами DocsVision and 1C. возврат к Nexus обязательно произойдет., имхо.
Нисходящие и восходящие методы программирования обсуждались самыми первыми программистами. Сейчас уже многое написано и хотелось бы, чтобы автор составил некую сводную таблицу по продуктам и какой метод лежал в основе разработок. Тогда было бы понятней, что же всетаки было более эффективней. Например, MSSQL. Какой метод программирования использовался при его разработке? Лично у меня существует метод определения правильности программного кода и его стиля. Если пишешь то, что нужно, то в голове складывается рифма, слова рифмуются и получается почти, я думаю, полноценное стихотворение. Этим и руководствуюсь при программировании уже почти 40 лет.
Когда умирал мой папа от рака, ему диагноз рак в больнице так и не поставили. Кто сказал, что смертность от ковид такая? Надо сравнить смертность от ковид с графиками смертности от рака, заболеваний сердца и гриппа. Ну м.б. добавить статистику смертей в автоавариях. Правда, сомневаюсь, что есть общедоступные данные об этом. А еще лучше, если сравнить данные и в доковидном периоде. Думаю, что приписки смертей от ковид налицо, чтобы объявить пандемию.
Есть небольшое отличие точки зрения автора от моей. Автор рассматривает nexus, как нечто прошлое. Я же рассматриваю его, как будущее. Может быть далекое, но будущее. Потому что вижу дорогу, по которой надо идти. Например, если привязать @@spid к схеме, то получится отличное разделение индивидуального от общественного. Каждый пользователь работает в своей схеме и со своими таблицами detailed etc. Процесс обобществления, конечно, есть. Но, это отдельная тема. Работа выполняется через слой view, которые несут в себе нагрузку метаданных для разных языков "человеков". Я уже не говорю про поисковые возможности класса иерархий без перемещения инфы в таблицах. Конечно, непривычно и на первых порах сложно, но это путь не к учетной системе, а прототипу искусственного интеллекта, который не есть чтото центральное и всеобъемлющее, а компактное. То есть nexus клиент + локальная база, к которой, если надо может подключиться другой клиент. Это путь к автоклассификации объектов с последовательным усложнением их свойств и поведенческих процедур.
Когда строишь дом, неважно какого размера, фундамент должен быть. Он, конечно, зависит от веса дома, почвы и пр. Но все это лишь параметры фундамента, а не какая-то фундаментальная характеристика «масштабируемость». Собственно, как и время, которую возвели в ранг чуть ли не измерения, а на самом деле, это всего лишь характеристика движения.
Это основной плюс nexus — он масштабируем. Поддерживать его действительно трудно поскольку в исходном варианте требуется вручную писать sql скрипты и полностью отсутствует работа с метаданными. Первое, что я сделал — это написал класс по генерации простого класса, потом класса посложнее, потом класса по выполнению динамического sql запроса. На самом деле надо писать полноценный конфигуратор, как в 1С. Поддержка — это всегда программист. Например, я — 1С программист. И чем я занимаюсь? По большому счету пишу код, который в конечном счете превращается в sql запрос. И чем мощее этот запрос, тем эффективнее код. Nexus работает с sql кодом только, и других программистов, кроме sql не надо. Вот в чем основная фишка. Все программисты и их технологии тоже, работающие на сервер приложений, в принципе не нужны.
Тонкий клиент 1С целиком и полностью копирует основную идею ultima or nexus резалтсет запроса хранить на сервере. Правда при этом программирование усложняется на порядок так как необходимо обеспечивать разделение программного текста на серверный и клиентский. Кстати через nexus можно совершенно спокойно рассматривать метаданные 1с или любых других mssql систем. У меня был опыт сопровождения биллинговой системы BillOnLine, в которую я внедрил nexus скрипт и тем самым обеспечил альтернативный интерфейс над таблицами системы. В силу того, что зачастую в современных системах база рассматривается как набор таблиц, хранящих данные и не более, а nexus работает с хранимыми процедурами, то на сегодняшний момент nexus — это единственная технология внедрения в любую учетную систему на базе mssql. Это я проделывал с базами DocsVision and 1C. возврат к Nexus обязательно произойдет., имхо.