Search
Write a publication
Pull to refresh
-14
0
Михаил Исаев @MiIs

Пользователь

Send message

1 С механизмом векторного поиска, который давно уже имеется в ClickHouse сравнивали по скорострельности и удобству?
2 Реализацию действительно серьезных вещей, типа движка таблиц, подобного тому, который используется в Oracle DB (по-простому - без Vacuum) от вас ждать можно, или - это фантастика?

Статья поверхностная в стиле "быстро, модно, молодежно с ИИ" с большим количеством неточностей.

Например, утверждается, что:

Идея создать C# возникла как ответ популярному Java, на который у Microsoft не было лицензии

На самом деле Microsoft выпускала свою версию Java (лучшую на тот момент для ОС Windows) , свою среду разработки на Java - Visual J++, которая рекламировалась как "2 в одном" и замена для приложений уровня Предприятий сред Visual C++ и Visual Basic (и, в общем-то, так оно и было), и свою библиотеку для разработки на языке Java GUI для Windows и не только, включая интеграцию с COM/OLE/ActiveX. Эта библиотека называлась WFC (Windows Foundation Classes) примерно как библиотека MFC (Microsoft Foundation Class Library) для разработки GUI на Visual C++. При этом Java продукты от Microsoft из-за их тесной привязки к операционной системе Windows не проходили тесты совместимости, что требовала лицензия от SUN (изначального разработчика Java), размывая таким образом Java. SUN подала в суд на Microsoft и выиграла суд, который запретил Microsoft использовать Java в интерпретации Microsoft. После этого Microsoft на базе наработок команды Visual J++ создало продукт Visual C#, а библиотека WFC J++ была переработана в библиотеку Windows Forms. Как-то так.

На самом деле "бум" low/no-code платформ продолжается еще с прошлого века. Каждый год появляются новые платформы, которые амбициозно спешат изменить мир ИТ.

Полностью согласен - инструменты RAD (Borland Delphi, Clarion, Ms Visual Basic, Oracle Forms, Sybase Power Builder) появились еще в начале-середине 1990-х годов того века. Кроме того были такие инструменты как "Oracle Designer" - где разработчик определял модель данных (таблицы, связи между ними) и на основе нее автоматически генерировались GUI-формочки для Oracle Forms и отчеты для Oracle Reports (MVP продукт, который можно было дальше самостоятельно доработать напильником). Примерно также мог Sybase PowerDesigner для PowerBuilder. С приходом Web-интерфейсов эта тема почему-то заглохла. Текущий Oracle APEX, который представляют как LOW-Code решение, сильно не дотягивает до своих предшественников - Forms & Designer. Хотя... в последние версии, вроде бы завезли автоматизацию Бизнес-Процессов (пристально не смотрел)

Хранение данных в виде key-value (EAV) безусловно имеет свои преимущества, но также имеет серьезные недостатки (особенно в случае postgresql):пропадает типизация, все значения представляют текст;

Не обязательно все значения в EAV должны быть текстовые. Есть и такой вариант организации таблицы значений объектов (в псевдокоде)

CREATE TABLE OBJECT_ATTRIBUTE_VALUE
(
-- идентификация атрибуат объекта определенного типа
, object_id       INTEGER NOT NULL -- ID объекта (экземпляра объекта)
, object_type_id  INTEGER NOT NULL -- ID типа объекта (класса объекта)
, attribite_id    INTEGER NOT NULL -- ID типа атрибута

  -- значения атрибута в зависимости от типа данных (одно из полей)
, num_value    NUMBER 
, text_value   TEXT
, date_value   DATE
-- ... еще какие-либо типы значений....

-- историчность изменения значения
, time_start   DATETIME NOT NULL DEFAULT CURRENT_DATETIME
, time_end     DATETIME NOT NULL DEFAULT LAST_DATE_TIME_FOR_DB
);

И из этой таблицы извлекать нужные нам атрибуты экземпляров объекта определенного типа, на определенную дату или диапазон.

Но как я и вы выше правильно отметили, что это действо превращается в "одевание трусов через голову" с плохими показателями производительности, и не совсем соответствует принципам Реляционной модели.

Это простой пример (я с 2003 года уже подзабыл все свои решения на эту тему), который конечно же можно улучшить, но это не будет кардинальным улучшением и решением проблемы.

Современные СУБД разрабатывались для реализации Реляционной модели данных. И для этого они хороши. Разрабатывая ERP-решения году так в 2002-2003, я тоде пытался приспособить СУБД под работу с Расширяемыми Объектами, в которых добавление новых атрибутов, изменения поведения Объектов, их визуальное представление и т.д. было бы версионируемым и проводилось бы в один клик на визуальной формочке без написания кода. Но пришел к выводу, что "натягиваю Сову на Глобус" и что для моей идеи надо что-то другое, а не СУБД Реляционной модели. Вы над этим не задумывались?

Вопросы такие:

  1. MWS Tables - это полностью своя разработка МТС или клон(форк) китайской aitable.ai, которую в девичестве звали Викой vika.cn?

  2. Ограничение на 50_000 строк в таблице есть или преодолено? Если преодолено, то каково максимальное количество строк, которые можно вводить в LOW-Code таблицу MWSTables сейчас?

  1. вы можете назвать СУБД где выбор из нескольких соединенных таблиц быстрее чем выбор из одной таблицы с заранее объединенными там данными из других таблиц особенно в распределенной среде с шардами?

  2. Вы ясно понимаете отличия OLAP подхода от OLTP?

В любом случае, это хорошо, что вы открываете для себя что-то новое. Плохо другое - вы свои маленькие открытия и виде очевидных истины считаете необходимым постить на Хабр, где предполагается другой, более профессиональный уровень материала.

Кстати, если все таки по разными причинам вам необходимо будет джойнить справочники или таблицы, которые можно привести к таковым, к основной таблице (например, фактов), то почитайте про Dictionary - тоже помогает увеличить скорость

Ну и самое основное в производительности CH - это конечно же правильный выбор столбцов, попадающих в первичные ключи или предложение ORDER BY. А все остальные способы увеличения производительности в CH больше про удобство.

Известно, что для Airflow нет официального провайдера для ClickHouse. Вы что использовали на стороне Airflow для взаимодействия с кликом - BashOperator, драйвер от ClickHouse, неофициальный PlugIn, связку с JDBC или еще что-то и были ли при этом какие-то проблемы?

Две чашки хорошего кофе этому человеку, который расшифровал то, что я хотел сказать.

Хотя язык VBA и не является полноценным объектно-ориентированным,

Вообще-то является. Есть возможность создавать классы - Class Module, в них определять Функции (Function), Процедуры(Sub), Свойства (Property Get, Set, Let), переменные класса, и даже события (Events) и потом использовать это в своем коде.

Особенностью использования VBA в Microsoft Office является то, что макросы не могут использоваться отдельно, вне документов.

При небольшой доработке могут - это называется VBScript, который имеет еще дополнительные объекты по сравнению с VBA вроде словаря, регулярок и т.д. VBScript-у для выполнения скриптов под Ms Office конечное же нужен будет установленный Ms Office на компе.

Поставить в Windows 7 Virtual Box, создать в нем виртуальную машину Debian 12 и поставить туда Node.js нужной версии (и даже несколько версий) с помощью современных пакетных менеджеров, а также Visual Studio Code последней версии (а не как в Windows 7, где крайняя версия 1.78.2) для разработки на JavaScript и Python заняло бы куда меньше времени. 2 Гб ОЗУ для виртуалки вполне хватает для простой разработки. На диске такая виртуалка занимает место меньше 10 Гб . Отклик от GUI виртуалки комфортен - старый i3 с 2-мя ядрами для виртуалки справляется нормально для комфортной работой. И нет проблем с надежностью собранного "поделия". А так, конечно можно и на Windows XP что-нить из современного пересобрать. Но "стоит ли овчинка выделки?" - вот в чем вопрос.

Нормальная статья с учетом отсутствия достаточной документации на русском языке. Офтоп: PostgresPro тоже запили свой Shardman - там документация должна быть русской. Но к чему ближе Shardman к GreenPlum или Oracle RAC пока не читал.

В следующий раз сделайте лицом вашей осенней рекламной "Осенней компании" Петра Дуброва - он не только Герой России, но и реальный IT-шник до прихода в отряд Космонавтов.

Так вы пишите в стиле "как было изначально задумано (Oracle-ом)", а не в стиле "стильно, модно, молодежно (по новому стандарту SQL)", так у вас все будет нормально:

with t as (select -2 as num_years from dual)
select add_months(to_date('20240229','YYYYMMDD'), num_years * 12) d from t

Это отработало даже на моей настольной Oracle 11.2 XE и выдало правильный результат

ПС. наверное косяк Oracle для относительно нового механизма работ с датами.

Насколько есть смысл изучать Джулию?

Изучать, чтобы изучать - наверное, это неумно. Для каких целей изучать? - это самый главный вопрос.

Julia позиционируется Процедурный и Объектно-Ориентированный язык с соответствующим синтаксисом для числовых и научных вычислений, который может работать намного быстрее Python. Глубоко под капотом у языка Julia находится Lisp-машина.

Есть плюсы, но и есть некоторые косяки как в самой реализации языка, так и в библиотеках, качество которых, считается, хуже чем в библиотеках для языков Python и R.

Посмотрите на кол-во вакансий в вашем местоположении и думайте - изучать или не изучать. Изучать, только если вы не научный работник, наверное, не стоит, а посмотреть можно, также, как впрочем, и языке Mojo, который тоже позиционируются как "намного быстрее Python", при этом с синтаксисом, похожим, но не одинаковым с Python.

Но всегда можно не "изучать", а "посмотреть" - это нетрудно для людей, которые знают другие Языки программирования, особенно если это С/C++ (хотя и другие тоже подойдут).

Сейчас, в общем случае, ориентируясь на кол-во вакансий и величину заработной платы, изучать стоит C/C++(после их изучения приходит понимание как работают все остальные языки программирования), SQL, Python, Java, Go, JavaScript/TypeScript, HTML/CSS.

Изучать/посмотреть R - если вы занимаетесь статистикой или около областями, типа эконометрии, биостатистики и т.д. - хотя Python и C++ закроют и это направление (мало вакансий по R и область узка).

Изучать/посмотреть Rust - как замену C/C++, Go, Fortran. (мало вакансий)

Не буду гадать за автора статьи и Johan_Palych зачем им Oracle 23C. Потому что совершенно ясно, что Oracle DB в России в дальнейшем не будет, по крайнй мере в государственном и банковском секторах (да и в других тоже). Причин две: 1. Прекращение поддержки российских пользователей фирмой Otacle после февраля 2022 года. 2. Странная и сильно жадная политика ценообразования Oracle на свои продукты ранее и сильно большой гонор и мвлый выхлоп от так называемой "поддердки". То есть переход с Oracle DB на что-то другой начался задолго до 2022 года. В 2022 году этот переход просто стал бесповоротным.

Последняя промышленная версия Oracle 19C. После этого переход на другие DB. Поэтому необходимость в Oracle 23C действительно либо академическая, либо работа на иностранного заказчика через несколько фирм-прослоек. И, возможно, если кто не в курсе, то еще с марта 2023 года для Virtual Box есть виртуалка с "разработческой" версией Oracle DB 23c - https://www.oracle.com/database/technologies/databaseappdev-vm.html, которую можно скачать абсолютно спокойно, в том числе и из России.

С другой стороны сильно порадовал богатый DDL и DML синтаксис. У любого CREATE INDEX и ADD COLUMN есть опция IF NOT EXISTS. Это после Oracle, где для безопасного создания индекса, надо писать солидный блок кода

  1. В Oracle DB 23c "IF NOT EXISTS" уже тоже имеется: https://docs.oracle.com/en/database/oracle/oracle-database/23/sqlrf/CREATE-TABLE.html#GUID-F9CE0CC3-13AE-4744-A43C-EAC7A71AAAB6

  2. В более ранних версиях Oracle для удобства в PL/SQL пакете Один раз писались соответствующие процедуры и дальше пользовались всегда. Типа,

PROCEDURE CREATE_TABLE_IF_NOT_EXISTS (p_owner IN STRING, p_table_name IN STRING. p_table_definition IN STRING) ...

  1. Oralce был и остается на данный момент лучшей реляционной базой данных в мире. Однако политика правительства США ведет нас к тому, что рано или поздно придется от него отказаться. Но лично я не особо вижу переходить с Oracle на что-то другое в авральном режиме, где на этой базе уже есть работающие продукты или решения. "Легитимные" для России версии Oracle 19C и даже 21С могут проработать еще лет 10 а то и больше, не особо устаревая. Главное, чтобы железо под них было подходящее. Как там, правило программистов "Не трогай работающую систему". Ну а все новые проекты, конечно же надо начинать на чем-то другом.

Если бы вы были немного любознательнее, а также менее категоричны, то вы, наверное, знали бы, что язык C# не мог никак появиться раньше языка Java. Почему? Ну хотя бы потому, что язык C# появился как развитие идей продукта Visual J++ и библиотеки WFC после того, как Microsoft проиграла суд за чистоту реализации виртуальной машины Java фирме SUN. ссылка

Еще ранее, вроде бы даже на LOR, я уже указывал вам на недостатки фреймворка - 1. Страшненький UI (который непонятно как развивать и расширять) 2. JVM. 3. Отсутствие "крупных" ERP-приложений на фремворке. По п. 1 все как было плохо, так и осталось. По п. 2 трудно заменить, но JVM, Oracle как-то не совсем вяжутся с такими понятиями как "современное", "Россия" и "open source" (потому что разработка JVM контролируется Oracle, кто бы что ни говорил - а это риск и большой риск в России) По п. 3 вроде бы какие-то работы велись, но ничем значительным это не окончилось. Что-то вроде 1С Бухгалтерия не появилось. Хотя начиналось всё очень неплохо - на Хабре были очень завлекательные статьи, рекламирующие фремворк. Но вот практическая реализация подкачала. Удачи вам. Вы молодцы - не ошибается тот, кто ничего не делает.

Как и среди кого автор решил проводить нижеследующий опрос?

А вы используете R в своей работе? Следите за выходом новых пакетов?

Статья про R, но почему-то у ней нет даже тега [R] , хотя для языка R на хабре имеется отдельный хаб - https://habr.com/ru/hub/r/ .

Information

Rating
6,480-th
Location
Россия
Registered
Activity