頼むから正規化しろよ 第二正規形
- : NAME IS NULL [] 2005/05/15(日) 03:56:41:43QLdn9b
- 正規化について語りましょう。
前スレ(dat落ち)
頼むから正規化しろよ
ttp://pc8.2ch.net/test/read.cgi/db/1060690405/
- : NAME IS NULL [sage] 2007/10/26(金) 11:24:48ID:???
- 許可マスタ
項目名 field名 型 桁数
コード code varchar2 2
エリアコード1 area_code_1 number 2
判定1 area_judge_1 varchar2 1
エリアコード2 area_code_2 number 2
判定2 area_judge_2 varchar2 1
エリアコード3 area_code_3 number 2
判定3 area_judge_3 varchar2 1
エリアコード4 area_code_4 number 2
判定4 area_judge_4 varchar2 1
エリアコード、判定は全84項目存在するが、途中を省略する
.
.
.
こんなDB定義もうやだー - : NAME IS NULL [sage] 2007/10/27(土) 09:58:27ID:???
- lol
- : NAME IS NULL [] 2007/11/01(木) 01:20:19:zMKsxNgF
- こんなスレもある。
ttp://pc11.2ch.net/test/read.cgi/prog/1179927770/ - : NAME IS NULL [sage] 2007/11/12(月) 21:07:31ID:???
- 会社コードと会社名だけのテーブルに正規化する価値ってあるかな?
JOINのコストが恐ろしく無駄な気がするんだけど。 - : NAME IS NULL [sage] 2007/11/12(月) 21:36:34ID:???
-
「カイシャメイ」 も追加しろ。 - : NAME IS NULL [sage] 2007/11/12(月) 21:39:15ID:???
- そうやってマスタでも管理してトリガで更新したいって提案したら不安な顔をされた。
こういうのはバットプラクティスだったのかな? - : NAME IS NULL [sage] 2007/11/13(火) 11:47:27ID:???
-
会社なら(のいうように)ふりがなとか所在地とか取引状況とか、付帯情報が後から湧いてきそうだから、俺ならマスタにする。
joinのコストがCPUを指してるなら「誤差の範囲ですよ」、開発時のタイプ量を指してるなら「ビュー用意しとくんで」。
つい最近だと、印紙種類(収入印紙と登記印紙)をどうしようか迷った。
「そんなもん、増えた時にシステムの対応が必要だったら、データ増やすだけじゃむりだから(アプリに手を入れるから)」
という理由で、これはマスタ可しなかった。 - : FEQoQDjgtx [zxxiwn@qqbnmr.com] 2007/11/14(水) 04:53:31ID:???
- gBMpor <a href="ttp://http://sflntwpuclbo.com/">sflntwpuclbo</a>, [url=ttp://http://vtoysuqfixvo.com/]vtoysuqfixvo[/url], [link=ttp://http://iarrmvwkbpot.com/]iarrmvwkbpot[/link], ttp://http://poyhgemjrdue.com/
- : NAME IS NULL [sage] 2007/11/17(土) 22:12:21ID:???
-
今の時代、会社名などいくらでも変わる可能性がある。
当然、正規化するべき。 - : NAME IS NULL [sage] 2007/11/18(日) 08:52:47ID:???
-
過去のデータで帳票を出す場合、
昔の名前で出なくなるな。
でも正規化自体は賛成。 - : NAME IS NULL [sage] 2007/11/18(日) 09:52:01ID:???
- 取引当時の社名を出力しなければならないという要件があるなら
そう作ればいいだけで、正規化の有無とは関係ない。 - : NAME IS NULL [sage] 2007/11/20(火) 02:00:19ID:???
- いや、それも本とかでは正規化(というか非正規化)の文脈で語られてるよ
- : NAME IS NULL [sage] 2007/11/20(火) 14:01:50ID:???
- 社名の変更ならその程度で済むかもしれんが、合併とかどうするよ
- : NAME IS NULL [sage] 2007/11/20(火) 17:12:39ID:???
- 合併したら新会社としてデータを起こすとか。
どうせ与信だなんだ大きく変更になるだろうし。
ただ旧組織との紐付けが必要か否かだなあ。
合算して昨年実績としたい、みたいな。 - : あぼーん [あぼーん] NGNG
- あぼーん
- : NAME IS NULL [sage] 2007/11/20(火) 22:25:34ID:???
- 社名と日付を用意するなんてわざわざしなくても
社名変更だろうが合併だろうが別会社として扱えばいい - : NOMO ESTAS NENIO [sage] 2007/11/22(木) 07:49:11ID:???
- >194
(1)取引当時の「社名」を「会社コード」と一緒に「取引テーブル」に書き写せばいい。
社名変更して「会社テーブル」の社名列を更新しても取引記録を打ち出すときは旧社名で出るし、
その会社との取引履歴を出すときにはコードで引けば社名変更に関わりなくすべての履歴を
引き出せる。
(2)もしくは、「会社テーブル」に「旧会社コード」を設けて、社名変更後はレコードを追加して
別の会社として扱うようにするとか。こうすると新会社分、旧会社分の履歴だけを取り出すときに
便利になるし、旧会社の名前も残せる。
(3)「会社系統テーブル{旧会社コード, 新会社コード}」を設けて、社名変更後は「社名レコード」に
レコードを追加して、旧会社のコードと新会社のコードを「会社系統テーブル」に記録するように
すれば、履歴を多対多の関連で残せるので会社合併・分社があっても追跡ができる。 - : NAME IS NULL [sage] 2007/11/22(木) 08:26:10ID:???
- (2)もしくは、「会社テーブル」に「旧会社コード」を設けて、社名変更後はレコードを追加して
別の会社として扱うようにするとか。こうすると新会社分、旧会社分の履歴だけを取り出すときに
便利になるし、旧会社の名前も残せる。
2回以上社名変更や合併を繰り返した場合でも大丈夫でしょうか?
- : NAME IS NULL [sage] 2007/11/22(木) 12:59:43ID:???
- 207じゃないけど、2回以上でも問題ないだろ、単なるリンクリストなんだから
リンクが1レベルしかできないリンクリストなんてないじゃん
ただ、「この会社名の通用期間」みたいなものを設けて、特定の日付がどの通用期間に含まれるかチェックするとか、面倒だよ - : NAME IS NULL [sage] 2007/11/22(木) 20:09:17ID:???
- 吸収された後でまたスピンアウトみたいな離れ業はあるのだろうか
法的には関連性が切れてるだろうから、新しく起こせばいいのかな? - : あぼーん [あぼーん] NGNG
- あぼーん
- : NAME IS NULL [sage] 2007/11/23(金) 23:15:27ID:???
-
(スレタイ)「頼むから正規化しろよ 第二正規形」
おそらく「取引テーブル」の候補キーは、「会社コード」以外の属性も含まれると
考えられ、
「取引テーブル」の「会社名」は、
「取引テーブル」の「会社コード」にのみ関数従属する為、
「取引テーブル」の候補キーの一部に関数従属することとなる。
よって、その「取引テーブル」は、第二正規形とならない。
ではどうするかというと、「会社テーブル」を履歴で作れば良い。
会社テーブル [ *会社コード、*適用開始日、会社名](*が主キー)
新旧「会社コード」もありだろうけど、実装を考えると、
SQLでリンクリストを検索するより、
適用日付で検索した方が明らかにラク。
「取引テーブル」という名前から想像すると、「取引日」という属性を
持ってるだろから、「会社コード」「取引日」と「会社コード」「適用開始日」で
JOINするだけ。
- : NAME IS NULL [sage] 2007/11/23(金) 23:19:50ID:???
- 212の続き
もともとJOINのコストが無駄という話しからだったが、
その程度のJOINコストが無駄というのは、どんなハード使ってるんだ、
という話しだと思う。 - : NOMO ESTAS NENIO [sage] 2007/11/24(土) 03:30:10ID:???
- >212
取引テーブルに会社名列を持たせる設計の場合、取引テーブルの会社名はスナップショット
として持たせるものであり、正規形を崩すものではない。正規形を崩す設計ならば、そもそも
会社テーブルを持たず会社の管理はすべて取引テーブルの中というようになる。
たとえば、商品販売明細テーブルに商品単価を転写するのと同じこと。商品単価を商品テーブル
から引いてくる設計にすると、商品の単価が変わったときに過去の売り上げまで全部書き換わるのを
防ぐためのよく知られた手法を、取引テーブルにおける会社名の持たせ方に応用したものだ。 - : NAME IS NULL [sage] 2007/11/28(水) 01:35:19ID:???
-
正規化について言及すると、それは正規形を崩してるだろ。
正規化手法は、”既約でない”関数従属を排除する為の射影である
必要があり、第二正規化された射影を結合することによって、
元の第一正規形の集合が得られる必要がある。
要するに、1事実1箇所になってないと正規形とは言えないってこと。
だから、スナップショットは正規化違反ということさ。
商品単価の話はJOINのコストが気にならないのであれば、
会社名と同様、履歴化して正規化すれば良かろう。
ただ、商品明細のように会社名に比べてデータ量が多く、
マシンの性能とJOINのコストバランスを考えると、
正規化崩して、明細にスナップショットを持たせた方が
良かったというだけだろ。
よろしく
- : NAME IS NULL [sage] 2008/04/04(金) 08:17:59ID:???
- 依頼とは別でアンケートの集計もお手伝いすることになったんだが、
先輩がエクセル表で
店舗ID 店舗名 質問1 質問2のA 質問2のB 質問2のA 質問2のB・・・
--------------------------------------------------------------------
ってな表を作っていた。
(質問2のAは複数回答有りで、2のBは複数回答した数だけ答えるアンケート。)
データを打ち込む人は、列が足りなかったら足していってた。
何万レコード分もあるから、普通に打つのさえ大変なのに…。
一緒に仕事したことないが、開発やってる時は多分できてることを
雑務になるとできないという不思議…。
いや、開発の時もできてるかどうか知らないが…。 - : NAME IS NULL [sage] 2008/04/04(金) 20:25:32ID:???
- > 一緒に仕事したことないが、開発やってる時は多分できてることを
どういうこと?
SPSSとかで集計するときのマルチアンサーのフォーマットって
先輩がやってるようなのが一般的だと思うが - : NAME IS NULL [sage] 2008/04/04(金) 22:06:03ID:???
- 先輩は勉強しはじめたばかりだから、
そんな仕事はしてない - : NAME IS NULL [sage] 2008/04/05(土) 08:22:30ID:???
- 統計で言うオカレンスとデータベースのタプルは似て非なるものだということだよ。
- : NAME IS NULL [sage] 2008/04/14(月) 13:44:48ID:???
- JOINのコストって高いね。
正確に言えば、検索キーワードとソートが必要な検索で
JOINを行うと、インデックスがどれか一つにしか使えないから遅い。
検索キーワードがlikeだったりするとさらに最悪。
非正規化したほうが良い。 - : NAME IS NULL [sage] 2009/04/11(土) 21:06:53ID:???
-
釣れますか? - : NAME IS NULL [sage] 2009/06/10(水) 17:33:31ID:???
-
クラウド革命でITエンジニアは監獄行きです
ttp://d.hatena.ne.jp/kazunori_279/20090610/1244599829
Google App Engine担当者に聞いた
クラウド環境ではデータベースは「非正規化」して使う?
ttp://www.atmarkit.co.jp/news/200906/09/gae.html - : NAME IS NULL [sage] 2009/06/22(月) 22:31:06ID:???
- 正規化について質問です
第一正規化は繰り返しフィールドの排除があるかと思いますが、
たとえば
ID|購入者|商品1|金額1|商品2|金額2|商品3|金額3|商品4|金額4
01|AAA.....|TV1....|10万...|TV2....|11万....|TV3...|12万....|TV4....|13万...
このような場合は
ID|購入者
01|AAA
......と
ID|商品|金額
01|TV1|10万
01|TV2|11万
01|TV3|12万
01|TV4|13万
と2つに分けるかと思いますが
ID|購入者|販売担当者|購入日|配送日
の場合
購入者と販売担当者は人フィールドで、
購入日と配送日は日付フィールドなので
これらも繰り返しフィールドとみなせるのでしょうか?
- : NAME IS NULL [] 2009/06/22(月) 22:46:59:Ii7lYaDv
-
それって違うんでねーの?
たぶん - : NAME IS NULL [sage] 2009/06/22(月) 23:11:29ID:???
-
そうみなしたければみなして良い。みなしたくなければみなさなくても良い。
正規化というのはそういったところを決定した後に行う操作だから。 - : NAME IS NULL [sage] 2009/06/23(火) 07:20:42ID:???
- 通常は繰り返しとはみなさない。
あなたの言うとおりなら、
ID、人種類、人ID、日付種類、日付
みたいなカオステーブルができあがってしまう。
エンティティをしぼりこむのは業務分析ありきだから上記のカオステーブルが絶対ないとは言わないが、通常はないと言える。 - : NAME IS NULL [] 2009/06/24(水) 21:28:15:FsaDUw2R
-
ありがとうございます
そうですよね
何かこれに関する情報がのっているサイトとかご存知でないですか?
これを正規化と豪語する人がいて、そうじゃないという説得材料にしたいのですけど
- : NAME IS NULL [sage] 2009/06/25(木) 18:47:46ID:???
- 簡単なデータで例を作ってみたら?
問題でれば、それで説明つく。
出なければ、そのデータでは、問題ないのかもしれないよ(その人は
それを言っているのかもしれない)。 - : NAME IS NULL [] 2009/06/25(木) 19:55:02:uVxmIhxY
-
今日、この件お話したら、納得してくれたようです
たまたま具体的なデータ例で、話をしてたら話の論点があって、ある程度解決作がみえてきました
具体的な例で話し合うのは重要かもしれませんね - : NAME IS NULL [sage] 2009/06/25(木) 22:24:51ID:???
- よかたねー
- : NAME IS NULL [sage] 2009/06/27(土) 04:19:07ID:???
- (・∀・) 白くなっとるワロタwwww
●● ttp://wakuwaku.docomo.han-be.com/4522154.jpg
●● ttp://wakuwaku.docomo.han-be.com/55426555.gif
- : NAME IS NULL [] 2009/09/21(月) 18:26:25:4bCDESCP
- 同じ表にmember_idとmember_nameの二つの列があって、
member_id ・・・社内の人間なら社員コード。社外の人はNULL
member_name ・・・社内の人間ならNULL。社外の人は名前
みたいになってるんだけど、これってもっといい方法があるよね?
社員コードは別の社員表にある。 - : NAME IS NULL [sage] 2009/09/21(月) 20:51:56ID:???
- 社員表(社員コード,社員名)
社外表(コード,名前)
メンバー表(メンバーID,・・・・・)
社員コード∈メンバーID
社員コード∈コード
select B.社員名,C.名前
from メンバー表 A left join 社員表 B ON A.メンバーID=B.社員コード left join 社外表 C ON A.メンバーID = C.コード
- : NAME IS NULL [] 2009/12/24(木) 17:18:39:ao0/KMLR
-
>正規化について言及すると、それは正規形を崩してるだろ。
>正規化手法は、”既約でない”関数従属を排除する為の射影である
>必要があり・・・
> :
>要するに、1事実1箇所になってないと正規形とは言えないってこと。
>だから、スナップショットは正規化違反ということさ。
超遅レスだが、の見解は的確で合理的じゃね?
販売業務で商品の販売単価が日時や取引数量、その他に応じて変動する場合、売上伝票や
注文書に載せる明細の単価に対し、商品マスタの単価との間に従属性を認めては駄目だよな。
ゆえに業務の性格によっては正規化の対象とはならないだろう。
そして、注文を行った時点でのスナップショットこそが、正に売買契約と売上認識の「事実」。
つまり、一つの売上伝票や一つの注文書をもって「一事実、一箇所」と認識しなければ、寧ろ
不都合なシステム設計をする事になるよな。 だから、は優良な実務経験者だと思うぞ。
ボイスコッドから高次の正規化は要注意だな。
それより対象業務をよく分析し、ER図等で得られた業務の大切な性格と特徴を損なわない正規化を
心掛け、顧客指向のITソリューションでメリットを提供することがプロフェッショナルの仕事だと思う。 - : NAME IS NULL [] 2009/12/26(土) 01:44:47:dn/wTtyt
- ニコニコ動画のコメントやアマゾンのレビュー、youtubeのコメントなど
1対多の関係はどういうデータベースの構造になっているんでしょうか?
自分は以下の3パターンを考えたのですがどれも疑問が残ります。
案1:1つのレコードに動画番号とその動画に対する全てのコメント番号を収納する
動画1, コメント1コメント2コメント3コメント4
動画2, コメント1コメント2
欠点:・コメント数が有限になってしまうのではないか。
・複数のコメントが一つのコラムに収納されている場合、
1つのコメントの追加によってそのフィールド全体を更新しないといけないから
重いのではないか。
案2:コメント主導で動画番号を対応づける
コメント1, 動画1
コメント2, 動画2
コメント3, 動画1
コメント4, 動画3
欠点:動画を見る度にコメントの抽出をしないといけないから重いのではないか
案3:各動画毎にコメント用のテーブルを用意する
動画1のコメントテーブル:
コメント1
コメント2
コメント3
動画2のコメントテーブル:
コメント1
欠点(?):動画の数だけテーブルを用意することになるけど、
自分はどうプログラミングするのか分からないです。 - : NAME IS NULL [] 2009/12/26(土) 02:51:10:rKp6qWLp
-
リレーショナルデータベースでのデータ設計は、プログラム言語のように構造体で
カタチを決めて配列やリスト構造を持たせていくデータ設計と違って、集合論理と
関連の概念で解決しないとダメなんだよ。
↓こんな風に持たせればそれらしくなるんじゃない? - : NAME IS NULL [] 2009/12/26(土) 02:51:56:rKp6qWLp
- 【投稿動画テーブル】
動画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 テラ画質w
sm1234567 00:12 キター!
sm1234510 00:02 w
: : :
sm1234567 01:32 これはすごいな
sm1234567 01:40 たしかにw
sm1234569 03:02 おおおおおおおおっ!
sm1234567 01:59 うp主様、乙でした - : NAME IS NULL [sage] 2009/12/26(土) 02:52:50ID:???
- そもそもRDBかどうかも疑うべきだと思うけど。
- : NAME IS NULL [] 2009/12/26(土) 03:21:23:dn/wTtyt
-
ありがとうございます。
つまりそれは案2で、動画を見る度に
全てのコメントを収納した巨大な投稿コメントテーブルから
動画IDでコメントの抽出を行うんですよね?
それって重くないんでしょうか。
案3だと抽出処理が要らないんで軽いのかと思ったんですが
そんな大差はないのかな。。 - : NAME IS NULL [sage] 2009/12/26(土) 04:06:02ID:???
-
案ずるには及ばないと思うよ。インデックスとサーチのアルゴリズムは高度だから。
この程度のデータなら、RDBMSで数万件からの抽出でも、あっという間な筈。
あと他の方法となれば、制限を設けて自前のアルゴリズムで管理するしかないね。
WindowsならVC++やVC#、VBなどでサービスプログラムを組んで、Webページの
サーバーサイドから呼ぶとかね。
ハッシュアルゴリズムとか独自方式とか好きな技法でカスタムメイドできるよ。 - : NAME IS NULL [sage] 2009/12/26(土) 19:20:41ID:???
-
ニコニコはMYSQLだと聞いてる。 - : NAME IS NULL [sage] 2009/12/26(土) 22:13:20ID:???
-
現実的に考えて、RDB以外にないだろ。
- : NAME IS NULL [sage] 2009/12/27(日) 00:06:26ID:???
- 多くの工業科&組込制御系育ちはRDBMSをなかなか理解できないらしい。
自分をCPUに見立てたプログラム実行ロジックで考えてしまう癖が抜けなくて、
データの順番や個数、アドレス問題はポインタで解決済みの早見表として
オンメモリですべてを掌握していないと納得できないという。
役割分担や分散処理が苦手で、すべて自分のプログラムだけでやろうとする。
そして孤高だったりする。 - : NAME IS NULL [] 2010/01/20(水) 21:17:11:X+55Zxtj
-
動画番号に対して固定長(古いコメントは消えるので)のコメント領域を返すkey-valueじゃだめ?
- : NAME IS NULL [sage] 2010/01/21(木) 08:45:08ID:???
-
現時点のいろんな意味で、その実装に
もっとも適しているのがRDBだろ。
- : NAME IS NULL [sage] 2010/01/21(木) 18:56:38ID:???
-
non-Relationalなkey-valueで済むなら、そのほうがスケーラビリティとかパフォーマンスで有利では。
- : NAME IS NULL [sage] 2010/01/21(木) 20:03:46ID:???
- それだと重くならないかとか・・・、固定長の領域を返せばとか・・・って、ちょっと違うんじゃね?
なぜ動画投稿コミュニティサイトのような規模のシステム全体を、同じCPUとメモリの配下で
動作する単一のプログラムやプロセスとして考えるんだよ。スレ的にも当然RDBMSを使い、
サブシステムごとに分散処理だろw - : NAME IS NULL [sage] 2010/01/22(金) 04:17:32ID:???
- 結構昔だけどYouTubeなんかはBigTable使い始めたってどっかで読んだ。
- : NAME IS NULL [sage] 2010/01/22(金) 15:53:53ID:???
-
>同じCPUとメモリの配下で動作する単一のプログラムやプロセスとして考える
何のことを言ってるのかちょっと分かんないです>< - : NAME IS NULL [sage] 2010/04/09(金) 23:50:09ID:???
- 4月1日からDBの仕事するようになって1週間だが、早くもタイトル通りの叫び声あげたくなった。
これが現場のDBって奴なのか…… - : NAME IS NULL [sage] 2010/04/14(水) 18:37:37ID:???
- 既存なら泣く
設計中なら正規化を押し通せ - : NAME IS NULL [sage] 2010/04/15(木) 05:02:26ID:???
- 設計は完全に終ってる。
既にシステムの一部は稼働していて、リリースまでに間に合わなかった機能を実装している段階だ。 - : NAME IS NULL [sage] 2010/04/23(金) 15:29:57ID:???
- 自分の視野が世界の全て病
- : NAME IS NULL [] 2010/07/07(水) 22:36:04:/39YW+Cp
- 正規化について勉強を始めたのですが
一人の人に複数の趣味のフィールドを持たせたい場合は
どうするべきでしょうか
shumi1,shumi2のようなカラムを作るのは非正規と理解しています。
趣味のテーブルを分けて、shumi_idという外部キーでやるとした場合
name shumi
kiteretu 1
kiteretu 2
の様に重複するフィールドが出てくるので正規化はされていない
と思っています。どうすればよいのか教えてください。 - : NAME IS NULL [sage] 2010/07/07(水) 23:10:47ID:???
- 第4正規形になるね。
正規形を崩すかBCNFにしてFKで整合性を取るかじゃないかな - : NAME IS NULL [sage] 2010/07/08(木) 12:20:56ID:???
-
普通に第二正規形ではない。例えばリレーション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とかにすると思うけれどもね。 - : NAME IS NULL [sage] 2010/07/08(木) 21:10:32ID:???
-
ありがとうございます。
なんとか理解できそうなので、続けてサンプルを見まくります。 - : Perl忍者 ◆M5ZWRnXOj6 [] 2010/09/03(金) 17:24:39:zlBbPnBj
- web土方でSQLもろくに使えねえし設定もできねえし
正規化もろくにできてねえし
お前ばかなの?しぬの?
っていったら
得意気に黒い画面だして ポストグレ起動して手動でinsertやりまくって追加してた
脳味噌がかわいそうだった
かわいそすぎて泣いた - : NAME IS NULL [sage] 2010/09/14(火) 03:05:12ID:???
-
何を言っているのかよくわかりません。
あなたもかわいそうな人に見えます。 - : NAME IS NULL [sage] 2010/10/28(木) 15:47:02ID:???
- 5年くらい昔であろうか?
有名なSlerが受注した外資系企業のシステムで開発者を200人以上集めた。
Oracleのバージョンは忘れた。
既にメンバーからはずれた人が設計したという500列だったかの
ワークテーブルなるのものがあって、正規化した各テーブルから
データをかき集めてワークテーブルでまとめて更新。
新たに参加したメンバーは必ずこの仕様ではプログラムは書けない、
ワークテーブルも削ろう、と進言したが、現テーブル設計担当は
ぐずぐずしているだけでまったく動かず。
動的SQLを多用しないとプログラムを書けず、当然プログラム・バグが
多発。残業・徹夜してもバグの原因がなかなかわからず。
結局、社長命令でシステム開発は中止。
改めて開発予算を確保してテーブル設計からやり直すことに。
得るものは何もない、むなしい仕事だった。
テーブル設計担当を大雪山に生き埋めにしてやりたかった。
正規化は大切だぞ。
- : NAME IS NULL [sage] 2010/10/28(木) 23:36:12ID:???
-
ああ、解るわー。
その500列を作った技術者は、コボラーじゃないか?
あと列の名前も意味の無いコードで定義されていたりした?
コボラーにテーブル設計をやらせては駄目だよな。 - : NAME IS NULL [sage] 2010/10/29(金) 02:16:04ID:???
- 物理名は英字+数字の連番な
- : NAME IS NULL [sage] 2010/11/09(火) 02:22:59ID:???
- アラフォーCガリガリプログラマなんだけど、担当者が逃げたASP.NETのシステムを
見ることになってそのままDBの勉強始めたんだけど、DBってこんなに面白かったんだね
正規化とか考えてると楽しい
DBの講習会とか「興味ない」とサボってたのを後悔した
ただSQLはつまらんね
なんでこう、表示、更新、追加でこんなに文法違うんだよ
考えたやつ、頭おかしいだろ - : NAME IS NULL [sage] 2010/11/09(火) 02:28:31ID:???
- COBOL文化の人って、CHAR型好きだよね。
枝番 … EDA CHAR(2) とか。
あと制約付けるのが嫌いで、FETCHが好き。 - : Perl忍者 ◆M5ZWRnXOj6 [] 2010/11/12(金) 17:39:54:LqoipeIo
- 正規化してないバカが作ったやつのWEBアプリが
すべてそのままデータぶち込んでてプライマリーすらわかってねーみたいで
頭おわってんなっておもったわ
SQLも理解できないカスグラマも世の中たくさんいるしな
WEBバカはかすばっかりだよ
とくに3キモ言語使ってるやつらな - : NAME IS NULL [sage] 2010/11/13(土) 08:35:08ID:???
- 一方で、DWH見て「ぜんぜん正規化とか理解してない、これ設計したのコボラだろwww」
みたいなこと言う奴もいたりするけどな。 - : NAME IS NULL [sage] 2010/11/13(土) 18:03:03ID:???
-
オレの事か?
本気でコボラーにはテーブル設計して貰いたくないと感じてる。 - : NAME IS NULL [] 2010/11/13(土) 18:43:10:WUzshbar
-
何もわかってないw - : NAME IS NULL [sage] 2010/11/13(土) 21:52:14ID:???
- 「コボラー」よりRDBをわかっているというのが唯一の自慢な人は所詮そんなもんw
- : NAME IS NULL [sage] 2010/11/13(土) 23:05:36ID:???
- DWHってなんぞやと検索したら納得
何もわかってないww - : NAME IS NULL [sage] 2010/11/14(日) 23:37:21ID:???
- いやいやいや!
DWHは、正規化が完了してから正規化崩しを行っていくんだろ。
コボラーの奴は、正規化が不完全な状態から正規化崩しを行うからgdgdなテーブル設計になるんだって。 - : NAME IS NULL [sage] 2010/11/15(月) 00:29:36ID:???
- もっと流れよめ
- : NAME IS NULL [sage] 2010/11/15(月) 02:12:21ID:???
- 頭が悪いのに付ける薬はないってことだ
- : NAME IS NULL [sage] 2010/11/15(月) 08:06:17ID:???
-
マジレスすると、DWHではそのような方法はとらない。
そもそも正規化というのが更新異常を防ぎデータの一貫性を保つための考え方である以上、
個々に更新を行わず、ETLであらかじめ一貫性を整えたデータを一括してロードするDWHには
必要のないもの。 - : NAME IS NULL [sage] 2010/12/12(日) 00:35:52ID:???
- 性器化の意義:項目間の相関性を極小にし記憶効率を改善する。性器化のしすぎは
多くの場合検索性を損ね、時には信頼性も下げる場合がある。
非性器化の意義:項目間の従属性を許可する。記憶効率は下がるが、多くの場合に
検索性が向上し、時には信頼性が向上する場合がある。 - : NAME IS NULL [sage] 2010/12/16(木) 19:18:29ID:???
-
アホちゃう? - : NAME IS NULL [sage] 2011/03/01(火) 14:42:43.26ID:???
- パーでんねん
- : NAME IS NULL [sage] 2011/08/09(火) 17:16:40.70ID:???
- 第一正規化まで終わってる、つまり1枚の大きなテーブル(4Gくらい)があるんですが、自動でその後の正規化をやってくれるソフトってないですか?
知っている人がいたら教えて下さい。 - : NAME IS NULL [] 2011/09/02(金) 19:31:02.37:XFcjaMI+
- 検索用にタグ機能を作りたいんですけど
どんなテーブル構造にするのが一般的ですか?
| 記事ID | タグ |
で記事IDを重複キーにするか
| 記事ID | タグ1 | タグ2 | タグ3 | ・・・ |
で記事IDをユニークキーにするか
タグの上限は未定です - : NAME IS NULL [sage] 2011/09/08(木) 18:42:15.74ID:???
-
要件次第だが
| 記事ID | タグ |
で記事IDとタグを主キーにするかな - : NAME IS NULL [sage] 2011/09/10(土) 19:46:26.54ID:???
-
> | 記事ID | タグ1 | タグ2 | タグ3 | ・・・ |
> で記事IDをユニークキーにするか
おいおい第一正規形にすらなってないぞ - : NAME IS NULL [] 2012/08/09(木) 02:11:16.27:57EvxVv2
- 保守age
- : NAME IS NULL [] 2012/10/30(火) 13:13:15.70:g6duZ5Cb
- 保守
- : NAME IS NULL [sage] 2014/04/28(月) 11:28:23.67ID:???
- テーブル設計(正規化)のアドバイスをお願いします。
メインテーブルがあり、フィールド数は全部で70程です。
主キーに対して従属はない状態(第二正規化)なのですが、
レコードが同じ内容で繰り返される各フィールドをテーブルに切り出す(第三正規化?)と35もマスタテーブルが出来てしまったのですが、
このテーブルとトランザクションテーブルをリレーションシップしてからクエリで全てのフィールドを再度結合する場合、
結合線もすごい数になってしまいますが、このような状態(数)は正規化出来ていないことになるのでしょうか?
各マスタテーブルは主キーとフィールドが一つのものばかりです。 - : NAME IS NULL [] 2015/04/21(火) 21:23:14.43:pQzWEcgh
- ☆ 日本の核武装は絶対に必須ですわ。☆
ttp://http://www.soumu.go.jp/senkyo/kokumin_touhyou/index.html
☆ 日本国民の皆様方、2016年7月の『第24回 参議院選挙』で、改憲の参議院議員が
3分の2以上を超えると日本国憲法の改正です。皆様方、必ず投票に自ら足を運んでください。
私たちの日本国憲法を絶対に改正しましょう。☆ - : NAME IS NULL [sage] 2015/05/11(月) 22:46:52.65ID:???
-
まず主キーはサロゲートキー?それともナチュラルキー?
後からサロゲートキー適当に足して主キーとか言ってないよね? - : NAME IS NULL [sage] 2017/04/20(木) 13:52:29.39ID:???
- 保守
- : NAME IS NULL [sage] 2017/05/15(月) 15:03:35.69ID:???
- 日本トップクラスの企業の次期案件下請けしてるけどテーブル定義マジでゴミ
コミュ力ある奴ばかりで技術力ある奴がマネージャークラスに居ないんだろうな
日本終わってるわ - : NAME IS NULL [sage] 2017/11/23(木) 09:48:07.38ID:???
- necや富士通など大手メーカー系sierの業務系案件でまともな設計のプロジェクトなんて存在するの???
- : NAME IS NULL [] 2017/12/29(金) 11:59:02.29:dtNZwIie
- 誰でも簡単にパソコン1台で稼げる方法など
参考までに、
⇒ 『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。
グーグル検索⇒『宮本のゴウリエセレレ』
N46QAZV1AG
凡例:
レス番
100 (赤) → 2つ以上レスが付いている
100 (紫) → 1つ以上レスが付いている
名前
名無しさん (青) → sage のレス
名無しさん (緑) → age のレス
ID
ID:xxxxxxx (赤) → 発言が3つ以上のID
ID:xxxxxxx (青) → 発言が2つ以上のID
このページは2ch勢いランキングが作成したキャッシュです。元のページはこちら。削除についてはこちら。