07/11/12 21:07:31 .net
会社コードと会社名だけのテーブルに正規化する価値ってあるかな？
JOINのコストが恐ろしく無駄な気がするんだけど。
195:NAME IS NULL
07/11/12 21:36:34 .net
>>194
「カイシャメイ」 も追加しろ。
196:NAME IS NULL
07/11/12 21:39:15 .net
そうやってマスタでも管理してトリガで更新したいって提案したら不安な顔をされた。
こういうのはバットプラクティスだったのかな？
197:NAME IS NULL
07/11/13 11:47:27 .net
>>194
会社なら(>>195のいうように)ふりがなとか所在地とか取引状況とか、付帯情報が後から湧いてきそうだから、俺ならマスタにする。
joinのコストがCPUを指してるなら「誤差の範囲ですよ」、開発時のタイプ量を指してるなら「ビュー用意しとくんで」。
つい最近だと、印紙種類(収入印紙と登記印紙)をどうしようか迷った。
「そんなもん、増えた時にシステムの対応が必要だったら、データ増やすだけじゃむりだから(アプリに手を入れるから)」
という理由で、これはマスタ可しなかった。
198:FEQoQDjgtx
07/11/14 04:53:31 .net
gBMpor <a href="URLﾘﾝｸ(sflntwpuclbo.com) [url=URLﾘﾝｸ(vtoysuqfixvo.com) [link=URLﾘﾝｸ(iarrmvwkbpot.com) URLﾘﾝｸ(poyhgemjrdue.com)
199:NAME IS NULL
07/11/17 22:12:21 .net
>>194
今の時代、会社名などいくらでも変わる可能性がある。
当然、正規化するべき。
200:NAME IS NULL
07/11/18 08:52:47 .net
>>199
過去のデータで帳票を出す場合、
昔の名前で出なくなるな。
でも正規化自体は賛成。
201:NAME IS NULL
07/11/18 09:52:01 .net
取引当時の社名を出力しなければならないという要件があるなら
そう作ればいいだけで、正規化の有無とは関係ない。
202:NAME IS NULL
07/11/20 02:00:19 .net
いや、それも本とかでは正規化（というか非正規化）の文脈で語られてるよ
203:NAME IS NULL
07/11/20 14:01:50 .net
社名の変更ならその程度で済むかもしれんが、合併とかどうするよ
204:NAME IS NULL
07/11/20 17:12:39 .net
合併したら新会社としてデータを起こすとか。
どうせ与信だなんだ大きく変更になるだろうし。
ただ旧組織との紐付けが必要か否かだなあ。
合算して昨年実績としたい、みたいな。
205:あぼーん
あぼーん.net
あぼーん
206:NAME IS NULL
07/11/20 22:25:34 .net
社名と日付を用意するなんてわざわざしなくても
社名変更だろうが合併だろうが別会社として扱えばいい
207:NOMO ESTAS NENIO
07/11/22 07:49:11 .net
>194
(1)取引当時の「社名」を「会社コード」と一緒に「取引テーブル」に書き写せばいい。
社名変更して「会社テーブル」の社名列を更新しても取引記録を打ち出すときは旧社名で出るし、
その会社との取引履歴を出すときにはコードで引けば社名変更に関わりなくすべての履歴を
引き出せる。
(2)もしくは、「会社テーブル」に「旧会社コード」を設けて、社名変更後はレコードを追加して
別の会社として扱うようにするとか。こうすると新会社分、旧会社分の履歴だけを取り出すときに
便利になるし、旧会社の名前も残せる。
(3)「会社系統テーブル{旧会社コード, 新会社コード}」を設けて、社名変更後は「社名レコード」に
レコードを追加して、旧会社のコードと新会社のコードを「会社系統テーブル」に記録するように
すれば、履歴を多対多の関連で残せるので会社合併・分社があっても追跡ができる。
208:NAME IS NULL
07/11/22 08:26:10 .net
(2)もしくは、「会社テーブル」に「旧会社コード」を設けて、社名変更後はレコードを追加して
別の会社として扱うようにするとか。こうすると新会社分、旧会社分の履歴だけを取り出すときに
便利になるし、旧会社の名前も残せる。
２回以上社名変更や合併を繰り返した場合でも大丈夫でしょうか？
209:NAME IS NULL
07/11/22 12:59:43 .net
207じゃないけど、2回以上でも問題ないだろ、単なるリンクリストなんだから
リンクが1レベルしかできないリンクリストなんてないじゃん
ただ、「この会社名の通用期間」みたいなものを設けて、特定の日付がどの通用期間に含まれるかチェックするとか、面倒だよ
210:NAME IS NULL
07/11/22 20:09:17 .net
吸収された後でまたスピンアウトみたいな離れ業はあるのだろうか
法的には関連性が切れてるだろうから、新しく起こせばいいのかな？
211:あぼーん
あぼーん.net
あぼーん
212:NAME IS NULL
07/11/23 23:15:27 .net
>>207
（スレタイ）「頼むから正規化しろよ 第二正規形」
おそらく「取引テーブル」の候補キーは、「会社コード」以外の属性も含まれると
考えられ、
「取引テーブル」の「会社名」は、
「取引テーブル」の「会社コード」にのみ関数従属する為、
「取引テーブル」の候補キーの一部に関数従属することとなる。
よって、その「取引テーブル」は、第二正規形とならない。
ではどうするかというと、「会社テーブル」を履歴で作れば良い。
会社テーブル [ *会社コード、*適用開始日、会社名]（*が主キー）
>>209
新旧「会社コード」もありだろうけど、実装を考えると、
SQLでリンクリストを検索するより、
適用日付で検索した方が明らかにラク。
「取引テーブル」という名前から想像すると、「取引日」という属性を
持ってるだろから、「会社コード」「取引日」と「会社コード」「適用開始日」で
JOINするだけ。
213:NAME IS NULL
07/11/23 23:19:50 .net
212の続き
もともとJOINのコストが無駄という話しからだったが、
その程度のJOINコストが無駄というのは、どんなハード使ってるんだ、
という話しだと思う。
214:NOMO ESTAS NENIO
07/11/24 03:30:10 .net
>212
取引テーブルに会社名列を持たせる設計の場合、取引テーブルの会社名はスナップショット
として持たせるものであり、正規形を崩すものではない。正規形を崩す設計ならば、そもそも
会社テーブルを持たず会社の管理はすべて取引テーブルの中というようになる。
たとえば、商品販売明細テーブルに商品単価を転写するのと同じこと。商品単価を商品テーブル
から引いてくる設計にすると、商品の単価が変わったときに過去の売り上げまで全部書き換わるのを
防ぐためのよく知られた手法を、取引テーブルにおける会社名の持たせ方に応用したものだ。
215:NAME IS NULL
07/11/28 01:35:19 .net
>>214
正規化について言及すると、それは正規形を崩してるだろ。
正規化手法は、”既約でない”関数従属を排除する為の射影である
必要があり、第二正規化された射影を結合することによって、
元の第一正規形の集合が得られる必要がある。
要するに、１事実１箇所になってないと正規形とは言えないってこと。
だから、スナップショットは正規化違反ということさ。
商品単価の話はJOINのコストが気にならないのであれば、
会社名と同様、履歴化して正規化すれば良かろう。
ただ、商品明細のように会社名に比べてデータ量が多く、
マシンの性能とJOINのコストバランスを考えると、
正規化崩して、明細にスナップショットを持たせた方が
良かったというだけだろ。
よろしく
216:NAME IS NULL
08/04/04 08:17:59 .net
依頼とは別でアンケートの集計もお手伝いすることになったんだが、
先輩がエクセル表で
店舗ID 店舗名 質問1 質問2のA 質問2のB 質問2のA 質問2のB・・・
--------------------------------------------------------------------
ってな表を作っていた。
(質問2のAは複数回答有りで、2のBは複数回答した数だけ答えるアンケート。)
データを打ち込む人は、列が足りなかったら足していってた。
何万レコード分もあるから、普通に打つのさえ大変なのに…。
一緒に仕事したことないが、開発やってる時は多分できてることを
雑務になるとできないという不思議…。
いや、開発の時もできてるかどうか知らないが…。
217:NAME IS NULL
08/04/04 20:25:32 .net
> 一緒に仕事したことないが、開発やってる時は多分できてることを
どういうこと？
SPSSとかで集計するときのマルチアンサーのフォーマットって
先輩がやってるようなのが一般的だと思うが
218:NAME IS NULL
08/04/04 22:06:03 .net
先輩は勉強しはじめたばかりだから、
そんな仕事はしてない
219:NAME IS NULL
08/04/05 08:22:30 .net
統計で言うオカレンスとデータベースのタプルは似て非なるものだということだよ。
220:NAME IS NULL
08/04/14 13:44:48 .net
JOINのコストって高いね。
正確に言えば、検索キーワードとソートが必要な検索で
JOINを行うと、インデックスがどれか一つにしか使えないから遅い。
検索キーワードがlikeだったりするとさらに最悪。
非正規化したほうが良い。
221:NAME IS NULL
09/04/11 21:06:53 .net
>>220
釣れますか？
222:NAME IS NULL
09/06/10 17:33:31 .net
>>220
クラウド革命でITエンジニアは監獄行きです
URLﾘﾝｸ(d.hatena.ne.jp)
Google App Engine担当者に聞いた
クラウド環境ではデータベースは「非正規化」して使う？
URLﾘﾝｸ(www.atmarkit.co.jp)
223:NAME IS NULL
09/06/22 22:31:06 .net
正規化について質問です
第一正規化は繰り返しフィールドの排除があるかと思いますが、
たとえば
ＩＤ｜購入者｜商品１｜金額１｜商品２｜金額２｜商品３｜金額３｜商品４｜金額４
01｜ＡＡＡ.....｜ＴＶ１....｜10万...｜ＴＶ２....｜11万....｜ＴＶ３...｜12万....｜ＴＶ４....｜13万...
このような場合は
ＩＤ｜購入者
01｜ＡＡＡ
......と
ＩＤ｜商品｜金額
01｜ＴＶ１｜10万
01｜ＴＶ２｜11万
01｜ＴＶ３｜12万
01｜ＴＶ４｜13万
と２つに分けるかと思いますが
ＩＤ｜購入者｜販売担当者｜購入日｜配送日
の場合
購入者と販売担当者は人フィールドで、
購入日と配送日は日付フィールドなので
これらも繰り返しフィールドとみなせるのでしょうか？
224:NAME IS NULL
09/06/22 22:46:59 Ii7lYaDv.net
>>223
それって違うんでねーの？
たぶん
225:NAME IS NULL
09/06/22 23:11:29 .net
>>223
そうみなしたければみなして良い。みなしたくなければみなさなくても良い。
正規化というのはそういったところを決定した後に行う操作だから。
226:NAME IS NULL
09/06/23 07:20:42 .net
通常は繰り返しとはみなさない。
あなたの言うとおりなら、
ID、人種類、人ID、日付種類、日付
みたいなカオステーブルができあがってしまう。
エンティティをしぼりこむのは業務分析ありきだから上記のカオステーブルが絶対ないとは言わないが、通常はないと言える。
227:NAME IS NULL
09/06/24 21:28:15 FsaDUw2R.net
>>226
ありがとうございます
そうですよね
何かこれに関する情報がのっているサイトとかご存知でないですか？
これを正規化と豪語する人がいて、そうじゃないという説得材料にしたいのですけど
228:NAME IS NULL
09/06/25 18:47:46 .net
簡単なデータで例を作ってみたら？
問題でれば、それで説明つく。
出なければ、そのデータでは、問題ないのかもしれないよ（その人は
それを言っているのかもしれない）。
229:NAME IS NULL
09/06/25 19:55:02 uVxmIhxY.net
>>228
今日、この件お話したら、納得してくれたようです
たまたま具体的なデータ例で、話をしてたら話の論点があって、ある程度解決作がみえてきました
具体的な例で話し合うのは重要かもしれませんね
230:NAME IS NULL
09/06/25 22:24:51 .net
よかたねー
231:NAME IS NULL
09/06/27 04:19:07 .net
(・∀・) 白くなっとるﾜﾛﾀｗｗｗｗ
●● URLﾘﾝｸ(wakuwaku.docomo.han-be.com)
●● URLﾘﾝｸ(wakuwaku.docomo.han-be.com)
232:NAME IS NULL
09/09/21 18:26:25 4bCDESCP.net
同じ表にmember_idとmember_nameの二つの列があって、
member_id ・・・社内の人間なら社員コード。社外の人はNULL
member_name ・・・社内の人間ならNULL。社外の人は名前
みたいになってるんだけど、これってもっといい方法があるよね？
社員コードは別の社員表にある。
233:NAME IS NULL
09/09/21 20:51:56 .net
社員表(社員コード,社員名)
社外表（コード,名前）
メンバー表(メンバーID,・・・・・)
社員コード∈メンバーID
社員コード∈コード
select B.社員名,C.名前
from メンバー表 A left join 社員表 B ON A.メンバーID=B.社員コード left join 社外表 C ON A.メンバーID = C.コード
234:NAME IS NULL
09/12/24 17:18:39 ao0/KMLR.net
>>215
＞正規化について言及すると、それは正規形を崩してるだろ。
＞正規化手法は、”既約でない”関数従属を排除する為の射影である
＞必要があり・・・
＞ ：
＞要するに、１事実１箇所になってないと正規形とは言えないってこと。
＞だから、スナップショットは正規化違反ということさ。
超遅レスだが、>>214の見解は的確で合理的じゃね？
販売業務で商品の販売単価が日時や取引数量、その他に応じて変動する場合、売上伝票や
注文書に載せる明細の単価に対し、商品マスタの単価との間に従属性を認めては駄目だよな。
ゆえに業務の性格によっては正規化の対象とはならないだろう。
そして、注文を行った時点でのスナップショットこそが、正に売買契約と売上認識の「事実」。
つまり、一つの売上伝票や一つの注文書をもって「一事実、一箇所」と認識しなければ、寧ろ
不都合なシステム設計をする事になるよな。 だから、>>214は優良な実務経験者だと思うぞ。
ボイスコッドから高次の正規化は要注意だな。
それより対象業務をよく分析し、ER図等で得られた業務の大切な性格と特徴を損なわない正規化を
心掛け、顧客指向のITソリューションでメリットを提供することがプロフェッショナルの仕事だと思う。
235:NAME IS NULL
09/12/26 01:44:47 dn/wTtyt.net
ニコニコ動画のコメントやアマゾンのレビュー、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
欠点(?)：動画の数だけテーブルを用意することになるけど、
自分はどうプログラミングするのか分からないです。
236:NAME IS NULL
09/12/26 02:51:10 rKp6qWLp.net
>>235
リレーショナルデータベースでのデータ設計は、プログラム言語のように構造体で
カタチを決めて配列やリスト構造を持たせていくデータ設計と違って、集合論理と
関連の概念で解決しないとダメなんだよ。
↓こんな風に持たせればそれらしくなるんじゃない？
237:NAME IS NULL
09/12/26 02:51:56 rKp6qWLp.net
【投稿動画テーブル】
動画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 うｐ主様、乙でした
238:NAME IS NULL
09/12/26 02:52:50 .net
そもそもRDBかどうかも疑うべきだと思うけど。
239:NAME IS NULL
09/12/26 03:21:23 dn/wTtyt.net
>>237
ありがとうございます。
つまりそれは案2で、動画を見る度に
全てのコメントを収納した巨大な投稿コメントテーブルから
動画IDでコメントの抽出を行うんですよね？
それって重くないんでしょうか。
案3だと抽出処理が要らないんで軽いのかと思ったんですが
そんな大差はないのかな。。
240:NAME IS NULL
09/12/26 04:06:02 .net
>>239
案ずるには及ばないと思うよ。インデックスとサーチのアルゴリズムは高度だから。
この程度のデータなら、RDBMSで数万件からの抽出でも、あっという間な筈。
あと他の方法となれば、制限を設けて自前のアルゴリズムで管理するしかないね。
WindowsならVC++やVC#、VBなどでサービスプログラムを組んで、Webページの
サーバーサイドから呼ぶとかね。
ハッシュアルゴリズムとか独自方式とか好きな技法でカスタムメイドできるよ。
241:NAME IS NULL
09/12/26 19:20:41 .net
>>238
ニコニコはMYSQLだと聞いてる。
242:NAME IS NULL
09/12/26 22:13:20 .net
>>238
現実的に考えて、RDB以外にないだろ。
243:NAME IS NULL
09/12/27 00:06:26 .net
多くの工業科＆組込制御系育ちはRDBMSをなかなか理解できないらしい。
自分をCPUに見立てたプログラム実行ロジックで考えてしまう癖が抜けなくて、
データの順番や個数、アドレス問題はポインタで解決済みの早見表として
オンメモリですべてを掌握していないと納得できないという。
役割分担や分散処理が苦手で、すべて自分のプログラムだけでやろうとする。
そして孤高だったりする。
244:NAME IS NULL
10/01/20 21:17:11 X+55Zxtj.net
>>242
動画番号に対して固定長（古いコメントは消えるので）のコメント領域を返すkey-valueじゃだめ？
245:NAME IS NULL
10/01/21 08:45:08 .net
>>244
現時点のいろんな意味で、その実装に
もっとも適しているのがRDBだろ。
246:NAME IS NULL
10/01/21 18:56:38 .net
>>245
non-Relationalなkey-valueで済むなら、そのほうがスケーラビリティとかパフォーマンスで有利では。
247:NAME IS NULL
10/01/21 20:03:46 .net
それだと重くならないかとか・・・、固定長の領域を返せばとか・・・って、ちょっと違うんじゃね？
なぜ動画投稿コミュニティサイトのような規模のシステム全体を、同じCPUとメモリの配下で
動作する単一のプログラムやプロセスとして考えるんだよ。スレ的にも当然RDBMSを使い、
サブシステムごとに分散処理だろｗ
248:NAME IS NULL
10/01/22 04:17:32 .net
結構昔だけどYouTubeなんかはBigTable使い始めたってどっかで読んだ。
249:NAME IS NULL
10/01/22 15:53:53 .net
>>247
>同じCPUとメモリの配下で動作する単一のプログラムやプロセスとして考える
何のことを言ってるのかちょっと分かんないです><
250:NAME IS NULL
10/04/09 23:50:09 .net
4月1日からDBの仕事するようになって1週間だが、早くもタイトル通りの叫び声あげたくなった。
これが現場のDBって奴なのか……
251:NAME IS NULL
10/04/14 18:37:37 .net
既存なら泣く
設計中なら正規化を押し通せ
252:NAME IS NULL
10/04/15 05:02:26 .net
設計は完全に終ってる。
既にシステムの一部は稼働していて、リリースまでに間に合わなかった機能を実装している段階だ。
253:NAME IS NULL
10/04/23 15:29:57 .net
自分の視野が世界の全て病
254:NAME IS NULL
10/07/07 22:36:04 /39YW+Cp.net
正規化について勉強を始めたのですが
一人の人に複数の趣味のフィールドを持たせたい場合は
どうするべきでしょうか
shumi1,shumi2のようなカラムを作るのは非正規と理解しています。
趣味のテーブルを分けて、shumi_idという外部キーでやるとした場合
name shumi
kiteretu 1
kiteretu 2
の様に重複するフィールドが出てくるので正規化はされていない
と思っています。どうすればよいのか教えてください。
255:NAME IS NULL
10/07/07 23:10:47 .net
第4正規形になるね。
正規形を崩すかBCNFにしてFKで整合性を取るかじゃないかな
256:NAME IS NULL
10/07/08 12:20:56 .net
>>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とかにすると思うけれどもね。
257:NAME IS NULL
10/07/08 21:10:32 .net
>>255
>>256
ありがとうございます。
なんとか理解できそうなので、続けてサンプルを見まくります。
258:Perl忍者 ◆M5ZWRnXOj6
10/09/03 17:24:39 zlBbPnBj.net
web土方でSQLもろくに使えねえし設定もできねえし
正規化もろくにできてねえし
お前ばかなの？しぬの？
っていったら
得意気に黒い画面だして ポストグレ起動して手動でinsertやりまくって追加してた
脳味噌がかわいそうだった
かわいそすぎて泣いた
259:NAME IS NULL
10/09/14 03:05:12 .net
>>258
何を言っているのかよくわかりません。
あなたもかわいそうな人に見えます。
260:NAME IS NULL
10/10/28 15:47:02 .net
5年くらい昔であろうか？
有名なSlerが受注した外資系企業のシステムで開発者を200人以上集めた。
Oracleのバージョンは忘れた。
既にメンバーからはずれた人が設計したという500列だったかの
ワークテーブルなるのものがあって、正規化した各テーブルから
データをかき集めてワークテーブルでまとめて更新。
新たに参加したメンバーは必ずこの仕様ではプログラムは書けない、
ワークテーブルも削ろう、と進言したが、現テーブル設計担当は
ぐずぐずしているだけでまったく動かず。
動的SQLを多用しないとプログラムを書けず、当然プログラム・バグが
多発。残業・徹夜してもバグの原因がなかなかわからず。
結局、社長命令でシステム開発は中止。
改めて開発予算を確保してテーブル設計からやり直すことに。
得るものは何もない、むなしい仕事だった。
テーブル設計担当を大雪山に生き埋めにしてやりたかった。
正規化は大切だぞ。
261:NAME IS NULL
10/10/28 23:36:12 .net
>>260
ああ、解るわー。
その500列を作った技術者は、コボラーじゃないか？
あと列の名前も意味の無いコードで定義されていたりした？
コボラーにテーブル設計をやらせては駄目だよな。
262:NAME IS NULL
10/10/29 02:16:04 .net
物理名は英字＋数字の連番な
263:NAME IS NULL
10/11/09 02:22:59 .net
アラフォーCガリガリプログラマなんだけど、担当者が逃げたASP.NETのシステムを
見ることになってそのままDBの勉強始めたんだけど、DBってこんなに面白かったんだね
正規化とか考えてると楽しい
DBの講習会とか「興味ない」とサボってたのを後悔した
ただSQLはつまらんね
なんでこう、表示、更新、追加でこんなに文法違うんだよ
考えたやつ、頭おかしいだろ
264:NAME IS NULL
10/11/09 02:28:31 .net
COBOL文化の人って、CHAR型好きだよね。
枝番 … EDA CHAR(2) とか。
あと制約付けるのが嫌いで、FETCHが好き。
265:Perl忍者 ◆M5ZWRnXOj6
10/11/12 17:39:54 LqoipeIo.net
正規化してないバカが作ったやつのWEBアプリが
すべてそのままデータぶち込んでてプライマリーすらわかってねーみたいで
頭おわってんなっておもったわ
SQLも理解できないカスグラマも世の中たくさんいるしな
WEBバカはかすばっかりだよ
とくに3キモ言語使ってるやつらな
266:NAME IS NULL
10/11/13 08:35:08 .net
一方で、DWH見て「ぜんぜん正規化とか理解してない、これ設計したのコボラだろwww」
みたいなこと言う奴もいたりするけどな。
267:NAME IS NULL
10/11/13 18:03:03 .net
>>266
オレの事か？
本気でコボラーにはテーブル設計して貰いたくないと感じてる。
268:NAME IS NULL
10/11/13 18:43:10 WUzshbar.net
>>267
何もわかってないw
269:NAME IS NULL
10/11/13 21:52:14 .net
「コボラー」よりRDBをわかっているというのが唯一の自慢な人は所詮そんなもんw
270:NAME IS NULL
10/11/13 23:05:36 .net
DWHってなんぞやと検索したら納得
>>267
何もわかってないｗｗ
271:NAME IS NULL
10/11/14 23:37:21 .net
いやいやいや！
DWHは、正規化が完了してから正規化崩しを行っていくんだろ。
コボラーの奴は、正規化が不完全な状態から正規化崩しを行うからｇｄｇｄなテーブル設計になるんだって。
272:NAME IS NULL
10/11/15 00:29:36 .net
もっと流れよめ
273:NAME IS NULL
10/11/15 02:12:21 .net
頭が悪いのに付ける薬はないってことだ
274:NAME IS NULL
10/11/15 08:06:17 .net
>>271
マジレスすると、DWHではそのような方法はとらない。
そもそも正規化というのが更新異常を防ぎデータの一貫性を保つための考え方である以上、
個々に更新を行わず、ETLであらかじめ一貫性を整えたデータを一括してロードするDWHには
必要のないもの。
275:NAME IS NULL
10/12/12 00:35:52 .net
性器化の意義：項目間の相関性を極小にし記憶効率を改善する。性器化のしすぎは
多くの場合検索性を損ね、時には信頼性も下げる場合がある。
非性器化の意義：項目間の従属性を許可する。記憶効率は下がるが、多くの場合に
検索性が向上し、時には信頼性が向上する場合がある。
276:NAME IS NULL
10/12/16 19:18:29 .net
>>275
アホちゃう？
277:NAME IS NULL
11/03/01 14:42:43.26 .net
パーでんねん
278:NAME IS NULL
11/08/09 17:16:40.70 .net
第一正規化まで終わってる、つまり１枚の大きなテーブル（4Gくらい）があるんですが、自動でその後の正規化をやってくれるソフトってないですか？
知っている人がいたら教えて下さい。
279:NAME IS NULL
11/09/02 19:31:02.37 XFcjaMI+.net
検索用にタグ機能を作りたいんですけど
どんなテーブル構造にするのが一般的ですか？
｜ 記事ID ｜ タグ ｜
で記事IDを重複キーにするか
｜ 記事ID ｜ タグ１ ｜ タグ２ ｜ タグ３ ｜ ・・・ ｜
で記事IDをユニークキーにするか
タグの上限は未定です
280:NAME IS NULL
11/09/08 18:42:15.74 .net
>>279
要件次第だが
｜ 記事ID ｜ タグ ｜
で記事IDとタグを主キーにするかな
281:NAME IS NULL
11/09/10 19:46:26.54 .net
>>279
> ｜ 記事ID ｜ タグ１ ｜ タグ２ ｜ タグ３ ｜ ・・・ ｜
> で記事IDをユニークキーにするか
おいおい第一正規形にすらなってないぞ
282:NAME IS NULL
12/08/09 02:11:16.27 57EvxVv2.net
保守age
283:NAME IS NULL
12/10/30 13:13:15.70 g6duZ5Cb.net
保守
284:NAME IS NULL
14/04/28 11:28:23.67 .net
テーブル設計（正規化）のアドバイスをお願いします。
メインテーブルがあり、フィールド数は全部で70程です。
主キーに対して従属はない状態（第二正規化）なのですが、
レコードが同じ内容で繰り返される各フィールドをテーブルに切り出す（第三正規化？）と35もマスタテーブルが出来てしまったのですが、
このテーブルとトランザクションテーブルをリレーションシップしてからクエリで全てのフィールドを再度結合する場合、
結合線もすごい数になってしまいますが、このような状態（数）は正規化出来ていないことになるのでしょうか？
各マスタテーブルは主キーとフィールドが一つのものばかりです。
285:NAME IS NULL
15/04/21 21:23:14.43 pQzWEcgh.net
☆ 日本の核武装は絶対に必須ですわ。☆
URLﾘﾝｸ(www.soumu.go.jp)
☆ 日本国民の皆様方、2016年7月の『第２４回 参議院選挙』で、改憲の参議院議員が
3分の2以上を超えると日本国憲法の改正です。皆様方、必ず投票に自ら足を運んでください。
私たちの日本国憲法を絶対に改正しましょう。☆
286:NAME IS NULL
15/05/11 22:46:52.65 .net
>>284
まず主キーはサロゲートキー？それともナチュラルキー？
後からサロゲートキー適当に足して主キーとか言ってないよね？
287:NAME IS NULL
17/04/20 13:52:29.39 .net
保守
288:NAME IS NULL
17/05/15 15:03:35.69 .net
日本トップクラスの企業の次期案件下請けしてるけどテーブル定義マジでゴミ
コミュ力ある奴ばかりで技術力ある奴がマネージャークラスに居ないんだろうな
日本終わってるわ
289:NAME IS NULL
17/11/23 09:48:07.38 .net
necや富士通など大手メーカー系sierの業務系案件でまともな設計のプロジェクトなんて存在するの？？？
290:NAME IS NULL
17/12/29 11:59:02.29 dtNZwIie.net
誰でも簡単にパソコン1台で稼げる方法など
参考までに、
⇒ 『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。
グーグル検索⇒『宮本のゴウリエセレレ』
N46QAZV1AG
291:NAME IS NULL
23/02/03 15:21:39.24 .net
(´・∀・｀ )ｱﾗﾏｧ
292:NAME IS NULL
23/03/14 13:11:10.87 ci3DM14kK
ミサイ儿云々た゛のワクチン云々た゛のクソ自民公明の白々しい税金泥棒っぷりに反吐が出るよな
私利私欲のために━部の賄賂癒着業者と税金泥棒して騷音に温室効果カ゛スにコ口ナにとまき散らして海水温上昇させて
かつてない量の水蒸気発生させて．曰本と゛ころか世界中で土砂崩れに洪水、暴風、大雪，猛暑，干は゛つ，森林火災にと災害連發
ワクチン打ったハ゛カのほうか゛ウイルス拡散率が高い統計すらアーア―聞こえないやって国民を殺害する氣満々て゛入国緩和に全国地球破壞支援
防衛という名目て゛増税して使途不明金着服して私腹を肥やす目的て゛，曰本に原爆落とした世界最惡のならず者国家とともに
軍事演習だなんだと北朝鮮挑発して，地球の外を飛ふ゛ミサイルを上空だのと表現した挙句に鉄道まて゛止めて
『ミサヰル迷惑た゛な」た゛のとハ゛力丸出しのインタヒ゛ュ─まて゛報道するキチガイ洗腦國家
こんな茶番を平氣て゛やってる世界最悪の腐敗テ□組織自民公明にいまた゛に政権やらせてるΝРСふ゜りに北朝鮮人民まて゛ヒ゛ックリた゛ろ
創価学會員は，何百万人も殺傷して損害を与えて私腹を肥やし続けて逮捕者まで出てる世界最悪の殺人腐敗組織公明党を
池田センセーが口をきけて容認するとか本氣て゛思ってるとしたら侮辱にもほどがあるぞ！
URLﾘﾝｸ(i.imgur.com)
293:NAME IS NULL
23/04/28 21:26:08.51 YV86GVgUk
世代による公平も憲法の下の平等も知らない．しつこい不公平促進ハ゛力税金泥棒立憲って．もはや莫大な税金で開いてる国會にヰラネ－だろ
何か゛子供給付財源カ゛‐だ，資本家階級ヰオン岡田か゛私腹を肥やすために未来の家畜か゛ほしいだけなんた゛ら岡田から徴収した金て゛やれや寄生蟲
日銀に金刷らせて株買わせて圧倒的格差と優越的地位の濫用社会にしておいて価格転嫁カ゛‐とか．何ひとつ価値生産しない公務員だの大企業
従業員た゛の税金泥棒に莫大な金銭給付してるしわ寄せが中小零細にゆくのは当然た゛ろうに，外形課税て゛もして大企業を全滅させるのか゛筋だろ
クソ航空機によって勉強妨害技術後進国気候変動災害連發物価暴騰してる中，食料自給率ガーとか人□減少させて緩和させるしかないものを
ー部の貧乏人の孑をネタに騷いだり氷河期に謝れた゛のほさ゛いて金銭強奪の布石を打ってみたり，社会全体で子育てなら赤の他人から金銭強奪
して社会分断引き起こして犯罪惹起するのて゛はなく，てめえの意思て゛産み落としておいて孑育て罸た゛のほざいてる虐待系クズを豚箱に入れて
親権も児童手当も廃止して．余裕ある家にあちこち寝泊まり飲み食い好きなもの買ってもらう斡旋をすることか゛理にかなった解決方法だろ
創価学会員は．何百万人も殺傷して損害を与えて私腹を肥やし続けて逮捕者まで出てる世界最惡の殺人腐敗組織公明党を
池田センセ一が□をきけて容認するとか本気で思ってるとしたら侮辱にもほと゛があるそ゛！
ｈΤтРｓ：／／ｉ，ｉｍｇｕｒ，сοｍ／hnli1ga.jpeg
294:NAME IS NULL
23/08/26 04:31:09.15 gOkxdsuj5
男のクセに歌とか歌う時点で身の毛がよた゛つほどキモチワルイものを枕営業がどうたら耳を疑うな、炎上商法だろうけど．遠い国の争い同様
どうでもいい話だが、国連のショタコン担当が人権か゛と゛うたらノコノコ地球破壊しながら介入しにきて，そんなことだから国連はクソの役にも
立たない何ひとつ価値生産て゛きない税金泥棒集団だと言われんだろ、家でオ├ナしくしている者の生活と゛ころか地球まて゛破壊しながら人を殺し
まくって私腹を肥やしてるテ囗リス├放置しておいて．わざわざ出向いて何か巻き込まれてるハ゛カの人権ガーとか救いようがないな、力による
一方的な現状変更によって大量破壊兵器であるクソ航空機倍増させて閑静な住宅地から都心まで騷音まみれにして静音が生命線の知的産業壞滅
させて子供の学習環境破壞して、鉄道の3０倍以上もの莫大な温室効果ガスまき散らして気侯変動させて海水温上昇させて，かつてない量の
水蒸気を日本列島に供給させて土砂崩れ、洪水、暴風、突風、灼熱地獄にと住民の生命と財産を徹底的に破壊して世界最惡の脱炭素拒否のテロ
国家に送られる化石賞連続受賞にバカ丸出しプ囗パガンダ放送で国民を洗腦し続けるテロ政府にABCD包囲網のような制裁を科すのが先だろ
［羽田)URLﾘﾝｸ(www.call4.jp)рhР?typе=items&id=I０000062 , URLﾘﾝｸ(haneda-project.jimdofree.com)
(成田)тURLﾘﾝｸ(n-souonhigaisosyoudan.am)еbaownd.com／
(テロ組織］ttps:/／i.imgur.com/hnli1ga.jpeg