外部結合に関する質問です。

表A         |  表B
ID   名前   |  ID   所持品
1   田中   |  1   りんご
2   佐藤   |  1   バナナ
3   鈴木   |  3   バナナ

このように「誰が、何を持っているか」を表した表AとBがあるとき、
以下の条件でデータを取得したいと考えております。

・ 所持品がある人は、名前と所持品の組み合わせを表示
・ 所持品がない人は、名前だけを表示
・ りんごをもっていない人は、名前と所持品の組み合わせに
 加え名前だけの結果も表示
・ UNIONは使いたくない

( 欲しい結果 )
 名前    所持品
 田中    りんご
 田中    バナナ
 佐藤    (空)   ← 所持品なし
 鈴木    バナナ
 鈴木    (空)   ← りんごなし

SELECT A.名前, B.所持品 FROM A, B WHERE A.ID = B.ID(+)
では『鈴木 ( 空 )』 が取得できません。。。
UNIONを使えばできたのですが、都合上UNIONを使わず
上記のような結果を取得したいと考えています。

どなたかお知恵をお貸しいただけませんでしょうか。
よろしくお願いします。

このQ&Aに関連する最新のQ&A

A 回答 (5件)

>件数が多いとちょっと重くなりそうな気がするのですが



『鈴木(空)』を取得するのが表示上の問題だとすると、
SQLとして本質的なことではないでしょう。
(人間様には必要でも、DBではあずかり知らぬこと)
そんな場合、DBには
SELECT A.名前, B.所持品 FROM A, B WHERE A.ID = B.ID(+)
だけ投げておいて、『鈴木(空)』はフロントエンド側で
何とかする……というのも一つの方法だと思います。

今回は、面白そうなSQLだったので参加しました(笑)。
    • good
    • 0
この回答へのお礼

お礼が遅くなって申し訳ありませんでした。
dda167さんの

>SQLとして本質的なことではないでしょう

という尤もなご指摘を受けて考え直しました。
色々と検討したのですが、今回はUNIONを使用した上で
プログラムの方をどうにかすることで解決いたしました。

的確なご指摘をいただいた点でベストアンサーに
選ばせていただきました。ありがとうございました!

ShimoHayhaさんの回答もSQLの知識の上で大変参考になりました。
結果的にベストアンサーにお選びできませんでしたが、
とても勉強になりました。ありがとうございました!

お礼日時:2011/04/23 14:18

>コストを気にするとやはりUNIONを使う方がいいのでしょうか。

。。

コストを気にするなら、UNION ALLを使ったほうが……
(重複問題がなければの話ですけど)

SQLは、同じ結果を得るのに、いろいろな書き方があるじゃないですか。
パフォーマンスやメンテナンスなどを考慮して最終的に決定するでしょうが、
その選択肢を自ら削る必要もないのでは……と思っただけです。

10gだとこんな書き方もありますね。

SELECT DISTINCT T.名前, T.所持品 FROM
(SELECT A.名前, B.所持品 FROM A LEFT OUTER JOIN B ON A.ID = B.ID) T
PARTITION BY (名前) RIGHT OUTER JOIN
(SELECT DISTINCT 所持品 FROM B) M
ON T.所持品 = M.所持品
    • good
    • 0

No.2 です。


No.2 は明らかに間違ってました。
こんな感じですかね・・・(またまた未検証ですが)

SELECT COALESCE(S.名前, R.名前), S.所持品
FROM
(
SELECT A.ID ID, A.名前 名前, B.所持品 所持品
FROM A
LEFT OUTER JOIN B ON A.ID = B.ID
)
S
FULL OUTER JOIN
(
SELECT A.ID ID, A.名前 名前
FROM A
LEFT INNER JOIN B ON A.ID = B.ID AND B.所持品 != 'りんご'
)
R
ON S.ID = R.ID
    • good
    • 0
この回答へのお礼

ご回答ありがとうございます!

今検証できる環境ではないので確認はまだなのですが、
COALESCという関数は知らなかったです。
検証してみて、またご報告させていただきます。

取り急ぎ御礼まで。ありがとうございます。

お礼日時:2011/04/17 02:24

え~っと、未検証ですが、こういうことでしょうかね?




SELECT
A.名前, B.所持品
FROM
A
LEFT OUTER JOIN B ON A.ID = B.ID
LEFT OUTER JOIN
(
SELECT A.ID, B.所持品
FROM A
LEFT OUTER JOIN B
ON A.ID = B.ID AND B.所持品 = 'りんご'
WHERE B.所持品 IS NULL
) R
ON
A.ID = R.ID
    • good
    • 0

「UNIONは使いたくない」理由は何ですか?



SELECT DISTINCT AX.名前, B.所持品 FROM (
SELECT DISTINCT A.ID, A.名前, B.所持品 FROM A, B
) AX, B
WHERE AX.ID = B.ID(+) AND AX.所持品 = B.所持品(+);
    • good
    • 0
この回答へのお礼

回答ありがとうございます!

SQLを動的に作成する箇所を含むプログラムを書いているのですが、
UNIONを使わないで済めば実装が簡単になりそうなので
そうした方法があれば、と思いまして。。。

今は検証ができないのですが、このSQLなら確かに取れそうですね。
件数が多いとちょっと重くなりそうな気がするのですが、
コストを気にするとやはりUNIONを使う方がいいのでしょうか。。。

その辺り確認してみたいと思います。ありがとうございます。

お礼日時:2011/04/17 02:12

このQ&Aに関連する人気のQ&A

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!

このQ&Aを見た人が検索しているワード

このQ&Aと関連する良く見られている質問

Q以下の文章のto and parties 以降の構造がわかりません。

以下の文章のto and parties 以降の構造がわかりません。
exports to states, countries, and parties という構造だと思ったのですが、違いますよね?
どう捉えるべきでしょうか?

The policy dates back to 1967, when Eisaku Sato, the prime minister at the time, declared a ban on weapons exports to communist states, countries to which the United Nations bans such exports to and parties to international conflicts.

引用元
http://search.japantimes.co.jp/cgi-bin/nn20100725a2.html

よろしくお願いします。

Aベストアンサー

「武器輸出の禁止を宣言した」
とあり,それがどこの国へかが
to
communist states「共産国家」
countries to which the United Nations bans such exports to
「国連が武器輸出を禁じている国」
parties to international conflicts「国際紛争への当事者→国際紛争の当事国」

こうしてみると,やはり to が一つ余計ですね。
countries (which) the United Nations bans such exports to
が正しいです。

Q3つの表の外部結合

表A、B、Cの3つがあり、Aのすべての行を出力したいと考えています。
外部結合を用いるのだとは思うのですが、3つの表に対して行う場合の
書き方がわからず困っています。
ご教授いただけないでしょうか?
select * from a,b,c
where a.商品ID =b.商品ID (+) and b.商品ID (+) =c.商品ID (+)
としてみましたが、うまくいきませんでした。

Aベストアンサー

ansi構文の趣旨からいえば、結合条件と絞り込み条件は分けて書くので・・

select *
from a
left join b on (a.商品ID =b.商品ID)
left join c on (b.商品ID =c.商品ID)
where a.年月 = 任意の値

と書くのが一般的でしょうね。

QI find parties like that ......

NHKラジオ英会話講座より
Everyone seemed to have a great time,myself included.
Although I find parties like that quite exhausting.
・・省略・・、ああいうパーティーはかなり疲れるけど。

(質問)I find parties like that quite exhausting.についてお尋ねします。
(1)第5文型(SVOC)でしょうか?
a)I (S)
b)find (V)
c)parties like that (O)
d)quite exhausting. (C)
(2)likeは前置詞ですか?
(3)findのフィーリングは日本語にするとどんな感じですか?やはり、見つける、わかる、ですかね? 類似の例文をお願いできれば・・?
 やさしい説明をお願いいたします。よろしくお願いいたします。以上

Aベストアンサー

こんにちは。

ご質問1:
<(1)第5文型(SVOC)でしょうか?>

その通りです。分類も合っています。


ご質問2:
<(2)likeは前置詞ですか?>

その通りです。

1.名詞thatを受けて、like thatで「あのように」「あのような」という意味になります。ここでは「ああいう(パーティ)」の部分に相当します。

2.この前置詞句は、すぐ前の名詞partiesにかかる形容詞句になります。


ご質問3:
<(3)findのフィーリングは日本語にするとどんな感じですか?やはり、見つける、わかる、ですかね?>

ここでは「と思う」という訳が適切です。

1.元々は「見つける」という意味ですが、第5文型の構文で使われると、「~とわかる」「~だと思う」といった訳になります。

2.なお、ここで使われているexhaustingは、他動詞のexhaust「~を疲れさせる」の現在分詞で、「(人を)疲れさせるような」という能動の意味があります。

3.以上から、ご質問文の訳出の流れは
(直訳)「私は、あのようなパーティを、かなり人を疲れさせるようなもの、だと思う」

(意訳)「あんなパーティは、かなり疲れると思う」
となり、これが抄訳のような訳になっているのです。


ご質問4:
<類似の例文をお願いできれば・・?>

1.ご質問文に即したもっとも分かり易い例文は
I find the book interesting.
「その本を、面白いと、思う」
です。同じくSVOCの第5文型です。

このinterestingもinterest「(人を)面白がせる」という他動詞の現在分詞なので、その意味を踏まえて「面白い」という訳になります。

ここでもfindは「~と思う」の意味で使われています。

2.この文をご質問文により忠実に再現すると
I find the book like that quite interesting.
「ああいう本は、かなり面白いと思う」
となります。

以上ご参考までに。
tommyさんはNHKのテキスト以外に何か参考書などをお使いですか?

こんにちは。

ご質問1:
<(1)第5文型(SVOC)でしょうか?>

その通りです。分類も合っています。


ご質問2:
<(2)likeは前置詞ですか?>

その通りです。

1.名詞thatを受けて、like thatで「あのように」「あのような」という意味になります。ここでは「ああいう(パーティ)」の部分に相当します。

2.この前置詞句は、すぐ前の名詞partiesにかかる形容詞句になります。


ご質問3:
<(3)findのフィーリングは日本語にするとどんな感じですか?やはり、見つける、わかる、ですかね...続きを読む

Q外部結合と等価結合のパフォーマンスの違いについて(ビューの場合)

Oracle10gでのSQL文の違いについて教えて下さい。

前回の質問は、ストアドプロシージャに記述
されていて、バッチとして動かしています。
と書きましたが、ビューの場合のパフォーマンスの違いは
どうなるのでしょうか?ビューの場合も同じような現象です。
下記の2つのSQL文は外部結合ありと外部結合なしの違いだけで、
他は変わりありません。
外部結合ありのほうは
結果がすぐに返されるのですが、外部結合なしのほうは
結果が返ってこない、あるいはかなり時間がかかるという
現象が起きています。
SQL文は簡略して記述していますが、SELECT句には、
TO_CHAR()やSUM(CASE WHEN ...THEN ...ELSE...)が使用してあり
少し重くなる処理も含まれています。
この2つのSQL文でパフォーマンスに影響している原因は
何なんでしょうか?オプティマイザとか実行計画とかの
説明を読んだのですが、いまいちよく解りません。。
自分では中級者以下だと思っていますので、わかりやすく
説明して頂けたら助かります。宜しくお願い致します。

(外部結合ありのSQL)
SELECT
 a.項目1,
 a.項目2,
 a.項目3,
 a.項目4,
 a.項目5
FROM
 TBL_A a,
 TBL_B b
WHERE
 a.項目1 = b.項目1(+) AND
 a.項目2 = b.項目2(+) AND
 a.項目3 = b.項目3(+) AND
 a.項目4 = b.項目4(+) AND
GROUP BY
 a.項目1,
 a.項目2,
 a.項目3,
 a.項目4,
 a.項目5

(外部結合なしのSQL)
SELECT
 a.項目1,
 a.項目2,
 a.項目3,
 a.項目4,
 a.項目5
FROM
 TBL_A a,
 TBL_B b
WHERE
 a.項目1 = b.項目1 AND
 a.項目2 = b.項目2 AND
 a.項目3 = b.項目3 AND
 a.項目4 = b.項目4 AND
GROUP BY
 a.項目1,
 a.項目2,
 a.項目3,
 a.項目4,
 a.項目5

Oracle10gでのSQL文の違いについて教えて下さい。

前回の質問は、ストアドプロシージャに記述
されていて、バッチとして動かしています。
と書きましたが、ビューの場合のパフォーマンスの違いは
どうなるのでしょうか?ビューの場合も同じような現象です。
下記の2つのSQL文は外部結合ありと外部結合なしの違いだけで、
他は変わりありません。
外部結合ありのほうは
結果がすぐに返されるのですが、外部結合なしのほうは
結果が返ってこない、あるいはかなり時間がかかるという
現象が起きています...続きを読む

Aベストアンサー

オラクルのオプティマイザは、テーブルの検索の方法を決めますが、外部結合と内部結合で
立案される実行計画に違いがあり、内部結合の方が合理的な検索方法を立案しているので
結果的に、内部結合の方が速いという話なんですが・・

実行計画を見なければ、判りませんが、
・外部結合はbに対して全表検索を選択した。
・内部結合では、bを索引検索を選択した。
・bの検索量が、bの格納件数のうち、ごく一部なので、全表検索と索引検索では、極端に検索時間が違う。
ということなんだと思います。(推測なので、実は違うかも知れません)

オラクルのマニュアルで、パフォーマンスチューニングガイドというマニュアルがあると思うので、
一読されることをお勧めします。


ちなみに、お書きになったSQLは何か変です。
内部結合のSQLは、bの項目を返さないので、実質的にbに存在するかのチェックを行っているに等しいものです。
書き方や流儀の問題で、内部結合が良いのか、exists条件が良いのか、in条件(メンバーシップ検査)が良いのか
変わってくると思いますが、一応理解できるものです。
しかし、外部結合のSQLについては、bを検索するけど、何もしない??理解に苦しむSQLになっています。
基本的に、内部結合より遅くなる外部結合を、わざわざ書いてみた、というように感じます。
(一般論ですが、同じ書き方をしたら、外部結合は内部結合と同等以下です)

オラクルのオプティマイザは、テーブルの検索の方法を決めますが、外部結合と内部結合で
立案される実行計画に違いがあり、内部結合の方が合理的な検索方法を立案しているので
結果的に、内部結合の方が速いという話なんですが・・

実行計画を見なければ、判りませんが、
・外部結合はbに対して全表検索を選択した。
・内部結合では、bを索引検索を選択した。
・bの検索量が、bの格納件数のうち、ごく一部なので、全表検索と索引検索では、極端に検索時間が違う。
ということなんだと思います。(推...続きを読む

Q契約書英語 parties to the contract

(1) The parties to the contract must be legally competent;

上記の文について質問です。「契約当事者が法的な資格を備えていること。」という意味だと思うのですが、"parties to the contract"の部分のtoがしっくりきません。"parties in the contract"ではなくて、toなのは何故ですか?また、inだと間違い/不自然ですか?

(2) It must be in writing if a written document is required for that kind of contract.

手元にある日本語訳が、「契約の種類に応じて書面契約が要求される場合は、書面で作成されること。」となっています。

"that kind of contract"の部分が、「契約の種類に応じて」となっているのですが、何故このような訳になるのですか?「その種の契約が必要な場合」だと思ったのですが・・・。

また、ここは、英語とは離れてしまうのですが、署名契約が要求されたら、書面で作成されるのは当たり前だと思うのですが、わざわざ定義するほどのことなのでしょうか?

以上

よろしくお願いします。

(1) The parties to the contract must be legally competent;

上記の文について質問です。「契約当事者が法的な資格を備えていること。」という意味だと思うのですが、"parties to the contract"の部分のtoがしっくりきません。"parties in the contract"ではなくて、toなのは何故ですか?また、inだと間違い/不自然ですか?

(2) It must be in writing if a written document is required for that kind of contract.

手元にある日本語訳が、「契約の種類に応じて書面契約が要求される場合は、書面で...続きを読む

Aベストアンサー

>parties in the contract"ではなくて、toなのは何故ですか?
決まり文句ですから、「何故ですか」と言われると困ってしまいます。

>また、inだと間違い/不自然ですか?
inだと不自然です。少なくとも「契約当事者」の意味で使っているなら、間違いと言わざるを得ないでしょう。

>"that kind of contract"の部分が、「契約の種類に応じて」となっているのですが、何故このような訳になるのですか?
直訳すると「その種類の契約について書面による文書が要求されている場合は、それは書面によらなければならない」ということです。
「契約の種類に応じて」という訳は少し意訳気味ですが、間違いではないと思います。

>署名契約が要求されたら、書面で作成されるのは当たり前だと思うのですが、わざわざ定義するほどのことなのでしょうか?
おっしゃるとおり、一読した限りでは至極当り前のことしか言っていないので、「こんなの、わざわざ書かなくても良いだろう」と思わないでもありません。

ただ、契約を書いた人の意図を推測すると、
「(うちの社内規定で)その種類の契約について書面による文書が要求されている場合は、それは書面によらなければならない」とか
「(法律で)その種類の契約について書面による文書が要求されている場合は、それは書面によらなければならない」のような意味だったのかもしれません。

前者の場合、この規定がなければ、元来相手側には書面による文書を作成する義務がなかったことになります。
後者の場合、この規定によって法律上の義務だけでなく契約上の義務も課されるので、相手に違反があったときには(損害があれば)損害賠償を請求できるようになります。

いずれにしろ、かなり言葉足らずではあると思います。

>parties in the contract"ではなくて、toなのは何故ですか?
決まり文句ですから、「何故ですか」と言われると困ってしまいます。

>また、inだと間違い/不自然ですか?
inだと不自然です。少なくとも「契約当事者」の意味で使っているなら、間違いと言わざるを得ないでしょう。

>"that kind of contract"の部分が、「契約の種類に応じて」となっているのですが、何故このような訳になるのですか?
直訳すると「その種類の契約について書面による文書が要求されている場合は、それは書面によらなければ...続きを読む

Qテーブル結合について、下記SQLをANSI結合の書き方で表したい。

テーブル結合について、下記SQLをANSI結合の書き方で表したい。

select *
from
(select key from A
union
select key from B
union
select key from C) X,
A,B,C
where X.key=A.key(+) and X.key=B.key(+) and X.key=C.key(+)

このSQLをANSI結合の記述で書きたいのですが、
(+)での結合文になれておらず試行錯誤しております。
下記のようなのかなとは模索しておりますが、
手元に実行環境がなくわかりません。
また、要所気付く点などありましたら、ご指摘願います。

select A.*, B.*, C.*
from
(select key from A
union
select key from B
union
select key from C) X,
LEFT JOIN A
ON X.key=A.key
LEFT JOIN B
ON X.key=B.key
LEFT JOIN C
ON X.key=C.key

テーブル結合について、下記SQLをANSI結合の書き方で表したい。

select *
from
(select key from A
union
select key from B
union
select key from C) X,
A,B,C
where X.key=A.key(+) and X.key=B.key(+) and X.key=C.key(+)

このSQLをANSI結合の記述で書きたいのですが、
(+)での結合文になれておらず試行錯誤しております。
下記のようなのかなとは模索しておりますが、
手元に実行環境がなくわかりません。
また、要所気付く点などありましたら、ご指摘願います。

select A.*, B.*, C.*
from
(sel...続きを読む

Aベストアンサー

敢えていうなら、Xの後のカンマが不要です。

select *
from
(select key from A
union
select key from B
union
select key from C) X
LEFT JOIN A ON X.key=A.key
LEFT JOIN B ON X.key=B.key
LEFT JOIN C ON X.key=C.key

Aテーブルのkey、Bテーブルのkey、Cテーブルのkeyが重複する可能性があり、
keyが重複する場合は、単純横展開ではなく、1行にしたいという条件であれば、
(+)を単純にLEFT OUTER JOINにするだけで良いと思います。

QI honestly don't like parties too much.

誰か英人のエッセー文かと思うのですが、上記タイトル以下の文を読むと、作者がパーティーを嫌う理由が色々書かれていて、作者がパーティーを心底嫌っていることが伺えます。
とするとタイトルにある英文は、「正直言うと、私はパーティーは全く好きじゃない」と訳していいのでしょうね?

それから
1.I don't like parties very much.
2.I don't like parties so much.
上記のような英文に出くわした場合、英文を書いた人はどのような気持ちを持っていると考えられますか?
また、日本語での「パーティーは余り好きじゃない」というニュアンスを含みたい場合の英語はどのように表現されますか?

以上宜しくお願い致します。

Aベストアンサー

very muchやso muchはどちらかといえばpositiveな時に使います。

一方too muchはnegativeですね。tooは過剰な表現です。
=I hate parties.
好きではないけど、それほど嫌いでもないというような表現の時に
I don't like parties very much. になるでしょう。

Qオラクル 外部結合についての質問

下記のようなテーブルがある場合に

Aテーブル     Bテーブル

品目(主)    品目(主) 子品目(主)SEQ
 パン1     パン1  小麦粉   1
          パン1  ジャム   2
          パン1  バター   3

結合条件
 A.品目 = B.品目

この時に1件のみ取得できるようにしたい。
Bテーブルから取得したいのは、SEQ3のデータ。

SELECT
A.品目,
B.子品目,
SEQ
FROM 
A,B
WHERE
A.品目 = B.品目(+)

とすると、下記3行のデータが取れてしまう。
パン1  小麦粉   1
パン1  ジャム   2
パン1  バター   3

これを↓だけ取得したいのです。
パン1  バター   3

外部結合ではそもそも取得できないのでしょうか?
どのようなSQLを書けばいいのか教えてください。

Aベストアンサー

Pieere85さんの回答にあるとおり、バターを取得する条件が不明なのですが、
Bテーブルのseqが一番大きいものと勝手に妄想しました。

select A.品目, B.子品目
from Aテーブル A
left join (
select 品目, 子品目
from Bテーブル
where seq = (select max(seq) from Bテーブル group by 品目)) B
on (A.品目 = B.品目);
とか
select A.品目, B.子品目
from Aテーブル A
left join (
select 品目, 子品目
from (
select 品目,子品目,row_number() over(partition by 品目 order by seq desc) rnum
from Bテーブル)
where rnum = 1) B
on (A.品目 = B.品目);

こんな感じでどうでしょうか。
質問の際には使用しているOracleのバージョンを記載した方がいいと思いますよ。

Q英文契約書のparty/partiesの和訳について教えてください

以下は3社間の英文契約書の抜粋です。

partyとpartiesをどのように訳し分ければよいでしょうか?
A, B, and C may be individually referred to herein as a Party or Company and collectively referred to as the Parties or the Companies.

恐れ入りますが、どなたかお助けください。

Aベストアンサー

訳し方は、NO.3の方のとおりです。
蛇足ですが、今回のように最初が大文字の場合は、「当事者」又は「全当事者」のようにカギ括弧をして、これらの当事者以外の当事者として現れる可能性がある小文字の当事者(party)やその他の会社(company)と区別することをお勧めします。

QテーブルのOR外部結合

※1
SELECT
 T1.*,
 T2.*,
 T3.*
FROM
 TBL1 T1,
 TBL2 T2,
 TBL3 T2
WHERE
 T1.T1_ID = T2.T2_ID(+) AND
 (T1.T1_ID = T2.T2_ID(+) OR T2.T2_ID = T3.T3_ID(+))

結果としては以下のようにしたいです。
T1_ID T2_ID T3_ID
100       300  ←T1とT3の結合結果
101       301      ”
100  200   302  ←T1+T2とT3の結合結果
101  201   303      ”

今のままではORによる外部結合でエラーが出てしまうため
(T1+[架空のT2_ID]+T3) UNION (T1+T2+T3)という回避策を取っていました。
実際にはT1,T2,T3共に出力カラム数が膨大で、更にT1,T2,T3(※1の結果)及びT4UNIONが存在する等、非常に扱いづらくなってしまっています。
なんとか※1のようにまとめることはできないのでしょうか?

※1
SELECT
 T1.*,
 T2.*,
 T3.*
FROM
 TBL1 T1,
 TBL2 T2,
 TBL3 T2
WHERE
 T1.T1_ID = T2.T2_ID(+) AND
 (T1.T1_ID = T2.T2_ID(+) OR T2.T2_ID = T3.T3_ID(+))

結果としては以下のようにしたいです。
T1_ID T2_ID T3_ID
100       300  ←T1とT3の結合結果
101       301      ”
100  200   302  ←T1+T2とT3の結合結果
101  201   303      ”

今のままではORによる外部結合でエラーが出てしまうため
(T1+[架空のT2_ID]+T3) UNION ...続きを読む

Aベストアンサー

SELECT T1.T1_NM,T2.T2_NM,T3.T3_NM
FROM TBL1 T1,TBL2 T2,TBL3 T3
WHERE T1.T1_ID = NVL(T2.T1_ID,T3.T1_ID)
AND T2.T2_ID(+) = T3.T2_ID
でどうですか?


人気Q&Aランキング

おすすめ情報