データベースはモナドとして見られるべきですか？
永続性の更新/挿入/削除は、ある意味データベースの状態変化の一種であるため、データベースをモナドと見なすことができるかどうか疑問に思います。関数型プログラミングにおけるモナドについても同じことが言えます。
このような思考プロセスを備えたシステムを設計しているときに、何が得られるか、何が失われる可能性がありますか？
あんまり。
データベースは、データの構造化および整理された保管と検索のための機能です。モナドは、機能的な純粋さを維持する方法でそのデータベースと通信する方法です。
モナドを、関数型プログラミング言語の純粋で不変の数学的世界からのコンバーターと考えてください。不純で変化しやすいI/Oの世界へ。変更可能な副作用はモナドの背後に隔離されているので、モナドの反対側の完全で不変の世界にまだ住んでいるように "偽装"できます。
しかし、結局のところ、それはまだモナドにすぎません。そのモナドの変更可能な側には、データベース、コンソール、Elizaを実行している別のコンピュータなど、何でもかまいません。
データベースは、関数型プログラミングでモナドとしてモデル化されることがよくあります。 HaskellDb 、 Quill 、 Slick 、および Doobie は、私が知っているいくつかの例です。データベース自体とデータベースへのプログラミングインターフェイスには違いがあると主張できます。これがこの文脈で有用な区別であるかどうかはわかりません。
より正確には、データベースの操作tableは、モナド。そのため、return関数は、いくつかのテーブル表現（レコードやクラスなど）を内部クエリ形式にラップします。これは、さらに変換（recordをQuery recordに変換するなど）に使用できます）。 bind関数（Haskellでは>>=と呼ばれます）は、指定された関数を使用して、ラップされたクエリアクションを変換します。たとえば、WHERE句をクエリに追加します。
ほとんどのコレクション型もモナドであるため、データベーステーブルを通常のコレクションのように扱うことができます。他のモナドと同じ簡略化を使用できます。Control.Monadライブラリー、表記法、内包表記、構成などです。クエリの構造は型チェックされます。 Quillのようにマクロをミックスに追加すると、コンパイル時にSQLを生成できます。これは非常に便利な抽象化です。
通常、モナドはある種の計算方法を表します。たとえば、Maybeは、計算の失敗を可能にするモナドです。 []は、複数の結果を許可する計算です。 IOは、曖昧なRealWorldとの通信を可能にするモナドです。
データベースは実際にはそうではありません。 State DataBase、これは1つの可変変数（つまり、DataBase）を使用した計算になりますが、データベース自体はおそらくモナドとは見なされません。
検索returnおよび>>=。すべてのモナドにはこれらが必要です。データベースはそれらを持っていますか？