2016-12-19 21 views
1

私が知る限り、Laravelのデータベースに接続するには2つの方法があります。Laravelでデータベースへの接続に最適な方法

アプローチ1:

// the name of table is defined in the model file 
Model_Name::WHERE(1)->get(); 

アプローチ2:

DB::table('table_name')->WHERE(1)->get(); 

okが、両方とも同じように機能し、それらが同一の結果を有します。だから何が違うの?どの状況でどちらが良いですか?

とにかく、いつどちらを使うべきですか?

答えて

5

Laravelは、データベースとのやり取りを容易にするEloquentという組み込みORMを提供します。 Eloquent ORMはActive Recordの実装を提供します。つまり、MVC構造で作成した各モデルがデータベースのテーブルに対応します。ここで、「投稿」モデルは「投稿」テーブルに対応します。名前が示すように

Post::all()   // Get all the posts 
Post::find($id)  // Find a post 
Post::delete($id) // Delete a post 

流暢クエリビルダ

を次のように、あなたはポストテーブル内のデータにアクセスすることができ、これは、データベースクエリを作成して実行するように流れるようなインターフェイスを提供します。 Laravelクエリビルダは、PDOパラメータバインディングを使用してSQLインジェクション攻撃からアプリケーションを保護します。バインディングとして渡される文字列をきれいにする必要はありません。いくつかの例があります。雄弁の雄弁の

DB::table('posts')->get();      // Get all the posts 
DB::table('posts')->where('id',$id)->first(); // Find a post 
DB::table('posts')->where('id',$id)->delete(); // Delete a post 

長所

You can use all Fluent functions in eloquent. But, You can’t use eloquent functions in the query builder 
Eloquent model relationship 
Easy to use 
Code Readability 

短所

Execution time may increase little bit 
In some places, Eloquent fail to compete against SQL queries for complex queries 

結論

シン両方の雄弁なと流暢なクエリビルダーは、独自の長所と短所があります。要件に基づいて両方を使用する必要があります。多くのことが、80:20のルールがここに当てはまるようです。あなたの仕事の80%を世話するために雄弁を使用し、流暢に使って他の20%のためのSQLといくつかのパーシスタンスコードを書く準備をしてください。雄弁なことからあまり期待しないでください。そうしないと、奇妙なバグやパフォーマンスの問題が発生します。

Complete Reference

+0

が.. – stack

+0

upvoteだから、私は私ができるよう、可能な限り* 'ポスト::すべての()' *(雄弁な)を使用する必要が提案し、それが失敗した場合、その後、私は持っていただき、ありがとうございます'DB :: table( 'post') - > get' *(流暢なクエリビルダー)*を使用するのは正しいですか? – stack

+0

私の提案はこれですが、それに応じて使用することができます。 –

4

パフォーマンスが問題でない場合ので、私は、最初のアプローチを好む:

はあなたのコードの100ヶ所で第二のアプローチを使用していると仮定します。ここで、特定の理由でテーブル名を変更したいとします。あなたは何をしますか?具体的に使用した場所100箇所を変更する必要がありますtable_name。あなたが最初のアプローチを使用している場合

DB::table('table_name')->where(1)->get(); //change table_name in 100 palces 

、あなたが

Model_Name::where(1)->get(); //no change here 

を書かれているかもしれませんさて、あなたはただ何をすべきか、テーブル名を変更する必要があり、変更/テーブルプロパティを追加していますあなたのモデル。このようなもの:

class Model_Name{ 
    protected $table = 'new_table_name'; //change table_name in one place 
} 

他には何もしません。あなたはあなたのテーブル名に非常に柔軟性があります。

注:最初のアプローチはEloquent ORMアプローチであり、ORMには多くの機能があります。一方、流暢なクエリはより良い実行者です。これまでに何をしたいのかを使うことができます。しかし、では、両方のアプローチを1つのプロジェクトで混在させないようにするのは良い考え方です。

+1

最初のアプローチでは、いくつかの特定の理由によりモデル名を変更したいとします。あなたは何をしますか?あなたは 'use App/model_name'を使った場所を100か所で変更する必要があります。 – stack

+0

実際の例を考えてみましょう。 'users'テーブルを' user'や 'systemUser'や、開発中に非常に一般的なもののように変更することができます。その後、 'User'モデルはまだモデル名として適切です。しかし、もしあなたがあなたの 'User'モデル/テーブルの名前を' Student'に変更して問題を作りたいなら、そうです。あなたは手を汚す必要があります。 – Imran

+0

ありがとう.. upvote – stack

1

どちらのアプローチが同じ結果に作業しているが、あなたはEloquentを使用しながら、Fluentは、複雑なSQLクエリを実行するのに役立ちます一方で、コードの可読性を維持できるような関係を持つかなり良いコード/仕事にできるようになります。

Laravelには、ORM Eloquentというビルトイン機能があります。 ORM Eloquentは、各モデルによってデータベースとコードのやり取りを容易にします。 MVC構造で作成する必要があるのは、DBテーブルに相当します。

Model_name::DB_interaction_functions 

Fluentクエリビルダは以下のように簡単な方法で事前に構築された流暢作成するためのインタフェースと実行データベースクエリを提供します:使用することは非常に単純なようでもあり

DB::table('table_name')->DB_interaction_functions 

これは単純なことですが、我々は話せばEloquentとFluentのパフォーマンスについては、FluentはEloquentが最も良いです。私はそれをテストすることはできませんが、あなたはそれを適用することができます。

夏らしい
雄弁はで使用するための簡単な方法であると、コードの可読性の良い条件が、それは、実行クエリにはもう少し時間がかかります。 Fluentは複雑なSQLクエリーを実行している間はうまくいきます。

参考:Laravel Eloquent vs Fluent query builder

+0

*「Fluentは** Eloquentよりも最高です**」*あなたはテキストに入力ミスはありますか? – stack

+0

@stack:* Fluent *は、実行パフォーマンスに基づいて+最高の複雑なクエリを処理します。 * Eloquent *は、コードの可読性と使いやすさに基づいて最適です。 –

+0

ありがとうございました! @スタック.... –

関連する問題