n
私がそれをよく理解していれば、画像が必要です。できれば別の商品から。それ以外の場合は、フォールバックとして同じ商品の複数の画像を使用できます。
これから、私が考えることができる唯一の解決策は、「上部」に各製品の「画像」が1つあるような番号付きの行を持つ一時テーブルを作成し、残りの画像をファイルすることです。
そのテーブルが作成されると、クエリは単なるSELECT ... LIMIT n
.
これはひどく実行されます-そして、何かインスピレーションを得たソリューションを選択した場合は、画像テーブルをオフラインまたはスケジュールに基づいて統合する必要があります.
http://sqlfiddle.com/#!2/81274/2を参照してください
--
-- test values
--
create table P (id int, title char(20));
insert into P values
(1, "product 1"),
(2, "product 2"),
(3, "product 3");
create table I (pid int, filename char(40));
insert into I values
(1, "image p1-1"),
(1, "image p1-2"),
(3, "image p3-1"),
(3, "image p3-2"),
(3, "image p3-3");
--
-- "ordered" image table
--
create table T(n int primary key auto_increment not null,
filename char(20));
--
-- consolidate images (once in a while)
--
delete from T;
insert into T(filename)
select filename from I group by pid;
insert into T(filename)
select filename from I order by rand();
--
-- do the actual query
--
select * from T limit n;
編集これはまったく異なるアイデアです。統合テーブル/ビューを使用していないため、これはより良いと見なされる可能性があります。
http://sqlfiddle.com/#!2/57ea9/4
select distinct(filename) from
(select 1 as p, filename from I group by pid
union (select 2 as p, filename from I order by rand() limit 3)) as T
order by p limit 3
ここで重要な点は、行に実際に「番号を付ける」必要がないことです。最初の からどの行が来ているかを追跡するためだけにSELECT
。それが の目的ですp
。簡単にするために、両方のLIMIT
句を同じ値に設定します。メリットが非常に小さいため、その部分を「最適化」する必要はないと思います-そして、ORDER BY RAND()
ここで「パフォーマンス」について考える必要がないほどひどいです;)
このソリューションを完全にテストしていないことに注意してください。機能しないいくつかのコーナーケース (まあ..いずれにせよ) があるかどうか教えてください。