DB設計を語るスレ 6

1 ：2012/06/30 〜 最終レス ：2013/09/09

語れ
前スレ
DB設計を語るスレ 5
http://toro.2ch.net/test/read.cgi/db/1331558806/
DB設計を語るスレ 4
http://toro.2ch.net/test/read.cgi/db/1309828440/
DB設計を語るスレ 3
http://hibari.2ch.net/test/read.cgi/db/1269585561/
DB設計を語るスレ ２
http://pc11.2ch.net/test/read.cgi/db/1223458453/
DB設計を語るスレ
http://pc11.2ch.net/test/read.cgi/db/1166540159/

2 ：

関連スレ
何故データベース設計は軽視されるのか？
http://toro.2ch.net/test/read.cgi/db/1228061247/
頼むから正規化しろよ　第二正規形
http://toro.2ch.net/test/read.cgi/db/1116097001/
【より良い】データモデリング【モデルを】
http://toro.2ch.net/test/read.cgi/db/1057509675/
T字形ER（TM)ってどうよ？
http://toro.2ch.net/test/read.cgi/db/1156946197/

3 ：

TMのリンク入ってて嬉しい。
ERなんてTMの補強理論でしかないのに、本屋行くとこればっかだな。

4 ：

最近DB始めてブログとかニコ動とかでよくあるタグ機能を作ろうとしてるんだけど一般的にはどう作るんだろう。
今考えてるのは
・タグ用のカラムをひとつ用意して、全部のタグをタブ（など）で連結してひとつのセルに入れる
・カラムを10個用意して1カラムごとに1タグずつ入れる
検索とかで効率良さそうなのは前者に思えるけど、もっと頭良い方法があったら意見を聞きたいです。

5 ：

>>4
> もっと頭良い方法があったら意見を聞きたいです。
まず、DB設計のスレで「セル」とか言うのを止める。

6 ：

正規化、非正規化でぐぐれ

7 ：

RDBに限定することもないだろ。

8 ：

レストンです。正規化とか一応概念だけは頭に入ってる感じですがなにせ経験が伴ってないんでよくわかってないのが正直なとこです。
できたら「俺ならこういう設計にするぜ」みたいな先人の方法論を聞いてみたいな、と。
ちなみにPerl+SQLite3で作ってます。いつかはログインが必要なDBも使ってみたいね…
>>5
どう呼ぶか知らないのでセルって言ってるんだけど普通はどう呼ぶのでしょう？ マス目？ｗ

9 ：

>>8
正規化の概念があるなら
>全部のタグをタブ（など）で連結してひとつのセルに入れる
がありえん事ぐらい解るだろうに
>どう呼ぶか知らないのでセルって言ってるんだけど
>カラムをひとつ用意して(中略)セルに入れる
用意したんならせめてそれに入れようぜ
先人の方法論は、本屋いけばいっぱいあるから
DB設計の初心者向けの本買って読め

10 ：

>>8
参照だけじゃなく更新や検索、集計したいときに
どんなクエリを書かなくてはならないのか想像するといいよ
正規化の必要性が理解できるようになるから

11 ：

>>9
ありえんこともわからんから素人なんだなｗ
ということはタグ検索をしたい時は WHERE col1='タグ' OR col2='タグ' ... ってカラムの数だけ並べないといけないのか…な
DBの本は一応持ってるけど説明がまわりくどくてわかりにくいんで明日にでももっと易しいのないか探しに行ってきます。
>>10
正規化のことはまだ理解できてないけどDB使う上では避けて通れない道って程度にはわかってるんで色々作って数こなしながら身体で憶えていこうと思います。
実際に作って実際に使って、このやり方だとどういう時にまずいことになるのかってのは時間かけて自分で経験しないとなかなか憶えられないしね…
場違いな素人の相手してくれて�dです。

12 ：

>>11
つまり正規化の概念も頭に入ってないんだな
お前の提示した方法はどっちも(RDBでは)普通はやらない
普通は１レコードでタグ一つで、そのタグと親を紐つけるんだ

13 ：

>>12
その普通が理解できてないから素人なのでございます。というかズブすぎる…
なるほど、普通はそんな感じにするんですね。参考になります。
とりあえず具体的にどういうテーブル構成にしたらいいのか自分で考えてみます。
その後で本屋行こう。

14 ：

本屋行って勉強してそれから考えたほうが良いと思うんだが

15 ：

>>14
ごもっともですｗ
でもせっかくヒントもらったことだし、ロジック？を考えるのも楽しいし、
回答を見る前に少し余分に回り道してみようかな、なんて…

16 ：

プロフを参照するとこの方、銀歯を作る仕事をしていたそうで（微笑）
道理で、物作りの厳しさ、商売の難しさどれを取っても何一つ理解しておらず、
突っ込み所満載なわけです
しかも過去形である所を見ると景気に関係なく黙ってても患者が来る、
病気や虫歯を直す商売でさえ勤まらなかったということでは（笑）
銀歯と金型では要求される精度も品質もまるで違います
質問者が何を作りたいのかが明らかにされていないため分かりませんが
趣味のようなもの、とおっしゃるなら趣味の掲示板で相談されたらいかがでしょうか
その分野の同好の士が良い方法を知っているかもしれませんから
もちろん、趣味の世界といえども技術は只で教えてもらえるほど甘くはないという事を肝に銘じておくべきでしょう

17 ：

↑のキモい文章はなんなんさ

18 ：

DBの設計で質問があります。
クラスの時間割(6時間)を5日分DBに登録するとします。
これを一つのテーブルに登録すると30行になると思います。
後で水曜日の時間割が一時間増えたってなったとき、
挿入しようとしてもDBって末尾にしか追加できないから、
その追加した水曜日の1時間だけ31行目に追加されてしまい、
GUIベースで表示しくてれるツールでDBを見たときに汚くなってしまいます。
なので月〜金までのテーブルを５つ作ったほうが、
後から追加しやすくなるかなと思ったのですが、どっちがいいでしょうか？
最初の方法でもどうせ曜日で検索かければデータとしては取得できるのでいいかなと思ったのですが、
実際は皆どうやってるのかなーと思いまして。
基本的にDBって書き込まれてる場所はどこでもよくて、
表示するときにちゃんと表示できれば問題ないって感じですか？
実際の現場でも？
アドバイスください

19 ：

＞基本的にDBって書き込まれてる場所はどこでもよくて、
＞表示するときにちゃんと表示できれば問題ないって感じですか？
パフォーマンスに問題ない限りこれでいい

20 ：

>>19
あざっす！
気が楽になりました！！！

21 ：

ID　数値
曜日　文字列　--月曜日
時限　数値　--1
教科　文字列　--数学
クラス　文字列　--1-A
曜日を文字列にしたが1を月曜7を日曜とかに見立てた数値でもよろしい
select 時限, 教科 from t where クラス='1-A' and 曜日='月曜日' order by 時限
1-Aの月曜日の時間割
どういうデータが欲しいかとか
登録数の規模によって後は適当に正規化すればよろしい

22 ：

>>21
おお〜！すげえ！
ありがとうございました！

23 ：

>>挿入しようとしてもDBって末尾にしか追加できないから
まずこれに突っ込んでやれよお前ら
基本として行の格納順序には意味がないってのが原則だぞ
行の格納順序は追加した順とはかぎらないし、出力される順序も指定しなければ不定
数十行程度のテーブルなら、実際の格納順序まで考慮する必要性は少ないと思うけど
そのへんはDBMSの実装に大きく依存する

24 ：

CHECK制約をDB側に書きまくるか
プログラム側でチェックしてDBにはプログラムからそのまま値を通すかで悩んでますが
どちらが一般的でしょう？

25 ：

制約は無しの方向で

26 ：

ありがとうございます
なしの方向でいきます

27 ：

性能に問題ないなら、両方やればいいと思うが…
まあ、CHECK 制約書きまくるとインポートの時に苦労したりするけど。

28 ：

性能うんぬんより、DBの保全のために制約が必要なわけで
そのプログラムがバグったときに、DBに不正なデータが格納されて良いなら
制約つけなくてもいいよとしか
単一のプログラムからしか使わんDBなら、制約なしでもいいけど
複数システムから使うようなDBなら、単一システムのバグで全システムがバグるぞ

29 ：

>>28
> DBの保全のために制約が必要なわけで
そんなことはわかってて、それでも性能足りないとどうしようもないことがありえるから
アホな突っ込み防止のために念のために「性能に問題ないなら」って書いてあるんだが、
それでもアホな突っ込みする奴はいるんだな…
> 単一のプログラムからしか使わんDBなら、制約なしでもいいけど
意味わからん。
単一のプログラムからしか使わないなら不正なデータ格納されていいのか？
データベース覚えたて厨房のアホレスにしか見えないぞ。(w

30 ：

イライラし過ぎｗ
暑いならエアコン使え

31 ：

８時頃はエアコンなしでもそんなに暑くなかったけど？
というか、>>29 がいらいらした文章に見えるなら、
君こそエアコンの冷風頭にあててた方がいいと思うぞ。(w

32 ：

>>29は夏休み仕様だろｗ

33 ：

悔しいねぇ。(w

34 ：

プログラマは他のプログラマを信用せず、
DBAはプログラマを全員信用しない。

35 ：

>>29
お前が制約の意味を理解してるとして、それが>>24に伝わってると思うか？
つか、お前の所は性能＞保全性なのな

36 ：

>>35
どうみても >>24 は、制約の意味を理解していると思うが。
伝わっていないと言う理由でもあるのか？
> 性能＞保全性なのな
別に DB でしか保全性が保てないわけじゃないだろ、馬鹿じゃねーの？

37 ：

>>36
すくなくとも>>24が、制約の意味がDBの保全にあると思ってるようには見えん
それが解ってるなら、アプリでのチェックで代替出来るようなもんじゃないと解るからな
>DB でしか保全性が保てないわけじゃないだろ
おまえ、DBの保全って意味理解してるか？
たとえばDBからみた不正な操作に対してDB側でどう防御できるかって話だぞ

38 ：

>>37
>たとえばDBからみた不正な操作に対してDB側でどう防御できるかって話だぞ
誰もそんな話してないし。
今回の件は、DBに入れるデータのチェックをアプリでやるかDBMSでやるか、は
たまたその両方でやるかと言う単純な話。
勝手に違う言葉出してきて、自滅してるアホがいるみたいだが。(w

39 ：

例えばJavaScript→Perl→DBを例にあげると
最初のJavaScriptからPerlはクライアントサイド→サーバサイドだから
JavaScriptでチェックをしていてもすり抜けてくる可能性があるので
Perlでもチェックしないといけない
次のPerlからDBはサーバサイド→サーバサイドであって
Perlでチェックしたものは十分信頼にあたるはずなのでそのまま突っ込んでも問題ない
ただlocalhostじゃなくサーバをまたぐ場合は途中で改変される可能性はなきにしもあらず

40 ：

>>39
>Perlでチェックしたものは十分信頼にあたるはずなのでそのまま突っ込んでも問題ない
いや、DBを複数かつ異種のAPがアクセスするシステムであれば必要だ
　JavaScript→Perl→DB←Java
この場合、片方の更新処理にバグがあった場合、他方へ予期できない障害が発生する可能性がある
だからDB側でもチェックは必要（これが誰かが言ってる「保全性」の意味だと思う）
まあDB設計の時点で単一APであることが「将来に渡って保証」できるのなら、
あるいは新規開発だけ請け負って保守せず逃げ出せる立場ならかまわんのだろうけどね

41 ：

普通は単一なのでは

42 ：

将来の話まで保証できるシステムなんて一つもない
現状の可能性で判断すべき

43 ：

何で複数にこだわるんだろう…
単一の AP でも、バグって DB 壊すこともあるし、
複数でもきちんとテストされててうまく動いているシステムももちろんある。
そもそも単一のAPでも、複数のモジュールで構成されてて、複数人で開発していることもあるんだし。

44 ：

JavaScript→Perl→DB←Perl←Java
普通こういうふうにするのでは？
Perl以外からは直接DBを操作させないで
Perlで用意したAPIを他のアプリケーションで叩くみたいな使い方で

45 ：

>>43
可能性の問題だな
単一システム前提なら、DB設計者とアプリ開発者の意思疎通がやりやすい
新規開発なら、DB設計もそのシステムに合わせて設計できるから問題が起きにくい
怖いのはプログラムのバグじゃなくて、設計段階での食い違い

46 ：

他社が作ったすでに動いてるシステムのテーブルを
更新する別のシステムを新規でつくった。
しかもその他社システムはテスト環境が無い。オワタ。

47 ：

>>45
>可能性の問題だな
まあ、そういうこと。
単一かどうかの問題じゃない。
プログラムのバグも怖いよ…

48 ：

アプリでやるのは当然として、
複数のプログラムから参照•更新するテーブルは、極力DB側の制約も入れとくのが吉。
ナチュラルキーの一意制約、日付型以外のNull禁止、フラグや区分も取りうる値のみ許可、項目間の整合性ルールなど。

49 ：

まだ複数とか言ってるのか…
単一でも極力やるべきだと思うが。

50 ：

フラグや区分は微妙だな。

51 ：

DQ10のバザーってSQLでも実装可能だろうか
どれくらいのテーブルが必要なのだろう

52 ：

ネットショップでの注文に対し、
○○をした日時、××をした日時など操作した日時を記録したいのですが、
どの方法がいいでしょうか？
１．注文テーブルに操作の数だけカラムを追加する
２．別テーブルを作り、操作の数だけカラムを作る（注文テーブルと１対１）
３．注文番号、日時、操作内容のカラムを持つテーブルを作る（注文テーブルと1対多）
１のメリット・デメリット
○構造がシンプル
×カラムが非常に多くなる
２のメリット・デメリット
○注文テーブルのカラムは増えない
×構造とSQLがわずかに複雑になる
３のメリット・デメリット
○操作を複数回行った場合も各回の日時を記録しておける
○操作の数が増えた場合もカラムを増やさなくてすむ
○注文テーブルのカラムは増えない
×構造が複雑
×SQLが複雑、遅くなる
あと、２を採用する場合、注文テーブルにインサートするとトリガーで時刻テーブルにも
インサートし、デリートも制約で行うというのはどうでしょうか？

53 ：

一つの注文に対する操作が、事前に完全に限定できるのでなければ１も２もあり得ん
この程度で構造が複雑とか言ってるレベルでネットショップとか話にならんぞ

54 ：

３の場合、最終○○時刻を出すには
SELECT order_no, (SELECT MAX(time) FROM logs WHERE logs.order_no = orders.order_no AND operation='XXX') AS last_XXX_time, ...
のようになりますよね？
operationの種類が30個あって、ordersが10万行くらいあってもパフォーマンスは大丈夫ですかね？

55 ：

それ、逆に1/2でやったら相当複雑なクエリになるしスピードも出ないだろ。
ほとんどfull-scanになるし。
もしそのクエリの速度が本当に問題になるんなら、最終操作時刻のみを
別テーブルで管理するんだな。

56 ：

今時のサーバスペックで考えたら
種別、日付、数値ぐらいしかないレコードサイズなら１０万行とか余裕
フルスキャンしても待てるぐらい
数千万行オーダーになってから心配しろ。それでも適切にインデックス効けば余裕だが

57 ：

MySQL InnoDBで実験してみたところ、orders30万行、logs150万行、サブクエリ30個でも
ちゃんとパフォーマンスが出たので、大丈夫そうでした。
説明不足だったかもしれませんが、
>最終操作時刻のみを別テーブルで管理
これが２ですね。
>種別、日付、数値ぐらいしかないレコードサイズ
これはlogsのことですね。ordersが10万行の場合、logsはその数倍になる見込みです。

58 ：

>>48
こんなDB使えない。
ビジネスロジックをDBの制約で実装するなんて論外。
アプリの不具合をDBでフォローしないといけないなんて運用に問題あるでしょ。

59 ：

ビジネスロジック？
※ こういう人は、アプリの不具合で OS API からエラー返されても文句言うんだろうか…

60 ：

そもそもビジネスロジックをDBの制約で実装しろなんて誰か言ってるか？

61 ：

>>60
>そもそもビジネスロジックをDBの制約で実装しろなんて誰か言ってるか？
>> ビジネスロジックをDBの制約で実装するなんて論外。
バカの上塗り。(w

62 ：

日本語読めない奴がいるな。
誰もそんな実装しろとも言ってないのに、そんなの論外と言う>>58がアホだという意味だろ。

63 ：

一つのテーブルに履歴番号を持たせて、最新のデータと履歴を同一テーブルに保持するやり方って古いように思うのですがどうでしょうか？
顧客テーブルに、
顧客番号　履歴番号　名前
0000001　　01　　　山田太郎
0000001　　02　　　山田太郎
…
みたいな持ち方をして、履歴番号が一番大きいレコードが最新のデータとなります。

64 ：

履歴番号じゃなくて日付（変更日）を持たなくて良いのか？

65 ：

63ですが、変更日付、変更ユーザIDなんかは全てのテーブルに持っています。
上の例で言えば、顧客番号と履歴番号でプライマリキーになるので、
外部キーが非常に張りにくい(と言うか事実上不可能)構造になっちゃってるのが、
少しアレかなー？と思っています。
しかもレコードを検索する際に副問い合わせ必須ですし…。

66 ：

じゃあどういうのが新しいんだ？
つか最新状態と履歴と別テーブルに持つ設計だって昔からあるけど

67 ：

どこまで正規化するかっちゅう話し
そんなのプロジェクト毎に違うっちゅう話し
でも履歴くらいは分けろっちゅう話し

68 ：

履歴を１テーブルに持つか別テーブルに持つかは、正規化の話じゃないし

69 ：

いや正規化だろ

70 ：

>>68
正規化を考えて普通にDB設計すれば、顧客(そのもの)と顧客履歴は別々のエンティティになるよね
・顧客(顧客ID, 取引開始日時)
　　　-- 顧客IDがプライマリキー
・顧客履歴(顧客ID, 履歴番号, 履歴変更日時, 名前, 住所, メールアドレス, ...etc)
　　　-- 顧客IDと履歴番号との対(つい)でプライマリキー
　　　-- 顧客IDは顧客テーブルへの参照キー
人は引っ越しがあれば住所や電話番号は変わるし、氏名も結婚で変わることがある
でも、もしも顧客そのものに一意性(identity)が無ければ(無くしたDB設計にしてしまえば)、
後々の監査の時に、ある対象顧客の取引記録を追跡できなくなる
(あるいは社会保険庁での事例の様に、血税を使って人海戦術で追跡することになる)
ここで、もし「正規化」を崩すのであれば以下のようになるけど、これをOKとするのかな？って話だ
・顧客(顧客ID, 取引開始日時, 履歴番号, 更新日時, 名前, 住所, メールアドレス, ...etc)

71 ：

>>70
リレーションの正規化は本来、値とその関係に基づいて行うものであって、
エンティティという考え方はないよ。

72 ：

開始日があれば履歴番号は要らないだろ。

73 ：

開始日じゃなくて変更日だった。

74 ：

1日に1回しか変更できない仕様ならね

75 ：

顧客情報が一日に2度以上変更されたら上書きするだろう。

76 ：

つかお前ら前提となる要件も確認せずに好き勝手言いたい放題だな

77 ：

まぁ大体言いたいことは上で言いたい放題言われてるわけですが、
顧客マスタとか受注トランザクションとかの件数が多く、
将来的にも増える可能性が高く、且つ更新頻度が高いテーブルで、
この手の設計すると、レコード数が実データに比べても数倍に膨れ上がるため、
パフォーマンス面でも良くないと思う次第です。

78 ：

>>77
これにて一件落着なのか？

79 ：

まったく解決してないとも言えるが、そもそも別に何も問題などないからな
単にとある設計をみて古いとか言い出した奴がいるだけで

80 ：

まぁ単なる相談なんで、こう言う設計も普通にあるんですね、と言うことで。

81 ：

>>74
>1日に1回しか変更できない仕様ならね
「履歴変更日時」にするだけじゃん、バカなの？

82 ：

>>81
顧客情報を時間単位で変更する馬鹿が居るのか？

83 ：

それは仕様を決める奴に言ってくれ。
そんなバカな仕様でも対応は簡単だと言ってるだけなんだから。

84 ：

>>81
> 「履歴変更日時」にするだけじゃん、バカなの？
お前のほうが馬鹿だったわけだがｗ

85 ：

意味わからん、どこがバカなのか説明してみな。

86 ：

完全な履歴をとれって要件で、日時の分解能以上の頻度で更新された場合を考えると
日時じゃ無理だわな
それ以上の話はDB設計の話じゃなくて要件と仕様の話だから他所でやってくれ

87 ：

顧客情報がミリ秒以下で更新とか？(w
もやは反論したいだけの詭弁だな。

88 ：

要件の話は他所でやってくれるかな

89 ：

要件じゃなくて常識の話しだな。

90 ：

でも履歴と現在のデータを同一テーブルに持たせると、
データ件数が本来の件数の数倍になっちゃうし、
検索時も履歴番号なり履歴更新日時なりの指定が必須になるから、
プログラムミスとかにもつながるし、
設計としてはまずい気がするけどな。

91 ：

>>90
良く読めば顧客マスタと顧客履歴のことを話題にしているのは分かると思うよ。
日付（日時）は当然履歴のこと・・・

92 ：

>>90
データ量の件は場合によるけど、最近の環境だとよほどでない限り問題になることは
少ないと思う。
検索時の指摘はそうだけど、ビュー作っとくとかでなんとでもなるでしょ。

93 ：

カテゴリ登録みたいに、1つのカラムに複数登録するとき、
たとえば1の記事は
1,2
1,3
1,5
みたいに２，３，５のカテゴリIDを登録するためにレコードを三つ追加してるんですが、
あとからこれを修正するときは、一度deleteで1の記事のレコードを全部消して、
全部再登録した方が早い気がします
それともそれぞれの組み合わせが存在すれば更新 or 削除って形にしたほうがいいでしょうか？
後者の方がsql文を実行する回数が増える気がするのですが。。

94 ：

適切なインデックスがあればどっちでも大差ないだろう
まあDELETEする行が大量になるようならUPDATEのほうがいいだろうけど
あと最近のSQL標準ではMERGE文（いわゆるUPSERT操作を行う文）
なんてものもある

95 ：

>>94
ありがとうございます。
でもupdateする場合だと、事前にselectでその組み合わせが存在するか調べて、
あればupdate、なければinsertって複雑になるしselectの処理が一回増えるので無駄かと思いました。
大量って言ってもせいぜい10個ぐらいですので、一旦消してからinsertするようにします
ありがとうございました

96 ：

入力画面にて、
選択項目により次の入力項目が枝分かれしていくような場合、
どのようなDB設計にするのでしょうか。

97 ：

馬鹿には無理なので誰かに頼みなさい。

98 ：

それだけ聞かれてどう設計すれば良いかなんて答えられる人間がいたらすごいと思います

99 ：

まあ、階層的な選択項目を管理したいんだろうなとエスパーしてみる。
一例はこんな感じ…
create table menu (Id int primary key, Parent int not null,Item text);
insert into menu values(1, 0, 'Man');
insert into menu values(2, 0, 'Woman');
insert into menu values(3, 1, 'Dotei');
insert into menu values(4, 1, 'kimoota');
insert into menu values(5, 2, 'bishoujyo');
insert into menu values(6, 2, 'busu');
insert into menu values(7, 2, 'BBA');
トップレベルのメニューは Parent = 0 で検索
select Id, Item from Menu where Parent = 0;
1|Man
2|Woman
で、例えば 'Women' が選択されたら Id = 2 とわかるから、Parent = 2 で検索
select Id, Item from Menu where Parent = 2;
5|bishoujyo
6|busu
7|BBA
以下同文…

100read 1read

1read 100read
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲

Oracle 質問総合スレ9 (266)
RDBMS比較総合スレ 【サーバ】 (105)
dbMAGICを超えるDBMSは未来永劫現れない。 (225)
mysqlについて語ろう (139)
ＤＢのキャラ、ここが好きだ！ (117)
Oracle 質問総合スレ9 (266)
--log9.info------------------
SW＝渡邉せいじって強いの? (778)
■□■柔術衣�Z■□■ (268)
剛柔流空手道 その13 (161)
剣道総合其ノ三十二 (453)
{右へ左へ}天然理心流{泣き別れ} (396)
合気道家の弱点を教えてください (713)
【ﾘﾆｭｰｱﾙ】ワールド空手を語ろう【MUGEN編】 (235)
（＾○＾） #揄wじ�o騾 (380)
群馬県の格闘技を語ろう (556)
レスリングのスレ (578)
【竹刀・防具】剣道具を語るスレ【剣道着・袴】２　 (756)
護身術に最適な武道・格闘技は何ですか？part5 (164)
●○●ブルース･リーは反日家だった●○● (160)
【董海川】八卦掌と形意拳のスレ Part3【姫際可】 (273)
■□■科学が伝統派空手の強さを実証■□■ (134)
武術の通信教育を大声で語ろう！2 (291)
--log55.com------------------
SMBCフレンド証券�B
日経新聞ってどこまで落ちぶれた糞なのｗｗ
野村證券金融工学研究センタ−
口座開設が趣味の人(有通帳限定)及び通帳マニアスレ
日本政策投資銀行を語ろう!
【東大卒】外資系金融のイケメン集まれ【エリート】
☆彡秋田銀行☆彡8風雲金融業界
三菱東京UFJでも何でもいいからー