ここでいうデータベース設計とは、
特定の業務システムにおける
テーブルレイアウトを設計し、決める作業であるとします。
業務システムにおいては、
このデータベース設計（テーブル設計）は仕様そのものを定義する作業にも
近いと思いますし、この設計は開発工程やその後の運用における品質を
絶対的に左右するものだと思っています。
逆にこの設計があまりにも実現すべき仕様と比較し不整合なため、
その後の開発工程がデスマーチに陥ることも少なくないのではないでしょうか？
にも関わらず、正規化程度も理解できないような担当者が
この設計を行っていたり、業務システムの受託開発において、
「テーブルレイアウトを決める」という作業が、あまりにも軽視されているような
気がしています。
みなさんの現場ではどうでしょうか？
ご意見などお聞かせください。
データベースとは、リレーショナルデータベースを指しています。
驚くぐらい何も知らない。
確かにの言う通りだと思う
日本語を使ってるのやめさせたい。それからコボラーの薫陶を
受けたVBA使いの作ったシステムを全て作り直したい。
動けばいいとすら思ってない。
作って納品しちまえばおｋと思ってるw
本運用に入ったら誤作動しまくり落ちまくりってのはもう
狙ってそう組んでるとしか思えなくなってきた・・・
IDが何なのかってのを記憶してる人間が技術力高いつて重宝されとる……
若手のSEがDB設計中だったので覗いたら、テーブル名・カラム名を日本語で書いてる・・・
んで、それはやめようよと言ったら、マニュアルのどこにダメって書いてあるんですか！日本語は使えるはずですよね！
と言われたので、その場でPJから外してもらうよう上司に頼みに行った。
送り仮名で嵌るんだよ・・・
SHOHIN
SHOUHIN
前任のアフォが設計したDBでこれらが混在してたから
全部「商品」で統一して新規で作り直す仕事何べんもやってるw
このスレ読んでおれもＤＢ設計してみようかなと思った
そのたびに一から作ってたら間に合わんし客も予算出せないでしょ
実稼働中の物を今日まではこれ、でも明日からはこのシステムで
なんて無茶な用件はたくさんある
だからある程度の遊びフィールド作ったり妙な拡張して過去の残骸が残ってたりする物が出来てくるわけ
それを最初見た奴にとっては謎いシステムかもしれないけどさ
簡単に言うとガチガチに設計すると馬鹿を見る事も多いんだよ
コボラ？
データベース屋がまともな仕事をしないからだろ。
のような技術力の不足、利用シーンを考えない独り善がりな設計など。
むやみに正規化してりゃいいってもんじゃないし。
2008/11/12
を画面上でH.20.11.12
とかで表現するのはいいけど
DBにまで
H.20.11.12
として保存する仕様は勘弁してください。
そんなのまだまし。
3601112←これ昭和60年な
3201112←これ平成20年な
4011112←これ西暦2001年な
和暦は3で西暦は4な。
平成22年とベビーブームが始まる昭和22年はバッティングしないのでせうか( ﾟдﾟ)
生年月日とかでなければバッティングしないんじゃない？
それにしても、その仕様は無いなw
データが和暦格納で使いにくいな。
スレとは関係ないけど、そいつが吐き出すCSVはクォーテーションが付いてないので
うっかりExcelなんかで開くと、コードの頭のゼロが取れていたりする糞仕様。(0001→1)
心配するな。「"」付きでもExcelはゼロサプレスしてくれるよ。
んで、うっかりExcelで開いて保存しちゃったCSVを本番に突っ込んじゃった
アホがいたもんだから、マスタが一切引けなくなってえらい目にあった。
…DB設計の問題じゃないけど。
バッティングする。しかし詳細はばれるので明かせないが、３０年の期限が
管理できればいいので、生きてるデータは最古でも1978年。
死んでるデータはもうグダグダ。ゴミ。
可能です。
以上。
↓次どうぞ
経営者や管理職や客は、目に見えるものしか評価できないから、
DB屋よりもJava屋の意見を聞く。
↓
Java屋は、O/Rマッパを使いまくって、DBをオブジェクトの永続化ストレージ
としか考えない。DB設計？なにそれ？おいしいの？
↓
それでも動く。
↓
Java屋
「ほら見ろ、俺のやり方が正しい」
「DB屋の言うことなんか聞いてたら開発おわんねw」
↓
数年後： DBあぼ(ry
↓
開発当時の人間いない。だれのせいか分からない。
DBがダメになったから、DB屋が悪かったに違いないという判断。
↓
DB屋、ますます発言力低下。
↓
以下、ループ。
既に実装スタートしてたから皆でオンデマンドでDB設計やってたぜw
明治は１，大正は２，昭和は３，西暦は４，
てなのを大昔にコボルさんが組んでて、
昭和天皇の崩御で困った困ったって話？
つっか、マジな話、
今の天皇が幾久しく健康でありますようにと、お祈りする必要があるね。
まさに文系乙の、非論理的な設計ですね。
文系の声がでかいのも、論理的な正しい設計が軽視される原因と見た。
文系とか関係ないだろ。見通しの甘さが全ての原因だ。
ようするにバカなんだよ。
俺は運用側なので、開発側が主催する
システムリリースの打ち合わせに呼ばれる。
開発側の説明を受けた後で、運用上、設計上の問題をあげ、
改定を提案すると、いつも返答はこれだ。
「リリースしないと業務に支障がでる！」
だったら、システム設計のころから打ち合わせに呼べよ。
割を食うのはいつもこっちだ。
すまん、愚痴った。
カラム名が日本語や日本語をローマ字にしたものであるとか、
運用を続けていくうえで仕様変更が続き過去の残骸データが残っているとか、
このあたりはもうしょうがないというか、諦めています。
我慢できます。
問題にしたいのは、論理性（純粋な意味での設計）です。
例えば1対nの関係にある情報を2テーブルに格納すべきところを
1側の情報を多側にn個格納したり、
候補キーが不十分で対象のレコードを特定できないケースがあるテーブルがあったり、
日々追加削除が発生するテーブルが第3正規形になっていなかったり、
（ケースバイケースがあることは承知しています）
こういった問題のほうがデスマーチに陥りやすいと思います。
で、デスマーチに陥ったら陥ったで何故かプログラムで対応しようとする。
設計に立ち戻らないんですね。ここが問題だと思っています。
それが緩い、いい加減なところの上でシステムを構築することが、
いかにリスクが高いか、判らないのかねぇ。
判らないんだろうなぁ。
システムは目に見えないからねぇ。
このスレは書き込み少ないけど非常に参考になります。
もう稼働してしまっているから大きな改造などは怖いので出来るだけやりたくないという理由
でも・・・なんであいつ等それを教訓にして次の土台の硬め方を変えようとしないのか
同じような設計して同じようなトラブル産んで・・・・
追伸
正規化とかもやりすぎは使いにくさにつながるかもしれないけど、適度な正規化くらいかけてください。
ＤＢも使い捨ての時代じゃないの？
DBは後々、受け継がれて残っていくからなぁ。
アプリケーションの進化に比べると、SQLやRDBの進化は遅いしね。
っていうか全角でＤＢ www
最新のDBの機能なんて誰も使いこなしてねーじゃねーか
OracleやDB2なんかは使いこなしている奴の方が極レアだろうに。
スキーマ設計手法やクエリ言語に関しては案外ゆっくりと
しているのではないかと。
SQL92以降の拡張って実際どの程度使われていますか？
あとは、ORマッピングの活用とかそっちも全然進んでなくね？＞特に日本
あれこれ頑張っていると感じる。
O/Rマッピングにそんなに価値を感じてるのですか？
流行に踊らされていませんか？
O/Rマッパには、
DB「設計」不要の簡易システムなら画面プログラマだけで作れる、
という以上の価値は感じられない。
簡単なものが簡単に作れるのは実際ありがたいし。
ちなみにDB設計不要ってくだりはｲﾐﾌﾒｲだな。
そりゃＤＢ設計者と思い込んでいる運用チームの人間が言っているなら
なんとなくわかるが。ｗ
糞なテーブル設計でも、一応動くし、速度も糞高い鯖でも買えば力技で何とかなるのも事実。
PGの学習能力は、そもそも糞なPGなのか、予算的問題で優秀なPGが確保できてないのか、営業的問題で長期運用を前提として無いとかだろう。
営業的には４年程度なんとか動いて、定期的に新しいシステムに更新してもらうのが儲かる。データ移行という名目でぼろ儲けしているのをわざわざ無くす必要は無いし。
運用ならもうちょっと強く逝ってもいいと思うぞ。開発の尻拭いも大変だろうし。
そのままリリースしてしまうと業務に支障がでる！
と強く逝ってやれ。実際、業務に支障が出るのは毎度の事だし。
ある程度汎用的に使おうとすると、結局は最新機能は使わずに終わってしまう事が多い。
このアプリケーションでは対応して無いとかで最大公約数的に使える機能が絞られて行く。
SELECT一文で数KBとか馬鹿もいいとこ
このマシン遅いとか、冗談きついわ
アプリで処理すべきことをDBにやらせて遅くしてるのはお前だ
アプリにやらせて遅くしてるやつの方が多い。
とても遅くなって困る。
ttp://capsctrl.que.jp/kdmsnr/wiki/bliki/?DomainLogicAndSQL なつかしいなそれ。割引金額をアプリで持ってるから
割引率変更になった時点で過去売り上げの改ざんになるのな。
揚げ足取りはさておき、ドメインロジックはまだいいんだけど
クロス集計とか頑張ってやってたのを見てびっくりした事ありますよ。
今はSQL/OLAPが使えるようになってきて随分楽ですね。
テーブル設計がよろしくなくて、アプリ側でエラい苦労させられたことがある。
SQL書けねえやつに設計させるなと。
SQLが問題なのか、
アプリが問題なのか…についてですが、
結論からいって、全てにおいてまずテーブル設計の問題だと思います。
理由はそれが土台だからです。
テーブル設計がおかしいという理由で、
おかしなSQLを書かざるを得ない状況に陥ることは多々あるし、
テーブル設計がおかしいから、
アプリでおかしな制御をせざるを得なくなったりするんです。
それと、「正規化もやりすぎると使いづらくなる」などという意見がありましたが、
自分は何があっても、どんなシステムあっても、どんな利用用途であっても
RDBでデータを管理する以上、必ず全てを第三正規形まで落とす必要があると思います。
正しくはその正規系を業務や仕様にあわせて（敢えて）「崩す」のです。
だから「正規化はしないほうがいい場合もある」というのは語弊があります。
正しくは「正規化は必ずしなければならない。その上で（状況に応じて）崩すことは構わない」
ということです。
要件定義から設計〜実装〜テストまで自前でやればドコがおかしいか
自分で気がつくだろうに。
時々、老害が自分の立場を守るためにくだらねぇ自己主張
しまくるから、設計がグダグダになっていくケースがあるしなぁ。
二人一組ぐらいにはするべき。
「意識が途切れる」「遠いところに逃げる」「宙を舞う」。含意は色々ですが。
と真顔でのたまう、うちのSE。。。
飛ぶっていうのは逃げるとか逃亡するとか辞めるとかの意味。
あるコードに対して対象か対象じゃないかをマスタのレコードが有るか無いか
で判定するのはRDBとしては誤っていると思うんだけど。
RDB設計をまともにやればシステムの便利さは格段に向上するのは間違いない
システムへの要求も高度化するだろう。RDB設計をまともにしない人には
低度な要求を解決する仕事を続けるためにRDB設計を軽視し続ける
べきだ、保身のために。
日本は現場の国だ。現場以外は糞。そしてシステムに関する決定権は
現場には無い。使う側の現場力と開発する側の現場力が糞によって
互いに相反する方向へ注力させられている。まったく無駄なことよ。
ttp://www.google.co.jp/search?q=result+site%3Acerema.co.jp 設計を軽視するとこうなる
>あるコードに対して対象か対象じゃないかをマスタのレコードが有るか無いか
>で判定するのはRDBとしては誤っていると思うんだけど。
RDBでないDBはそうするしかないと思うが。
RDBでそうしているオマエの現場が糞と言うなら「そうだろうな」としかいい様がないわけだが。
「システムに関する決定権は現場には無い」ってオマエがオペレーターみたいな
現場といっても最底辺だとないだろうとは思うが、普通の開発現場なら
あからさまにイカれている設計なんかはレビューや評価で却下すればいいんじゃねーか？
そのレビューとやらに呼ばれないｗ
Oracleやってる奴も汎用機COBOLで経験つんだエンジニアばっか。COBOL流のシステム
設計をむりやりOracleに載せてる。それが常識で考えた標準らしいですよ。何も言えねえ。
こいつはどういう状態のことだ？
つうか、>67はどんな対案が正論だと言いたいんだ？
1:n設計は間違いだっていう主張？
ひどいｗ
これは損害請求レベルじゃないのか
---------------------------
1 | 存在する
2 | 存在しない
3 | 存在する
or
レコード番号 | 存在フラグ
---------------------------
1 | 存在する
3 | 存在する
の違いって事？
レコード番号 | 対象フラグ
---------------------------
1 | 対象
2 | 非対象
3 | 対象
※フラグ見て対象かどうか判断
or
レコード番号
-----------
1
3
※レコードの存在の有無で対象かどうか判断
の違いって事？
どういう状況でどんなテーブルに何をしようとしたのか端的に説明してくれ。
とにかく状況が小出しじゃ何も判断できん。
あと、「引く」という言葉の意味が分かりません。
ひくわ
なにか、ＲＤＢがあるからデータ入れよう的な考え方に聞こえるぞ
まったく結合するものがないなら、「Ｒ」ＤＢである必要はないわな
レコードがあるかないかで判断するか、（結合された）レコードに書かれてる内容で判断するかは、
それがどういった情報を格納してるかで決定するべきで、ＲＤＢなのだから
必要ない結合先のレコード（や、もしかするとそのテーブルそのものも）を作らないといけないということはないだろう
>そしてシステムに関する決定権は現場には無い
現場は必要もないＲＤＢを使いたくなく使ってるのかもしれないな
そして必要もないのに、ＲＤＢだからどうのこうのという、
現場の空気を読まない原理主義者みたいなやつがさらに話をややこしくするんだ
口調が違うが同一人物じゃないのか？
ちなみに、ＲＤＢ使った開発でＳＱＬを書いてるやつでも、
exists使ったことないってやつは結構いるだろう
ＲＤＢだから、ＯＲＡＣＬＥだから、レコードのあるなしで判断するのは間違ってるだろうとか
その判断基準がおかしいとしか思えん
まあ、現実的なＤＢの選択としてはＲＤＢＭＳしかない現状もあるがな
実際にこういうことを口に出しちゃうと
「頭でっかちで現場じゃ使えない」って評価になるんだよね
おれがそうだからよく分かるwww
それで親の無い子レコードや、不正なデータが山のようにあるんじゃ世話ねーよ
設計と製造の現場はまさに自分はDB設計を軽視してませんって顔して
キーマンの顔色を伺って程度をあわせる世界だよね。アホすぎｗｗ
ここもそんなもんだね。あ〜あ
ここもそんなもんだねとか達観した気になる前にここで吐き出せよ。>80みたいに。
それすらできないくせに嘆くな。
はどう？
市況２のスレを読んだら、どうも
データベースがぶっこわれたみたいで、金曜の取引データが飛んだみたい
で、約定メールから復旧させようとしてるとか
ぼくの考えたデータベース持ってキター！
さて、どうすっかな・・・
データベース設計に携わる人間が軽視されているのだ。
という命題をたててみる。
それは、その人間の行う作業が軽視されてるから、
その人間が軽視されてるじゃないか
そうでないなら、別の人間が代わりにその作業をすることになるだろう
データベース以前の問題だな。
結局、現場の意見のほうが採用されて、ボンクラDBA涙目。
組織で仕事するという条件で目標を達成するためのスキームをちゃんと考えたほうがいいよ。
本気で思ってそうな人がいることだ。RDB的な不備が出るのは現実的に
仕方の無いことだが、あくまでも例外であって、あるシステムの中で数個の
数少ない心残りとして記憶されてしかるべきもの。
こんなバカだらけではキーマンの顔色を伺ってISAMバカ基準でシステムを組んだほうが
計画は立てやすいだろう。RDBMSを使ったPK、ソート、VSAMユーティリティと考える。
だいたいRDBMSをPK、ソート、VSAMユーティリティとしてシステム組んだ経験がある
人だとそれで正解だと誤解しちゃうんだろうな。それで動くから。
底辺会社の底辺システムの目標としてはそれでもいいだろう。動けば底辺客も
文句言わないから。しかし、そんな設計してRDBの特徴を活かさなかったら
RBD以前の非生産性を引きずったシステムが出来上がるわけだよ。しかし、
その非生産性は1円入札して保守で儲けるビジネスモデルでは工数が稼げる
かもしれんよ。いつか関わりたいなRDBのシステム。。。
そういえば某メガバン統合でCOBOLアホシステムで統合決定してるのが象徴的だねえ。
COBOLアホシステム準拠が日本では巻かれるべき長いものと決定したようなもんだ。
ああいうのは変に金があるから、コスト度外視の設計しても疑問に思わずに、
「こういうもんだ」と納得してんだろう。
提案してるベンダもリスク回避として、今のシステム踏襲路線てのも悪く無い決断だと思うけどな。
まずは確実に統合して不具合を出さない事が第一目標だろう。一気に欲張って失敗するくらいなら、落ち着いてじっくり今後を考えればいい。
RDB的に正しい正規化した設計と、現場が把握し易い伝票ベースの設計のどちらがいいかは力関係も大きいし。
お前の考え方は、道具に合わせてものを作れって考え方だ。
それはそれで否定しないが、その考え方だけが唯一の正解のごとく、
他の考え方を貶めるのはやめたほうがいいぞ
DBAは不満だけど、実績のある既存のシステムで、銀行ATM止めずに問題なく使えるのと、
どちらを決断するって話だろ。
DBA様の首斬って損害賠償請求逝ってもよければ、勝負もあり。
単に突然使えないのが事前に「メンテナンス」と言う言葉で停止させるかの
違いなんだろうけど、その「メンテナンス」が予定時間オーバーも珍しくないワケで、
利用者としては「アレ？朝には使えるって言っていたのに･･･」ってクレームも
たくさんあるんだが。
結果論からすると「COBOLでも十分に失敗する」と言う前例は今回の合併だけでなく
以前から繰り返されている予定調和な感があるけどな。
U○Jの以前の倒壊＆惨羽の合併ではそんなに混乱は起きていないけど、
ＭとU○Jではこんなにゴタゴタしているのは、両者の技術レベルのギャップが
凄いんだろうなぁ。Ｍは特に悪評高いパッケージだし。
DBAの提案聞いてオープソ系とか導入して何日も復旧できなかったら終わる。
「○時時点でこのチェックポイントをクリアできない場合は戻す」と言う具合に。
そこまでしておいて、それでも予定時間オーバーってのは、
COBOLを前提とするシステムと言うのは性善説に成り立っている仕組みが多いという事だな。
逆にオープン系なんかは性悪説(?)に成り立っている感があるので、
JOBの再投入もやりやすいように設計する人おおいからなぁ。
そして何日も復旧できない事態なんて存在しない。
オープン系が優位とは言わんが、COBOLが実績があって安定性云々なんて
寝言を言う人間は間違いなく現場の金融系の実体を知らん厨房だと思う。
君は知識的にコンプレックスがあるだけだと思うよ。勉強不足だからホントの事いわれると
貶められたような誤解をするんだと思う。スコップをちりとり代わりに使用しても不便だ、
三角より平型スコップならちりとり性もupするよね。実際、いくつかのOracleのバージョン
アップはISAMシステム実装のしやすさも機能強化されていってると思う。
おれはDBAらしい仕事は一度もしたこと無いが、SEのRDBコンプレックスは見苦しい。
もっと使いこなさないと関係モデルは組めん。半端な知識だから破綻してISAMに
逃げることになんだよ。そんなISAMやりたいんならRDBMSを開発する側に回るべき
だね。そこに食い込めないなら引退すべきだよ。老害なのかなと思う。
だれもオープン系のシステムにしてくれないｗｗｗ
Mが従来通りの路線で行くのを理解できないほうが、現場の金融系の実体を知らん厨房でしょ。
だからオープン系のシステムにこだわり続ける。
実務やってる現場は、結局システムの中身なんてどうでも良いし。ちゃんとシステムが動く実績がある事が重要。
オープン系って何日も復旧できない事態って本当に存在しないの？
全部のオープン系システムの事態を把握してるのも怪しいが。
1つの長大なテーブルをいくつものPGでいくつもいくつも作るシステムといえば伝わるかな？
現に動いてないと言う実態を知らんのか？
あのメガバンのメンテナンスと言う名の停止っぷりは半端ないが。
当初のスケジュールがどんどん遅延して何年かけて統合するつもりなのか知らんが、
現場はいい迷惑だ。
本当にそんな人種いるの？
それならExcelでいいじゃんよｗ
俺は別にコンプレックスをもって言ってる気はないんだがな
お前のいうホントのことって何だ？
まあ、お前がＲＤＢ使ってないのはバカ基準で底辺のアホシステムだと
考えてるというのはよくわかった
まあ、思っててもあんまり簡単に他人をバカだアホだ底辺だといわんほうが良いよ
オープンだろうが大型汎用機だろうが関係なく、あんな大規模なシステム統合を本気で丁寧に障害なく
進めるならあれくらいは当然だと思うよ。
見切り発車のＭとみっちり石橋たたきのＭ。どちらがいいか経営者には良い判断サンプルになったんじゃないか？
石橋を叩くのを選べるほど金が使えるのはＭくらいだろうけど。システム部長は石橋を叩けるだけ叩くのが仕事だわな
理解し合うのははっきり言って無理
いや相容れないだろ。このスレ読んでもわかるように
それぞれの優先順位が違いすぎるもの。
プログラム言語の違い以上に深い隔たりがあると思う。
新人の時からデータ中心アプローチをたたきこまれた俺としては、
９２さんの文章は少し挑発的だけど、内容はけっこう共感できるよ。
によると、ここでは「業務システム」についての設計の話だそうだから、
データ中心で考えるのが正解ではないのか？
理解するだけではだめだな。妥協が必要
ただ、その妥協点は、かなりどっちかよりでないと成立しない
実際は設計するときにどっちの考え方でやるか統一しとかないとだめだな
業務システムの設計だから、データ中心が正解だという理由を説明してほしいもんだが
プロセス中心の設計は間違いなのか？
データーベース設計の話だから、データ中心の方が良いというのなら理解できるんだがな
たいがいにおいて業務プロセス中心に開発するんじゃなくて
システムプロセス中心に開発するの意だからな
そして次の契約が取れず淘汰されて行く。
いや、逆でエンジニアにオナニーさせたほうがいいものができるぜ。
マネージャのオナニーの結果、よくないものができてるのが現状でしょ？
マネージャとエンジニアのセックスなんてありえないでしょ？
DB設計は家を建てるのに例えれば基礎工事みたいなもんでしょ
外観や内装に注文つける客はいても、基礎工事に注文つける客はいないでしょ
ここは地盤が緩いから事前にこれだけアンカー打ち込んでおけと
指示しても施工出来る人がいないとか後での設計変更が云々とか。
DB設計軽視はシステム開発の耐震偽装みたいなものかな。
一番怖いのは、営業と客のオナニー
日本ではマネージメント専門の人はプロジェクトにいないのが普通
そういう意味では真のマネージャーなぞ存在しない
情報系の人間がただでさえ軽んじられてててさ、
当社では工学部おっけ〜、文系でもおっけ〜、だれでもおっけ〜みたいな会社ばっかで
まともに学校でDBについて勉強したことないやつが多すぎるからだろ
情報系はもっとも理解されてない学科
文系、理系の問題ではないと思います。
私は文系ですし。
ふむ。
今の情報系の学科がどのようなカリキュラムか知らないが、
大学出の者を戦力と考える会社はいまどき居ないだろ。
会社としては2,3年掛けてようやく戦力として使えるかな？
という人間を探しとているということではないかなぁ。
それには出身の大学、学部、学科はあまり考慮されないと思う。
中途なら、出身大学のランク高くても、経験や実績無ければゴミだろ。
IT系は専門知識不要で採用してしまうからな。そして現場で不良施工状態のデスマ。
ちゃんとIT理解してる理系が、人嫌いでPCにばっかり向かっていて、客との対話を営業任せで放棄してるのも、低コストで短納期で突貫工事的な変な仕様で迷走する理由の一つだと思う。
客は住み易さとか快適性能に重点置いてるのに、施工してる側は基礎工事だけに専念していいものが出来たってオナニーを満足してちゃ意味無いだろ。
家は３回建て直さないとまともなものが出来ないように、システムも１回で使えるものが出てこないのは、理系のオナニーのため。
ＰＧ無しで開発できる。プロトタイピングからスパイラルモデルで進めれる
２サイクル目でＰＧの帳尻合わせなんかしないリモデルリトライだ
だいたい物理的組み立て積み上げで作る家なんかと比較してるなんて現実にあるシステムの機能を
知らな過ぎ
二人ともモノ知らなさ過ぎな事はわかるがｗ
突っ込みどころ満載だなwww
DB技術者を名乗っちゃうから嫌になる。
自称DB技術者のおっさんが主キーがどれかすらはっきりしない
テーブルもどきの何かを作ってきたんで正規化してくれと頼んだら
しばらくネットで何かを調べた後にテーブル数が増えてわかりにくくなるから
正規化しなかったと言い訳してきた。
よくネットでテーブル数が増えるから正規化はしなくていいなんていう
無茶苦茶なことを書いてる似非DB入門サイトがあるが、それに騙されちゃったんだろうな。
いたら結構イヤン。
データベースがどのような事に使われていくかはシステム稼働後にしか分からないし。
呼び出してるDBアプリほど、柔軟には、DB側は組み直しとか出来ないし。
簡単に正規化組み直しとか出来る機能が付けばいいけどね。
組み直しが難しいのはPG
使う、っていうのが、システムの変更も含めているのならまあそうかもしれん
だが意図して正規化を崩すのでなければ、変更した技術者のスキルの問題だろう
普通はシステム稼働まえに、設計の段階でどのように使われるか考えるものだろう
DBの変更はプログラムの変更に比べれば簡単だと思う
簡単であるが故に、設計がおろそかになってるんじゃないかと思うな
データモデルを作り上げてインプットとアウトプットを固めないと
糞PGになんじゃん
何を言ってるんだか。
おまえは半年仕事を休んでデータベーススペシャリスト試験を
本気で合格する気で勉強してみろ。
言っておくがオラクルなんかのベンダー資格なんてとっても意味はないぞ。
基本が身についていない奴が製品に依存した知識を持ったところで意味はないからな。
まったく、嫌になる。
１０年後まで考えてデータベース設計するのは無理。
最初は在庫管理で作ったのに、拡張で顧客管理も入って、更に拡張で売り上げや経営財務管理まで入ってくるし。
アナログ的に言うと、社内帳簿フォーマット変えるのと、利用してる現場担当者入れ替えるのとどっちが簡単かって話。
問題は糞利用者が使ってる糞帳簿を改善することではないんだよ。デジドカの鉄則だ
他の板に居場所ないのか？
ちゃんと安価書けよこのうんこ
自明って、お前の主張はどっちなんだ？への反論なのか？
最近は単純に「上流」工程だの、「下流」工程だのと、
誰かが宣伝したテンプレに従い過ぎだ…
んなもん、ケースによって全然違うんじゃ〜い！
崩れる」というのは具体的にどういう状況を指すのかちょっと興味が
あります。
更新のコストが馬鹿にならないので非正規化する、というケースは
理解できるのですが、例えば業務内容に上手くマッチしなくなった
のでスキーマを改変する、というケースであれば、なんで改変後も
正規形を満たすように改変しないのかな、と素人考えでは思って
しまいます。
もし宜しければ簡単な例など教えていただけないでしょうか。
スキーマ改変なんて現実は、なかなか遣れない。スキーマ改変について来れるようにアプリ側で対応してるのも見た事無いし。
そもそも決まった数以下しかないから」っていわれて
しかも見出し・明細が1行のレコードとして
外部と連携したりなどなどで正規化やめたことはある。
それはその技術者のスキルが低いからうまくマッチングできないんだろ
が言う、既存部分の変更を嫌がるのが一番の要因だとおもう
あとはのいう、外部要求に合わせるためか。
こっちはできれば、ビューとか外部出力するアプリでの操作で回避したいとこではある
なるほど。の繋がる相手に合わせる、というのはよく分かる
気がします。
はまだちょっと難しいです。
既存のスキーマを改変するのはなかなか難しいというところまでは
理解出来るのですが、スキーマを改変しないならそもそも正規形も
崩れようが無いのでは？と思ってしまいます。
これは例えば住所を2件持てるようにしたいので一つの住所カラムに
タブ区切りで2個住所を入れちゃうぞとか、スキーマはそのままでも
入れるデータによって正規形が崩れてしまうような状況を指している
のでしょうか。
いろいろなデータが追加されていくと、正規化が崩れていく。
１０年拡張もせずに動かすというシステムなら、正規化は当初のまま有効だろうね。
たとえばアクセスだとトリガやストアドプロシジャが使えない
そういった、アクセスではできないことを考慮した設計は必要
テーブル設計での正規化とか、そういった基本はあんまり大差ないとは思うが
その人の言う「汎用系DB」って、IMSとかのことだったりしてな。
それを非難するやつがいたとしたら
そうなるまでには経緯とレベルがあるなんて
理解出来ひんねやろうな。
DBがあります。それが正規化されてるとします。
その場合は
１仕様策定の主導権がDB側にある
２パッケージソフト
３数人で作った小規模システム
４出来たてのシステム
５システム仕様が業務効率化など低レベルなもの
かな。
は、特定の部署でしか使わない、今まで手でやってた仕事を
システム化しましたみたいな
入門者みたいなシステムしか作ってないんちゃうかな
正規化されてないDBに経緯があるのは理解できるがな、
レベルってのはなんだ？レベルが低いから正規化されてないのか？
そんなの非難されて当然だろう
お前の言い分だと、正規化されていないのが当然のように聞こえるが、
お前こそ入門者みたいなシステムしか作ってないんじゃないのか？
は何も正規化だけを問題にしてるんじゃなくて、
設計が大事なのになぜ軽視されてるんだろう、って話だが
お前みたいなやつがいるからなんだと思ったぜ
遅くなりましたが、
ありがとうございます。
ﾄﾘｶﾞ、ｽﾄｱﾄﾞﾌﾟﾛｼｼﾞｬ、頑張って調べます。
正規化したくても全部のアプリ作り直しは無理。
ttp://pc11.2ch.net/test/read.cgi/db/1116097001/ 頼むから正規化しろよ 第二正規形
アパッチのアクセルログで取れる情報のER図をかけといわれたのですがどんな感じのものをかけばよいでしょうか？
一応アクセスログの仕様については調べたのでログフォーマットとかカスタムログとかの記述方法はわかるのですが
これをER図にしろと言われたらよく意味が分かりません
データベースのテーブルでもないのにこんなもんをER図に出来るもんなのでしょうか
よろしるおねがいします
でも、きっとそんなことは無いはずなので指示者に一応確認してみる。
うまく聞き出せないなら、指示者が長期休暇中なら、貴方が｢こういう使い方したら便利だよね｣と思う使い方を想像し、それにあわせた構成でER図を描けばおｋ。
あとはログフォーマットの各項目をそれぞれ配置する、と。
ついでに｢こういうことするならこんなデータも無きゃいけませんよね｣ってな要素を付け加えて提案してみるのも良いのではないかしらん。
例えば、IPアドレスのブラックリストを準備して、ログテーブルとIPアドレスをキーにジョインして｢ブラックリストのIPからのアクセスだ｣とわかるような仕組みを入れてみるとか。
・IPアドレス
・ユーザ
・アクセス日時
・発行メソッド(参照URL)
・ステータス
・他もろもろ
がどういった関連を持っているか書け、と言う事なのでしょうね。
例えば、URLを中心において
・そのURLに紐づくユーザ
・そのURLに紐づくIPアドレス(アクセス元IPアドレス)
・そのURLに紐づくアクセス日時
といった要素の関連を書き表すとか。
学校の宿題なのか、新入社員さんの研修課題なのかわからないけど、まぁがんばって。
出したやつは馬鹿だなｗ
結構こういう汎用ログからのデータ収集って実社会で役に立つと思うが。
注目してる香具師が極端に少ないだけで。
普通にアクセスログ表示ソフトがどんな項目で分析してるか調べるといいと思う。
ttp://pc11.2ch.net/test/read.cgi/db/1232457109/ 「ビジネス」BIツール「インテリジェンス」
ttp://pc11.2ch.net/test/read.cgi/hp/1218494105/ 【アクセス解析】Google Analytics 5
ttp://pc11.2ch.net/test/read.cgi/hp/1098282501/ 詳細なアクセス解析をしたい！！！
ttp://pc11.2ch.net/test/read.cgi/php/996937818/ Analogスレ
ttp://pc12.2ch.net/test/read.cgi/unix/1014402672/ 統合監視ツールどうよ?
ttp://pc11.2ch.net/test/read.cgi/linux/1150732249/ GNU/Linux とネットワーク/セキュリティ
あと、IT監査とかで結構需要は多い。一般ソフト並みとはいかないけど。
よく読め。ログをERで表せって話だ。
もう少し他の意見も参考にしたいと思ってこっちに来ました。オッケーウェブの方はもう締め切って
あるので、マルチだと言わずに聞いて欲しいです
僕が質問したトピックはこちら
ttp://okwave.jp/qa4946216.html ＥＲ図が削除されていたのでもう一度アップしました
ttp://kansai2channeler.hp.infoseek.co.jp/cgi-bin/joyful/img/9156.zip 確かに回答の通りこの場合はok_ngで検索すればいいだけなので冗長だと思いました。
そうすると、この１対１の関係が成り立つのはどのような場合でしょうか？
使い分け方とメリットデメリットあたりが聞きたいです。
それと、１対１のテーブルは、たまたまマイレージプログラムと乗客のテーブルで見たのですが、
それは「特殊」なパターンなのでしょうか？それとも一般的なものでしょうか？
そのあたりも教えて下さい。
｢こういう理由でこの１対１の関係を作ったのだけど、どういった問題があるか指摘して欲しい｣
のような話でないと、なんともいえないです。
｢合格者テーブル｣を作った理由ですね。その理由からメリットデメリットが導かれてくるんじゃないかなぁと。
訳もわからず、理由も無く、なんとなく作ったのなら、それは意味が無いし先の回答者の様な返事になるだけですよ。
※自身で「冗長だ」と思うならそういう設計をしなければ良いわけで....何故悩むのかと。
もし本を読んで見つけたのならそのデータ構造を作る理由を読み直して理解した方が良いです。
※あと、「そうすると、この１対１の関係が成り立つのはどのような場合でしょうか？」も
ちょっと意味が判りかねます
okで回答した香具師に失礼と思わない訳？
にちゃんで回答した香具師にも失礼な行動は予想出来るよな。
にちゃんで回答してもらったが、納得出来ないので教えて欲しいと他所でまた訊くのだろ？
後日談とかちょっとだけ楽しみにしてた私はマヌケだった。ﾊｽﾞｶｼ.....
UNIONで結合したような統合テーブルが設計されていたのだが
オラクルが特別なのか、案件が特別なのかどっちらでしょうか。
viewのこと？
view ではなく Table です。項目を大雑把に書くと
テーブル名,詳細キー,値1,値2,テキスト1,テキスト2,日付1,日付2,備考,etc…
値の例）
部門,1,null,null,営業,null,null,null,テキスト1:部門名,etc･･･
消費税,1,5,null,null,null,null,null,値1:消費税率×100,etc･･･
オラクルに限ったやり方ではないし
特別ってほど奇異でもない
ただ例としている部門と消費税を一緒にするのはエスカレートしすぎって感じ
もしかしたらものすごく特別な使い方してる可能性もあるし、
結構見られるようなものかもしれない
汎用的なマスタとして使ってるのかもしれない、リポジトリのような使い方かもしれない
が、使ってるDBMSだ何だろうと、そのテーブルがそのままの形なら
設計やり直してくれとお願いするな、俺ならｗ
まあその時の担当じゃなければどうでもｗｗｗ
コボルベースの設計とかを引き継ぐ理由とか有るのでは？
オラクルだからって事ではないんですね。
リポジトリではないですね。
汎用的なマスタなんだろうけど汎用性が高すぎる。
次のプロジェクトから設計やり直しをお願いしてみるよw
なるほどコボルベースの設計か、
設計者が実績あると言っていたから伝統なんだろうな
ASP.net2008で開発してDBが伝統か
ちゃんとコストとか実行速度のデータ示せないと検討も出来ない。
釣れますか？
DB構造もプログラムも大改修して多大なコストがかかりました
技術屋として間違ってはないと信じてる
でも経営としては間違ってるんだろうな、きっと
将来のデータ不整合、障害発生のリスクと
目先のコスト、どっちが大事かな。
まぁ、派遣切りのご時世だもんな。
元々の設計がダメだったせいってなんで気がつかないの
お偉いさんには「こんな簡単なことに時間かけて何やってんだアイツは」としか映らない
技術者をないがしろにしてきた代償だよ
もともと正規化してなかったので、そのちょっとの修正の「ついでに」
正規化した、というのであれば、そのコストは、ついでの作業に伴い発生したコスト
技術屋って言い方すればコスト意識を無視できるわけではないと思うがな
ｘｘ屋さんってのは、ｘｘを売るから屋なわけで
コスト関係なく技術的に最善最上な状態でないと気に食わないというのであれば
それは技術原理主義者とｗ
コストとのバランスをとれるから技術者じゃなくて技術屋なんだと
全てを「自分の好みに修正」したいってんなら、お前なにやってるんだの世界だけど。
後まで見据えての決断であれば技術者の良心だろ。
姉歯はいかんよ、姉歯は。
好みや良心の技術第一主義で通しても、理解してくれる客は少ない。
でも自分のアピールや努力が足りずに、姉派みたいな弱い立場に陥るのは技術第一主義者には多いと思うよ。
漏れは設計しか遣らないとか逝っても、設計外の人間に理解してもらえる事は少ない。その積み重ねがどんどん立場を弱くして、設計だけしか頼まれない弱い立場で責任だけ押し付けられる事に成る。
設計に金を出してくれる客と良い関係を築けての商売。
その、しかしってのはを受けていってるのか？
技術屋ならバランスとれっていってるのに
コストのために犯罪犯すような話といっしょにするなよ
すくなくとも今のソフトウェア産業において、設計だけでは
ビジネスとして成り立たないと思うがな
本来客は、設計に金をだすんじゃなくて、プログラムやシステム全体に金をだすわけで
その中の設計に配分される割合が低すぎる＝設計が軽視されている
それは客の理解の問題じゃなくて、売り側が過当競争によって
目に見えにくいコストから削ってるからじゃないかと思うが
何もしないから、配分の割合減らされて、コスト削られてるのだよ。
これって客先に説明しておしまい。ってならいいけど
無知な上級SEが良いところ見せようとして・・・説得したあとから
平気で台無しになるようなことをしてきて、あとよろしくって♪って感じの多いわな
身内の敵はもっと上だぞ
マネージャーやら社長やら・・・
そういう人たちにも、ちゃんとした設計がコストに影響する事を示せないと負け。
設計がコストに影響することを理解できないような人たちが、
マネージャやら、〇〇長やらを
やってることが問題なんじゃない？
で、この問題をどう解決するか、なんだか。
これ最強。
文句有るなら自分の資金で設計遣ってれば良い。
実際に運用されていて問題のないものはあまりいじらないものだよ。
致命的なのや、将来的に問題になりそうなのは苦労してでも弄らないと後で困るよ。
弄らないまでも、報告だけはしてシステム関係者の中で共通認識は築いておくべき。
後で、問題が起きてからDB担当の個人の責任にされたほうが割喰うよ。
あと、問題が発生して誤動作したときのリカバリーの手順とかもマニュアル化しておく。
データ失うよね？
もっともらしい事言いたいだけの
他の板に居場所がない老害コボラー
多少の開発経験がある人が居れば DB経験がなくても バックアップや履歴、ログは残るはずだよ
スムーズに復旧できるかどうかは別の問題だが…
顧客コードとそれに対応する顧客名称などがテーブルにあっても、
実はマスタ化するまでもない一見の顧客の場合、特定のコードを使って、
顧客名称のみ画面から入力したいという与件があったりするケース。
ＥＤＩで顧客からマスタと依頼データをもらっていて、
依頼データをもらった時点のマスタの値を依頼データに付加して保持しないと
いけないケース。
複雑な料金計算の設定マスタなど、既存のデータと処理をそのまま移行する
必要があって、下手にデータの持ち方を変えてしまうと、
明確に仕様化されていない部分の動作が保障できなくなってしまうケースなど。
>顧客コードとそれに対応する顧客名称などがテーブルにあっても、
>実はマスタ化するまでもない一見の顧客の場合、特定のコードを使って、
>顧客名称のみ画面から入力したいという与件があったりするケース。
>ＥＤＩで顧客からマスタと依頼データをもらっていて、
>依頼データをもらった時点のマスタの値を依頼データに付加して保持しないと
>いけないケース。
これは別に全然問題ない
「顧客名称のみの登録もできる」
「依頼データをもらった時点の値を保持する」
という仕様のもとに設計して正規化すればいいだけの話
>複雑な料金計算の設定マスタなど、既存のデータと処理をそのまま移行する
>必要があって、下手にデータの持ち方を変えてしまうと、
>明確に仕様化されていない部分の動作が保障できなくなってしまうケースなど。
これはありがちな話で、実際妥協してしまうことも多いんだけど
そもそも「明確に仕様化されていない部分」があることが問題なわけで
正規化できない理由にはしてほしくない
正規化したいだけの自己満足程度？
正規化することに理由を求められてもな・・
逆に「正規化しないこと」にこそ理由が必要だと思うんだが
逆に質問していい？
「君の会社の開発標準において、論理データモデルを
作成するという工程はないの？」
例えば会員テーブルというのがあったとして通常なら（型とサイズは面倒なので略）
create table 会員(会員番号,姓,名,性別,住所,誕生日)
レコードは
00001,会員,太郎,男,東京都,2000/01/01
00002,会員,花子,女,神奈川県,2000/01/02
ってな感じだろうけど、それを
create table 会員(会員番号,属性コード,値)
00001,001,会員,...
00001,002,太郎,...
00001,003,男,...
00001,004,東京都,...
00001,005,2000/01/01,...
00002,001,会員,...
00002,002,花子,...
00002,003,女,...
00002,004,神奈川県,...
00002,005,2000/01/02,...
基本的にジョインはしない。複数テーブルの情報が欲しければそれぞれのテーブルからその都度取る。
メリットとしては
・SQLがきわめて単純になる。
・DB構造に頭を悩ませる必要がなくなる。
・スケールアウトしやすい。
・項目単位でロックが掛けられる。
デメリットとしては
・レコード数が多くなる。
・今まで1つのSQLで取得できてたものが複数回のSQLになる。
・今まで1行で帰ってきたものが複数行になるのでコードでループでまわしてレコードを組み立てる必要がある。
個人的にはSQLが単純になるというのが大きい。複雑なSQLなんて見たくもない。バグの原因＆パフォーマンス劣化の原因になりやすい。
もちろん、全てのケースでこの形でうまくいくとは思えないが多くの部分はこの型におさめられるのではなかろうか。そうすれば余計な頭を使わなくて済む箇所が一つ減る。
今でも一部はそういう作りはあるけど（汎用マスタ等）、それを可能な限り全てのテーブルでやる。（究極的にはテーブルは一つで全レコードがそのテーブルの中。レコードを区別する為のコードがさらに必要にはなるけど）
>・SQLがきわめて単純になる。
>・DB構造に頭を悩ませる必要がなくなる。
ちゃんとしたDB設計もできない設計者、SQLもかけないようなプログラマにとってはメリットかもしれんがな
>・スケールアウトしやすい。
クラウドに適した形式だから、莫大なデータ量で通常ではハンドリングできなくて
クラウドにするってならわかるが、クラウド考慮しないなら関係ないんじゃない？
>複雑なSQLなんて見たくもない。バグの原因＆パフォーマンス劣化の原因になりやすい。
すくなくとも複雑なSQLがパフォーマンス劣化の原因ではなく、（SQLにより実行される）複雑な処理が原因なわけで
>・今まで1つのSQLで取得できてたものが複数回のSQLになる。
>・今まで1行で帰ってきたものが複数行になるのでコードでループでまわしてレコードを組み立てる必要がある。
ような状況で、パフォーマンス劣化は避けられるどころか余計悪くなると思うがな
>多くの部分はこの型におさめられるのではなかろうか。そうすれば余計な頭を使わなくて済む箇所が一つ減る。
頭使わなくて済む個所が減ったらダメだろｗ
いままでSQL書いただけでやってくれてたことを、全部自前で実装するんだぞ？
プログラムしないといけないことも増えるし、頭使うとこも増えると思うがな
>今でも一部はそういう作りはあるけど（汎用マスタ等）、それを可能な限り全てのテーブルでやる。（
いまのRDBMSでも、やろうと思えばそういう風にできるわけだ
でも普通はみんなそんなことはやらない。それが答えだと思うがな
メリットデメリットってのは、何に対してなのかはっきりさせてから評価してくれないか
このままだと頭使わない奴にとってメリットがあるって結論になるなｗ
>クラウドに適した形式だから、莫大なデータ量で通常ではハンドリングできなくて
>クラウドにするってならわかるが、クラウド考慮しないなら関係ないんじゃない？
最初は考慮してなかったが後からやっぱ必要だった！（見積もりが甘い？）って時にはメリットになると思います。
>ような状況で、パフォーマンス劣化は避けられるどころか余計悪くなると思うがな
SQLだとちょっと書き方変えるだけで10倍、100倍もパフォーマンスが違う事ってありますよね。みんながみんなSQLのエキスパートであれば問題ないのですが。それに比べればましかなと思ってます。もちろん処理内容によりますが。
>頭使わなくて済む個所が減ったらダメだろｗ
”余計な頭を使う箇所が減る”の間違いでした。
>メリットデメリットってのは、何に対してなのかはっきりさせてから評価してくれないか
メリット、デメリットは一般的なテーブル構造（先の例での前者）に対する、KVS的なテーブル構造のメリット、デメリットです。
>このままだと頭使わない奴にとってメリットがあるって結論になるなｗ
おっしゃるとおりで、このスレッドの趣旨には反しますがこれが一番のメリットと思います。頭を使う必要が少なければ、設計する人によって品質がバラバラという可能性が減るのではないのでしょうか（こういう構造で業務を満たせるのであれば）。
職人頼りなシステム開発が工業製品へと一歩前に進めるような気がします。
こんなことしなくても
みんなお前ほど頭悪くないから大丈夫だよ
カスレベルの人材でも働けるのは業界にとって大きなマイナスだ。
>職人頼りなシステム開発が工業製品へと一歩前に進めるような気がします。
逆だ。DBでやらない分アプリでやることが増えて、
プログラマの腕頼みになるだけだ
みんなが言ってるとおり、時代に逆行しているよ
単にDB使いこなせないからアプリでがんばるよ的発想だよな。
SQLを使ってたほうが遥かにパフォーマンスが良い現実。
これまでの歴史で今の状況に成ってるのを理解しないと。
オブジェクト廚が、オブジェクトDBなら便利になるぜとかのたまってたけど遅くて結局は消えてるし。
また馬鹿が湧いて、無駄な事を繰り返すのかな。
>最初は考慮してなかったが後からやっぱ必要だった！（見積もりが甘い？）って時にはメリット
クラウドにしやすい、ゆえにスケールアウトしやすいメリットがあるっていうならわかるが
クラウド云々関係なしに ってのはお前の出した前提条件だが？
クラウドにしないでスケールアウトってんならデータ形式はあんまり関係ないだろ
あくまでクラウドに適してるのがメリットであって、スケールアウトは副次的な話だ
>SQLだとちょっと書き方変えるだけで10倍、100倍もパフォーマンスが違う事ってありますよね。
オプティマイザが入るSQL処理でさえ簡単にそれだけの差がでる。
自前アプリでその処理をやるわけだ
みんながみんなSQLのオプティマイザより賢くプログラム組めるのか？
>みんながみんなSQLのエキスパートであれば問題ないのですが。それに比べればましかなと思ってます。
みんながみんなプログラムのエキスパートであれば問題ないのですが。
それに比べれば(SQLの方がオプティマイザある分)ましかなと思ってます
>メリット、デメリットは一般的なテーブル構造（先の例での前者）に対する、KVS的なテーブル構造のメリット、デメリットです。
いやだからその２者をくらべたときに、誰にとってメリットデメリットだと？
ほんとに頭使わないシステム開発者にとってのメリットでいいのかよ
>品質がバラバラという可能性が減るのではないのでしょうか
減るかもしれんな。頭使わない安価粗悪な物によってまともな物が駆逐されてな
全体のレベルを下げるだけだ。品質低い方に統一してどうする
>職人頼りなシステム開発が工業製品へと
工芸品が工業製品になるためには、その職人の技が一般化されてることが必要なわけで
一部の人しかできないことを、だれにでもできる事だけで作ったとしてもそれは単なる粗悪品
一部の人しかできなかったことを、誰にでもできるようにしないと意味がない
そのために論理や技法があり、それを学んだり論議したりしてるんだよ
お前の主張は、
工業製品ならだれでも作れないとダメでしょ。
馬鹿にはシステム開発できないんで、システム開発は工業製品じゃないよね
ってことだ
> みんながみんなSQLのエキスパートであれば問題ないのですが。
SQLのエキスパートはそんなにいらない。
もちろん、一見優秀そうなゴミでは何の役にも立たないが…。
スレの趣旨に合っていれば、DB技術者の意見を気軽に言い合ってもいいんじゃない。
レスが一つ入ると反応する方が結構居そうなので。
それぞれ扱ってるシステムの規模や影響、会社の風土とが違うでしょうから、
一概に良いか悪いかは言えませんが。
とりあえず、「KVS的な構造」といって後者はないだろう。
COBOLやRPGの時代にそういうテーブル設計しているのありました。
今SQLで実装している業務を試しにCOBOLで実装してみたほうがいい。
まあ、あの時代はある種夢の時代だったな。
「おれ５０００ステップのプログラム作っちゃったぜ！」と
無駄に長いプログラムを作れば儲かった頃だし。
ちなみにSQLより速い処理が組めるRPGやCOBOLのプログラマなんて
ツチノコ並みの珍獣だと思うが。
COBOLやRPGは知らないけど、「処理の速さ」という点では
プログラムでゴリゴリ書いたほうが良いこともある
DB側（リレーション、制約、ストアド、SQL）に機能を持たせる
一番のメリットはやはり保守性だろう
メリット・デメリットはの他に
メリット
自分で最適化できる。
デメリット
サーバー/クライアント間のデータ転送量が多くなる。（高速LANなら無視できる）
かな？
ストアドの速さに勝てるの？ありえなくないか？
DBに機能をもたせると保守性は落ちるとおもうが。
DBMSに格納されているなら、そのDBMSに特化したストアドより早く外部プログラムが
実行できるとは思えない。
ストアドでも外部プログラムでも、ロジックは同じように作れるわけだからな
保守性については、システムの保全とか改修のしやすさとか、
何を主眼として保守性とするかによって変わると思うが
「保守性」っていうのは、改修の効率の良さ、再利用性の高さ、
論理的整合性の保ちやすさなどをひっくるめた意味で書いた
曖昧な定義でごめんね
だったら外部プログラムならなお一層遅いだろ？
論理性がまったくないようだけど本業のほうは大丈夫？
全クラウドが、光ファイバーで繋がってて、膨大なクエリ処理しても、遅延は最大でも数百ナノ秒だぜってわけじゃないだろうし。
>COBOLやRPGは知らないけど、「処理の速さ」という点では
>プログラムでゴリゴリ書いたほうが良いこともある
SQLの実行エンジンの最適化処理でブロックI/Oやらをやられると
プログラムで１行FETCHや1行WRITEしている
これらの言語は太刀打ちできないワケだが。
そりゃ、OSのAPIを直打ちするレベルになれば別だけどな…。
今時のRDBMSは統計情報を元にSQLの実行プランを最適化するが、
一般プログラマにコレを越えるプログラム組めって言っても
かなり辛い。
むろんプログラマが書いた方が良いこともあるだろう。
どんな例か知らんけど。
詭弁のガイドライン
2.ごくまれな反例をとりあげる
「だが、RDBよりプログラマが書いた方が良いこともある」
15.新しい概念が全て正しいのだとミスリードする
「クラウドで使われているKVSを使わぬ限りシステム構築に明日はない」
> 今時のRDBMSは統計情報を元にSQLの実行プランを最適化するが、
> 一般プログラマにコレを越えるプログラム組めって言っても
> かなり辛い。
腐るほどあるよ。
腐ったSQLを平気で書くプログラマのプログラムを想像した。
北へと旅に出たくなった・・・
腐るほどある。と言われても、AS/400みたいなマシンで無い限りSQLと他の言語の
速度比較とかは出来んはずだが、AS/400なんざ普及していないだろ。
RDBMSでSQL使うよりもC++でコレクションクラスを使った方が速いよ、なんて
議論無意味だしな。
は、処理の速さについては
メリットとしてもデメリットとしても挙げてないんだし
問題の本質はそこじゃなくない？
SQL覚えるのが一番の近道。
問題の本質とは?
確かに、214さんが処理の速さについては
言及しておられないようです。
ただ、私見ですが214さんがSQLを良く
理解しておられないのは感じます。
開発側とすれば画面に表示する情報を
1SQLで取得できるように設計するべきで、
その方が楽だと思いますがね。
遅かったら運用のせいにも出来るしね。
まぁ、そんなこと言わないで、がんばって行きましょ。
分かるけどね…
クエリの知識しかないアプリ屋のくせに
えらく上から目線だなオイ
いえいえ、とんでもない。
そんなお褒めの言葉、
こちらこそありがとうございます。
select *だけで全部済む様にしたいとか言いそうだし。
まるでオープン系コボラｗｗｗ
情報を1SQLでとれないってのは、どっちが？
下請けソフトハウスのアプリ屋なんてそんな奴ばっか…
何のためにキーやインデックスがあるのかちょっとは考えてくれよ
複雑なSQLはそれ自体のメンテが大変かもね。アクセスパスは不変じゃないし
無理矢理SQLに詰め込まれても、常に効率が良いとは限らない。
要はバランスだと思う。ちょっと頑張ればSQLのみで済むからSQLに詰め込もうとか、
どうせUAPで処理必要なんだから、SQLでは無理せずにUAP側にロジック入れようとか
いろいろ状況もあるだろうし、適材適所で臨機応変に使って行きゃ良い。
まぁ同一システム内でばらばらだと困るので、ある程度の取り決めは必須だが。
ところで、組み込みSQLで select * 使う人はいないはずだけど…。
さすがにそんな人にはコード書かせないでしょ。
>ところで、組み込みSQLで select * 使う人はいないはずだけど…。
>適材適所で臨機応変に使って行きゃ良い。
こんばんは。246で発言した者です。
どちらかとの御質問ですが、どれとどれのことか分かりませんでした。
私が不出来なもので申し訳ございません。
先に私が発言した主旨としては以下の様になります。
開発側の人としては画面に表示するデータが1SQLで(select * は論外ですが)、
もちろんジョイン、必要であればサブクエリーを使用し取得したデータ群を、
使用する言語によったデータセットで使った方が楽なのではないかと思った次第です。
(それぞれの環境次第なので一概に言えないのは分かっております。)
214さんはそれぞれ必要な都度SQLを発行し、表示するデータを構築される
ように思われたので上記の様な発言を致しました。
ただ、214さんがデメリットでそのことを挙げておられることを見過ごしておりました。
申し訳ございません。
先に私が発言しました「214さんがSQLを〜]の発言は撤回させてください。
その後の「遅かったら運用の〜」は私の過去に受けた経験から発言したものです。
開発より、運用に従事している期間が長いものですから。
お気を悪くされましたらお詫びいたします。
そもそもの発端はKVS的な設計はどうだろうって論題で、
KVS的な設計では１SQLでデータ取るのは不可能だって話だ
それを前提にしてるから
>214さんはそれぞれ必要な都度SQLを発行し、表示するデータを構築される
ようになってるわけで
１SQLでデータ取れるような設計しろってのは、議論の前提がおかしいだろうが
その言い方だとDB設計者は開発側の人間じゃないように聞こえるが
それなら駄目すぎて話しにならんと思うが。
あれが1SQLでデータが取得できないというのも変。
いったいオマエラ何の議論をしているの？
自演乙
まあdb知らない人みたいだから無茶言いそうだが。
ttp://masuda220.jugem.jp/?cid=11 ・テーブルの役割・用途は一つ
・（極力？）データに対する更新・削除は行わない
など
なるほどとも思うのですが、役割に応じて分割すると
あまりに細かく分割しすぎて見通しが悪くなりそうな気もしますし、
データの更新・削除を認めないのは冗長かつ非効率な気もします。
実務による、というお答えが返ってきそうですが、一般的な設計指針として
ご意見をお聞かせいただければ幸いです。
モデリングの手法としては合ってると思う
ただこの後の工程で、パフォーマンスや効率性を考慮して
冗長化、非正規化することは必要だけど
>あまりに細かく分割しすぎて見通しが悪くなりそうな気もしますし、
モデル上は、細かくテーブル分割してあるほうが分かりやすいよ
テーブル名とリレーション見るだけで何を表しているか分かるからね
>データの更新・削除を認めないのは冗長かつ非効率な気もします。
「データの更新・削除を認めない」って書いてあるところが見つけられなかったんだけど、
どこから引用したの？
レスありがとうございます。
書籍などではここまで言及してあるものを読んだことがなかったので、
どうなんだろうと思っていたのですが、正しい手法なのですね。
（「正しい」という表現が適切かわかりませんが）
> 「データの更新・削除を認めない」って書いてあるところが見つけられなかったんだけど、
> どこから引用したの？
これは少しコメントを端折り過ぎました。
「テーブル設計 データモデリングのエッセンス（２）」などに書かれているのですが
> ビジネスイベントは一度作成（インサート）したら、後から、更新や削除はしない。
> このテーブルに許される操作は、インサートと参照のみにする。
とあります。
また、ビジネスリソース系のテーブルについても同様の方法を取ることもあると書かれています。
ここに書かれている業務システムの例に合わせて言えば、
受注テーブルは最新の状態にしておき、更新や削除の記録が必要ならば別テーブルにログとして保持する。
受注テーブルにはキャンセルされた受注や変更前の受注は保持しない。
というのが主流だと自分は思っていました。
また、導出テーブルをトリガで作成するという手法も初めて知りました。
1. Excelのワークシートと勘違いしてるから。
2. 設計＆指揮者がコードに関心があるのにデータに関心がないから。
レベル低すぎ？
正規化なんか理想論だ、実際は性能が落ちる原因だとか
トンデモ説を信仰している（ふりをする）からじゃん
それよりも、RDBしか使ったことがなくても実はわかってない、ってのが
圧倒的じゃないか？の言うexcelと勘違いしてるようなのとか。
正規化なんて全く記述無し。
してもテーブルの連結がめんどくさかったら意味ねえ！
（つーか、負荷テスト後もあんまり性能が落ちない）DBがあったなｗ
そこが曖昧なまま薦められても困るのよね。
長さチェックも空白詰めもしないから
ただしOracleだけは固定長が速い
逆だろ。
Oracleには固定長の文字列型なんてないはず。
最小長と最大長が等しい可変長文字列を、便宜上固定長文字列型って騙ってるだけ。
まぁほとんどのDBMSで、列サイズが固定であるが故の速度的メリットは大きいから、
Oracleでも可変長文字列を入れていた項目を擬似固定長に変更した時の速度向上は
見込めるかもしれないって程度。
> 列サイズが固定であるが故の速度的メリットは大きい
矛盾してないか？ 最初の文は、内部的には可変長文字列の特殊設定だと
言っているような気がするんだが。
text型みたいなのはある程度まではそこそこ速いけど、
ある閾値を越えると急に遅くなったりするので
処理系しだいだろうとは思う。
つか、Oracleとかの「こうすると速い」系のネタは都市伝説が多いよなー。
商品コードとかの長さが決まっている項目なら固定長で、
備考の様な長さが不確定な部分は可変長と素直に設計していけばいいのでは？
「速いから固定長」とかはなんか違うだろ。
「考えるのが嫌だから全て可変長」の方がまだスジが通っている。ｗ
Oracleは内部的には全部可変長扱いだって聞いたことがあるからそのことじゃね？
DB2とかだと内部的にCHAR型とVARCHAR型は別扱いなので、きちんと使い分けた
方が望ましいけど、Oracleはちょっと変態なのでムリにCHAR型にする必要はないと。
(全ての？)列サイズが固定で速くなるってのはまた別の話で、データの格納と言うか、
表領域の使われ方のことではないかと。まぁどっちかって言うと行サイズだが…。
HiRDBだとFIX表ってわざわざ宣言したりするね。
適切な設計にあわせて実スピードは上がっていく。
逆に設計がアレだとあんまし速度はでないRDBMSだな。
Oracleも昔の都市伝説と言うか、昔のヘンテコ小技を今のVerに持ち込むのは
ヤめてくれって感じるな。
普通に設計して普通にSQL書いてください。
M$やらIBMやらが注力しなかったからかな？
ごめんね、キミの大好きなOracleを馬鹿にしちゃってｗｗｗ
○○○○○は遅いねってお前の設計が（ry
性能がいいものが売れるとは限らない。
大人の事情というのがあるんだよｗ
オラクルの出現で競争が生まれ、それらも今やかなりマシになった功績は大きい。
周りのヘンテコDB仕様に合わせて客取り込んでいって成長したから、今でも名残が残るのはしょうがない。だんだん洗練してヘンテコ仕様もろとも下位互換は切ってくだろうけど。
後発のInformix、Sybase、Ingres等が現れてから。DB2もあったけど、当時のIBMはIMSの
商売の方が重要でDB2はほとんど力を入れておらず、顧客がRDBMSを必要とする場合に
程度でSymfowareやHiRDBのような扱い。
MSのSQL Serverや、他社OSでも使えるDB2 UDB(の原型)が現れて現在のような競争状態に
なるのはそれよりもさらに後。
総合1位なんて点数のつけ方で変わるよ。
じゃあSQLiteが一番だな。これで満足か？
って感じますが、他のRDBMSでもあるんですかね？
Oracleよりは少ないが、それだけDB2普及していない証明でもあるような希ガス。
別に不具合あってもいいんだけどさ、それの対応がタマに「我慢汁」とか「それはOSの不具合です」
とか解決に繋がらない回答を貰うと、「あー、Postgresでいいじゃん」とか思うな。
インスタンスダウン→「次のFPで修正されます」のコンボに何回遭遇したか。
Oracleもよくインスタンス落ちるがiのDB2は落ちた事がない。
これもIBMの中の人とガチで仲良し(?)レベルで会話できる人が少ない性もあるんだろうな。
全部as内完結で、不安定になる様な秘穴を突けなくしてあるとも言うが。
オラは、いろいろ弄れる割に秘穴を突いてしまう確率が高くなるだけ。
ちゃんと組めばド安定で運用出来るよ。RACも組めるし。
ポスグレはサポート無いから、業務では選択肢に無いな。
マイエスはオラクルがサポートしてくれるなら、これから使う鴨田が。
別にサポートあったって落ちたときに損害補償してくれるわけでもないんだし
金払うだけ無駄なのがサポートだぜ
パッチの提供なんて逆にPostgreSQLなんか速攻で修正されて出てくる
オープンソースだから原因も即バレで、仕様ですと隠される事もないしな
一応サポート契約していれば、どんな障害/質問に対しても「マニュアル
読め」以上の何らかの回答を一定期間内にしてくれるし。
PostgreSQLの構築/運用実績あるSIにやって貰った方が
Oracleに無駄に500万払い続けるよりマシな気がする
サポート契約してれば何か起きたときの事故対策会議で「サポートに問い合わせ中です」
って言える。もちろんその後は「原因不明なので再現待ちです」って逃げる。
DBMSに限らず、商用OS等でも良くあるが…運用担当者が泣く黄金パターンだよな。
まぁ実際問題として、サポートにまともな回答もらえるとはだれも思ってないんだよ。
ただ、実質使えないサポートであっても、それを望んでいる客がいるのもまた事実だから、
そういう提案してしまうのはしょうがないと思う。
そりゃ役に立つ人はいるだろうさ。
当然、Postgresでシステム構築したとしても、Postgresのサポートを
必要とする場合だってあるだろうし。
＞Oracleに無駄に500万払い続けるよりマシな気がする
ぶっちゃけその通りだけどな。
漏れの中ではOracleは言うほどマシなRDBMSじゃないと認識している。
Oracleが必要な業務があるのは事実だろうが、多くの導入例では
「Oracleはいらんだろ」的な納品されている現場は多い。
付き合いある範囲じゃ見当たらないな。
内製するかどうかとオープンソースかどうかなんてあんま関係ない。ただ、開発を
SIに任せる場合にOSSで受けてくれる業者がほとんどないというだけ。
知り合いかどうか知らんがPostgresはNTTやらNEC系はやってるな。
別に漏れもヤれと言われれば並みのOracle程度には出来る。
つか漏れも社内のなんちゃってテスト環境用にはDreby使っている。
俺的には別に特殊なスキルが必要とは思えないのだが、商用/フリーに関わらず
調査すら出来ない人間ってのが意外といるわけで。
Linuxは大メーカー自身が手がけるようになって大分よくなったけど。
オープンソースで手厚いサポートできるようなスキルある香具師雇うなら、オラクル以上に金かかりそうだw
オラクルに損害賠償請求する馬鹿企業は居ないが、個人に損害賠償してくる馬鹿企業は山ほど居るだろうし。
凄い妄想だな。
底辺のオマエには知らん世界だろうが、Oracle使った案件でも契約書に
損害賠償跳ね除ける文面が契約事項としてあげてあるベンダーがほとんどだが。
サポートが心の拠り所らしい。
と言える製品ならそれはそれで構わんよ。
漏れはそんなOracle見た事ないが。年に１・２回はｲﾐﾌﾒｲに落ちる。
ただまあ、漏れの経験でｲﾐﾌﾒｲに落ちた場合サポートに問い合わせても「原因不明です。OSかハードに問題があると思われます」
の逃げ口上が出て終わりなんで、PostgresだろうとOracleだろうと能力のない人間が構築したシステムは
どれも自殺したくなる。
むしろ、上の発言で出てきた問題を全てIBMに投げられるiSeries、もしくはOSSだからと言う理由でPostgresを
選んだほうがラクになれる。
2000万払った挙げ句、使用は自己責任でとか言われたｗ
まあ、未だにそれで動いているトコはあるんだろうけど。
HP-UXの8でもそれくらい取るベンダー見た事あるし。ただイニシャルはともかくランニングコストは
あんまし安くなかったが。年600万くらい。
Linuxの8iは自己責任と言うからにはランニングコストは０なんだろ。w
DB2(iSeries)だとイニシャルは下は300万で上は２億くらいの幅でランニングは100〜600万くらい飛んでいく。
東証がポスグレ採用なんて無謀な事はしないのと同じ。
IBMに丸投げ出来るぐらいの資金が有るなら、日電や不実に丸投げしてオラクルの面倒見てもらえるけどな。
うちはRACだけど意味不明に落ちてもリカバリは出来る仕組みにしてるよ。
そもそも絶対に落ちないなんてあり得ないし、ソフトのバグが無いのも信用してない。PGなんてバグ入りの欠陥品しか作れないし。製造業の品質管理に比べたら認識が甘過ぎるよ。
逆に、ポスグレは絶対落ちなくてサポートも満足と保証されてるの？
２億の案件でポスグレで組んで、損害賠償なんて喰らったら人生終わるなw
どんなdbを使おうがフェイルセーフな構成にすればいいって自分で答えだしてるじゃん
なんかあんまし大型案件やった事ないみたいなのでコメントだが。
規模と傾向もあるが基幹系ならIBM(i)とその他のベンダー＋Oracleの組み合わせだとIBMの方が半額くらいのコストで開発・運用が可能だ。
無論、Oracleの方がコスト安いケースもあるが、「IBM＝高い」と言うのは思い込みだ。
ある程度以上の資金がいるのは事実だが、の意見は「安物買いの銭失い」な思考だ。
そして東証もけっこう落ちてるじゃねーかｗ
東証を落としてもお咎めなしだぜきっと。
デマルコ読め
ttp://www.amazon.co.jp/dp/4822281116 これ読めばいいの？
たとえば、２ｃｈとか「PC等」→「プログラム」→「【PHP】CakePHP」→「レス」って構成ですよね。
これってどういうDB設計になってるんですか？
実務経験がないのでわかりません。
「PC等（カテゴリID）」→「プログラム（カテゴリID＋サブカテゴリID）」→「【PHP】CakePHP（サブカテゴリID＋スレID）」→「レス（スレID＋レスID）」
→「デスクトップ（カテゴリID＋サブカテゴリID）」→「cpuをとっかえたい（サブカテゴリID＋スレID）」→「レス（スレID＋レスID）」
って感じですか？
１つのデータベースに、テーブルを1000個とか作ることとかあるんですか？
その場合、テーブルの名前を特定して探しにいく方法でしょうか？
ttp://pc11.2ch.net/test/read.cgi/db/1056967775/ SQL総合案内スレッド
ttp://pc11.2ch.net/test/read.cgi/db/1133798099/ 姉歯DB設計
RDBで実装する意味が解らん。
人間のイメージなんてちっぽけなものなんだな。
実務経験がないから仕方ないのかもしれんが、
RDBに不思議な幻想を持つのはヤめた方がいい。
2chの場合は要求される仕様が「追記オンリー、更新は基本なし、当然削除もなし
発言は1000もしくは512KB(板によるが)で、ブラウザを使うユーザーにはhtml変換し
専用ブラウザはdat直読み。
そして圧倒的な書き込み&ＰＶときたら並のRDBMSでは即死する。
たしかに、DBは偉大ってイメージがあるかも。組み込みエンジニアだからDBに縁がなくて。
twitterと2chは同じようなものかと思ったの。twitterはDBだよね。メンバーの紐付けあるし。
無数にレコードが追加されるからどういう設計なのかなーって。
そりゃ2chだってタマに落ちるけどな。
ツイタはしばらくすると消えるからdbのほうが向いてる。
潤沢な資金力さえ有ればdbでも捌けると思うけどね。
東京証券取引所の売買銘柄数や売買高でもちゃんとdbで注文捌いて約定処理が出来てるし。
組み込みでも携帯のアドレス帳ぐらいはdbで作ってあると思うよ。テキストファイルで管理だと大変だし。
当然組み込み用のdbもある。
ttp://pc11.2ch.net/test/read.cgi/db/1207476744/ RDBMS比較総合スレ 【サーバ】
ttp://pc11.2ch.net/test/read.cgi/db/1063716668/ MSDEよりいいDB、ありませんか?
（略
＞潤沢な資金力さえ有ればdbでも捌けると思うけどね。
金かければなんでも出来るだろ。
コストパフォーマンス無視して「ＤＢの方が向いている」なんて・・・。
2chのサーバーと同じ導入コストでRDBMSを用いて実装し、
2ch以上のパフォーマンス出してから語ってくれ。
そして東証も派手に落ちてニュースになったんだが。
あれを「ちゃんとdbで注文捌いて約定処理が出来てるし。」とコメントできる神経が凄いな。
テキストファイルだってなんだってDBはDBだ
RoR は O/Rマッパーに ActiveRecord 使ってるから、多分バックエンドの DB は
RDBMS だとは思うけど、何を使ってるかまでは調べてない。
そういえば、ニコニコ動画のコメントサーバはバックエンドに MySQL 使ってるね。
更新頻度の高いテーブルと低いテーブルに選別して、InnoDBとMyISAMを
使い分けてると、どこかに書いてあった。あと memcached だったかの
キーバリューストアも併用して、パフォーマンス稼いでたはず。
ってか、この辺の話はDB設計と言うより、アーキテクチャ設計の話だね……
テキストファイルに書き出すのだって独自DBなわけで
銀行の取り付け騒ぎで人が大量に押し寄せてATM操作するとISAMでがんばってるホストが堕ちるのと同じ。
テキストファイル自体はdbじゃないだろ。
ナニ言ってんだ？コレ？
タイムアウトやら領域が足りなくてトランザクションがコケた事とISAMの関連が意味不明。
ISAMでなく、普通のRDBでも帯域＆領域足りなきゃ落ちるのは一緒なんだが。
テキストを独自ＤＢと言うのは痛いが、引き合いにホストを持ち出してトンデモ理論展開スナ。
データベースの定義 ＠ Wikipedia
> 特定のテーマに沿ったデータを集めて管理し、容易に検索・抽出などの
> 再利用をできるようにしたもの。
> 狭義には、コンピュータによって実現されたものを言う。
広義には記録メディアが紙だろうが石版だろうがDBはDBなんだぜ。
テキストファイルは言わずもがな。
ニコ動とか東京証券取引所のシステムを「石版」で構築してから語ってくれ。
それを読み出してデータストアとして利用するロジックがあるんだからDBと言えるだろうに
ただ石板は情報システム的にDBにはなり得ないから例えが悪い
ミドルエアとしてのDBMSと勝手に解釈して限定してるんだろ。
追記専用で基本屋外設置かつメンテ頻度も大変低いという条件下では
中の人の名前が順に彫り込まれる墓石というデータメディアは大変に
優れたものだと思う。
何より墓石メディアを用いた墓場というDBは古くは古代メソポタミア
に始まる何千年もの利用実績があるわけで、侮れん。
常識でモノを考えて喋ってくれ。
会社でよく「コミュニケーション力が低い」と怒られている人だろうけど。
指摘が全く意味不明だ。
石版メディアを使ったDBは読み書きが遅く電子処理に向かないので、
東京証券取引所では使えない。それだけの話がなんで理解できない？
おそらく君が「DB」と呼んでいるものは、正式には「RDBMS」だ。
テキストファイル、パンチカード、印刷物あたりまでは理解できるが
石板をシステムで読み書きするシステムなんて現実的に存在しないだろ
今は純粋に「データベース」という言葉の定義についての話をしてるんだろ？
情報システムで容易に媒体以外はデータベースにあらず、というのは単に君個人の
思い込みであって常識じゃない。
電話帳は電話番号のデータベース。これが常識レベルの解釈。
そういう意味じゃ、石版がNGなら紙もNGだろ。
石板に掘っておいてあとで読み込むなんて使い方をしている奴は誰もいないわけで
電子的に扱えるかどうかなんて問題じゃないんだって。
印刷物はDBとして使えるって言ってるじゃんみんな
否定されてるのは石版なんてとんでもない例でしょ？
手書き文書は印刷物じゃないし、情報システムと親和性が無いのは石版と同じ。
石版の話は極端な例だけど間違いや嘘じゃない。
「データベースと呼べるかどうか」は、使いやすい／使いにくい、早い／遅いなんて
話とは別次元の問題だよ。
「みんな」が誰を指してるのか知らんが、世の中の常識とは言葉の認識が乖離してるな。
データベースってのは、メディアは関係ない
ハンドリングの容易さとか管理のしやすさとかは別の話
ＤＢとＤＢＭＳの区別ついてない奴が多すぎるな
俺も普段はＤＢ＝（Ｒ）ＤＢＭＳの意味で使ってる場合が多いが
こういった議論のときはきっちり区別しろよ
話なんだよね。DBかどうか、ってのは記録された情報の性質で決まる事なんだから、
「テキスト形式で保存したから」「記録媒体がアナログだから」なんて理由で
DBじゃなくなるという理屈は根本的におかしい。
ないので、墓石はDBとは呼びにくいな。
上記の目的で墓石にデータを記録したなら、それはDBと呼んで差し支えない。
>特定のテーマに沿ったデータを集めて
お墓の中に入っている人の名前しか入っていないけど。
>データの再利用を目的として
毎年お墓参りしないの?
一般的には、墓石は単に故人の名前を残すこと自体が目的だと思うけど。
例えば「大量の先祖の中から特定の故人の名前を探す事を容易にする」のを目的に
墓石に名前を彫ったんだとしたらDBと呼べるんだろうけど。
目的がデータの再利用ならデータの構造も探索に適した構造になってる筈だけど、
故人の名前に見出しが付いてたりはしないだろ？
>毎年お墓参りしないの?
俺はしないw
つか、お墓参りはデータの再利用なのか？
墓地の管理人さんも含めて初めてデータベース管理「システム」
と呼べる。
しょうもない話だけど、本質を捉えていて面白いじゃないか。
こういう話を見てると、普段「データベース」という物がいかに
表面的かつ一面的にしか捉えられていないかが解るな。
今では博物学的意味しかないかもしれん。
石版とかになるともうデータを取り出す目的で作ってるわけじゃないし
データベースじゃなくてストレージなんじゃないかと
石版の例で言えば、厳密には石版そのものがデータベースなのでなく、石版に記録された情報が
データベースなの。
> 石版とかになるともうデータを取り出す目的で作ってるわけじゃないし
この話は「仮にデータの集積方法が石版への記述であったとしてもDBはDB」という例え話だろ。
データを取り出す目的で石版を作る事だって当然できる。
ほかのデバイスより読み書きの効率が悪いとか集積率が悪いとか、そんな事はここでは全く
問題ではない。
> しかし「データベース」の定義という知識が必要となることはまずないからなぁ。
知識以前に常識の問題だと思う。
データベースという言葉が何を指すのか知らないで日々その言葉を使うのか？
狭義のDB＝DBMSの中にもDBって言葉は入ってるんだぜ。
あるAが「データベース」の定義にはてはまるかどうかという判断が求められることって
こんな議論の場でもなきゃまずないだろ。だいたい、「データベース」という言葉は
そもそもDBMSと比較して定義があいまいだし。
掲示板/BBSという用語を正確に定義付けられなくても2chやるのに何の支障も
ないってことよ。
職場で「空気読めないヤツ」とか言われないか？＞石版データベース君
日常的に行われている事だけど、当たり前過ぎて普通は意識しないだけだろ。
というか、そんな高尚な話か？
一から十まで常識レベルの話をとくとくと聞かせてるのに、まるで理解してるように
見受けられないから話が長引いてるだけだと思うんだけど。
> 掲示板/BBSという用語を正確に定義付けられなくても2chやるのに何の支障も
> ないってことよ。
エンジニアが仕事で使うならそんな訳にいかんだろ。ちゃんとしろよ。
石版の話は単なる例え話だ。言葉の定義は単なる遊びでなく現実の問題だ。
散々感覚のズレを指摘されてるのに反省が見られんな。
こういういい加減な奴が技術者ってのが信じられん。
主張の方がよっぽど屁理屈だと思うんだ。
別に判断が必要じゃなきゃ仕事でもしないだろ。そもそも、データベースに該当するか
どうかという判断なんて、たとえばどういうケースで何のために行うの？
仕様書に「ログインユーザのデータベースを作成する」と書いてあったとして、
書いた側と受け手に共通認識が無いとおかしな事になる。
ぶっちゃけこういう時、勝手にRDBMSの準備をする奴は無能なエンジニアだと思う。
この場合は普通にDBMSを用いてログイン情報を管理する事を想定すると思うが。
要件に「ログインユーザの履歴を記録する」ならテキストに順次書き出しを想定する。
＞書いた側と受け手に共通認識が無いとおかしな事になる。
＞ぶっちゃけこういう時、勝手にRDBMSの準備をする奴は無能なエンジニアだと思う。
現実の仕事だとすり合わせとか会議があるからありえないケースだが、
そういう発想できる人の方がコミュニケーション能力と実務経験が欠如したエンジニアだと感じる。
DBが概念に過ぎない事を知っているエンジニアは、実装はどうするか？という発想になる。
そうでない人はDBMSを使う（仕様作成元は使いたがっている）と信じて疑わない。
> 現実の仕事だとすり合わせとか会議があるからありえないケースだが
勘違いしたまま実装まで行かないのは当然。
だだし、すり合わせの場でその話が出るまではずっと勘違いしてるわけだ。
仕事の仕方は全然違うと思うがね。
コミュニケーションミスの話はまた別のような。
「AはXである」
「『Iさんの言うA』はXである」
この2つの命題はは異なるからね。
データベースとDBMSは概念が異なるという常識があって、その上でその仕様書に
書かれた「データベース」がどちらを指しているのか明確でなく、さらにその違いが
実装する上で重要な違いなのであれば、普通は確認するよね。
そういう状況で、「『データベース』は必ずしもDBMSを必要としない」といって
勝手にテキストファイルで作ってしまうのも同様に困ったチャンだろうね。
後で客と「データベースを作れと言ったじゃん」「テキストファイルでもデータベースです」
みたいな押し問答になったりして。
石板DB肯定派＝DBとは概念のこと。DBの実装形態が様々あることを理解し、色々な可能性を想定している。
DBを概念として捉えている人は、実装について勝手な思い込みはしない。
> 勝手にテキストファイルで作ってしまうのも同様に困ったチャンだろうね。
その人はポジション的に石板DB否定派だと思う。
>この場合は普通にDBMSを用いてログイン情報を管理する事を想定すると思うが。
スタンドアロンや組み込みのシステムでもかい？
アンタさぁ、自分ひとりが後者、他の全員が前者だと思ってるだろw
既婚女性に成り済ましレスを繰り返してます。
残念だが既婚板の政治スレは全部カルトの工作スレです。
例えばこのスレ
↓
【民主党の政策に不安を感じる奥様の雑談室】その80
ttp://hideyoshi.2ch.net/test/read.cgi/ms/1259420965/ web魚拓
ttp://s03.megalodon.jp/2009-1129-0505-19/hideyoshi.2ch.net/test/read.cgi/ms/1259420965/ いや、常識的な大半のエンジニアが後者、このスレにいる数名が前者だと思ってるが？
なんでそう思う？
その話題でループしてんのアンタ一人じゃない？
そもそも石版の話を出したのは俺じゃないんだけどな。
テキストファイルはNGだ、紙ならセーフだ、墓石はどうだ、なんて話をしてた人は
明らかに前者だろ。石版DBの話にチャチャ入れてた奴も前者だと思ってるけど。
あ、君がどっちかは知らんよ。
>337以前の流れに戻そうや。面白かったけど、ちょっと引っ張りすぎ。
つかその時点で既にデータベース≠DBMSが前提の議論じゃん。
>383 とか >391 のつもりだったんだが。
>382はそれもそうだなあ、と思いながら読んだよ。
> その時点で既にデータベース≠DBMSが前提の議論じゃん
君はそうかも知れんけども。
>386 とか >397 は理解してるようには見えん。
定義厨は他人の意見を絶対に聞き入れないからカキコするだけ無駄だな。
データベース設計が軽視されているという流れでOK？
頭が固いを通り越してアホとしか思えん。
htpasswd知らないとかないよな
実は軽視されてるのはデータ設計全般なんだろうか。
と、ここ数日のやりとりを見ていて思った。
2chのレベルが平均的とは思わないけれども。
ひどいね
一級建築士と同じように、充分な知識を学習した人間のみが、
システム設計に参画出来るようにするのが本来の正しい姿。
もう、遅いけどね。
正確には「各行程を経験し死ぬまで学習意欲があり常に成長し続ける
コミュニケーション能力の高い人間」でないと設計はやるべきではない、
が正しいな。
知識なんてあって当たり前でなんの自慢にもならん。
まあ、免許制にして欲しいと思う事は多々あるがｗ
無資格で現場で痛い目に遭ってる奴の方がまだいいだろうな
知識も経験もどっちかが欠けてたらダメじゃん。
知識なんてあって当たり前。経験なんて勝手に積み上がる。
スレチだが、ちまちま何かを作ったのに、それをカバーした上品なライブラリ見つけたらマジへこむ。
そういう奴は得てして怪しげなノウハウを振りかざしたり、理論的な話をするとなぜか怒ったり。
Platinumはペーパーでは取れんだろう。
資格もっててスマソｗ
つかDB関連の資格はペーパーはなくなないがある程度以上は実際に使った人間でないと
受かるのは辛いだろ。
現実には資格持ちは「古くて使えなくて胡散臭い都市伝説」を信じてるヤツ多いけどな。
「SQLはこう書くと・・・」とか「サロゲートキーが・・・」とか「こういう場合はストアドが・・・」とか、
「こうやって教えられた」とか、応用を知らんのかと小一時間(ry
実際やらしてみるとパフォーマンスでなかったり、JOBの再投入が不可能な論理設計したりとか。
資格取った後も最新動向やら勉強会やらニュースとか読め。
goldだとやたらいる
テーブルの主キーの空きを管理するテーブルを作って、
主キーの空きを管理するっていうことを聞いたんだけど、ほんとかぬ？
難しいのは確かだけど時間と金がものを言う資格でもある
1970年1月1日0時0分0秒からの経過秒数をDBに整数型で入れてるってこと？
…それはナイスな方法だな。今度使わせてもらうわ。
というか死んだ
プログラム上でだっていちいち変換して使わなきゃならんのだし
そういう型がないRDBMSなら仕方ないと思うけど。
変換するコストもいらないし。
入力は？
日付や時刻関連でGROUP BYするときにちょっと殺意が沸くくらいだな。
全然普通
要求性能にもよるが、10年前のハイエンドクラスだときついだろうね
0.25人月で60万円でおｋ
俺のとこなんて1人月120万だよ基本orz
ttp://twitter.com/ozawa_yuuki/status/6549767047872513 国家資格（笑）の情報処理試験受けたことあんのかと
あんなもん実務に役立つのはどのポジションだろうが2割程度だろ
「プラズマテレビがガス放電で発光してます」とか知ってる必要あんの？
IPAは今年度になってようやく業界のゼネコン型に言及するレベル
お勉強しか出来ない無能集団の天下り先
国家自体が無能で仕事遅いしなｗ
ロジックとデータ（論理・物理）見てテストして
壁にぶち当たってマニュアルやら仕様書見て
ソースとデータ（論理・物理）見てｒｙ・・・・ループ
この作業以外で技術力を上げる方法なんか存在しない
糞ﾜﾛﾀお前の情試の例はよりによってITパス/FEの午前かよｗ
高度のスペシャリスト系は良く出来てる
所詮知識なので合格即実務で出来る、ではないが
「この程度も知らずに実務やってないよね？」感はある
高度がよく出来てる？
アホか？回答速報当日出ないような奇問も混じってるわけだが？
お前はずっとFE午前レベルの「プラズマテレビの〜」だけやってろｗ
お前みたいに高度もとれない程度の知識レベルの奴が設計してるシステムとか・・・
関わってる連中が可愛そうだわ。まさにスレタイにピッタリな人間ｗｗｗ
難易度低い時に受けてたまたま取れたヤツが偉そうにしてるの見ると痛々しくなるよな。
基本はわかってるが応用効かないし、製品個別の仕様部分を考慮できなかったりロクなヤツがいない。
逆に末端がどんどん依存してくれるから後で変更するのがた〜いへん。
わかってるとこだとDB設計にコストかけてくれる。
わかってないとこだと作る側の営業と使う側の購買が交渉にコストかけてくれる。
後者、会社関係単位で迷惑。
詳細テーブル全てに予めtempカラム群持たせるのって、
個人的にはかなりの糞だと思うんだが・・・
ところで激安中古CAD専門店っていいの見つけた。
かなり安いし使える
何百万レコード級のテーブルを
使ったことはある？
ALTER TABLEだけで何十分とか
当たり前にかかったりするぞ。
それを思えば、ハナからバカにした
ものでもない。
レコード数が多いからこそ、カラム数を減らすべきだってことが分からないのか？
あいつらなんでもかんでも一行づつ処理しようとする。
処理時間=一行の処理時間(一定)×行数
はRDBじゃ通用しないんだよ
「ここでSQLのSUM関数で合計を取得します」
「それ信用できるの？ちゃんと一つずつ足さないとダメだよ」
２１世紀でこれかと驚いた
ケースバイケースだと言ってるんだよ。
絶対どっちか、というものではない。
予備カラムがあっても、理由が充分なら、
それでよいではないか。
検索パフォーマンスが必要無いならxml型にするって手もあるけど
予備項目を活用する分には保守の範囲内で出来るから
予備を多めに作っとくっていうのがあったな
クソだと言われてる設計でも事情でそうなってるのも結構あるよね
画面から予備カラムにセットする値にも制限掛からないから、変な値入ってバグってみたり。
予備カラムをあらかじめ作る必要性はうすい
COBOLだから予備カラムつくるんじゃなくて、それが動いているプラットフォームが
固定長バッファのシーケンシャル入出力を基本としてたから必要なだけ
あんな天下り先確保のための試験を
ボッタクリ価格で受けるとか、
怒りが湧いてくる。
とはいえ午後1は酷い問題混じってることあるから、選択運の要素が強いけど。
安いので許せや
酷い問題のってどれですか
は取れなかった奴の言い訳じゃね (w
www.2ch.net
toro.2ch.net/db/
toro.2ch.net/test/read.cgi/db/1228061247/
せっかく合意のとれた業務フローとテーブル設計を
180度ひっくり返しに来る奴（客・身内問わず）がいるから
それが最初からわかってるから軽視される
ちょうど私はその時新しいパソコンがほしいと思っていて本当に買おうかと悩みました。
というのも２０１１年製でCPUがCorei5、メモリも４ＧＢあるしHDDが１ＴＢもあってお値段がなんと３８０００円でした。
まだ発売日からあまり期間も経っていないしこのスペックでこの値段ならかなりお買い得かなと思ったのですが、問題は少スペース型というか拡張性がないタイプのものだったんです。
それにグラフィックボードもついておらず後々の事を考えるとやめといたほうがいいかなという結論に達しました。
結局ネットでBTOのパソコンを後で注文しました。
いやぁしかしまさか周りにあるパソコンの中で一番スペックが高いのに一番安い値段になってるとは思いませんでした。
ttp://toro.2ch.net/test/read.cgi/hp/1382021349/ ttp://toro.2ch.net/test/read.cgi/hp/1352858999/ どんなプログラミング言語を学習すればいいですか？
競馬を通してプログラミングを勉強すれば楽しいと思うし、
仕事にも役立つとなれば一石二鳥。
データーソースは外部の物を利用。
日本小学校
１年 |２年
1組 ２組 | 1組 ２組
座席番号１安藤 伊藤|五十嵐 飯田
座席番号２臼井 榎本|上田 岡田
座席番号３０（全クラス３０で統一）
↑をデータベースに格納しようとすると
こういう風な感じになると思いますが
日本小学校 一年 1組 座席番号1 安藤
日本小学校 一年 1組 座席番号2 山田
日本小学校 ２年 1組 座席番号1 伊藤
視覚的に編集するには前者の方がやりやすいですよね
こういう前者のデータ構造は何か名称があったりしますでしょうか
また前者のテーブルの横にアメリカ小学校を追加する場合もあります
こういうデータを管理するために何かいいツールとかないでしょうか？
データベースに格納できるよう変換してくれたり
１年 |２年
1組 ２組 | 1組 ２組
日 座席番号１安藤 伊藤|五十嵐 飯田
本 座席番号２臼井 榎本|上田 岡田
小
ア 座席番号１ボブ トム
メ 座席番号２マリー
リ
カ
小
こんな風にしたり
そもそもそれはデータ構造と呼べる代物かが疑問なんだが
表現方法としては「マトリクス表」とか呼べばいいんじゃね？
ツール？excel使えばいいじゃん
excel VBAでcsvを出力するマクロを作れば終いだ
どうもです！
◎ +ニュース板
・ 2NN
・ 2chTimes
◎ +ニュース板新着
・ 2NN新着
・ Headline BBY
・ unker Headline
◎ +ニュース板他
・ Desktop2ch
・ 記者別一覧
◎ 全板
・ 全板縦断勢いランキング
・ スレッドランキング総合ランキング
・ ログ速
◎ 全板実況込み
・ 2勢
・ READ2CH
・ i-ikioi
※ 要サイト名検索
同県蕨市南町、東大大学院博士課程の内藤慶一容疑者（２６）を逮捕した。
川口署によると、内藤容疑者は「研究が忙しく、ストレスがたまっていた。少女に興味があった」と供述している。
逮捕容疑は１月４日午後５時半ごろ、埼玉県川口市並木２丁目の書店１階の階段近くで、
当時９歳で小学４年だった女児の下半身を触った疑い。
書店の防犯カメラ画像を解析するなどして内藤容疑者が浮上した。
３月上旬に近くのスーパーで別の女児が下半身を触られる被害があり、関連を調べる。
ttp://www.47news.jp/CN/201407/CN2014072001001585.html 役に立たないんだよ。
まじで。
オプティマイザがいい仕事するんやで
総務省の『憲法改正国民投票法』、でググってみてください。
日本国民の皆様方、2016年7月の『第24回 参議院選挙』で、日本人の悲願である
改憲の成就が決まります。皆様方、必ず投票に自ら足を運んでください。お願い致します。
インターフェイスって何？
> 噂の日教組保育士がまた報復やったってさ
>
> 749 名前：名無しピーポ君 ：2015/11/24(火) 12:41:16.38
> あーーーー在日居住地にある能満幼稚園の
システム間インターフェイスだとしても、ユーザーインターフェイスだとしても間違っているか？
Googleの検索システムがKVSの御時世に何言ってっだこいつ？
8年前の書き込みに何言ってっだこいつ？
自演なのかも知れんがクッソワロタ
データベース設計を「テーブルレイアウトを決める」という作業と捉えてる時点でDB設計を軽視してるんだよね
テーブル設計はDB設計の中でも末端作業だから、そういう認識から変えたほうがいい気がする
経験上、DB設計出来ますってやつのうち概念設計や論理設計がまともにできるやつは20人に1人いればいいほう
論理設計が出来るとは思ってないが
テーブルを正規化したり
適切なデータ型を決定したり
制約を定義するといったことを
末端作業と言って軽視すのは
どうかと思うよ
それも最後のほうにやる作業だって意味
ある業務に関わるデータをどういうデータ構造で管理するのが適切かを考えようとしてる時に
「Excelのフォーマットを決める」ような作業が、RDBなら「テーブルレイアウトを決める」という作業
「どういうExcelフォーマットにしようか」ってのと同じ観点から始めて
テーブル定義書と申し訳程度のER図を書くことがDB設計だと思ってる人がすごく多い
DB設計はテーブルレイアウトを決める作業じゃなくて、DB設計の結果としてテーブルレイアウトが決まる
クラス図とクラス定義書を書くのが設計だと思ってる人はほとんどいないけど
DB設計においてはそのレベルの人がたくさんいるよね
適切なデータ型を決定したり
制約を定義するといったことが
最も大切だよ
それだけの話
それらを必要に応じて
敢えて崩すのはアリだけど
正規化をやらないとかはありえない
それって結局、DB設計をテーブルレイアウトを決める作業と捉えてて
テーブルレイアウトを決めるのにはそれらが最も大切だって言ってるんじゃねーの？
例えば正規化ってOOにおけるSRPやOCPみたいな設計原則に相当するものだよ
SRPに従ってクラスを分けることがシステムやプログラム全体の設計の中で最も大切だったりする？
クラス定義においてならまだ理解できるけどさ
それと同じで正規化の知識は必須だし、業務アプリなら当然その設計原則に従ったモデルを作るんだけど
DB設計において正規化することが最も大切なわけではないよ
テーブルを正規化したり
適切なデータ型を決定したり
制約を定義するといったことが
最も大切だよ
それより大切なことって何かな？
>何故データベース設計は軽視されるのか？
理由を考えてみたが、教育不足と経験不足が大きな原因だと思う
まず一般的なプログラムの設計に比べてDB設計はその機会自体が圧倒的に少ない
それはプログラムに比べてDBは数も少なくライフライクルも長いし、プログラム設計に比べればDB設計は一人で担当できる規模が大きいから
機会自体が少ないから、業務アプリに関わるエンジニアの中で繰り返し何度もDB設計の経験が積めるような人も当然少ないし
その中でも優れたDB設計者となるともっと少ない
だから一部のDB設計に特化した会社や部門を除くと、かなり大手でもDB設計に関してまともに後進の教育や育成ができるような人はすごく稀
そうでない人たちに教育・育成されたエンジニアが大多数を占めるからDB設計が軽視されることが自然と多くなる
DB設計能力の低いと、どうしてもプログラムの処理に重きを置きがちで
プログラムからデータをどう使いたいかという観点でDBを設計しちゃう人が多い(=DB設計の軽視)
そういうやり方を見てきた人たちはそれが当たり前だと考えるからDB設計軽視が再生産される
個人レベルでは優れた教育を受けたり、数多くの経験を積むことで負の連鎖からは抜け出せそう
会社レベルではDB設計の機会の少なさと重要性を認識して、優れた育成者を多く育てる努力が必須かな
DB設計において最も重要なことは
ビジネスドメインと要求を深く理解して適切なデータモデルを作ること
ビジネスドメインと要求を深く理解するというのは
そもそもデータベース設計レベルの話かい？
そうだよ
ちゃんとしたデータベース設計には必須だよ
対象のドメインと要求を深く理解しないと適切なデータモデルは作れないから
だからプログラムの実装に近い人がDB設計するよりも
要求分析をする人で技術力もある人がDB設計をしたほうがまともな設計ができることが多いよ
後者の場合は組織や責任者がDB設計にとって何が重要か理解しててDB設計を軽視してないっていう理由も大きいけどね。
ふむ
要求分析をする人で技術力もある人が
ビジネスドメインと要求を深く理解して適切なデータモデルを作れば
テーブルを正規化したり
適切なデータ型を決定したり
制約を定義するのは
やらなくて良いと仰りたいなかな？
大局的には「計算機で効率的に処理可能な形式で対象を表現したモデル」――「対象領域の計算機向けモデル」（数理モデルとか、あっちの意味でのモデル）の構築こそが根本であるので、
それを重要視する、ということ？
でも個人的には正規化などのtuple（型）の設計しながらフィードバックしていって上記の概念を理解・把握・構築している感じがある
具象から始まり抽象化する、というか、つまり何なのか、を追求していくとそこに至るというか
なので個人的には 兼 ww
データベースに長けた人からみるとまた違うのかな？
ビジネスドメインと要求を深く理解して適切なデータモデルを作る
という作業の中に
テーブルを正規化したり
適切なデータ型を決定したり
制約を定義する
という作業が内包されてるなら
そもそも比較することが間違い
ほぼ機械的に決定して薦めれるからなぁ
本質的に不可分なのだという主張なら、それはそれというか、方向性としてはわかる。
もっとも、そうなるとその線引きは難しいだろうけど。
機械的にやれるからと言って軽視するのが
そもそも間違い
DB設計の一部である概念設計は要件定義の一部
という考え方なので不可分といえば不可分
フェーズの呼び方は会社によって違うだろうけど
要件定義時に概念設計,
基本設計時に論理設計,
詳細設計時に物理設計が基本
DB設計の質を一番大きく左右するのが概念設計
エンティティの漏れやリレーションの間違いがあると
制約の定義漏れやデータ型の選択ミスとは比べられないレベルの悪影響が出る
(正規化の多くは概念設計で行われる)
もっと狭義のDB設計フェーズという考え方があるのかもしれないけど
そういう考え方自体がデータベース設計軽視につながっている可能性があるのかも
その考え方を徹底すると、DB設計はなくなりそう。ｗ
機械的にやれるということと、軽視するということには関連性がない
君はいったい何と戦ってるんだ？
概念設計、論理設計、物理設計のどの段階で正規化するの？
普通は初めから正規化したようなまとまりで考える。
概念を正しく論理モデルにする作業が正規化だろ
の言うとおり、どこかで正規化の工程があるというよりは
最初からほぼ正規化されたモデルで考えて
モデルを改善するたびに正規化違反をチェックしながら都度対応する
なので概念設計が終わったらその段階まででの正規化も終わってる
論理設計時にはサロゲートキーや削除フラグみたいなのが追加されて
正規化が崩れる場合があるからその場合も都度判断して対応する
物理設計では正規化に関わるようなところは基本的にいじらない
DB概念設計のインプットになるようなドメインモデリングをする時は
概念間の関係とわかりやすさを重視するので正規化されてるかどうかは気にしない
参考までに、
⇒ 『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。
グーグル検索⇒『宮本のゴウリエセレレ』
DX2Z9GYZ7S
