ほかは見ないねえ・・・ 0009NAME IS NULL2005/05/18(水) 00:26:23ID:??? Microsoft の Access についてなかったっけ?簡単な奴が。 0010NAME IS NULL2005/05/25(水) 01:01:16ID:??? sage 0011NAME IS NULL2005/05/28(土) 12:51:06ID:GrEiaLyo 自動なんたらツールって嫌! そんなのがあったら俺の仕事無くなっちゃうよ! 0012NAME IS NULL2005/05/28(土) 13:13:19ID:??? 今まで寝た女のあらゆるデータをカテゴライズしてDBにしたいのだが。。 0013NAME IS NULL2005/05/28(土) 14:26:58ID:??? 女(女ID) カテゴリ(カテゴリID, カテゴリ名) あらゆるデータ(女ID, カテゴリID, データ) 0014NAME IS NULL2005/05/28(土) 17:18:20ID:??? SELECT count(女ID) FROM 女; 0015NAME IS NULL2005/05/28(土) 17:23:15ID:??? レコードが選択されませんでした・・・ 0016NAME IS NULL2005/05/28(土) 22:04:23ID:??? 二年近くかけてやっと第二正規形か。 第五正規形になるのはいつの日か… 0017NAME IS NULL2005/05/28(土) 22:05:55ID:??? しかも第一は落ちただけだしな 0018NAME IS NULL2005/05/29(日) 07:55:28ID:??? SELECT cunt(女ID) FROM 女; 0019NAME IS NULL2005/05/29(日) 13:16:10ID:???>>18 SELECT 女.cunt FROM 女; 0020NAME IS NULL2005/05/29(日) 19:48:22ID:??? select distinct cunt(女ID) as count from 女 group by 女ID; これで決定か? 0021NAME IS NULL2005/05/29(日) 19:49:09ID:???>>20 大事なことを書き忘れた。 因みにMysql4.1.11です。 0022NAME IS NULL2005/06/07(火) 15:29:45ID:??? 正規化工数ってナンディスカ? いやここで聞くのも間違ってる気がするけど誰か知ってたら教えてアモーレ 0023NAME IS NULL2005/06/17(金) 02:41:50ID:??? 春のDB落ちた。午後Tあと15点だった。 0024NAME IS NULL2005/07/09(土) 02:15:52ID:??? Access好きはIDって列にPrimary Keyつければいいってもんじゃない事を 肝に銘じておいてくださーい!!DBAの敵ですよー!! 0025NAME IS NULL2005/07/09(土) 07:28:02ID:Ussu/qQy>>24 意味不明ですが覚えておきます。 0026NAME IS NULL2005/07/09(土) 07:28:18ID:??? 上げてしまった・・・orz 0027NAME IS NULL2005/07/11(月) 02:30:15ID:??? あー、>>24を読んだだけであの歌が頭から離れないー! 0028NAME IS NULL2005/07/19(火) 10:27:19ID:??? Normalization!! 0029NAME IS NULL2005/07/20(水) 05:28:41ID:??? Normalization is for modeling. When we actually building a database, we do not have to follow the rule. You 2ch guys should understand it, should'n you? 0030NAME IS NULL2005/07/25(月) 00:17:02ID:4Te3/qIT テーブルの構成の仕方で質問です。
最近は、そんな項目つけないようにさせてるので、自分ではみないです。 0068NAME IS NULL2005/10/11(火) 15:38:30ID:??? ここはお前の日記帳です 0069NAME IS NULL2005/10/13(木) 18:22:42ID:CdlqOxne>>49 のパターンで正規化する際に、 俺なら一番上の行のテーブルにtype列はつけないな。 主キー同士でexists演算やれば行抽出の段階では 索引しか物理読み取りしないのでパフォーマンス的にも問題ないと思うのだがどうだろう 0070NAME IS NULL2005/10/29(土) 12:14:45ID:zOZqpbV9 完全に近い形で正規化された設計を見てみたい(つдT) 0071NAME IS NULL2005/10/30(日) 02:58:04ID:??? 完全に「近い」形か、難しいな。 0072NAME IS NULL2005/10/30(日) 10:53:28ID:???>>70 完全なのは見たくないの?
とりあえず例となる問題を書いてよ。 「社員がいてー、社員には名前と生年月日があってー、社員は課に属していてー」云々。 わたしは、そういう問題が出されてからテーブル構成が出来ていく様子を見てみたい。 0073NAME IS NULL2005/10/30(日) 10:57:03ID:??? じゃあ、社員がいて名前と生年月日があって、課に属している 0074NAME IS NULL2005/11/09(水) 15:37:35ID:??? 社員テーブル1つ 0075NAME IS NULL2005/11/10(木) 01:16:33ID:??? >74 課テーブルくらい作ってやれよ。寂しいだろ。 0076NAME IS NULL2005/11/10(木) 12:40:37ID:???>>72 >そういう問題が出されてから 問題に出されている条件が正確なら正規化は難しくないが、 現実だとその条件が正しいかどうか抜けが無いかどうかの検証が作業の大半をしめる。 例えば同時に複数の課に所属する可能性や、部付きや社長や役員など課に所属しない 人間はいないのか、いたらどうするかなど検討する必要がある。 0077NAME IS NULL2005/11/10(木) 23:50:11ID:??? 社員テーブル ------------ 社員ID 名前
部署テーブル ----------- 部署ID 部署名 親部署ID
所属テーブル ----------- 社員ID 所属部署ID プライマリ所属部署? 付き? 0078NAME IS NULL2005/11/10(木) 23:55:33ID:???>>77 お前がやっていることはネタにマジレスってやつだ 0079NAME IS NULL2005/11/11(金) 11:07:24ID:??? 生年月日テーブルも作らなくちゃ
生年月日テーブル ----------- 生年月日ID 年 月 日 0080NAME IS NULL2005/11/11(金) 16:52:46ID:??? 年テーブルと月テーブルと日テーブルも 0081NAME IS NULL2005/11/11(金) 17:24:39ID:??? じゃあ曜日テーブルも作ろうぜ 0082NAME IS NULL2005/11/11(金) 21:41:39ID:??? 時分秒も・・・ 0083NAME IS NULL2005/11/11(金) 22:01:08ID:???>>82 いや、それはいらないな 0084NAME IS NULL2005/11/11(金) 22:04:55ID:??? 名前文字テーブルも作らないと ---------- 名前文字コード LONG PRIMARY KEY, 名前 IMAGE NOT NULL
社員名テーブル ---------- 社員ID LONG PRIMARY KEY, 文字順序数 INT NOT NULL, -- 名前の文字を表示する順序 名前文字コード LONG NOT NULL FOREIGN KEY REFERENCES 名前文字テーブル(名前文字コード) 0085NAME IS NULL2005/11/11(金) 22:11:56ID:???>>84 名前の読みはどうすればいいのだろう? やっぱ、PCMかな。 0086NAME IS NULL2005/11/11(金) 22:15:41ID:???>>83 そのつっこみ、今週で一番笑った 0087NAME IS NULL2005/11/11(金) 23:29:09ID:???>>77
出直せ。 0088NAME IS NULL2005/11/24(木) 11:31:47ID:??? 体重テーブルも必須だろ
体重テーブル ----------- 社員ID 体重
updateが多そうなので体重にindex付けるかどうか迷うが 0089NAME IS NULL2005/11/24(木) 11:40:14ID:???>>88 以前の体重と比較できるように計測日フィールド入れないとダメだろ 0090NAME IS NULL2005/11/26(土) 18:01:45ID:???http://www.doaplus.com/html/bun03_20051101.html 「正規化するとレスポンスが悪くなる」という「うわさ」は本当か? 百聞は一見にしかず。当分科会が実証実験を行いました。 0091NAME IS NULL2005/11/26(土) 23:39:38ID:??? 非正規化したテーブルを何でジョインするんだw 0092NAME IS NULL2005/11/27(日) 00:43:20ID:??? 確かに不思議屋根 0093NAME IS NULL2005/11/27(日) 16:57:05ID:??? >非正規形のDBを使っている技術者はJOINが遅くなることを体験しており、 >「正規化するともっと遅くなる」と誤解している。
比正規形のDBを使っている「技術者」だってよ。 0094NAME IS NULL2005/11/27(日) 19:51:55ID:??? 欺術者偽術者疑術者擬術者戯術者好きなのドソー 0095NAME IS NULL2005/11/27(日) 20:39:15ID:??? 俺も方法論的にはどっちかというとDOA派だけど、 >>90のようなアホなこと真面目にやってるから 古いって馬鹿にされるんだよな・・・ 0096NAME IS NULL2006/01/05(木) 06:21:42ID:RI5QmBcj 販売系のシステムで、受注データ取り込み時に、 取引先の商品コードと自社の商品コードを1:1で変換する必要があるのだが、 連関(変換)マスタを作るのが面倒という理由で、 自社の商品マスタ内に取引先の商品コードをも持っていた。 当時の設計担当に聞いたところ 「取り込み時に取引先の商品コードが重複してたら警告を出すから問題はない それにテーブルを増やすとPGが複雑になってバグが増えるだろ?」 と言っていたがしかし・・・・
0098NAME IS NULL2006/01/07(土) 03:33:51ID:??? 複雑にするとバグがおきやすいってのは真だな。パフォーマンス上もシンプルな方がキャッシュとか効きやすいし。 0099NAME IS NULL2006/01/07(土) 05:18:37ID:???>>96は思い込みが激しそうだなw 0100NAME IS NULL2006/01/10(火) 21:22:34ID:emDEfEEV すみませんが、質問です。