どのような種類のコードが低いと見なされますか？
ローコードという言葉は過去2年間で活気づき、これを行うために多数の起業家チームが出現しました。以前はコードの長さしか知りませんでしたが、今ではコードのレベルがわかりました。
いわゆるローコードは、直感的に言えば、コードを書きやすくすることです。同じタスクを完了すると、コードの量（ワークロードとして理解できます）が少なくなります。さらに、開発者の要件が十分に低いことを示すもう1つの重要な指標があります。また、コスト削減の目的を達成することも困難です。短く書くと効率が上がります。
明らかに、ローコードについて話すときは、最初にコードを用意して、このコードが他のコードよりも少し低いかどうかを確認する必要があります。
ただし、現在、ローコードを必要とする多くのいわゆる開発プラットフォームには独自のコードがありませんが、いくつかのフレームワークとテンプレートが作成されており、開発者はテンプレートに入力してアプリケーションシステムを構築します。単純なニーズに対応することは問題なく、それでも使いやすいですが、ビジネスがコードを使用して処理するほど複雑な場合でも、Java / C＃コードを使用する必要があります。
ローコードは、フレームワークではなく、コードが少ないです。コードのないテンプレートは確かにいくつかの問題を解決できますが、コードを使用して実行する必要のあるビジネスはまだ多すぎます。コードのレベルは確かに開発効率と密接に関連しています。
では、どのような種類のコードがローコードとしてカウントされますか？
ローコードは主に情報システム（広義にはMISと呼ばれます）向けに開発されています。このアプリケーションだけがさまざまなニーズを持ち、それぞれが異なり、完成することはないからです。
情報システムの主なタスクは、実際にはデータに関する3つのことです。入力入力、プロセスプロセス、および出力出力です。これらは一緒になってIPOになります。IOは、成熟したレポートツールとインターフェイスコントロールによって解決できるようになったため、問題は残り、開発プロセスで記述されるビジネスロジックのほとんどはこの種のものです。
このようにして、コードが十分に低いかどうかを判断し、このコードがデータを処理するのに便利かどうかを確認します。
どんなデータ？
主に構造化されたデータ、つまりリレーショナルデータベースに存在する種類のデータ。これは、情報システムで最も一般的な種類のデータです。他の非構造化データには、特別で固定された処理要件しかないか、構造化データを変換または抽出するだけで柔軟な処理要件があります。
問題は、構造化データを処理するのにどのようなコードが適しているかということです。
この基準の下では、Javaは確かに低くはなく、まともな構造化データオブジェクトを持っていません。新しいバージョンのJavaには、Streamなどのコレクションクラスライブラリがあり、Lambda構文のサポートを開始しましたが、これは非常に一般的なデータオブジェクトにのみ使用でき（これはJava自体の目的によって決定されます）、作成するのは依然として面倒です。構造化データを処理する場合。さらに、Javaはコンパイル型言語であり、動的にすることは本質的に困難です。また、Javaは強力なオブジェクト指向言語であり、オブジェクト指向の概念を深く理解することは容易ではありません。Javaアプリケーションを開発する場合、複雑なエンジニアリング環境を確立する必要があります。これらは開発者にとって低いしきい値ではありません。
C＃に似ています。
SQLはある程度低いです。多くの非専門家はSQLを使用してクエリを作成できます。SQLを作成する場合、データとビジネス自体を理解している限り、アプリケーションアーキテクチャについてあまり気にする必要はありません。これは、開発者が持っていなければならない知識でもあります。
ただし、SQLには2つの欠陥があります。順序付き計算と手続き型ロジックです。これにより、少し複雑な処理が非常に面倒になり、Nレベルのネストされた文法が数百行も書き込まれることが多く、数か月後には理解できなくなります。SQLもデバッグが特に難しく、開発コストがさらに上昇します。
代わりにストアドプロシージャを使用する場合は、手続き型操作を実装できますが、これはJavaに切り替えるようなものです。ストアドプロシージャはSQLで記述されていますが、有用な構造化データオブジェクト（一時テーブルでのみ処理可能）やセット操作もありません。多くの場合、Javaを使用してSQLに動作するように命令する方が適切です（多くのアプリケーションはで記述されています）。 Java + SQL）。of）。さらに、ストアドプロシージャを使用すると、アプリケーションアーキテクチャの問題も発生します。
SQLの「低」は、比較的単純なシナリオにのみ適しています。ビジネスニーズがより複雑になるにつれて、その複雑さは指数関数的に増加します。
Pythonの方が少し優れています。パンダには、構造化データオブジェクトとしてカウントできるデータフレームがあります。しかし、アプリケーション全体がPythonで書かれていない限り、Pythonの統合は比較的貧弱です。これはまれです。さらに、データフレームは中途半端なものとしか見なすことができません。これは本質的に行列であり、従来の意味でのデータテーブルではありません。多くの操作は非常に混乱します。さらに、パンダはサードパーティのパッケージであり、そのアプリケーション環境はそれほど単純ではなく、デバッグは依然として面倒です。
Scalaもオプションであり、構造化されたデータ処理を処理できるデータフレームもありますが、あまり専門的ではありません。Scalaコード自体は比較的低いですが、オブジェクト指向のものの理解のしきい値はまったく低くはなく、複雑なエンジニアリング環境にも直面しています。
SPLはローコードです
それでは、そのコードは十分に低いのではないでしょうか。
まだいくつかあります。オープンソースのesProcのSPLはローコードであり、現在はそれだけである可能性が非常に高いです。
これが実際にSPLが発明された理由です。レポートツールとして実行すると、当然、多くの複雑な操作が必要になりますが、これらの操作をSQLやJavaで作成するのは困難であり、既存のシステムでは解決できません。N年間粉砕した後、私はこれらの問題を解決するための言語、つまりSPLを発明しました。
SPLには完全な構造化データオブジェクトがあり、大小のデータを処理できます。少量のオブジェクト指向構文を使用しますが、難解なオブジェクト指向の概念を使用せず、データ処理と操作に重点を置いています。プログラムロジックは初期のBASIC言語に少し似ており、基本的なブランチ、ループ、およびサブルーチンがあり、理解しやすいものです。また、構造化データと豊富なライブラリ関数に基づくコレクションタイプを提供し、特に複雑なコレクションと順序付けられた操作のサポートに優れているため、コードの記述がはるかに簡単になります。
話は安いです、コードを見せましょう
。SPLコードはグリッドに記述されており、グリッドを変数名として直接使用でき（Excelユーザーはとても親切です）、ステップバイステップの操作を自然にサポートし、グリッドのインデントは明確に反映できますコードのレベル、そしてそれはまた提供します完璧なデバッグ機能があります。
豊富なライブラリ機能、一般的な基本操作を1行で実行できます。
SPLでは、SQLを直接使用することもできます（データベースの依存関係はありません）。
$select * from d:/Orders.csv where (OrderDate<date('2020-01-01') and Amount<=100)or
(OrderDate>=date('2020-12-31') and Amount>100)
$select year(OrderDate),Client ,sum(Amount),count(1) from d:/Orders.csv
group by year(OrderDate),Client
having sum(Amount)<=100
$select o.OrderId,o.Client,e.Name e.Dept from d:/Orders.csv o
join d:/Employees.csv e on o.SellerId=e.Eid
$with t as (select Client ,sum(amount) s from d:/Orders.csv group by Client)
select t.Client, t.s, ct.Name, ct.address from t
left join ClientTable ct on t.Client=ct.Client
SPL自体には、Javaと同様のプロセス制御機能があります。このように、データベースの有無に関係なく、SPLはJava+SQLの効果を発揮できます。
他のコードと比較します。たとえば、在庫が継続的に上昇した日数を計算します。
SQLは次のように記述されています。
select max(consecutive_days)
from (select count(*) consecutive_days
from (select sum(updown_flag) over(order by sdate) no_up_days
from (select sDate,
case when price>LAG(price) over(order by sDate)
then 0 else 1 end updown_flag
from share))
group by no_up_days)
このコードは少し理解しにくいです。それがどのように機能するかを考えるための演習として残してください。
Pythonはこれを書きます：
import pandas as pd
aapl = pd.read_excel(‘d:/AAPL.xlsx’)
continue_inc_days=0;
max_continue_inc_days=0
for i in aapl['price'].shift(0)>aapl[‘price’].shift(1):
continue_inc_days =0 if i==False else continue_inc_days+1
max_continue_inc_days = continue_inc_days if max_continue_inc_days < continue_inc_days else max_continue_inc_days
print(max_continue_inc_days)
このロジックは複雑ではありませんが、書くのはそれほど簡単ではありません。
Javaに関しては、私はそれを試さないでしょう、誰もが自分の決心をします。
同じ操作で、SPLは次のように書き出します。
| A | |
|---|---|
| 1 | = T（“ d：/AAPL.xlsx”） |
| 2 | = a = 0、A1.max（a = if（price> price [-1]、a + 1,0）） |
SPLには強力なLambda構文スタイルの集合関数が多数あり、他の言語のループによってのみ達成できる多くのタスクはSPLの単一のステートメントであるため、このコードにはループステートメントはありません。
SPLは、SQLの欠陥を解決し、JavaとSQLの共通の利点を組み合わせています。SPLはビッグデータ操作とマルチスレッド並列処理も簡単にサポートでき、Pythonはこの状況で簡単に盲目になります。興味のある学生は、STEM Academyにアクセスして、SPLコードの例をさらに見ることができます。
ローコードだけではありません
SPLは完全なデータソースサポートを提供し、聞いたことがある、または聞いたことのないほとんどすべてのデータソースがサポートできます。
これにより、インターフェイスとデータ変換の多くの作業負荷が軽減されます。
SPLはJavaで実装され、Javaアプリケーションにシームレスに埋め込むことができるJDBCドライバーを提供します。
…
Class.forName("com.esproc.jdbc.InternalDriver");
Connection conn =DriverManager.getConnection("jdbc:esproc:local://");
Statement st = connection.();
CallableStatement st = conn.prepareCall("{call xxxx(?, ?)}");
st.setObject(1, 3000);
st.setObject(2, 5000);
ResultSet result=st.execute();
このようにして、SPLをアプリケーションフレームワークに簡単に統合できます。ほとんどの開発者は、ビジネスロジックとデータ構造だけを気にする必要があり、複雑なアプリケーションアーキテクチャを理解する必要さえありません。
特に、コードのない「ローコードプラットフォーム」の場合、オープンソースSPLを統合した後、実際のローコードがあり、テンプレートとコードは互いに補完し合っています。これは完全なローコードプラットフォームです。
SPLは、解釈と実行のための動的言語でもあり、作成されたスクリプトはメインアプリケーションの外部に配置できます。これは、一方で、スクリプトとメインアプリケーション間の結合を減らし、ホットスワップの利点ももたらします。結局のところ、ビジネスロジック（特にクエリレポートクラス）は頻繁に変更されます。要件が変更された後、スクリプトが書き直されている限り、スクリプトはすぐに有効になり、アプリケーションを再起動する必要はありません。Javaコードを使用する場合は、...（これは、Javaコードがまったく低くないことも示しています）。
SPLダウンロードアドレス：http
：//c.raqsoft.com.cn/article/1595816810031 SPLオープンソースアドレス：https ：//github.com/SPLWare/esProc