通常これは実在しない。 0562NAME IS NULL2020/12/28(月) 23:56:41.44ID:???>>561 ごめん、何言ってるかわからない 抽象的なデータモデルって何のこと? どっから出てきたの? 0563NAME IS NULL2020/12/29(火) 03:14:05.40ID:??? 更新異常が発生しにくいだけで 考慮する必要がないわけないわな >>561はエアプが即バレして煙に巻きたいのだろう 0564NAME IS NULL2020/12/29(火) 09:14:29.22ID:??? >ソースデータの正規形
これが抽象的なデータモデルを指しているのかと思ったんだが、そうでないなら話は簡単。 DWHは「ソースデータの正規形」が存在することを要求しないんで>>560は正しくない。 データソースが正規化された他のDBであることはあるが、それはそのシステム自身の 要求によって正規化されているだけ。 0565NAME IS NULL2020/12/29(火) 12:56:45.72ID:???>>557 正規化がバカにされてるんじゃなく 正規化を理解してなかったり正規化されてるかどうか以外にDB設計を見る目がないのに ドヤ顔でDB設計を語ろうとしてる人間がバカにされてるんだと思うぞ 0566NAME IS NULL2020/12/29(火) 14:29:23.16ID:??? それな ちょうど当てはまるやつがいるな 0567NAME IS NULL2020/12/29(火) 14:46:08.18ID:??? 頭おかしいやつには下手に触らず黙ってスルー推奨 0568NAME IS NULL2020/12/30(水) 00:27:51.52ID:??? RDBと関係ないRやPython使った統計処理の分野でも 分析をやりやすくするために下準備としてDBで言うところの正規化をしてる 更新異常を考慮する必要は全くないけど 0569NAME IS NULL2020/12/30(水) 09:11:39.06ID:??? そういうのごっちゃにすると話が発散するからやめて。 そもそもその「正規化」って、リレーションの正規化と違ってなにをどうするかきちんと定義されたものじゃないでしょ。 0570NAME IS NULL2020/12/30(水) 09:15:25.16ID:??? それに統計解析向けの加工って、クレンジングは最初に必要かもしれないけどあとは解析しやすいようにJOINしまくるのがふつう。 DWHのスタースキーマから任意に抽出した1つの表の形のデータセット、あれがまさに統計解析向けのもの。 0571NAME IS NULL2020/12/30(水) 18:11:29.74ID:??? エアプDWHの次はエアプ統計解析かよw なんでろくにやったこともない事を語りたがるのかね 0572NAME IS NULL2020/12/30(水) 18:23:27.87ID:??? データベース設計は軽視されるの原因と エアプ野郎が語りたがる原因の一つに 素人に毛が生えたような人間には難しさが分からず 自分でもできそうに思えてしまうところにある 0573NAME IS NULL2020/12/30(水) 22:22:42.93ID:???>>571 誰のどのレスに対して言っているのか曖昧でよくわからんが、とりあえずどのレスの どこがどう違っているのかはっきり書いたら? 反論は受けたくないけどマウントだけ取った気分になりたい中学生じゃなけりゃ。 0574NAME IS NULL2020/12/31(木) 00:08:25.03ID:??? エアプ素人さんはスタースキーマのファクトとディメンションがそれぞれ第何正規形か考えると良いと思うよ
>>565の言葉を借りれば正規化すら理解してないのにドヤ顔で語ろうとしてるのが丸わかりだから 0575NAME IS NULL2021/01/02(土) 16:36:20.20ID:2lMlvbHe ど底辺の土方グラマーだけどDB設計させられて「なんでちゃんとしたDB屋に頼まないんだよ、DBって根幹部分で大切だろ!」って疑問だったけどここ見て納得。 日本の企業が作る(使う)システムがクソな理由も・・・ 0576NAME IS NULL2021/01/02(土) 18:35:41.55ID:??? ある意味当たってる。 そうやってしばらくして、曲がりなりにもER図書いたり正規化ができるようになって いっぱしのDB屋を気取れるようになったら彼等の仲間入り。 0577NAME IS NULL2021/01/03(日) 14:52:40.06ID:???>>575 根幹部分だからこそDB中心のシステムを作る開発者なら誰もが身につけておくべきスキルだぞ
要件定義や基本設計を含めて依頼するならともかく DB設計だけを外部に依頼するのは今の時代にはそぐわないので設計専業のDB屋は絶滅危惧種 0578NAME IS NULL2021/01/04(月) 05:23:06.48ID:THUOMM/C ホンマにうわさ以上に凄いのが金さんの億様株レシピて投資ブログ。 ここまじで神すぎる! めちゃ当てまくる。 おすすめなのは危険な銘柄と宝石の銘柄て記事に出てくる銘柄。 0579NAME IS NULL2021/01/12(火) 12:19:00.49ID:??? プログラム組まないやつが設計すると保守性重視になるよな… 人間がパッと見て理解しやすい設計にしがち ナチュラルキー多用したり 0580NAME IS NULL2021/01/12(火) 15:18:33.28ID:???>>579 ナチュラルキーを多用してるにもかかわらず保守性が高いならいいんじゃね 0581NAME IS NULL2021/01/12(火) 16:22:51.65ID:???>>580 >>579は「保守性」と言っちゃってるが、実はたぶん保守性の話やないな。 初見のわかりやすさしか見えてないような、困ったちゃんの話なんやろな。 0582NAME IS NULL2021/01/12(火) 17:06:29.79ID:??? そうすると保守性を理解してない>>579が困ったちゃんってことになる 0583NAME IS NULL2021/01/12(火) 17:48:57.44ID:??? すまん、保守性って言葉が悪かったな プログラムの保守性ではなくて ユーザーからの問い合わせ時にデータ見てパッとわかるテーブル構造を好む 0584NAME IS NULL2021/01/12(火) 20:38:59.75ID:??? 人間にとっての見やすさというかわかりやすさも重要な品質要素だからね それを犠牲にして得られるメリットとのバランス次第 何と何をトレードオフしようとしてるのか理解してないうちはまともな設計は期待できない 0585NAME IS NULL2021/01/12(火) 21:08:10.26ID:??? パッと見理解しやすくて保守性も高いならいいことずくめに読めるが。
たぶん言いたいことは逆になにか問題があるということなんだろうけど 結論書いてないから何を言いたいのかわからない。 0586NAME IS NULL2021/01/12(火) 21:28:46.10ID:???>>585 理解力なさすぎ。 人工キー+JOIN前提みたいな、不慣れだとややこしげに見えるテーブルを組みたがらない素人の話なだけやろ。 0587NAME IS NULL2021/01/12(火) 21:37:08.48ID:??? だから、そこで自然キーの欠点や人工キーの利点を説明しなきゃ何を言いたいのかわからんだろ。 人工キーが自然キーより優れているのは自明だと思ってるとかそんなとこかね。 0588NAME IS NULL2021/01/12(火) 21:45:26.42ID:???>>587 SQL書くときに条件や結合は少ないほうがバグが発生しにくい プログラマにとってはサロゲートキーの方がわかりやすい
しかしサロゲートキーだと生データを見たときにわかりにくいことがある
ナチュラルキーとサロゲートキーの代表的なメリットデメリットだと思うけど…
その辺天秤にかけてこのテーブルはサロゲートキー、このテーブルはナチュラルキーと決定できるのは 設計もプログラムも保守もやる人。 どれか一つしかやらない人はこのへんのさじ加減わからないのでは。 0589NAME IS NULL2021/01/12(火) 21:57:42.32ID:??? こうやってブレイクダウンするとどこに誤解があるか見えてくる。
複合キーは扱いづらいのでかわりにサロゲートキーを使うことはあるが 自然キーだと一律にサロゲートキーより扱いづらいなんて理由はないだろう。 0590NAME IS NULL2021/01/12(火) 22:30:44.50ID:???>>589 おっしゃる通り複合キーの場合だな 大変失礼しました
設計と保守しかしない年配のSEさんはサロゲートキーを知らずに複合キーを使いまくる傾向にある プログラマは若かったり雇われだったりなので口出しできずにクソシステムの出来上がり 0591NAME IS NULL2021/01/12(火) 22:34:47.77ID:???>>589 めんどくさ。 そんな話じゃなかったやろ。。。
おまえは、自分が理解できない話を、自分が理解できるようにしたいだけ。w 何が「ブレイクダウン」や。w 0592NAME IS NULL2021/01/12(火) 22:41:52.84ID:??? >そんな話じゃなかったやろ。。。
どういう話なのか、お前はまず言いたいことを結論からハッキリ書くようにしろ。 0593NAME IS NULL2021/01/13(水) 00:21:46.78ID:??? 呼び名はともかく人工キーは80~90年代でも普通に使われてただろうから年配だろうが知らないわけない
複合キーは見てわかりやすいわけじゃないが 人工キーに比べると整合性を維持する設計が簡単なんだよ SQL書く時は面倒くさいから嫌がられるけど不整合が発生するのに比べればマシだから 0594NAME IS NULL2021/01/13(水) 00:38:42.76ID:???>>592 自分の理解力を棚に上げんなよ。 0595NAME IS NULL2021/01/13(水) 00:53:04.45ID:???>>593 不整合はユニーク制約つければいいんでないの 0596NAME IS NULL2021/01/13(水) 08:06:07.69ID:??? 同じ型の単純キー同士なら、それが自然キーか人工キーかで扱いやすさが変わることはないやね。 0597NAME IS NULL2021/01/13(水) 08:13:51.20ID:???>>596 変わらない 複合キーが問題 0598NAME IS NULL2021/01/14(木) 02:05:44.63ID:???>>593 ちょっと、「整合性を維持する設計」について詳しく説明してくれ 0599NAME IS NULL2021/01/20(水) 22:55:59.22ID:LfU5rlWt>>557 仕様変更に強いかどうか。それと人間にとってわかりやすいかどうか。正規化の話はもっともらしいが、ちゃんとしたテストと運用・保守をやっていれば、ただの非現実的な理屈だとわかる。 0600NAME IS NULL2021/01/20(水) 23:01:10.32ID:LfU5rlWt>>593 論理的な整合性をアプリケーションで担保する。そうでないとアプリケーションのテストも難しい。 0601NAME IS NULL2021/01/20(水) 23:02:58.59ID:LfU5rlWt>>598 彼はアプリ屋と壁を作るタイプだから、かかわらない方がいいよ。 0602NAME IS NULL2021/01/20(水) 23:16:12.27ID:???>>599 アホなの? 0603NAME IS NULL2021/01/22(金) 08:45:35.16ID:???>>599 このちゃんとした ってのがどれだけ難しいか 0604NAME IS NULL2021/01/25(月) 05:16:41.94ID:cGhuaVFN よく読め 06055752021/06/22(火) 17:07:34.18ID:??? ははは・・・ 晴れて?「DB屋()」の仲間入りしそうだ・・・ PostgreSQL9.3とSQLServer2005を、プライベートで、弄ったことあるだけなのに(実務ではOracle11の炎上案件の燃料として放り込まれたぐらい) 7月からPostgreSQL12がフロントエンドで、Oracle(ナンバリングは効いてない)がバックエンドで動いてる「工場のFAのすごいやつと思えば間違いじゃない(スマートファクトリー)」とかいう謎の説明されたシステムのDBチームに配属になったわ・・・ メカ系や移動体通信系のファームしか経験ないつにいきなり・・・ ズブの素人よりはマシかもしれないけどDBそのもののスキルだったらそこらの学生以下だよ俺・・・orz. 0606NAME IS NULL2021/06/22(火) 18:09:02.74ID:??? いまどきDBでチームがあるのか ある意味すごいな 0607NAME IS NULL2021/06/22(火) 18:59:21.66ID:wVCfrFWc>>606 開発対象が、工場の機械からデータ受け取る中継ボックスみたいなところから、工場の中間サーバから複数の工場の情報をまとめるサーバまで一貫してるんだそうな。 そして中継ボックス、中間サーバ、全体の情報あつめるサーバってのを全部面倒見てる10人ほどのチームとのこと。 まだ現場に入ってないから実態判らんけど、門外漢な俺を採用しちゃうところだし、上下どころか横の連携もまともにとれないようなカオスなところでもおかしくないって個人的な経験則が言ってる。
他に仕事ないから受けたけど、今から「どんなとこかなー? 抜けるとしたらどうやって抜けようかなー?」って考えてるw 0608NAME IS NULL2021/06/22(火) 21:26:23.41ID:??? もし関係者が見たら、特定できそうやな。w ほどほどにしとけよ。 0609NAME IS NULL2021/06/26(土) 18:20:28.11ID:??? データベースのテーブル設計書ってどうしてる? エクセル方眼紙にしてかいてるんだけど、なんかいいのないのかな 0610NAME IS NULL2021/06/26(土) 23:14:34.00ID:???>>609 MySQL Workbenchはどや? 最近は使ってないから知らんが。 0611NAME IS NULL2021/07/03(土) 17:38:43.26ID:R35jReGz>>609 A5Mk-Uがよく使われている。 0612NAME IS NULL2021/10/13(水) 12:36:34.50ID:??? データベーススペシャリストでよく問われるページサイズとか空き容量率とかどのメーカーのDBをターゲットにしてるんや? 教えてくれ 0613NAME IS NULL2021/10/13(水) 13:54:50.17ID:??? 特にどのDBMSをターゲットにしてるとかないぞ 一般的なBTreeを前提にしてるだけ 0614ド底辺PG2021/11/10(水) 22:00:45.28ID:KaB0M86I プロジェクトが燃え尽きたから別の案件に燃料しに行ったんだが、TEXT(可変長文字列)をPKにしてINDEX張ってて「パフォーマンス出ねぇ!」ってやってんですけど・・・ ちょう乱暴に描くと CREATE TABLE T_TAGS( JPN AS TEXT NOT NULL, ENG AS TEXT, ・・・品詞とか同義語とかの定義いろいろ・・・ PRIMARY KEY(JPN) ) て感じの定義で、SELECTのサブクエリとかでも ON TBL1.JPN = ・・・ みたいにテキストのカラムをJOINしてるんすよ?
ドテ・イ・ヘーンな俺でも「なんで数値でIDのカラムを作らないの?」ぐらいの疑問はあるんだけど、 これって「データベースあるある」だったりするの? 0615NAME IS NULL2021/11/10(水) 22:40:02.10ID:??? 遅いのがTEXTのせいだってどうやって判断したの? 0616NAME IS NULL2021/11/11(木) 00:02:07.19ID:???>>614 >これって「データベースあるある」だったりするの? 文字列をPKに使うかどうかは状況による 絶対避けるというほどのものでもない 個人的には可変長は極力避けるけどパフォーマンスクリティカルなシステムじゃなければ 全部可変長で揃えてても特に問題なかったりする
PKを数値にしたバージョン作ってさくっと比較すればいいんじゃん? 0617NAME IS NULL2021/11/11(木) 19:06:31.16ID:NSxyRLjO>>614 あなたの言っていることは頭がおかしいくらい変なことを言っている。
たまたまいままで見てきたテーブルの主キー項目が数値型だっただけで、根拠のない思い込みをしてないか?
念を押すと、頭のおかしい発言だぞ。 0618NAME IS NULL2021/11/11(木) 19:36:50.37ID:NSxyRLjO>>614 そのTEXT型がラージオブジェクト型というオチのネタ書き込みじゃないだろうな? 0619NAME IS NULL2021/11/11(木) 20:16:55.16ID:???>>617 そこまでやないやろ。w テキストはCOLLATEの懸念があるし、 数値のが望ましいのはたしかやし。