ORMによるデータベース抽象化を使用する利点は何ですか？[閉まっている]

選択したフレームワークで推奨されているORMを使用し始めています。ORMが提供する抽象化の追加レイヤーのアイデアは気に入っていますが、これが本当に何を意味するのか理解し始めています。これは、データベース（mysql）を使用しなくなったため、mysql固有の機能が存在しなくなったためにウィンドウの外に出てしまったことを意味します。

ORMの考えは、データベースをすべて非依存にすることで、私を助けようとしているということです。これはすばらしいように聞こえますが、多くの場合、特定のデータベースシステムを選択する理由があります。しかし、データベースにとらわれないルートをたどることにより、ORMは最小公約数を取ります。つまり、最小の機能セット（すべてのデータベースでサポートされる機能）になります。

長期にわたって基礎となるデータベースを切り替えないことを知っている場合はどうなりますか？データベース固有の機能にもアクセスしてみませんか？

同じように見えます。必要なときにその下に入れない抽象化は悪です。コード内のあらゆる種類のabstractい抽象化の反転につながるからです。

職場では、かなりうまく機能する自家製のORMがありますが、その機能が明示的に提供しないものが必要な場合には、文字列を取得し、それを生成するクエリに直接ドロップするメソッドがあります必要なときに生のSQLを使用する場合。

IMOこの機能を持たないORMは、コンパイル元のビットに値しません。

ORMは最小公分母を取ります

私はあなたの声明に反対しなければなりません。例としてnHibernateを取り上げます。このフレームワークは、ほとんどのORMと同様に、バージョン（およびサポートされている機能）に関係なく、最も人気のあるものを含む多くのデータベースをサポートします。

クイックノート：データベースの抽象化についてのみ言及します。これは多くの利点の1つですが、オブジェクト指向機能のほうが強力だと思います（例：継承）。そしてYou design your domain model first...

...抽象に戻ります。最小公分母ではありません。でNHibernateは、あなたは方言を持っています。同じコードを使用して、異なるデータベースを照会できます。方言が機能管理を行います。正しいステートメントはそれa given dialect will try to use all the power of a given database systemです。

例として、SqlServer2005導入されたときに新しいSQL Server 2005ページング機能を利用していた方言を取り上げます。SqlServer2000パフォーマンスを向上させるだけでなく、その方言を使用しました。

もちろん例外もありますが、nHibernateを使用して長年作業したことのあるものは1つもありませんでした。私のアプリケーションは非常にデータ中心です。

アイデアはきちんとしているが、私はORMツールを使用するポイントに移動したことがない。SQLを自分で記述する（または使用するストレージを処理する）ことは問題ではありませんでした。しかし、私は製品寿命の長い少数のプロジェクトに取り組む余裕があるので、手作業でコーディングされたSQLおよびDB操作が適切に行われると、その場所に配置されます。さらに、プロセスをORMツールの考え方に合わせる必要なく、必要なSQLクエリを直接処理できることは明らかです。

だから、私はあなたが1に飛び込む前に質問があるべきだと思う：

あなたは、実際にそれらを使用してから何かを得ますか？つまり、ORMツールを実装して使用する価値があり、システムにさらに複雑なものを追加する価値があるようにすることで、十分な労力を節約していますか？（これは特に、その余分な「ピース」が潜在的なサポート問題の余分なベクトルである商用アプリに当てはまります）

そして、追加の抽象化レイヤーはアプリに悪影響を及ぼしますか？手動でコーディングされたSQLなどよりも遅くなりますか？

O / RMは定期的に批判されています。テッド・ニューアードは数年前にそれを「コンピューター科学のベトナム」と呼んだ。O / RM

順調にスタートし、時間が経つにつれてより複雑になり、やがて明確な境界点、明確な勝利条件、明確な出口戦略を持たないコミットメントにユーザーを閉じ込めます。

独自のアドホックマッピング（他の人が既に述べたように、多くの場合、これは良い解決策です）を独自に作成しない限り、非リレーショナルデータベースを使用するなどの代替手段を検討できます。真のオブジェクトデータベースの方が良いと言う人もいます。この文脈で言及されている他の流行語はLINQ、Ruby、チュートリアルDです。真のリレーショナルデータベースとは対照的に、真のオブジェクトデータベースがあると思います。しかし、実際には、概念データモデリング-つまり、データを保存する現実世界のオブジェクト、およびこれらのオブジェクトが相互にどのように関連しているかを調べることが、概念モデルを表現する方法をいじるよりも重要であることがわかりましたプログラミングまたはデータベース言語。

代替手段は何ですか？

これは興味深い概念です。基礎となるデータベースの機能を抽象化することにより、特定のデータベース実装の機能の一部が確実に失われます。（特定のデータベース機能に依存すべきかどうかは別の議論です）これは特定の機能にアクセスできるデータベース固有のORMによって解決できると思いますが、それは価値があるだけでなく、間違った方向。

一日の終わりに、あなたは自問する必要があります- 代替案は何ですか？

ORMの使用を停止して、すべてのデータベースアクセスの記述に戻る必要がありますか？確かに、ORMを介していくつかのデータベース機能にアクセスできなくなる可能性がありますが、旧式の手法を使用していつでもアクセスできます。最終的に、生産性の向上は、欠点を完全に上回ります。

ORMは基本的に「ストアドプロシージャ」に相当します。そこで、用語を作り出しました。

ORMが行うすべてのことを、ビュー、トリガー、ストアドプロシージャを使用して複製できます。生のSQLを抽象化するのに役立ち、正規化されたデータベースの一貫性を保つことができます。ただし、単純な場合にのみ有効です。Machデータが多すぎて処理できない場合、それらはパフォーマンスの低下になります。（PHPのORMは、SQLビルダーチェーンがすべてを抽象化できないため、多くの場合、スクリプト側のデータを使用します。）

しかし、いつものように、それはすべて手元のアプリケーションとタスクに依存します。

ORMを使用して痛いのは、多くのファンが、SQLおよびRDBの理論を知る必要がなくなったと主張する傾向があることです。結果はおかしいものから完全に壊滅的なものまでさまざまです。これは、ORM が適切に使用および構成するためにSQLおよびRDB理論を十分に理解する必要があるとORMが製造および評論家が主張している100万回にも関わらずです。

すべてのコンテキストではなく、多くのコンテキストで使用されるツールを人々が魔法のような普遍的に適用可能な銀の弾丸に取り入れる理由は、私を超えています。

昨年、頻繁に変更される社内アプリを作成しましたが、ORMを使用して非常に満足しています。このアプリは変更管理チームをサポートするアプリであり、より大きなプロジェクトが発展するにつれて、私たちの小さなアプリは存在せず、数か月前には予測できなかった状況に対する新しい要件を獲得しました。

ORM（PHPのPropel）のおかげで、コードのロジックの一部を分割したため、1つの関数がクエリの「レコード有効」部分を追加し、別の関数がセキュリティ部分（「ユーザーがこれらの機能がある」）、...基礎となる構造が変更された場合（「レコードの有効性」を考慮すべき追加フィールド）、20個のSQL節ではなく、1つの関数のみを変更する必要がありました。

私たちは、すべての（ほとんどの）SQL句が別のXMLファイルに格納されているため、「データベースの変更は簡単に処理できる」という状況から生まれました。私を信じて、彼らはそうではなかった。1つは非常に恐ろしいので、私はそれをThe Daily WTFに提出しなければなりませんでした。

クエリが複雑すぎてPropel Criteriaで表現できない場合、またはベンダー固有の機能（MySQLを使用しているため、ほとんどが全文検索）が必要な場合、これはPropelでは問題ありませんでした。カスタム基準を追加するか、本当に必要なときに生のSQLを使用できます（実際のPropelオブジェクトとの結合がさらに簡単になりました）。生成されたクラスにベンダー固有のアドオンを簡単に追加できるため、アプリコードにSQLはなく、データベースエンジンのすべての機能を備えた、両方の長所を活用できます。

しかし、ポイントは、データベースから離れてプログラムできるようになることです。つまり、データベースにいるように考える必要はありません。

私は今C＃で働いており、LINQをたくさん使っているので、流andな方法がたくさんあります。オブジェクトがどのように保存または検索され、さらにはプログラムレベルで保存されるかを考える必要はなく、ビジネスレイヤーレベルではほとんどありません。

特定のデータベース自体が提供するメソッドは、多くの場合DBコネクターで使用されるため、それらが何であるかを知る必要なく最適化を実現できます。

DB側で関数を作成できます。多くの場合、単にそれらをマップすることができます。

そして何よりも、そのような分離はテスト容易性を可能にし、（少し）より良い構造化コードを書くことを強制します

オームズはできますが、データベースの特定へのアクセス権を与えるだけでなく、それはあなたが使用してどのような機能が提供するしているORMいるに依存していただけます。

たとえば、現在取り組んでいるプロジェクトでは、Java Persistence APIとHibernateを使用しています。それでも、soundexを使用してテーブルを検索するなど、データベース固有の機能をいくつか使用します。

私にとって、ORMを使用する主な利点は、必ずしもアプリケーションデータベースを非依存にすることではありません（それは良いことですが）取得しました。

ただし、アプリケーションの要件に応じて、とにかくこの点について考えなければならない場合がほとんどです。ORMは魔法ではありません。

簡単に選択と挿入を行うのに役立つ独自のプログラムを作成しました。

Evey db固有のものが利用可能です。ライブラリが支援するクエリを自分で記述する必要があります（手動でパラメータに名前を付けて.Addを使用する代わりに、「？」とparamsを使用できます）

私の半分は有用な半分を吸うと思います。ORMの世界で助けを得て、クエリの世界で重要な役割を果たします。

インラインまたはストアドプロシージャを使用して挿入および選択、更新を行うコードを記述し、それらをDALを介してマッピングし直すことは、例外的な場合にのみ有益です。利用可能なORM、サポートしているデータベース、および言語あなたがORMを使用しない理由を尋ねるべき質問。

それらは標準化されており、ユニバーサルであり、指定されているか汎用です。さらに、より高速で簡単に実装できます。私は亜音速、linq-to-sql、およびエンティティフレームワークを使用しました。開発者は、データベースマッピングではなくロジックとビジネスルールに集中できます。

私の（単純な）2セント：

1：ORMSとORMSがあります。一部のORMSはActive Recordに基づいており、その他はData Mapperに基づいています-それ自体は関連する考慮事項ですが、その意味を理解するには調査が必要です。一般に、PHPでの私の経験では、ORMSは前者をサポートしていますが、後者はほとんどサポートしていません。Active RecordベースのORMには、データベースの非正規化、またはオブジェクトの相互作用をサポートするために大量のクラスを呼び出すという2つの効果のいずれかがあります。

2：ORMの利点は、実行する必要のあるクエリの複雑さとの直接的な相関関係で低下します。素敵でシンプルな関係、つまりユーザー->投稿があれば、とてもうまく機能します。これ（IMO）が、ほとんどのORM /フレームワークがこのような例を使用する理由です。ただし、複雑なクエリを実行する必要がある場合、生成する必要があるORMQLの量は通常のSQLクエリの文字列の長さに匹敵しますが、クエリを実行するオブジェクトグラフにより、パフォーマンスが低下します。抽象化。つまり、簡単に言えば、ORMはデータベースタスクの最初の30〜50％は素晴らしいですが、最後はひどいものです。これがARが非常に普及しているもう1つの理由だと思います。

3：なぜデータベースから隠すのですか？サーバーサイド言語を使用してjavascriptを抽象化しますか？

個人的に私はこれらのアプローチを混ぜます：

• 基本にORMを使用し、「ユーザー」をロードする
• いくつかの事前にベイクされたSQLクエリを含むDAOを使用します（つまり、selectLike、selectWhere）。
• 必要に応じてDAOを拡張し、より具体的で再利用可能なカスタムクエリを追加する
• DAOを介した単純なデータベースアクセスを提供します。つまり、$ data = Dao-> query（SQL文字列）を使用して、1回限りのクエリを実行します。

そうは言っても、Doctrine 2は間もなくリリースされます。

SQL機能を利用する場合は、myBatisなどのSQLマッパーフレームワークを使用できます。