ここでいうデータベース設計とは、
特定の業務システムにおける
テーブルレイアウトを設計し、決める作業であるとします。
業務システムにおいては、
このデータベース設計（テーブル設計）は仕様そのものを定義する作業にも
近いと思いますし、この設計は開発工程やその後の運用における品質を
絶対的に左右するものだと思っています。
逆にこの設計があまりにも実現すべき仕様と比較し不整合なため、
その後の開発工程がデスマーチに陥ることも少なくないのではないでしょうか？
にも関わらず、正規化程度も理解できないような担当者が
この設計を行っていたり、業務システムの受託開発において、
「テーブルレイアウトを決める」という作業が、あまりにも軽視されているような
気がしています。
みなさんの現場ではどうでしょうか？
ご意見などお聞かせください。
データベースとは、リレーショナルデータベースを指しています。
驚くぐらい何も知らない。
確かに>>3の言う通りだと思う
日本語を使ってるのやめさせたい。それからコボラーの薫陶を
受けたVBA使いの作ったシステムを全て作り直したい。
動けばいいとすら思ってない。
作って納品しちまえばおｋと思ってるw
本運用に入ったら誤作動しまくり落ちまくりってのはもう
狙ってそう組んでるとしか思えなくなってきた・・・
IDが何なのかってのを記憶してる人間が技術力高いつて重宝されとる……
若手のSEがDB設計中だったので覗いたら、テーブル名・カラム名を日本語で書いてる・・・
んで、それはやめようよと言ったら、マニュアルのどこにダメって書いてあるんですか！日本語は使えるはずですよね！
と言われたので、その場でPJから外してもらうよう上司に頼みに行った。
送り仮名で嵌るんだよ・・・
SHOHIN
SHOUHIN
前任のアフォが設計したDBでこれらが混在してたから
全部「商品」で統一して新規で作り直す仕事何べんもやってるw
このスレ読んでおれもＤＢ設計してみようかなと思った
そのたびに一から作ってたら間に合わんし客も予算出せないでしょ
実稼働中の物を今日まではこれ、でも明日からはこのシステムで
なんて無茶な用件はたくさんある
だからある程度の遊びフィールド作ったり妙な拡張して過去の残骸が残ってたりする物が出来てくるわけ
それを最初見た奴にとっては謎いシステムかもしれないけどさ
簡単に言うとガチガチに設計すると馬鹿を見る事も多いんだよ
コボラ？
データベース屋がまともな仕事をしないからだろ。
>>3のような技術力の不足、利用シーンを考えない独り善がりな設計など。
むやみに正規化してりゃいいってもんじゃないし。
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にやらせて遅くしてるのはお前だ
アプリにやらせて遅くしてるやつの方が多い。
とても遅くなって困る。
なつかしいなそれ。割引金額をアプリで持ってるから
割引率変更になった時点で過去売り上げの改ざんになるのな。
揚げ足取りはさておき、ドメインロジックはまだいいんだけど
クロス集計とか頑張ってやってたのを見てびっくりした事ありますよ。
今はSQL/OLAPが使えるようになってきて随分楽ですね。
テーブル設計がよろしくなくて、アプリ側でエラい苦労させられたことがある。
SQL書けねえやつに設計させるなと。
SQLが問題なのか、
アプリが問題なのか…についてですが、
結論からいって、全てにおいてまずテーブル設計の問題だと思います。
理由はそれが土台だからです。
テーブル設計がおかしいという理由で、
おかしなSQLを書かざるを得ない状況に陥ることは多々あるし、
テーブル設計がおかしいから、
アプリでおかしな制御をせざるを得なくなったりするんです。
それと、「正規化もやりすぎると使いづらくなる」などという意見がありましたが、
自分は何があっても、どんなシステムあっても、どんな利用用途であっても
RDBでデータを管理する以上、必ず全てを第三正規形まで落とす必要があると思います。
正しくはその正規系を業務や仕様にあわせて（敢えて）「崩す」のです。
だから「正規化はしないほうがいい場合もある」というのは語弊があります。
正しくは「正規化は必ずしなければならない。その上で（状況に応じて）崩すことは構わない」
ということです。
要件定義から設計～実装～テストまで自前でやればドコがおかしいか
自分で気がつくだろうに。
時々、老害が自分の立場を守るためにくだらねぇ自己主張
しまくるから、設計がグダグダになっていくケースがあるしなぁ。
二人一組ぐらいにはするべき。
「意識が途切れる」「遠いところに逃げる」「宙を舞う」。含意は色々ですが。
と真顔でのたまう、うちのSE。。。
飛ぶっていうのは逃げるとか逃亡するとか辞めるとかの意味。
あるコードに対して対象か対象じゃないかをマスタのレコードが有るか無いか
で判定するのはRDBとしては誤っていると思うんだけど。
RDB設計をまともにやればシステムの便利さは格段に向上するのは間違いない
システムへの要求も高度化するだろう。RDB設計をまともにしない人には
低度な要求を解決する仕事を続けるためにRDB設計を軽視し続ける
べきだ、保身のために。
日本は現場の国だ。現場以外は糞。そしてシステムに関する決定権は
現場には無い。使う側の現場力と開発する側の現場力が糞によって
互いに相反する方向へ注力させられている。まったく無駄なことよ。
設計を軽視するとこうなる
>あるコードに対して対象か対象じゃないかをマスタのレコードが有るか無いか
>で判定するのはRDBとしては誤っていると思うんだけど。
RDBでないDBはそうするしかないと思うが。
RDBでそうしているオマエの現場が糞と言うなら「そうだろうな」としかいい様がないわけだが。
「システムに関する決定権は現場には無い」ってオマエがオペレーターみたいな
現場といっても最底辺だとないだろうとは思うが、普通の開発現場なら
あからさまにイカれている設計なんかはレビューや評価で却下すればいいんじゃねーか？
そのレビューとやらに呼ばれないｗ
Oracleやってる奴も汎用機COBOLで経験つんだエンジニアばっか。COBOL流のシステム
設計をむりやりOracleに載せてる。それが常識で考えた標準らしいですよ。何も言えねえ。
こいつはどういう状態のことだ？
つうか、>67はどんな対案が正論だと言いたいんだ？
1:n設計は間違いだっていう主張？
ひどいｗ
これは損害請求レベルじゃないのか
---------------------------
1 | 存在する
2 | 存在しない
3 | 存在する
or
レコード番号 | 存在フラグ
---------------------------
1 | 存在する
3 | 存在する
の違いって事？
レコード番号 | 対象フラグ
---------------------------
1 | 対象
2 | 非対象
3 | 対象
※フラグ見て対象かどうか判断
or
レコード番号
-----------
1
3
※レコードの存在の有無で対象かどうか判断
の違いって事？
どういう状況でどんなテーブルに何をしようとしたのか端的に説明してくれ。
とにかく状況が小出しじゃ何も判断できん。
あと、「引く」という言葉の意味が分かりません。
ひくわ
なにか、ＲＤＢがあるからデータ入れよう的な考え方に聞こえるぞ
まったく結合するものがないなら、「Ｒ」ＤＢである必要はないわな
レコードがあるかないかで判断するか、（結合された）レコードに書かれてる内容で判断するかは、
それがどういった情報を格納してるかで決定するべきで、ＲＤＢなのだから
必要ない結合先のレコード（や、もしかするとそのテーブルそのものも）を作らないといけないということはないだろう
>そしてシステムに関する決定権は現場には無い
現場は必要もないＲＤＢを使いたくなく使ってるのかもしれないな
そして必要もないのに、ＲＤＢだからどうのこうのという、
現場の空気を読まない原理主義者みたいなやつがさらに話をややこしくするんだ
>>67
口調が違うが同一人物じゃないのか？
ちなみに、ＲＤＢ使った開発でＳＱＬを書いてるやつでも、
exists使ったことないってやつは結構いるだろう
ＲＤＢだから、ＯＲＡＣＬＥだから、レコードのあるなしで判断するのは間違ってるだろうとか
その判断基準がおかしいとしか思えん
まあ、現実的なＤＢの選択としてはＲＤＢＭＳしかない現状もあるがな
実際にこういうことを口に出しちゃうと
「頭でっかちで現場じゃ使えない」って評価になるんだよね
おれがそうだからよく分かるwww
それで親の無い子レコードや、不正なデータが山のようにあるんじゃ世話ねーよ
設計と製造の現場はまさに自分はDB設計を軽視してませんって顔して
キーマンの顔色を伺って程度をあわせる世界だよね。アホすぎｗｗ
ここもそんなもんだね。あ～あ
ここもそんなもんだねとか達観した気になる前にここで吐き出せよ。>80みたいに。
それすらできないくせに嘆くな。
>>86はどう？
市況２のスレを読んだら、どうも
データベースがぶっこわれたみたいで、金曜の取引データが飛んだみたい
で、約定メールから復旧させようとしてるとか
ぼくの考えたデータベース持ってキター！
さて、どうすっかな・・・
データベース設計に携わる人間が軽視されているのだ。
という命題をたててみる。
それは、その人間の行う作業が軽視されてるから、
その人間が軽視されてるじゃないか
そうでないなら、別の人間が代わりにその作業をすることになるだろう
データベース以前の問題だな。
結局、現場の意見のほうが採用されて、ボンクラ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が実績があって安定性云々なんて
寝言を言う人間は間違いなく現場の金融系の実体を知らん厨房だと思う。
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲
Ｄ Ｂ (129)
推薦図書/推薦ＨＰ/必読書のためのスレッド (182)
CSVファイルのスレ (219)
データベース破壊録カイジ (144)
【初心者】オラクルマスター Bronze 3【入門者】 (814)
XML統合スレッド (391)
--log9.info------------------
長渕剛 と 矢沢永吉 どっち聴くべき？ (109)
くるり岸田に比べればカスチル桜井はゴミ (311)
オレンジレンジ ＶＳ 岸田 ＶＳ 桜井 (445)
【蛇足】名曲を台無しにするスレ (365)
【無能】他人の曲をカバーするな！【】 (307)
中島美嘉の可愛さってマジヤヴぁくね？ (746)
ID砲丸投げin音楽サロン板 47曲目 (793)
路上ライブってうざくねえ？ (635)
J-POP と K-POP を語るスレ 38 (794)
坂本龍一「菅おろしに国民の大半があきれている」 (227)
強震モニタ、眺めながら曲を聴くスレ２枚目 (544)
藤原基央は自すべき (507)
JPOP KPOP 洋楽 14 (420)
【圧倒的】世界最強の三大歌姫【歌唱力】 (847)
音楽無料ダウンロードしてはいけない (108)
ゆず 北川悠仁の実家が宗教の総本山 (194)
--log55.com------------------
獨協大学は学歴フィルターでＮＧ
■東京3理工■工学院大・芝浦工大・電機大■
獨協大学オープンキャンパス
獨協大学の履歴書はゴミ箱直行
獨大生の大部分は無名の中小企業に就職する
【あなたをとる】医学部再受験【メリットは？】
【東大】東京大学・理科三類 18 【理Ⅲ】
早稲田アカデミーの内幕ってｗ ★5