データベースと関数型プログラミングは相反するものですか? 質問する

データベースと関数型プログラミングは相反するものですか? 質問する

私はこれまで長い間 Web 開発者として活動してきましたが、最近になって関数型プログラミングを学び始めました。他の人たちと同様、これらの概念の多くを仕事に応用するのにかなり苦労しました。私にとって、その主な理由は、ステートレスを維持するという FP の目標が、私がこれまで行ってきた Web 開発作業のほとんどが、非常にデータ中心であるデータベースに大きく結びついているという事実とかなり矛盾しているように思えたからです。

私が OOP の面ではるかに生産性の高い開発者になった理由の 1 つは、.Net の MyGeneration d00dads、perl の Class::DBI、ruby の ActiveRecord などのオブジェクト リレーショナル マッパーを発見したことです。これにより、挿入ステートメントや選択ステートメントを一日中記述する必要がなくなり、データをオブジェクトとして簡単に操作することに集中できるようになりました。もちろん、SQL クエリのパワーが必要なときには記述することもできましたが、それ以外は舞台裏でうまく抽象化されていました。

さて、関数型プログラミングに目を向けると、Linksのような多くの関数型Webフレームワークでは、次のような定型SQLコードを大量に記述する必要があるようです。この例. Weblocksの方が少し優れているようですが、データの処理には一種のOOPモデルを使用しているようで、データベース内の各テーブルごとに手動でコードを記述する必要があります。この例これらのマッピング関数を記述するには何らかのコード生成を使用すると思いますが、それは明らかに Lisp らしくないようです。

(注: 私は Weblocks や Links を詳しく調べたわけではないので、その使い方を誤解しているだけかもしれません。)

そこで疑問なのは、Web アプリケーションや SQL データベースとのインターフェースを必要とするその他の開発におけるデータベース アクセス部分 (かなり大きいと思われます) については、次のいずれかの道を進むしかないように思われるということです。

  1. 関数型プログラミングを使用しないでください。
  2. 煩わしく抽象化されていない方法でデータにアクセスします。この方法では、大量の SQL または Links のような SQL のようなコードを手動で記述する必要があります。
  3. 関数型言語を擬似 OOP パラダイムに強制すると、真の関数型プログラミングの優雅さと安定性の一部が失われます。

明らかに、これらのオプションはどれも理想的ではないようです。これらの問題を回避する方法を見つけた人はいますか? 本当に問題があるのでしょうか?

注: 私は個人的に FP の分野では LISP に最も精通しているので、例を挙げたい場合や複数の FP 言語を知っている場合は、おそらく LISP が推奨される言語になるでしょう。

PS: Web開発の他の側面に関する問題については、この質問

ベストアンサー1

データベース担当者の視点から見ると、フロントエンド開発者は、オブジェクト指向や関数型ではなく、リレーショナルで集合論を使用するデータベースを最も効果的に使用する方法を考えるのではなく、データベースを自分のモデルに適合させる方法を見つけることに熱中しすぎているように思います。これは通常、パフォーマンスの低いコードにつながります。さらに、パフォーマンスの調整が難しいコードも作成されます。

データベース アクセスを検討する場合、データの整合性 (すべてのビジネス ルールをユーザー インターフェイスではなくデータベース レベルで適用する必要がある理由)、パフォーマンス、セキュリティという 3 つの主な考慮事項があります。SQL は、特にそのように設計されているため、どのフロントエンド言語よりも効率的に最初の 2 つの考慮事項を管理するように記述されています。データベースのタスクは、ユーザー インターフェイスのタスクとは大きく異なります。タスクを管理するのに最も効果的なコードの種類が概念的に異なるのは当然のことでしょうか。

また、データベースには、企業の存続に不可欠な情報が保存されています。企業が存続の危機に瀕しているときに、新しい方法を試そうとしないのは当然のことではないでしょうか。実際、多くの企業は、既存のデータベースを新しいバージョンにアップグレードすることさえ望んでいません。つまり、データベース設計には本来の保守性があり、それは意図的に行われているのです。

私は T-SQL を記述したり、データベース設計概念を使用してユーザー インターフェイスを作成しようとはしません。では、なぜあなたはインターフェイス言語と設計概念を使用して私のデータベースにアクセスしようとするのでしょうか。SQL が十分に洗練されていない (または新しい) と考えているからでしょうか。それとも、SQL に慣れていないからでしょうか。何かが、最も慣れているモデルに適合しないからといって、それが悪い、または間違っているというわけではありません。それは、それが異なっており、おそらく正当な理由で異なっていることを意味します。異なるタスクには異なるツールを使用します。

おすすめ記事