私『...はい』という事でテーブル構成等々を手直し。作成者と思われる方のツイッターアカウントをたまたま見つけつぶやきを見てしまいました。見て、おそらく各ツアーの公演毎のセットリストを横に並べて表示させたかったんじゃないかな、と想像しました。見てもらったのに解決しなかったのは残念だな、と思いましたので、私なりの実装方法を書いていってみます。私はPHP使いではないのでPerlのCGIで実装します。実装するにしてもデータがないとどうにもなりません。先のサイトを少しの間眺めて、以下のPerlコードを書きました。サイトの左側フレームにはツアータイトルと公演回のリンクがリストになっていて、クリックすると右側フレームにその公演の情報が表示されます。リンクを見た様子では、URLのパラメタcategoryが1~148のコンテンツを表示できるようです。)にして最初の3つの公演情報を取り出したものです。}]148の公演情報を取り出しできたら、このnana.jsonの内容をデータベースへ格納していきます。作成し7つのテーブルを定義しました。使っているので、シーケンス(SEQUENCE)オブジェクトも同時に定義されます。私が使っているpgAdminIIのGUIグリッドでテーブルの編集を行いたいので項目idは主キーに使っています。KEY(id));データ取り込みnana.jsonはJSON形式データとなっているので、PHPやPerlはじめいろいろな言語やツールで参照できるデータ形式になります。JSONデータからSQL生成perlでnana.jsonを読みSQLを生成させました。使ったPerlのコードは泥臭くこんな感じ。生成されたSQLはこんな感じ。最初のデータを取り込みします。以下はテーブルsetlistsに格納されたデータを基に残りのテーブルへ格納していくSQLです。演目テーブルの項目commentsから曲タイトルを抜き出して曲テーブルへ格納します。演目テーブルの項目commentsから場所を抜き出して場所テーブルへ格納します。演目テーブルの項目commentsから会場を抜き出して会場テーブルへ格納します。演目テーブルの項目commentsからツアーのタイトルを抜き出してツアーテーブルへ格納します。演目テーブルの項目song_idに曲テーブルの項目idを設定します。演目テーブルから集約処理で邪魔になる情報(曲タイトル)を項目commentsから取り除きます。演目テーブルから公演テーブルへ格納します。演目テーブルの曲情報が無い状態で集約すると、1レコードが1公演の情報、となります。公演テーブルの項目event_dateに項目commentsの公演日を転記します。演目テーブルの項目event_idに公演テーブルの項目idを設定します。公演テーブルの項目commentsを使って公演テーブルのtour_idにツアーテーブルの項目idを設定します。公演テーブルの項目commentsを使って公演テーブルのplace_idに場所テーブルの項目idを設定します。公演テーブルの項目commentsを使って公演テーブルのvenue_idに会場テーブルの項目idを設定します。このテーブルへは手書きで追加します。このテーブルはなくてもかまいません。ツアー開始、終了の項目があります。この項目をテーブルeventsのデータで設定します。取り込みと関連付け作業で使ったデータが残ったままですのでこれを削除します。結果をコミットcommit;データ取り込みはこれで終わりです。今回のような、横に並ぶ数が可変となるような(ツアー毎に公演回数が異なる)場合は基本的にクエリを書けないです。最近ですとPivotとかcrosstabとかの構文を備えているRDBMSも出てきていますが、そのクエリを発行した側が動的な戻り値に対応できていなくてはなりません。すべてのクエリの結果項目が同じ型に落とし込めるのであれば、UNION演算子で複数クエリを縦に繋ぐ方法も考えられなくはないのですが、面倒ばかりが多くあまりいい結果にならないかもしれないです。ここではクエリで横につなげるのではなく、クエリ結果を横につなげる方法で実装してみます。ツアー一覧メニューで使うであろうツアー一覧を作成するクエリ。tour_start,id結果はこうなります。nanamizuki=>公演リスト指定のツアーの公演情報を一覧します。id)を指定すると、このような出力になります。nanamizuki=>セットリスト指定の公演のセットリストを一覧します。;テーブルsetlist_typesを作成していないならこのクエリで。nanamizuki=>本家様とも一致していることがわかりました。作成したクエリを基に、HTMLコンテンツを生成するCGIを作成します。ツアーリストツアーのリストをHTMLで出力します。ツアー名にリンクを張り、b.plを呼び出せるようにします。$dbh->disconnect();公演情報とセットリストツアーの公演会場を横に並べたテーブルを作り、その中にセットリストを埋め込みします。示すツアーの公演情報を横並びに表示、情報中にセットリストが配置されます。2003”を選択した場合の結果です。$dbh->disconnect();データメンテナンスなんで曲や場所、会場、ツアーを別々にしたのか。それはデータのメンテナンスを行いやすくするためです。会場の情報を一覧してみます。nanamizuki=>以下の組ははたぶん同じ場所ですよね。[名古屋国際会議場センチュリーホール]NHK大阪ホールの表記が正しそうだけど実際がわからないので保留。[NHK大阪ホール]こういうデータの揺れはよくあります。このidがどのくらい使われているか公演テーブルを見てみましょう。記述が正しいなら、それ以外は間違っていることになるので訂正しなくてはなりません。苦労してテーブルを分けた結果がこういう時に報われます。nanamizuki=>テーブルeventsの項目venue_idの差し替えだけで、公演場所の誤記が訂正されました。曲テーブルもざっと眺めてみます。nanamizuki=>ちょっと怪しげ。2007誤表記をワザと掲載している訳でないなら、ID=792は誤りでID=793が正解ですね。nanamizuki=>9つの公演のセットリストに誤りがあることがわかります。修正しちゃいましょう。nanamizuki=>コメントを残しておくと後からやったことを思い出すのに役立ちます。girl”」の公演情報が足りないよ、と連絡があった。見ると、このツアーは同日に2回、同じ場所同じ会場で実施されたものらしく、公演テーブル上へのデータ取り込み時に1レコードに集約されてしまっていた。公演テーブルに項目stageを追加。その公演は第何回目なのか明示的に表すことにする。ツアー毎に公演回数を計算して項目stageへ格納する。以降は対処のクエリ実行ログ。127.0.0.1ページ用ツール文書の先頭へ。