X
トップページ⇒DB＠2ch掲示板
1002コメント323KB
DB設計を語るスレ 10 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
0683NAME IS NULL
垢版 |
2020/05/28(木) 12:11:39.95ID:???
>>682
想像してるんじゃなくてDBだけでやりたいという形でケースの特定化がなされたことで>>677や>>680の回答が出やすくなってるんやで
0684NAME IS NULL
垢版 |
2020/05/28(木) 12:49:31.13ID:???
>>682
これに関してケースバイケースなんて言われてないだろ
お前はそれ以前に日本語が読めないのか？
0686NAME IS NULL
垢版 |
2020/05/28(木) 17:13:38.87ID:???
カテゴリー君はよほど悔しかったんだなw
0687NAME IS NULL
垢版 |
2020/10/02(金) 04:29:53.32ID:8BLp41VJ
すみません。IDの設定について教えて下さい。
現在、id (INTEGER) と user_name (TEXT) の2カラムで、以下のデータがあるとします。
1 , 東京営業所
2 , 沖縄営業所
3 , 北海道営業所
4 , 東北営業所

データを取得時、以下のように北のほうからの並びで取得したい場合は、並び順を設定するカラムを追加するしかないでしょうか？
3 , 北海道営業所 , 1
4 , 東北営業所 , 2
1 , 東京営業所 , 3
2 , 沖縄営業所 , 4

既存のテーブルで、設計を変更するとプログラム側も変更しないといけない場所が何か所か出てくるので、
極力変更したくないのですが・・・
0688NAME IS NULL
垢版 |
2020/10/02(金) 07:18:02.94ID:???
どうしても変更したくないならソートオーダーの為だけの新テーブルを追加
素直にフィールド追加した方が後の保守は楽ですよ
プログラム側はフィールド追加で影響が出ない様に作るものですけどね
0689NAME IS NULL
垢版 |
2020/10/02(金) 08:33:57.24ID:???
既存テーブルへのカラム追加で既存プログラムも修正が必要になるのって
データを複製してるような処理しか思いつかない
そういう処理なら並び順もデータとして必要になるよね
0691NAME IS NULL
垢版 |
2020/10/02(金) 22:02:47.07ID:???
今どきアスタリスク指定してるくらいじゃ問題にならんよ
最終目的地までカラムを指定せず全部出力するなら別だけど
0692NAME IS NULL
垢版 |
2020/10/02(金) 22:21:30.11ID:???
今order by指定していないなら、それは「たまたま」id順で出てるだけ
どっちにしてもorder by指定する必要がある

今idでorder byしてるが、それを変えたくないなら、id振りなおすしかないわな
id振りなおすのとカラム追加＆プログラム変更とid振り直しとどっちが楽か判断して決めれば良いんじゃね
0693NAME IS NULL
垢版 |
2020/10/03(土) 20:16:27.73ID:???
なんで行順番の話?
0694NAME IS NULL
垢版 |
2020/10/03(土) 23:37:33.72ID:???
さあ

しかしorder byがなくて
バクるアプリを引き継いだワイにはタイムリーネタやで
0695NAME IS NULL
垢版 |
2020/10/03(土) 23:46:00.34ID:???
都道府県コード使うとしても、北からの並びではないからなあ
並べたい順に自分で番号付けたテーブルを用意しないと無理でしょ
0697NAME IS NULL
垢版 |
2020/10/05(月) 16:37:36.91ID:???
case でマッピングするという力業もあるけど
0698NAME IS NULL
垢版 |
2020/10/05(月) 19:58:12.35ID:mY4x3iPH
>>687
そのIDにエリアの概念を持たせなかったのが失敗なんだよ。
0699NAME IS NULL
垢版 |
2020/10/05(月) 20:44:41.26ID:???
idにidentity以外の意味を持たせるのは愚策。素直に順序列を追加するのが吉。
0700NAME IS NULL
垢版 |
2020/10/05(月) 20:44:48.17ID:???
あるあるアンチパターンを勧めてくるとは

さすが
0702NAME IS NULL
垢版 |
2020/10/06(火) 01:05:10.04ID:HE4gRaIT
電話番号や郵便番号のコード体系を考えたこともないのかね。
0703NAME IS NULL
垢版 |
2020/10/06(火) 09:23:09.69ID:???
コード体系が必要なら各意味を別々のカラムで管理してコード自体は導出項目にする

コード体系を作ったこともないのかね。
0704NAME IS NULL
垢版 |
2020/10/06(火) 10:17:55.36ID:???
汎用機世代の人やRDBをよく知らないExcel屋さんは
すぐ暗黙のコードを使おうとするんだよね

昔、東大卒のマーケティング屋さんが
10個以上の意味を埋め込んだオレオレ独自コードを
自信満々のドヤ顔で説明してきた時は困り果てたよ
0705NAME IS NULL
垢版 |
2020/10/06(火) 11:04:05.32ID:9/QKAQYT
代理キーが標準のような話になってますね
0706NAME IS NULL
垢版 |
2020/10/06(火) 11:47:26.23ID:???
匿名掲示板で、ID表示なし、コテハンもトリップもナシでどやられてもなあ
0707NAME IS NULL
垢版 |
2020/10/06(火) 11:47:30.72ID:???
コード体系の話はプライマリキーが代理キーかナチュラルキーかは関係ないよ

複数の意味を持たせるのがアンチパターン
0708NAME IS NULL
垢版 |
2020/10/06(火) 13:04:33.85ID:9/QKAQYT
主キーの意味がわかってないのか？
0709NAME IS NULL
垢版 |
2020/10/06(火) 13:25:17.40ID:???
いつもの触っちゃだめなやつ
控えめに言ってガイキチなので気をつけろ
0710NAME IS NULL
垢版 |
2020/10/06(火) 14:07:09.38ID:9/QKAQYT
>>699
identityではなくidentifier。
0711NAME IS NULL
垢版 |
2020/10/06(火) 14:07:39.63ID:9/QKAQYT
>>707
IDはユニークという意味しかない
0712NAME IS NULL
垢版 |
2020/10/06(火) 14:37:54.31ID:???
>>699が言ってるのは「identifierにidentity以外の意味を持たせるのは愚策」ってことやぞ
0713NAME IS NULL
垢版 |
2020/10/06(火) 14:54:07.51ID:???
あるコード(体系)を設計し導出項目となり、それをキーとしたいとなった場合
必然それは代理キーとなるだろう、とは言えるが

導出項目をつねに代理キーにするとか言ってないし
代理キーが主キーに限定されているわけでもないし

そもそもコード体系云々以前に
一つの項目に複数の意味を持たせるなって大原則があるだけ
0714NAME IS NULL
垢版 |
2020/10/06(火) 16:27:35.99ID:9/QKAQYT
実務経験のなさが露呈してますよ
0715NAME IS NULL
垢版 |
2020/10/06(火) 18:02:55.53ID:???
もしかして代理キーをsurrogate keyの意味じゃなくalternate keyの意味で使ってるのか？

もしそうなら誤訳以外のなにものでもないので別の訳語なり用語を選んだほうがいいと思うぞ
0716NAME IS NULL
垢版 |
2020/10/06(火) 18:11:26.80ID:???
https://ja.wikipedia.org/wiki/代理キー
代理キー（だいりキー、英: alternate key）
代替キー (サロゲートキー、surrogate key)

これはやべぇw
英語の日本語の意味が完全に逆
0717NAME IS NULL
垢版 |
2020/10/06(火) 18:14:46.93ID:HE4gRaIT
いまになって調べてるのか？
0718NAME IS NULL
垢版 |
2020/10/06(火) 18:24:08.59ID:HE4gRaIT
>>716
その代替キーはIPAでは代用キーと呼んでいる。

サロゲートキーのことを「代理キー」と呼ぶのは日本の慣習です。

英語の翻訳語は使われ方が反対になることがあるので注意してください。
0719NAME IS NULL
垢版 |
2020/10/06(火) 22:06:20.96ID:???
>>716
wikipediaの記事ができるより前の時期で検索してみたが
surrogate keyは代理キーは、alternate keyは代替キーと正しく訳してるものしか見つからない
オラクル、富士通、ユニシス、@IT、オージス総研などなど

古いDBマガジンを確認しても代理キーはsurrogate keyの意味で使われてるものしかない

歴史修正主義なんかな？
0720NAME IS NULL
垢版 |
2020/10/06(火) 22:15:47.94ID:???
alternate keyは二次識別子と言っておけばだいたいOK
0721NAME IS NULL
垢版 |
2020/10/20(火) 07:31:35.62ID:???
テーブル設計であえて正規化しないで置くべき理由ってなにがあるでしょうか？
ちょろっとググった感じだと、パフォーマンスが重要な要件だとテーブル結合をなるべく避けたい
とかが見つかりましたが
0722NAME IS NULL
垢版 |
2020/10/20(火) 07:34:17.42ID:???
逆に正規化する「べき」理由ってあるの？
0723NAME IS NULL
垢版 |
2020/10/20(火) 07:40:17.35ID:???
素人なので断言できませんがパッと思いつくのは
多重管理を避けることができ、それに付随して
・テーブルの意図が明確になる
・データ不整合の発生を防げる
などです
0724NAME IS NULL
垢版 |
2020/10/20(火) 10:09:11.35ID:???
>>721
トランザクション処理中心の業務系データベースの場合は基本的に正規化する
更新異常を防いで整合性を維持するため

ただしパフォーマンス最適化のために正規化されたものを非正規化することはある
その場合でも設計時には正規化された場合の構造を明確にした上で非正規化する
そうしないと非正規化したことでどういう更新異常が発生しうるのかや
アプリ側で担保しなくてはいけないデータ整合性が明文化されないから

データウェアハウスのようにデータの追加はあっても更新のない情報系データベースの場合は
全く正規化しないわけではないけど最初から分析しやすい形を念頭に設計する
0725NAME IS NULL
垢版 |
2020/10/20(火) 14:09:08.77ID:???
>>724
やはり特殊な用途を除き正規化するのが基本なのですね
ありがとうございます

身近で詳しそうな人に正規化した設計を提出したところ
フラットに作り直すよう指摘され、明確な理由がわからず
もやもやしておりました

開発観点の他に運用・保守観点（項目の追加/削除、データの追跡可能性）
を想像してみても特に正規化を避けるべき理由が思い当たりませんでした
0726NAME IS NULL
垢版 |
2020/10/20(火) 14:56:58.07ID:???
なぜ指摘した本人に理由を聞かないのか

そもそもそれほんとにちゃんとした正規化が出来てるのか？
正規化を避けるべき理由はないのか？

そもそも設計を提出ってなんだよ。業務なのか？
だったらなぜ上司ではなく詳しそうな人なんだ
0727NAME IS NULL
垢版 |
2020/10/20(火) 15:05:03.53ID:???
もしかしてRDBじゃなくMongoみたいの使う前提なのかな？

まあ指摘した本人に理由を聞くべきなのは間違いない
0728NAME IS NULL
垢版 |
2020/10/20(火) 15:31:38.20ID:???
理由ははぐらかされてしまいました
そっちのほうがいい気がする
というようなことを言っていました

> もしかしてRDBじゃなくMongoみたいの使う前提なのかな？
RDBです
0729NAME IS NULL
垢版 |
2020/10/20(火) 16:12:36.27ID:???
技術的な面じゃなくサーバーが年代物で貧弱とか
開発予算がないから手抜きで作るとか政治的な事だったり
0730NAME IS NULL
垢版 |
2020/10/20(火) 17:39:35.83ID:???
正規化した設計とかフラットにした設計の中身が
もう少し具体的にわからんとなんとも言えないね

フラットにすることで更新異常が発生しうるんなら
メリットデメリット理解して選択するしかない
0731NAME IS NULL
垢版 |
2020/10/20(火) 19:58:51.65ID:???
>>725
世の中には自分の理解できないものは使うな
って言う上司とか先輩はいっぱいいる
その人に従わないとダメなら言質を押さえて従うがよろし
単に詳しそうな身近な人と言うだけならもう変更の工数ないからとか言って無視しとけばいい
0732NAME IS NULL
垢版 |
2020/10/21(水) 00:08:11.04ID:???
原則は教科書通りにるすのが一番ですが

場数踏んだ熟練のPGさんとか
製造工数おさえてギリokみたいな
絶妙な作りしてくる人もいる
理由は経験とカンみたいな

気にやまないことだと思います
0733NAME IS NULL
垢版 |
2020/10/21(水) 01:41:41.26ID:???
すぐに言語化できなくても直感的にモヤッとする設計ってのはある
必ずしもその直感が妥当というわけではないんだけど
熟練になればなるほど感覚的なものも大事にしたほうがいい
0734NAME IS NULL
垢版 |
2020/10/21(水) 01:49:04.44ID:???
なんとなく分かる
気持ち悪い設計って確かにある
0735NAME IS NULL
垢版 |
2020/10/21(水) 13:04:54.08ID:???
第4や第5とかボイス何たらとかを第3に戻されたとか？
0736NAME IS NULL
垢版 |
2020/10/21(水) 13:07:36.31ID:???
第5はともかくボイスコッドで設計できる人の質問ではない気がする
0737NAME IS NULL
垢版 |
2020/10/21(水) 17:30:47.48ID:???
詳しそうで素人な人もいるぜ
クソ設計なテーブルで、プログラム書かされて死にそうになったことある
0738NAME IS NULL
垢版 |
2020/10/23(金) 14:20:38.63ID:???
>>736
ボイスコッドの方が難易上なの？
自分が理解し切れてないのだけど、ボイスコッド正規形は条件満たすだけならまあ簡単だけど実務とか現実世界の関係的に違和感のある設計になるよくわからんもの、みたいなイメージがある……
0739NAME IS NULL
垢版 |
2020/10/23(金) 23:40:51.85ID:???
実務のボイスコッド正規形は理論のそれと違って
導出属性を使った制約を追加することで第三正規形から関数従属性を失わずに
ある種のビジネスルールをデータモデルに埋め込むことができる

第3や第5よりもBC正規形使った設計ができる人のほうが
DB設計に対して深い理解があると思うよ
0740NAME IS NULL
垢版 |
2020/11/30(月) 22:31:04.06ID:???
とりあえずサロゲートキー持たせたいとき（持たせるって表現で良いのか解らないけど）って、
数字のみの連番にする？　何か文字列も付与する？　ケースバイケース？

数字のみで良いのかなと思ってたんだけど、文字列付けた方が良い時ってあるんじゃろか
0741NAME IS NULL
垢版 |
2020/11/30(月) 23:55:06.66ID:???
サロゲートキーという範疇に入らないかもしれないがUUIDを使ったほうがいいケースは自然と文字列も入る
分散データベース間でも一意に識別したいとかDBにアクセスせずに一意なIDを生成したい場合

でもそういうのはDBのプライマリキーには使わないから
1つのテーブル内の一意性で十分で、数字の連番を使い切る可能性がなければ文字列を入れる理由はないかな

他には人間に読みやすくかつ間違いにくくするために文字を入れるケースもあるけど
その場合は生成した数字とは別のカラムで文字列込みの値を管理する
0742NAME IS NULL
垢版 |
2020/12/01(火) 00:00:33.65ID:???
最初に文字を入れると全部桁数は揃うだろうから見た目は気持ちはいいかもな
0743NAME IS NULL
垢版 |
2020/12/02(水) 02:52:19.08ID:???
>>741
なるほど。こういうのもあるのか
> その場合は生成した数字とは別のカラムで文字列込みの値を管理する

これはこれで、それぞれのカラム名どうしようとか悩みます
文字列込みにした方が人間に読みやすいのは確かなんだけど、２つ管理するのも不慣れなせいかしっくりこない
選択肢が増えてますます混乱したｗ
0744NAME IS NULL
垢版 |
2020/12/02(水) 09:55:10.43ID:???
そもそも代理キーに文字を入れたいとか、代理キーになんらかの意味を持たせたいってことだろ
それすでに代理キーじゃなくね
0745NAME IS NULL
垢版 |
2020/12/04(金) 10:49:18.51ID:???
>>744
代理キーならあるでしょ
サロゲートキーの話をしてるなら同意するけど
0747NAME IS NULL
垢版 |
2021/01/04(月) 11:20:12.25ID:???
商品に、表示フラグ、新着フラグ、18禁フラグや、表示優先順位などWeb上の表示だけに特化した値を持つ場合、商品マスタに書いてしまっていいのでしょうか？それとも別に持ったほうがいいのでしょうか？
0748NAME IS NULL
垢版 |
2021/01/04(月) 12:28:55.25ID:???
表示フラグと18金ｗはいるだろうな
他は、コロコロ変わるものだから
別にして良いと思う
0749NAME IS NULL
垢版 |
2021/01/04(月) 18:53:45.42ID:???
>>747
商品マスタの構成や商品マスタをどう使う前提なのかによる

一般論で言えば商品IDが決まれば値が確実に決まるような属性なら商品マスタに書く
商品すべてがWeb上で扱う前提ならWebに特化した値も商品マスタに書いてもいい
Webに特化した属性のCRUDのタイミングが商品マスタの基本属性と異なるなら
別テーブルにしたほうがいい可能性が高い

18禁フラグ以外は商品ID+日時の組み合わせで管理できるようにしておいたほうが運用は楽
(商品マスタ自体が商品ID+日時の組み合わせで一意になるようなら更新頻度/更新タイミングなどから別テーブルにするかどうか検討)

あと新着かどうかは販売開始日付みたいなのからアプリで判断するほうが普通
0750NAME IS NULL
垢版 |
2021/01/04(月) 21:39:09.85ID:???
サロゲートキーにulid 使うのは異端？
スレ検索してもulid 出てこないね。
0751NAME IS NULL
垢版 |
2021/01/04(月) 22:01:16.35ID:???
サロゲートキーにUUIDを必要とするユースケース自体がかなり稀だからね
0752NAME IS NULL
垢版 |
2021/01/04(月) 23:04:35.94ID:???
ごめん、ちゃんと注意して書けば良かった。
128bitのUUID(Universally Unique Identifier)ではなくて、
同じく128bit(Timestamp 48 bit + Randomness 80 bit)のULID(Universally unique Lexicographically sortable IDentifier)。

日時でソートできるUUID的なヤツなんだけど、あんま使われてないんかな？
0753NAME IS NULL
垢版 |
2021/01/04(月) 23:37:36.45ID:???
わかってるよ
UUIDを必要とするユースケース以外でULID使うことないでしょ
0754NAME IS NULL
垢版 |
2021/01/04(月) 23:55:03.99ID:???
仰る通りです。すいませんでした。
0755NAME IS NULL
垢版 |
2021/01/05(火) 00:56:58.70ID:???
それサロゲートキー項目に一意性と日時って二つの意味を持たせることになるんじゃね
ありえないな。日時でソートしたいならちゃんと日時の項目もつべき
0756NAME IS NULL
垢版 |
2021/01/05(火) 01:50:26.16ID:???
生成順にソート可能にするための実装として日時を使っているからといって
日時の意味を持たせてるということにはならないよ

ULIDから日時を取り出してデータ作成日時として利用するなら別だが
0757NAME IS NULL
垢版 |
2021/01/05(火) 15:53:27.55ID:???
日時としての意味はなくても、その日時で生成順としての意味をもたせてるじゃないか

シーケンスとか生成順に使うような場合って実際には結構あるけど、本来それも間違ってる
昔のオラクルのマニュアルとか生成順は保証しないようなこと書いてあったんだがなぁ
0758NAME IS NULL
垢版 |
2021/01/05(火) 17:16:48.59ID:???
大小比較可能な値を生成したら「二つの意味を持たせてるからありえない」ってどういう脳みそしてるんだか

オラクルが正だと思ってるようなやつは中途半端な知識で
斜め上の御託を並べ立てるやつが多くて困る
0759NAME IS NULL
垢版 |
2021/01/05(火) 20:05:33.88ID:???
一意保障以外に大小比較って意味をもたせてるんだから二つの意味なんだが
サロゲートキーに一意保障以外の意味を持たせるなって大原則をまず理解しような
0760NAME IS NULL
垢版 |
2021/01/05(火) 20:08:21.25ID:???
シーケンスのDB発番はクラスタ化が難しいので元々ありえない。

UUIDは日時でソート出来ない。

ULIDはソート出来るだけでありがてぇ。パーティショニングで役に立ちそう。あ、DB発番しないよ。
0761NAME IS NULL
垢版 |
2021/01/05(火) 20:24:27.35ID:???
だったら素直にUUIDと日付列用意すればいいんじゃね
インデックスの効率落ちそうだ
0762NAME IS NULL
垢版 |
2021/01/05(火) 22:59:49.77ID:???
>>759
なんで2つ意味を持たせると良くないのかをまず考えろよ
その理由を理解せずにトンチンカンなことばっかり言ってマウント取ろうとするからいつもバカにされてるんだぞ
0763NAME IS NULL
垢版 |
2021/01/09(土) 14:41:54.56ID:???
上の話どうなった？
自分740の質問した人間なので気になる

きのこたけのこ論争みたいなもんで正解はないやつ？
0764NAME IS NULL
垢版 |
2021/01/09(土) 16:21:49.00ID:???
UUIDの代替としてULID使うべきかどうかはケースバイケースだからその点ついての正解はない
ULID使いたければ特徴と限界を理解した上で使えばいい
まだ比較的新しいものだから標準ライブラリ相当で安定した実装が提供されてる言語は少ない

二つの意味を持たせてる云々は少し考えればわかるでしょ
0765NAME IS NULL
垢版 |
2021/01/10(日) 00:03:48.39ID:???
ULIDはUUIDのパフォーマンス問題を軽減できるのが一番大きい
0766NAME IS NULL
垢版 |
2021/01/10(日) 07:38:57.64ID:???
>>765
インサートが遅くなるアレ？
ulid 解決できるんだ！？
0767NAME IS NULL
垢版 |
2021/01/10(日) 08:36:14.08ID:???
UUIDを主キーにするって人は、衝突しないって前提でやってるの？
0768NAME IS NULL
垢版 |
2021/01/10(日) 08:59:33.73ID:???
そりゃそのために作られたものなわけだし。使う場合はその前提に乗っかるのが当たり前。
0769NAME IS NULL
垢版 |
2021/01/10(日) 16:24:43.84ID:???
UUID使ってるシステム見たけど
データが無駄にデカイし
インデックスもやたら膨らむしで
主キーに使うのも考えもんだな
気持ちはわからんでもないが
0770NAME IS NULL
垢版 |
2021/01/10(日) 16:25:36.71ID:???
主キーなら衝突したらわかるでしょ
0771NAME IS NULL
垢版 |
2021/01/10(日) 18:29:44.20ID:???
>>770
衝突しない前提なら、衝突したときのリトライ処理等は不要だ
つまり衝突したときの対処してるかって質問だろ
0772NAME IS NULL
垢版 |
2021/01/10(日) 18:59:06.79ID:???
それはエラーをどう扱うかという話で衝突しない前提ではないよ
ユーザーにリトライを促すような個別の対処はしてなくても集約エラーハンドラで結局対処してる
0773NAME IS NULL
垢版 |
2021/01/10(日) 20:54:05.63ID:???
だから、UUIDが衝突したときに個別の対応してるかって質問なんだが
まあ、お前がやってないだろうことは理解した

GUIDが衝突したって話は聞いたことがある
UUID衝突の可能性はゼロではないんだが、まあ起こったときの重要度次第か
0775NAME IS NULL
垢版 |
2021/01/10(日) 21:33:58.44ID:???
UUIDやULIDって衝突した事を想定した方がいいの？
だったらオートインクリメントで良い気がする。
0776NAME IS NULL
垢版 |
2021/01/10(日) 21:36:18.27ID:???
トランザクションが失敗したらリカバリなりするだろうが、キーの重複が原因の時だけ特にどうこうってのはないんじゃないかね
0777NAME IS NULL
垢版 |
2021/01/10(日) 22:06:27.15ID:???
オートインクリメントのように一箇所で採番できる状況ならUUIDは使わないよ
0778NAME IS NULL
垢版 |
2021/01/10(日) 22:26:37.20ID:???
プロシージャー書いて自前で発番すれば良いのではないか
0779NAME IS NULL
垢版 |
2021/01/11(月) 18:12:04.80ID:???
UUID/ULIDよりも18禁商品マスタのほうがいかにもDB設計っぽい内容にもかかわらずレス数が桁違いになるのはなぜなんだ？
0780NAME IS NULL
垢版 |
2021/01/11(月) 19:03:34.36ID:???
>>747ならどっちが正しいと決まるもんでもないから、追加情報でもない限りそれ以上話が広がらないし
単純に内容がつまらない。
0781NAME IS NULL
垢版 |
2021/01/11(月) 21:33:51.50ID:???
設計スレなのにどっちが正しいか決まるようなものを期待してるのか
理解に苦しむ
0782NAME IS NULL
垢版 |
2021/01/11(月) 22:15:19.50ID:???
質問者はどっちがいいか聞いてるわけだろ？でもどっちでもいいから話はそこでおしまい。
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況