2

検索フィルターがあります。各フィルター/属性には、表示する必要がある独自の値があります。

<?php foreach(getAdditionalFilters() as $attributeName => $filterData): ?>
<ul>
  <?php showLiCheckBoxes($attributeName); ?>
</ul>     
<?php endforeach; ?>

フィルタを表示するには、次の 2 つの方法があります。

1.

function showLiCheckBoxes($attribute,$checked=null){
    $CI = get_instance();
    $CI->load->model('helper_model');
    $allAttrOptions = $CI->helper_model->getAttrOptions($attribute);
    foreach($allAttrOptions as $key => $option){         
      //print html of inputs like <li><input type='checkox' value='{$option['optionId']}...
    };    
}

function getAttrOptions($attrCode){
      $sql = "SELECT option_id as optionId, label FROM eav_attribute_option
              INNER JOIN eav_attribute USING(attr_id)
              WHERE code='$attrCode'";
      $query = $this->db->prepare($sql);        
      $query->execute(); 
      $query->setFetchMode(PDO::FETCH_ASSOC);
      return $query->fetchAll();      
}

2.

function showLiCheckBoxes($attribute,$checked=null){
    foreach(Attributes::${$attribute} as $key => $value){        
      //print html of inputs like <li><input type='checkox' value='{$option['optionId']}...
    };    
}

class Attributes 
{  

    public static $education        = array(0 => 'No answer', 
                                            1 => 'High school',
                                            2 => 'Some college',
                                            3 => 'In college',
                                            4 => 'College graduate',
                                            5 => 'Grad / professional school',                                    
                                            6 => 'Post grad');   
     public static $...

したがって、最初の方法では、属性オプションがデータベースに保存され、ご覧のとおり、属性ごとに追加のクエリが作成されます。2 番目の方法では、属性オプションが配列に格納されます。

ここに書かれていない他の事実があるので、どちらが正しいかを尋ねているわけではありません。私が求めているのは、テーブル eav_attribute_option に対して 500 行しかない 20 個の非常に単純なクエリがパフォーマンスに影響を与える可能性があるということです。私はそれを気にする必要がありますか、それとも私がここに書いたクエリは非常に単純で、テーブルは非常に小さいので、まったく違いはありませんか?

もちろん、これも 1 つのクエリで作成できますが、これも問題ではありません。クエリ自体ではなく、SQL Server への非常に多くの余分なリクエストが悪いことではないかと自問していました。

4

4 に答える 4

0

一般に、実際に問題が発生するまでパフォーマンスについて心配することはありません。顧客からのフィードバックにより、パフォーマンスが問題になるずっと前に、関数を書き直すように促される場合があります。

そうは言っても、RBAR ( row by agonizing row ) は、データベースの古典的なパフォーマンスの問題です。データベースへの往復は高価になる可能性があります (特に、データベースが別のサーバー上にある場合)。これは、すべての注文、それらの注文に含まれるすべての製品、およびそれらの製品のプロパティを顧客にロードすると手に負えなくなります。 . 些細な 1 つのクエリで。エンティティごとに 1 つのクエリを使用すると、パフォーマンスが大幅に低下します。

したがって、多くの作業をせずに実行できる場合は、RBAR を回避することをお勧めします。すでに両方のシナリオを書き上げているので、クエリの少ない方を選んでも問題ありません。

于 2013-02-06T10:24:39.420 に答える
0

追加のクエリは、コンテキスト切り替えのオーバーヘッドのためにパフォーマンスを低下させる可能性があります (その場合、20 行を返す 1 つのクエリは、それぞれ 1 行を返す 20 個のクエリよりも優れています)。

これらのクエリが非常に頻繁に実行される場合、それらがキャッシュ可能であれば、処理が大幅に高速化されます。

于 2013-05-23T06:56:54.720 に答える
0

シナリオに時間がかかりすぎるかどうかを知るために、プロファイルを作成する必要があります。

返される行数に関係なく、すべてのクエリにはオーバーヘッドがあります。
したがって、一般に、20 行を返す 1 つのクエリは、それぞれ 1 行を返す 20 個のクエリよりも優れています。

于 2013-02-06T10:05:50.060 に答える