何故データベース設計は軽視されるのか? (653レス)
1-

201: 2009/06/28(日)00:47 ID:??? AAS
日本で仕事をしない。
これ最強。
202: 2009/06/28(日)02:52 ID:??? AAS
理解しなくても、会社の資本金を出してたり、出資者から任命されてたりするから権限持ってる。
文句有るなら自分の資金で設計遣ってれば良い。
203
(1): 2009/07/27(月)20:54 ID:??? AAS
どんなまずい設計のシステムでも、
実際に運用されていて問題のないものはあまりいじらないものだよ。
204: 2009/07/28(火)06:21 ID:??? AAS
まずさ加減に寄るな。
致命的なのや、将来的に問題になりそうなのは苦労してでも弄らないと後で困るよ。
弄らないまでも、報告だけはしてシステム関係者の中で共通認識は築いておくべき。
後で、問題が起きてからDB担当の個人の責任にされたほうが割喰うよ。
205: 2009/07/28(火)21:02 ID:??? AAS
もちろん問題点の把握はしておかなければいけない。
あと、問題が発生して誤動作したときのリカバリーの手順とかもマニュアル化しておく。
206
(1): 2009/07/29(水)03:38 ID:??? AAS
誤動作する時点て致命的じゃないのかなあ。
データ失うよね?
207: 2009/07/29(水)14:16 ID:??? AAS
>>203=205は
もっともらしい事言いたいだけの
他の板に居場所がない老害コボラー
208: 2009/08/10(月)19:46 ID:fUpv0ZNe(1) AAS
>>206 完璧主義者の集まりが作ったシステムなら あっさりデータなくなるだろうけど
多少の開発経験がある人が居れば DB経験がなくても バックアップや履歴、ログは残るはずだよ
スムーズに復旧できるかどうかは別の問題だが…
209
(1): 2009/08/22(土)00:12 ID:/H1vAtQw(1) AAS
むやみに正規化できないケースはいくつもあるぞ。
顧客コードとそれに対応する顧客名称などがテーブルにあっても、
実はマスタ化するまでもない一見の顧客の場合、特定のコードを使って、
顧客名称のみ画面から入力したいという与件があったりするケース。
EDIで顧客からマスタと依頼データをもらっていて、
依頼データをもらった時点のマスタの値を依頼データに付加して保持しないと
いけないケース。
複雑な料金計算の設定マスタなど、既存のデータと処理をそのまま移行する
必要があって、下手にデータの持ち方を変えてしまうと、
明確に仕様化されていない部分の動作が保障できなくなってしまうケースなど。
210: 2009/08/22(土)02:06 ID:??? AAS
>>209
>顧客コードとそれに対応する顧客名称などがテーブルにあっても、
>実はマスタ化するまでもない一見の顧客の場合、特定のコードを使って、
>顧客名称のみ画面から入力したいという与件があったりするケース。
>EDIで顧客からマスタと依頼データをもらっていて、
>依頼データをもらった時点のマスタの値を依頼データに付加して保持しないと
>いけないケース。

これは別に全然問題ない
「顧客名称のみの登録もできる」
「依頼データをもらった時点の値を保持する」
省7
211
(1): 2009/08/22(土)03:20 ID:??? AAS
その辺は正規化してちゃんと効果有るの?
正規化したいだけの自己満足程度?
212: 2009/08/22(土)04:39 ID:??? AAS
>>211
正規化することに理由を求められてもな・・
逆に「正規化しないこと」にこそ理由が必要だと思うんだが

逆に質問していい?
「君の会社の開発標準において、論理データモデルを
作成するという工程はないの?」
213: 2009/08/22(土)06:57 ID:??? AAS
あるわけがない。
214
(10): 2009/08/22(土)15:07 ID:??? AAS
最近、クラウド絡みでKVSって聞くけど、別にクラウド云々関係なしにKVS的な構造ってどうなんだろ?

例えば会員テーブルというのがあったとして通常なら(型とサイズは面倒なので略)

create table 会員(会員番号,姓,名,性別,住所,誕生日)

レコードは
00001,会員,太郎,男,東京都,2000/01/01
00002,会員,花子,女,神奈川県,2000/01/02
ってな感じだろうけど、それを

create table 会員(会員番号,属性コード,値)
省23
215: 2009/08/22(土)15:16 ID:??? AAS
RDBすてろよw
216
(3): 2009/08/22(土)18:01 ID:??? AAS
>>214
>・SQLがきわめて単純になる。
>・DB構造に頭を悩ませる必要がなくなる。
ちゃんとしたDB設計もできない設計者、SQLもかけないようなプログラマにとってはメリットかもしれんがな
>・スケールアウトしやすい。
クラウドに適した形式だから、莫大なデータ量で通常ではハンドリングできなくて
クラウドにするってならわかるが、クラウド考慮しないなら関係ないんじゃない?

>複雑なSQLなんて見たくもない。バグの原因&パフォーマンス劣化の原因になりやすい。
すくなくとも複雑なSQLがパフォーマンス劣化の原因ではなく、(SQLにより実行される)複雑な処理が原因なわけで
>・今まで1つのSQLで取得できてたものが複数回のSQLになる。
省11
217
(3): 2009/08/22(土)18:50 ID:??? AAS
>>216

>クラウドに適した形式だから、莫大なデータ量で通常ではハンドリングできなくて
>クラウドにするってならわかるが、クラウド考慮しないなら関係ないんじゃない?

最初は考慮してなかったが後からやっぱ必要だった!(見積もりが甘い?)って時にはメリットになると思います。

>ような状況で、パフォーマンス劣化は避けられるどころか余計悪くなると思うがな

SQLだとちょっと書き方変えるだけで10倍、100倍もパフォーマンスが違う事ってありますよね。みんながみんなSQLのエキスパートであれば問題ないのですが。それに比べればましかなと思ってます。もちろん処理内容によりますが。
省7
218: 2009/08/22(土)19:11 ID:??? AAS
>>214
こんなことしなくても
みんなお前ほど頭悪くないから大丈夫だよ
219: 2009/08/22(土)21:45 ID:QZMSHBrB(1) AAS
開発効率が30年前に逆戻りすることだけは確実だな…
220: 2009/08/22(土)22:12 ID:??? AAS
馬鹿でも扱えるようにしたら色んなところで問題が出るってなぜわからんのだ。
カスレベルの人材でも働けるのは業界にとって大きなマイナスだ。
1-
あと 433 レスあります
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ AAサムネイル

ぬこの手 ぬこTOP 1.458s*