頼むから正規化しろよ　第二正規形

ニコニコ動画のコメントやアマゾンのレビュー、youtubeのコメントなど
1対多の関係はどういうデータベースの構造になっているんでしょうか？
自分は以下の3パターンを考えたのですがどれも疑問が残ります。

案1：1つのレコードに動画番号とその動画に対する全てのコメント番号を収納する
動画1, コメント1コメント2コメント3コメント4
動画2, コメント1コメント2
欠点：・コメント数が有限になってしまうのではないか。
　　　・複数のコメントが一つのコラムに収納されている場合、
　　　　１つのコメントの追加によってそのフィールド全体を更新しないといけないから
　　　　重いのではないか。

案2：コメント主導で動画番号を対応づける
コメント1, 動画1
コメント2, 動画2
コメント3, 動画1
コメント4, 動画3
欠点：動画を見る度にコメントの抽出をしないといけないから重いのではないか

案3：各動画毎にコメント用のテーブルを用意する
動画1のコメントテーブル：
コメント1
コメント2
コメント3
動画2のコメントテーブル：
コメント1
欠点(?)：動画の数だけテーブルを用意することになるけど、
　　　　自分はどうプログラミングするのか分からないです。

>>235
リレーショナルデータベースでのデータ設計は、プログラム言語のように構造体で
カタチを決めて配列やリスト構造を持たせていくデータ設計と違って、集合論理と
関連の概念で解決しないとダメなんだよ。

↓こんな風に持たせればそれらしくなるんじゃない？

【投稿動画テーブル】
　動画ID　　　会員ID　　　　　投稿日時　　　　　　動画データ　・・・
---------+----------+---------------+----------+---
sm1234567　nv1000000　2008/10/21 11:25　mov999999　・・・
sm1234568　nv1300000　2009/01/13 18:31　mov888888　・・・
sm1234569　nv2000000　2009/07/02 09:05　mov989898　・・・
sm1234510　nv1000000　2009/12/25 23:41　mov010101　・・・
　　　：　　　　　　　　：　　　　　　　　　：　　　　　　　　　　　：

【投稿コメントテーブル】
　動画ID　　タイム　　コメント
---------+-----+-----------------
sm1234567　00:01　wktk
sm1234567　00:03　高画質
sm1234568　01:52　ああああああああ
sm1234567　00:08　ﾃﾗ画質ｗ
sm1234567　00:12　ｷﾀｰ!
sm1234510　00:02　ｗ
　　　：　　　　　　：　　　　　：
sm1234567　01:32　これはすごいな
sm1234567　01:40　たしかにｗ
sm1234569　03:02　おおおおおおおおっ！
sm1234567　01:59　うｐ主様、乙でした

そもそもRDBかどうかも疑うべきだと思うけど。

>>237
ありがとうございます。
つまりそれは案2で、動画を見る度に
全てのコメントを収納した巨大な投稿コメントテーブルから
動画IDでコメントの抽出を行うんですよね？
それって重くないんでしょうか。
案3だと抽出処理が要らないんで軽いのかと思ったんですが
そんな大差はないのかな。。

>>239
案ずるには及ばないと思うよ。インデックスとサーチのアルゴリズムは高度だから。
この程度のデータなら、RDBMSで数万件からの抽出でも、あっという間な筈。

あと他の方法となれば、制限を設けて自前のアルゴリズムで管理するしかないね。
WindowsならVC++やVC#、VBなどでサービスプログラムを組んで、Webページの
サーバーサイドから呼ぶとかね。
ハッシュアルゴリズムとか独自方式とか好きな技法でカスタムメイドできるよ。

>>238
ニコニコはMYSQLだと聞いてる。

>>238
現実的に考えて、RDB以外にないだろ。

多くの工業科＆組込制御系育ちはRDBMSをなかなか理解できないらしい。
自分をCPUに見立てたプログラム実行ロジックで考えてしまう癖が抜けなくて、
データの順番や個数、アドレス問題はポインタで解決済みの早見表として
オンメモリですべてを掌握していないと納得できないという。

役割分担や分散処理が苦手で、すべて自分のプログラムだけでやろうとする。
そして孤高だったりする。

>>242
動画番号に対して固定長（古いコメントは消えるので）のコメント領域を返すkey-valueじゃだめ？

>>244
現時点のいろんな意味で、その実装に
もっとも適しているのがRDBだろ。

>>245
non-Relationalなkey-valueで済むなら、そのほうがスケーラビリティとかパフォーマンスで有利では。

それだと重くならないかとか・・・、固定長の領域を返せばとか・・・って、ちょっと違うんじゃね？

なぜ動画投稿コミュニティサイトのような規模のシステム全体を、同じCPUとメモリの配下で
動作する単一のプログラムやプロセスとして考えるんだよ。スレ的にも当然RDBMSを使い、
サブシステムごとに分散処理だろｗ

結構昔だけどYouTubeなんかはBigTable使い始めたってどっかで読んだ。

>>247
>同じCPUとメモリの配下で動作する単一のプログラムやプロセスとして考える
何のことを言ってるのかちょっと分かんないです><

4月1日からDBの仕事するようになって1週間だが、早くもタイトル通りの叫び声あげたくなった。
これが現場のDBって奴なのか……

既存なら泣く
設計中なら正規化を押し通せ

設計は完全に終ってる。
既にシステムの一部は稼働していて、リリースまでに間に合わなかった機能を実装している段階だ。

自分の視野が世界の全て病

正規化について勉強を始めたのですが
一人の人に複数の趣味のフィールドを持たせたい場合は
どうするべきでしょうか
shumi1,shumi2のようなカラムを作るのは非正規と理解しています。
趣味のテーブルを分けて、shumi_idという外部キーでやるとした場合

name shumi
kiteretu 1
kiteretu 2

の様に重複するフィールドが出てくるので正規化はされていない
と思っています。どうすればよいのか教えてください。

第4正規形になるね。
正規形を崩すかBCNFにしてFKで整合性を取るかじゃないかな

>>254
普通に第二正規形ではない。例えばリレーションpersonが以下の
ようであるとして、

person(person_id, name, gender, shumi_id)

で仮に一人の人が複数の趣味を持つとすると、このリレーション
の候補キーは(person_id, shumi_id)になる。
でもnameやgender(性別)といった非キー属性はperson_idにだけ
関係従属する。

person_id -> name
person_id -> gender

テーブルの候補キーに完全関数従属していないので非第二正規形。
これを第二正規形にするには、部分従属する非キー属性nameと
genderを別のリレーションに分ける。

person(person_id, shumi_id)　候補キーperson_id, shumi_id
person2(person_id, name, gender)　候補キーperson_id

まぁ実際は後者のリレーション名をpersonにして前者は
person_shumiとかにすると思うけれどもね。

>>255
>>256
ありがとうございます。
なんとか理解できそうなので、続けてサンプルを見まくります。

web土方でSQLもろくに使えねえし設定もできねえし
正規化もろくにできてねえし
お前ばかなの？しぬの？
っていったら

得意気に黒い画面だして　ポストグレ起動して手動でinsertやりまくって追加してた

脳味噌がかわいそうだった

かわいそすぎて泣いた

>>258
何を言っているのかよくわかりません。
あなたもかわいそうな人に見えます。

5年くらい昔であろうか？
有名なSlerが受注した外資系企業のシステムで開発者を200人以上集めた。
Oracleのバージョンは忘れた。

既にメンバーからはずれた人が設計したという500列だったかの
ワークテーブルなるのものがあって、正規化した各テーブルから
データをかき集めてワークテーブルでまとめて更新。

新たに参加したメンバーは必ずこの仕様ではプログラムは書けない、
ワークテーブルも削ろう、と進言したが、現テーブル設計担当は
ぐずぐずしているだけでまったく動かず。

動的SQLを多用しないとプログラムを書けず、当然プログラム・バグが
多発。残業・徹夜してもバグの原因がなかなかわからず。

結局、社長命令でシステム開発は中止。
改めて開発予算を確保してテーブル設計からやり直すことに。

得るものは何もない、むなしい仕事だった。
テーブル設計担当を大雪山に生き埋めにしてやりたかった。

正規化は大切だぞ。

>>260
ああ、解るわー。

その500列を作った技術者は、コボラーじゃないか？
あと列の名前も意味の無いコードで定義されていたりした？

コボラーにテーブル設計をやらせては駄目だよな。

物理名は英字＋数字の連番な

アラフォーCガリガリプログラマなんだけど、担当者が逃げたASP.NETのシステムを
見ることになってそのままDBの勉強始めたんだけど、DBってこんなに面白かったんだね
正規化とか考えてると楽しい
DBの講習会とか「興味ない」とサボってたのを後悔した

ただSQLはつまらんね
なんでこう、表示、更新、追加でこんなに文法違うんだよ
考えたやつ、頭おかしいだろ

COBOL文化の人って、CHAR型好きだよね。
枝番 … EDA CHAR(2) とか。

あと制約付けるのが嫌いで、FETCHが好き。

正規化してないバカが作ったやつのWEBアプリが
すべてそのままデータぶち込んでてプライマリーすらわかってねーみたいで
頭おわってんなっておもったわ

SQLも理解できないカスグラマも世の中たくさんいるしな
WEBバカはかすばっかりだよ
とくに3キモ言語使ってるやつらな

一方で、DWH見て「ぜんぜん正規化とか理解してない、これ設計したのコボラだろwww」
みたいなこと言う奴もいたりするけどな。

>>266
オレの事か？

本気でコボラーにはテーブル設計して貰いたくないと感じてる。

>>267
何もわかってないw

「コボラー」よりRDBをわかっているというのが唯一の自慢な人は所詮そんなもんw

DWHってなんぞやと検索したら納得

>>267
何もわかってないｗｗ

いやいやいや！
DWHは、正規化が完了してから正規化崩しを行っていくんだろ。

コボラーの奴は、正規化が不完全な状態から正規化崩しを行うからｇｄｇｄなテーブル設計になるんだって。

もっと流れよめ

頭が悪いのに付ける薬はないってことだ

>>271
マジレスすると、DWHではそのような方法はとらない。
そもそも正規化というのが更新異常を防ぎデータの一貫性を保つための考え方である以上、
個々に更新を行わず、ETLであらかじめ一貫性を整えたデータを一括してロードするDWHには
必要のないもの。

性器化の意義：項目間の相関性を極小にし記憶効率を改善する。性器化のしすぎは
多くの場合検索性を損ね、時には信頼性も下げる場合がある。

非性器化の意義：項目間の従属性を許可する。記憶効率は下がるが、多くの場合に
検索性が向上し、時には信頼性が向上する場合がある。

>>275
アホちゃう？

パーでんねん

第一正規化まで終わってる、つまり１枚の大きなテーブル（4Gくらい）があるんですが、自動でその後の正規化をやってくれるソフトってないですか？
知っている人がいたら教えて下さい。

検索用にタグ機能を作りたいんですけど
どんなテーブル構造にするのが一般的ですか？

｜　記事ID　｜　タグ　｜
で記事IDを重複キーにするか

｜　記事ID　｜　タグ１　｜　タグ２　｜　タグ３　｜　・・・　｜
で記事IDをユニークキーにするか

タグの上限は未定です

>>279
要件次第だが

｜　記事ID　｜　タグ　｜

で記事IDとタグを主キーにするかな

>>279
> ｜　記事ID　｜　タグ１　｜　タグ２　｜　タグ３　｜　・・・　｜
> で記事IDをユニークキーにするか
おいおい第一正規形にすらなってないぞ

保守age

保守

テーブル設計（正規化）のアドバイスをお願いします。
メインテーブルがあり、フィールド数は全部で70程です。
主キーに対して従属はない状態（第二正規化）なのですが、
レコードが同じ内容で繰り返される各フィールドをテーブルに切り出す（第三正規化？）と35もマスタテーブルが出来てしまったのですが、
このテーブルとトランザクションテーブルをリレーションシップしてからクエリで全てのフィールドを再度結合する場合、
結合線もすごい数になってしまいますが、このような状態（数）は正規化出来ていないことになるのでしょうか？
各マスタテーブルは主キーとフィールドが一つのものばかりです。