09/05/02 16:13:53 .net
そうか？
結構こういう汎用ログからのデータ収集って実社会で役に立つと思うが。
注目してる香具師が極端に少ないだけで。
普通にアクセスログ表示ソフトがどんな項目で分析してるか調べるといいと思う。
ｽﾚﾘﾝｸ(db板)
「ビジネス」BIツール「インテリジェンス」
ｽﾚﾘﾝｸ(hp板)
【アクセス解析】Google Analytics 5
ｽﾚﾘﾝｸ(hp板)
詳細なアクセス解析をしたい！！！
ｽﾚﾘﾝｸ(php板)
Analogスレ
ｽﾚﾘﾝｸ(unix板)
統合監視ツールどうよ?
ｽﾚﾘﾝｸ(linux板)
GNU/Linux とネットワーク/セキュリティ
あと、IT監査とかで結構需要は多い。一般ソフト並みとはいかないけど。
167:NAME IS NULL
09/05/02 17:29:02 .net
>>166
よく読め。ログをERで表せって話だ。
168:素人
09/05/11 00:45:40 .net
すみません。オッケーウェブで質問して、回答ももらったのですが、回答が１件だけだったので
もう少し他の意見も参考にしたいと思ってこっちに来ました。オッケーウェブの方はもう締め切って
あるので、マルチだと言わずに聞いて欲しいです
僕が質問したトピックはこちら
URLﾘﾝｸ(okwave.jp)
ＥＲ図が削除されていたのでもう一度アップしました
URLﾘﾝｸ(kansai2channeler.hp.infoseek.co.jp)
確かに回答の通りこの場合はok_ngで検索すればいいだけなので冗長だと思いました。
そうすると、この１対１の関係が成り立つのはどのような場合でしょうか？
使い分け方とメリットデメリットあたりが聞きたいです。
それと、１対１のテーブルは、たまたまマイレージプログラムと乗客のテーブルで見たのですが、
それは「特殊」なパターンなのでしょうか？それとも一般的なものでしょうか？
そのあたりも教えて下さい。
169:NAME IS NULL
09/05/11 05:28:05 .net
｢こういう理由でこの１対１の関係を作ったのだけど、どういった問題があるか指摘して欲しい｣
のような話でないと、なんともいえないです。
｢合格者テーブル｣を作った理由ですね。その理由からメリットデメリットが導かれてくるんじゃないかなぁと。
訳もわからず、理由も無く、なんとなく作ったのなら、それは意味が無いし先の回答者の様な返事になるだけですよ。
※自身で「冗長だ」と思うならそういう設計をしなければ良いわけで....何故悩むのかと。
もし本を読んで見つけたのならそのデータ構造を作る理由を読み直して理解した方が良いです。
※あと、「そうすると、この１対１の関係が成り立つのはどのような場合でしょうか？」も
ちょっと意味が判りかねます
170:NAME IS NULL
09/05/11 08:54:15 .net
なんでマルチが嫌われるのかと言えばだな、回答した香具師に失礼だからさ。
okで回答した香具師に失礼と思わない訳？
にちゃんで回答した香具師にも失礼な行動は予想出来るよな。
にちゃんで回答してもらったが、納得出来ないので教えて欲しいと他所でまた訊くのだろ？
171:素人
09/05/11 09:31:11 .net
大変失礼しました。
172:NAME IS NULL
09/05/25 05:26:51 .net
結局、 >>161 も>>168 も音沙汰無しなんだな。
後日談とかちょっとだけ楽しみにしてた私はマヌケだった。ﾊｽﾞｶｼ.....
173:NAME IS NULL
09/05/26 07:16:07 .net
今にちゃんでの回答に納得出来なくて、他所で訊いてる所だろ。
174:NAME IS NULL
09/06/18 01:33:24 .net
えーと、初めてのオラクル案件でマスタテーブルを
UNIONで結合したような統合テーブルが設計されていたのだが
オラクルが特別なのか、案件が特別なのかどっちらでしょうか。
175:NAME IS NULL
09/06/18 21:46:40 .net
統合テーブルってなに？
viewのこと？
176:174
09/06/18 23:37:09 .net
すまん、それは漏れが感じたテーブルのイメージ名。
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･･･
177:NAME IS NULL
09/06/19 00:47:06 .net
特別だからってどうなるの？ 指定なら対応するしか選択肢無いと思うが。
178:NAME IS NULL
09/06/19 01:05:15 .net
>>174
オラクルに限ったやり方ではないし
特別ってほど奇異でもない
ただ例としている部門と消費税を一緒にするのはエスカレートしすぎって感じ
179:NAME IS NULL
09/06/19 03:25:51 .net
単にテーブルだけ出してきて、それが特別かどうか聞かれてもな
もしかしたらものすごく特別な使い方してる可能性もあるし、
結構見られるようなものかもしれない
汎用的なマスタとして使ってるのかもしれない、リポジトリのような使い方かもしれない
が、使ってるDBMSだ何だろうと、そのテーブルがそのままの形なら
設計やり直してくれとお願いするな、俺ならｗ
180:NAME IS NULL
09/06/19 06:01:10 .net
消費税なんて変わりそうなものは別に分けたいね。
まあその時の担当じゃなければどうでもｗｗｗ
コボルベースの設計とかを引き継ぐ理由とか有るのでは？
181:174
09/06/19 21:37:46 .net
>>178
オラクルだからって事ではないんですね。
>>179
リポジトリではないですね。
汎用的なマスタなんだろうけど汎用性が高すぎる。
次のプロジェクトから設計やり直しをお願いしてみるよw
>>180
なるほどコボルベースの設計か、
設計者が実績あると言っていたから伝統なんだろうな
ASP.net2008で開発してDBが伝統か
182:NAME IS NULL
09/06/19 22:07:28 .net
中身のない実績なんだろうな。
183:NAME IS NULL
09/06/20 08:47:31 .net
昔コボルでの実績だろう。
184:NAME IS NULL
09/06/20 10:17:54 .net
しかしその何がどう問題なのか、正しく指摘できる者はいないのであった。
185:NAME IS NULL
09/06/21 08:51:28 .net
コボルにも対応出来るのが普通だしな。
ちゃんとコストとか実行速度のデータ示せないと検討も出来ない。
186:NAME IS NULL
09/06/22 21:30:17 .net
>>184-185
釣れますか？
187:NAME IS NULL
09/06/22 23:32:51 .net
3日粘ってようやく一匹。
188:NAME IS NULL
09/06/24 00:24:45 .net
すいません、正規化を俺が望まなければちょっとの修正ですんだものを、
DB構造もプログラムも大改修して多大なコストがかかりました
技術屋として間違ってはないと信じてる
でも経営としては間違ってるんだろうな、きっと
189:NAME IS NULL
09/06/24 06:53:19 .net
>>188
将来のデータ不整合、障害発生のリスクと
目先のコスト、どっちが大事かな。
まぁ、派遣切りのご時世だもんな。
190:NAME IS NULL
09/06/24 09:00:48 .net
金がかかったそもそもの原因は正規化のせいじゃなくて
元々の設計がダメだったせいってなんで気がつかないの
191:NAME IS NULL
09/06/24 16:12:25 .net
表層に現れるのは「修正にコストかかった」ってことだけだからな
お偉いさんには「こんな簡単なことに時間かけて何やってんだアイツは」としか映らない
技術者をないがしろにしてきた代償だよ
192:NAME IS NULL
09/06/24 19:12:46 .net
>>188
もともと正規化してなかったので、そのちょっとの修正の「ついでに」
正規化した、というのであれば、そのコストは、ついでの作業に伴い発生したコスト
技術屋って言い方すればコスト意識を無視できるわけではないと思うがな
ｘｘ屋さんってのは、ｘｘを売るから屋なわけで
コスト関係なく技術的に最善最上な状態でないと気に食わないというのであれば
それは技術原理主義者とｗ
コストとのバランスをとれるから技術者じゃなくて技術屋なんだと
193:NAME IS NULL
09/06/24 19:32:12 .net
しかし、コスト至上を理由に次々とパッチワークしていったシステムはひじょうに脆く、改定に対する耐性が格段に低くなる。
全てを「自分の好みに修正」したいってんなら、お前なにやってるんだの世界だけど。
後まで見据えての決断であれば技術者の良心だろ。
姉歯はいかんよ、姉歯は。
194:NAME IS NULL
09/06/25 00:20:29 .net
元々の設計のままでのコストの発生具合による。
好みや良心の技術第一主義で通しても、理解してくれる客は少ない。
でも自分のアピールや努力が足りずに、姉派みたいな弱い立場に陥るのは技術第一主義者には多いと思うよ。
漏れは設計しか遣らないとか逝っても、設計外の人間に理解してもらえる事は少ない。その積み重ねがどんどん立場を弱くして、設計だけしか頼まれない弱い立場で責任だけ押し付けられる事に成る。
設計に金を出してくれる客と良い関係を築けての商売。
195:NAME IS NULL
09/06/25 04:53:37 .net
>>193
その、しかしってのは>>192を受けていってるのか？
技術屋ならバランスとれっていってるのに
コストのために犯罪犯すような話といっしょにするなよ
>>194
すくなくとも今のソフトウェア産業において、設計だけでは
ビジネスとして成り立たないと思うがな
本来客は、設計に金をだすんじゃなくて、プログラムやシステム全体に金をだすわけで
その中の設計に配分される割合が低すぎる＝設計が軽視されている
それは客の理解の問題じゃなくて、売り側が過当競争によって
目に見えにくいコストから削ってるからじゃないかと思うが
196:NAME IS NULL
09/06/25 06:13:48 .net
だから設計でちゃんとコストが変わる事を設計担当がアピールするのが大事。
何もしないから、配分の割合減らされて、コスト削られてるのだよ。
197:NAME IS NULL
09/06/27 01:37:32 .net
>>196
これって客先に説明しておしまい。ってならいいけど
無知な上級SEが良いところ見せようとして・・・説得したあとから
平気で台無しになるようなことをしてきて、あとよろしくって♪って感じの多いわな
198:NAME IS NULL
09/06/27 07:52:04 .net
上級SEぐらいおさえられないでどうする
身内の敵はもっと上だぞ
マネージャーやら社長やら・・・
199:NAME IS NULL
09/06/27 08:56:32 .net
常に人減らせないか、安い人材に出来ないか考えてるからね。
そういう人たちにも、ちゃんとした設計がコストに影響する事を示せないと負け。
200:NAME IS NULL
09/06/27 21:04:36 .net
逆に考えて、
設計がコストに影響することを理解できないような人たちが、
マネージャやら、〇〇長やらを
やってることが問題なんじゃない？
で、この問題をどう解決するか、なんだか。
201:NAME IS NULL
09/06/28 00:47:26 .net
日本で仕事をしない。
これ最強。
202:NAME IS NULL
09/06/28 02:52:03 .net
理解しなくても、会社の資本金を出してたり、出資者から任命されてたりするから権限持ってる。
文句有るなら自分の資金で設計遣ってれば良い。
203:NAME IS NULL
09/07/27 20:54:41 .net
どんなまずい設計のシステムでも、
実際に運用されていて問題のないものはあまりいじらないものだよ。
204:NAME IS NULL
09/07/28 06:21:49 .net
まずさ加減に寄るな。
致命的なのや、将来的に問題になりそうなのは苦労してでも弄らないと後で困るよ。
弄らないまでも、報告だけはしてシステム関係者の中で共通認識は築いておくべき。
後で、問題が起きてからDB担当の個人の責任にされたほうが割喰うよ。
205:NAME IS NULL
09/07/28 21:02:53 .net
もちろん問題点の把握はしておかなければいけない。
あと、問題が発生して誤動作したときのリカバリーの手順とかもマニュアル化しておく。
206:NAME IS NULL
09/07/29 03:38:45 .net
誤動作する時点て致命的じゃないのかなあ。
データ失うよね？
207:NAME IS NULL
09/07/29 14:16:26 .net
>>203=205は
もっともらしい事言いたいだけの
他の板に居場所がない老害コボラー
208:NAME IS NULL
09/08/10 19:46:20 fUpv0ZNe.net
>>206 完璧主義者の集まりが作ったシステムなら あっさりデータなくなるだろうけど
多少の開発経験がある人が居れば DB経験がなくても バックアップや履歴、ログは残るはずだよ
スムーズに復旧できるかどうかは別の問題だが…
209:NAME IS NULL
09/08/22 00:12:51 /H1vAtQw.net
むやみに正規化できないケースはいくつもあるぞ。
顧客コードとそれに対応する顧客名称などがテーブルにあっても、
実はマスタ化するまでもない一見の顧客の場合、特定のコードを使って、
顧客名称のみ画面から入力したいという与件があったりするケース。
ＥＤＩで顧客からマスタと依頼データをもらっていて、
依頼データをもらった時点のマスタの値を依頼データに付加して保持しないと
いけないケース。
複雑な料金計算の設定マスタなど、既存のデータと処理をそのまま移行する
必要があって、下手にデータの持ち方を変えてしまうと、
明確に仕様化されていない部分の動作が保障できなくなってしまうケースなど。
210:NAME IS NULL
09/08/22 02:06:14 .net
>>209
>顧客コードとそれに対応する顧客名称などがテーブルにあっても、
>実はマスタ化するまでもない一見の顧客の場合、特定のコードを使って、
>顧客名称のみ画面から入力したいという与件があったりするケース。
>ＥＤＩで顧客からマスタと依頼データをもらっていて、
>依頼データをもらった時点のマスタの値を依頼データに付加して保持しないと
>いけないケース。
これは別に全然問題ない
「顧客名称のみの登録もできる」
「依頼データをもらった時点の値を保持する」
という仕様のもとに設計して正規化すればいいだけの話
>複雑な料金計算の設定マスタなど、既存のデータと処理をそのまま移行する
>必要があって、下手にデータの持ち方を変えてしまうと、
>明確に仕様化されていない部分の動作が保障できなくなってしまうケースなど。
これはありがちな話で、実際妥協してしまうことも多いんだけど
そもそも「明確に仕様化されていない部分」があることが問題なわけで
正規化できない理由にはしてほしくない
211:NAME IS NULL
09/08/22 03:20:06 .net
その辺は正規化してちゃんと効果有るの？
正規化したいだけの自己満足程度？
212:NAME IS NULL
09/08/22 04:39:23 .net
>>211
正規化することに理由を求められてもな・・
逆に「正規化しないこと」にこそ理由が必要だと思うんだが
逆に質問していい？
「君の会社の開発標準において、論理データモデルを
作成するという工程はないの？」
213:NAME IS NULL
09/08/22 06:57:35 .net
あるわけがない。
214:NAME IS NULL
09/08/22 15:07:29 .net
最近、クラウド絡みでKVSって聞くけど、別にクラウド云々関係なしにKVS的な構造ってどうなんだろ？
例えば会員テーブルというのがあったとして通常なら（型とサイズは面倒なので略）
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なんて見たくもない。バグの原因＆パフォーマンス劣化の原因になりやすい。
もちろん、全てのケースでこの形でうまくいくとは思えないが多くの部分はこの型におさめられるのではなかろうか。そうすれば余計な頭を使わなくて済む箇所が一つ減る。
今でも一部はそういう作りはあるけど（汎用マスタ等）、それを可能な限り全てのテーブルでやる。（究極的にはテーブルは一つで全レコードがそのテーブルの中。レコードを区別する為のコードがさらに必要にはなるけど）
215:NAME IS NULL
09/08/22 15:16:00 .net
RDBすてろよｗ
216:NAME IS NULL
09/08/22 18:01:32 .net
>>214
>・SQLがきわめて単純になる。
>・DB構造に頭を悩ませる必要がなくなる。
ちゃんとしたDB設計もできない設計者、SQLもかけないようなプログラマにとってはメリットかもしれんがな
>・スケールアウトしやすい。
クラウドに適した形式だから、莫大なデータ量で通常ではハンドリングできなくて
クラウドにするってならわかるが、クラウド考慮しないなら関係ないんじゃない？
>複雑なSQLなんて見たくもない。バグの原因＆パフォーマンス劣化の原因になりやすい。
すくなくとも複雑なSQLがパフォーマンス劣化の原因ではなく、（SQLにより実行される）複雑な処理が原因なわけで
>・今まで1つのSQLで取得できてたものが複数回のSQLになる。
>・今まで1行で帰ってきたものが複数行になるのでコードでループでまわしてレコードを組み立てる必要がある。
ような状況で、パフォーマンス劣化は避けられるどころか余計悪くなると思うがな
>多くの部分はこの型におさめられるのではなかろうか。そうすれば余計な頭を使わなくて済む箇所が一つ減る。
頭使わなくて済む個所が減ったらダメだろｗ
いままでSQL書いただけでやってくれてたことを、全部自前で実装するんだぞ？
プログラムしないといけないことも増えるし、頭使うとこも増えると思うがな
>今でも一部はそういう作りはあるけど（汎用マスタ等）、それを可能な限り全てのテーブルでやる。（
いまのRDBMSでも、やろうと思えばそういう風にできるわけだ
でも普通はみんなそんなことはやらない。それが答えだと思うがな
メリットデメリットってのは、何に対してなのかはっきりさせてから評価してくれないか
このままだと頭使わない奴にとってメリットがあるって結論になるなｗ
217:NAME IS NULL
09/08/22 18:50:31 .net
>>216
>クラウドに適した形式だから、莫大なデータ量で通常ではハンドリングできなくて
>クラウドにするってならわかるが、クラウド考慮しないなら関係ないんじゃない？
最初は考慮してなかったが後からやっぱ必要だった！（見積もりが甘い？）って時にはメリットになると思います。
>ような状況で、パフォーマンス劣化は避けられるどころか余計悪くなると思うがな
SQLだとちょっと書き方変えるだけで10倍、100倍もパフォーマンスが違う事ってありますよね。みんながみんなSQLのエキスパートであれば問題ないのですが。それに比べればましかなと思ってます。もちろん処理内容によりますが。
>頭使わなくて済む個所が減ったらダメだろｗ
”余計な頭を使う箇所が減る”の間違いでした。
>メリットデメリットってのは、何に対してなのかはっきりさせてから評価してくれないか
メリット、デメリットは一般的なテーブル構造（先の例での前者）に対する、KVS的なテーブル構造のメリット、デメリットです。
>このままだと頭使わない奴にとってメリットがあるって結論になるなｗ
おっしゃるとおりで、このスレッドの趣旨には反しますがこれが一番のメリットと思います。頭を使う必要が少なければ、設計する人によって品質がバラバラという可能性が減るのではないのでしょうか（こういう構造で業務を満たせるのであれば）。
職人頼りなシステム開発が工業製品へと一歩前に進めるような気がします。
218:NAME IS NULL
09/08/22 19:11:02 .net
>>214
こんなことしなくても
みんなお前ほど頭悪くないから大丈夫だよ
219:NAME IS NULL
09/08/22 21:45:36 QZMSHBrB.net
開発効率が３０年前に逆戻りすることだけは確実だな…
220:NAME IS NULL
09/08/22 22:12:18 .net
馬鹿でも扱えるようにしたら色んなところで問題が出るってなぜわからんのだ。
カスレベルの人材でも働けるのは業界にとって大きなマイナスだ。
221:NAME IS NULL
09/08/22 22:19:41 .net
>>217
>職人頼りなシステム開発が工業製品へと一歩前に進めるような気がします。
逆だ。DBでやらない分アプリでやることが増えて、
プログラマの腕頼みになるだけだ
みんなが言ってるとおり、時代に逆行しているよ
222:NAME IS NULL
09/08/23 00:47:33 .net
カスは時給安くても働くから、時給高い熟練は不要になるしな。熟練にしか出来ない正規化とかの無駄な仕事が必要ｗｗｗ
単にDB使いこなせないからアプリでがんばるよ的発想だよな。
SQLを使ってたほうが遥かにパフォーマンスが良い現実。
これまでの歴史で今の状況に成ってるのを理解しないと。
オブジェクト廚が、オブジェクトDBなら便利になるぜとかのたまってたけど遅くて結局は消えてるし。
また馬鹿が湧いて、無駄な事を繰り返すのかな。
223:216
09/08/23 01:05:42 .net
>>217
>最初は考慮してなかったが後からやっぱ必要だった！（見積もりが甘い？）って時にはメリット
クラウドにしやすい、ゆえにスケールアウトしやすいメリットがあるっていうならわかるが
クラウド云々関係なしに ってのはお前の出した前提条件だが？
クラウドにしないでスケールアウトってんならデータ形式はあんまり関係ないだろ
あくまでクラウドに適してるのがメリットであって、スケールアウトは副次的な話だ
>SQLだとちょっと書き方変えるだけで10倍、100倍もパフォーマンスが違う事ってありますよね。
オプティマイザが入るSQL処理でさえ簡単にそれだけの差がでる。
自前アプリでその処理をやるわけだ
みんながみんなSQLのオプティマイザより賢くプログラム組めるのか？
>みんながみんなSQLのエキスパートであれば問題ないのですが。それに比べればましかなと思ってます。
みんながみんなプログラムのエキスパートであれば問題ないのですが。
それに比べれば(SQLの方がオプティマイザある分)ましかなと思ってます
>メリット、デメリットは一般的なテーブル構造（先の例での前者）に対する、KVS的なテーブル構造のメリット、デメリットです。
いやだからその２者をくらべたときに、誰にとってメリットデメリットだと？
ほんとに頭使わないシステム開発者にとってのメリットでいいのかよ
>品質がバラバラという可能性が減るのではないのでしょうか
減るかもしれんな。頭使わない安価粗悪な物によってまともな物が駆逐されてな
全体のレベルを下げるだけだ。品質低い方に統一してどうする
>職人頼りなシステム開発が工業製品へと
工芸品が工業製品になるためには、その職人の技が一般化されてることが必要なわけで
一部の人しかできないことを、だれにでもできる事だけで作ったとしてもそれは単なる粗悪品
一部の人しかできなかったことを、誰にでもできるようにしないと意味がない
そのために論理や技法があり、それを学んだり論議したりしてるんだよ
お前の主張は、
工業製品ならだれでも作れないとダメでしょ。
馬鹿にはシステム開発できないんで、システム開発は工業製品じゃないよね
ってことだ
224:NAME IS NULL
09/08/23 01:25:59 .net
>>214袋叩きワロタw
225:NAME IS NULL
09/08/23 02:35:18 .net
>>217
> みんながみんなSQLのエキスパートであれば問題ないのですが。
SQLのエキスパートはそんなにいらない。
もちろん、一見優秀そうなゴミでは何の役にも立たないが…。
226:NAME IS NULL
09/08/23 03:11:11 .net
おっ！最近レス多いですねぇ。いいじゃないですか。
スレの趣旨に合っていれば、DB技術者の意見を気軽に言い合ってもいいんじゃない。
レスが一つ入ると反応する方が結構居そうなので。
それぞれ扱ってるシステムの規模や影響、会社の風土とが違うでしょうから、
一概に良いか悪いかは言えませんが。
227:NAME IS NULL
09/08/23 04:28:10 .net
>>214
とりあえず、「KVS的な構造」といって後者はないだろう。
228:NAME IS NULL
09/08/23 07:11:42 .net
>>214
COBOLやRPGの時代にそういうテーブル設計しているのありました。
今SQLで実装している業務を試しにCOBOLで実装してみたほうがいい。
まあ、あの時代はある種夢の時代だったな。
「おれ５０００ステップのプログラム作っちゃったぜ！」と
無駄に長いプログラムを作れば儲かった頃だし。
ちなみにSQLより速い処理が組めるRPGやCOBOLのプログラマなんて
ツチノコ並みの珍獣だと思うが。
229:NAME IS NULL
09/08/23 10:56:13 .net
>>228
COBOLやRPGは知らないけど、「処理の速さ」という点では
プログラムでゴリゴリ書いたほうが良いこともある
DB側（リレーション、制約、ストアド、SQL）に機能を持たせる
一番のメリットはやはり保守性だろう
230:NAME IS NULL
09/08/23 13:45:30 .net
サーバーでやるかクライアントでやるかの違いだろうね。>>214
メリット・デメリットは>>214の他に
メリット
自分で最適化できる。
デメリット
サーバー/クライアント間のデータ転送量が多くなる。（高速LANなら無視できる）
かな？
231:NAME IS NULL
09/08/23 14:32:06 .net
>>229
ストアドの速さに勝てるの？ありえなくないか？
DBに機能をもたせると保守性は落ちるとおもうが。
232:NAME IS NULL
09/08/23 15:05:03 .net
ストアドにしたからといっては飛躍的に高速になるわけではない。
233:NAME IS NULL
09/08/23 16:21:00 .net
処理の種類によるけど遅くなることはないだろｗ
234:NAME IS NULL
09/08/23 21:31:35 .net
データをどこに持っているかにもよる
DBMSに格納されているなら、そのDBMSに特化したストアドより早く外部プログラムが
実行できるとは思えない。
ストアドでも外部プログラムでも、ロジックは同じように作れるわけだからな
保守性については、システムの保全とか改修のしやすさとか、
何を主眼として保守性とするかによって変わると思うが
235:NAME IS NULL
09/08/23 21:33:12 .net
遅いクエリーはストアドであっても遅い
236:229
09/08/23 21:54:10 .net
>>234
「保守性」っていうのは、改修の効率の良さ、再利用性の高さ、
論理的整合性の保ちやすさなどをひっくるめた意味で書いた
曖昧な定義でごめんね
237:NAME IS NULL
09/08/24 00:12:00 .net
>>235
だったら外部プログラムならなお一層遅いだろ？
論理性がまったくないようだけど本業のほうは大丈夫？
238:NAME IS NULL
09/08/24 04:53:27 .net
他のクラウドで処理したデータも拾ってこなきゃならんから遅いだろうね。
全クラウドが、光ファイバーで繋がってて、膨大なクエリ処理しても、遅延は最大でも数百ナノ秒だぜってわけじゃないだろうし。
239:NAME IS NULL
09/08/24 06:28:52 .net
サーバーサイドの処理と限定して話をするけど
>COBOLやRPGは知らないけど、「処理の速さ」という点では
>プログラムでゴリゴリ書いたほうが良いこともある
SQLの実行エンジンの最適化処理でブロックI/Oやらをやられると
プログラムで１行FETCHや1行WRITEしている
これらの言語は太刀打ちできないワケだが。
そりゃ、OSのAPIを直打ちするレベルになれば別だけどな…。
今時のRDBMSは統計情報を元にSQLの実行プランを最適化するが、
一般プログラマにコレを越えるプログラム組めって言っても
かなり辛い。
むろんプログラマが書いた方が良いこともあるだろう。
どんな例か知らんけど。
240:NAME IS NULL
09/08/24 17:29:10 .net
なんかストアドよりインデックスが速いよスレの二番煎じな流れだな。
詭弁のガイドライン
2.ごくまれな反例をとりあげる
「だが、RDBよりプログラマが書いた方が良いこともある」
15.新しい概念が全て正しいのだとミスリードする
「クラウドで使われているKVSを使わぬ限りシステム構築に明日はない」
241:NAME IS NULL
09/08/24 21:15:01 .net
>>239
> 今時のRDBMSは統計情報を元にSQLの実行プランを最適化するが、
> 一般プログラマにコレを越えるプログラム組めって言っても
> かなり辛い。
腐るほどあるよ。
242:NAME IS NULL
09/08/24 22:02:49 .net
>>241
腐ったSQLを平気で書くプログラマのプログラムを想像した。
北へと旅に出たくなった・・・
243:NAME IS NULL
09/08/24 22:27:07 .net
>>241
腐るほどある。と言われても、AS/400みたいなマシンで無い限りSQLと他の言語の
速度比較とかは出来んはずだが、AS/400なんざ普及していないだろ。
RDBMSでSQL使うよりもC++でコレクションクラスを使った方が速いよ、なんて
議論無意味だしな。
244:NAME IS NULL
09/08/24 23:03:22 .net
ちょっと議論の的がズレていってない？
>>214は、処理の速さについては
メリットとしてもデメリットとしても挙げてないんだし
問題の本質はそこじゃなくない？
245:NAME IS NULL
09/08/25 00:03:36 .net
単に屑PGが適当に組んでも速度が出ないと困るってか？
SQL覚えるのが一番の近道。
246:NAME IS NULL
09/08/25 02:06:15 .net
>>244
問題の本質とは?
確かに、214さんが処理の速さについては
言及しておられないようです。
ただ、私見ですが214さんがSQLを良く
理解しておられないのは感じます。
開発側とすれば画面に表示する情報を
1SQLで取得できるように設計するべきで、
その方が楽だと思いますがね。
遅かったら運用のせいにも出来るしね。
>>242
まぁ、そんなこと言わないで、がんばって行きましょ。
分かるけどね…
247:NAME IS NULL
09/08/25 02:50:49 .net
>>246
クエリの知識しかないアプリ屋のくせに
えらく上から目線だなオイ
248:NAME IS NULL
09/08/25 03:07:51 .net
>>247
いえいえ、とんでもない。
そんなお褒めの言葉、
こちらこそありがとうございます。
249:NAME IS NULL
09/08/25 04:14:41 .net
単に複雑なSQL組めない屑PGだろ。
select *だけで全部済む様にしたいとか言いそうだし。
まるでオープン系コボラｗｗｗ
250:NAME IS NULL
09/08/25 07:07:25 .net
>>246
情報を1SQLでとれないってのは、どっちが？
251:NAME IS NULL
09/08/25 09:54:39 /mfME5w3.net
まだまだＤＢのオプティマイザはアホだから、実行プランやトータルコスト考えながらクエリやＰＧ書けない奴はダメだな。
下請けソフトハウスのアプリ屋なんてそんな奴ばっか…
何のためにキーやインデックスがあるのかちょっとは考えてくれよ
252:NAME IS NULL
09/08/25 10:08:13 .net
>>249
複雑なSQLはそれ自体のメンテが大変かもね。アクセスパスは不変じゃないし
無理矢理SQLに詰め込まれても、常に効率が良いとは限らない。
要はバランスだと思う。ちょっと頑張ればSQLのみで済むからSQLに詰め込もうとか、
どうせUAPで処理必要なんだから、SQLでは無理せずにUAP側にロジック入れようとか
いろいろ状況もあるだろうし、適材適所で臨機応変に使って行きゃ良い。
まぁ同一システム内でばらばらだと困るので、ある程度の取り決めは必須だが。
ところで、組み込みSQLで select * 使う人はいないはずだけど…。
さすがにそんな人にはコード書かせないでしょ。
253:NAME IS NULL
09/08/25 14:02:27 .net
>>252
>ところで、組み込みSQLで select * 使う人はいないはずだけど…。
>適材適所で臨機応変に使って行きゃ良い。
254:NAME IS NULL
09/08/26 02:19:56 .net
>>250
こんばんは。246で発言した者です。
どちらかとの御質問ですが、どれとどれのことか分かりませんでした。
私が不出来なもので申し訳ございません。
先に私が発言した主旨としては以下の様になります。
開発側の人としては画面に表示するデータが1SQLで(select * は論外ですが)、
もちろんジョイン、必要であればサブクエリーを使用し取得したデータ群を、
使用する言語によったデータセットで使った方が楽なのではないかと思った次第です。
(それぞれの環境次第なので一概に言えないのは分かっております。)
214さんはそれぞれ必要な都度SQLを発行し、表示するデータを構築される
ように思われたので上記の様な発言を致しました。
ただ、214さんがデメリットでそのことを挙げておられることを見過ごしておりました。
申し訳ございません。
先に私が発言しました「214さんがSQLを～]の発言は撤回させてください。
その後の「遅かったら運用の～」は私の過去に受けた経験から発言したものです。
開発より、運用に従事している期間が長いものですから。
>>247
お気を悪くされましたらお詫びいたします。
255:NAME IS NULL
09/08/26 07:13:53 .net
遅いのは開発側、というよりDB設計者のせいだよ。
256:NAME IS NULL
09/08/26 15:34:09 .net
>>254
そもそもの発端はKVS的な設計はどうだろうって論題で、
KVS的な設計では１SQLでデータ取るのは不可能だって話だ
それを前提にしてるから
>214さんはそれぞれ必要な都度SQLを発行し、表示するデータを構築される
ようになってるわけで
１SQLでデータ取れるような設計しろってのは、議論の前提がおかしいだろうが
>>255
その言い方だとDB設計者は開発側の人間じゃないように聞こえるが
257:NAME IS NULL
09/08/26 16:03:01 .net
>>214は、この設計を既存のRDBに割り当てて使うって言ってんのかな。
それなら駄目すぎて話しにならんと思うが。
258:NAME IS NULL
09/08/27 00:00:34 .net
そもそも「KVS的」といって>>214みたいなのが出てくるのがおかしいし、
あれが1SQLでデータが取得できないというのも変。
いったいオマエラ何の議論をしているの？
259:NAME IS NULL
09/08/27 00:27:25 .net
もう>>252がベストアンサーって事で良くね？
260:NAME IS NULL
09/08/27 07:01:17 .net
>>259
自演乙
261:NAME IS NULL
09/08/29 00:37:35 .net
具体的に1sqlってどこまで許すのか示されてないしな。
まあdb知らない人みたいだから無茶言いそうだが。
262:NAME IS NULL
09/09/10 16:45:52 .net
こちらの方がおっしゃっている設計指針についてどう思われるでしょうか。
URLﾘﾝｸ(masuda220.jugem.jp)
・テーブルの役割・用途は一つ
・（極力？）データに対する更新・削除は行わない
など
なるほどとも思うのですが、役割に応じて分割すると
あまりに細かく分割しすぎて見通しが悪くなりそうな気もしますし、
データの更新・削除を認めないのは冗長かつ非効率な気もします。
実務による、というお答えが返ってきそうですが、一般的な設計指針として
ご意見をお聞かせいただければ幸いです。
263:NAME IS NULL
09/09/10 23:30:01 .net
>>262
モデリングの手法としては合ってると思う
ただこの後の工程で、パフォーマンスや効率性を考慮して
冗長化、非正規化することは必要だけど
>あまりに細かく分割しすぎて見通しが悪くなりそうな気もしますし、
モデル上は、細かくテーブル分割してあるほうが分かりやすいよ
テーブル名とリレーション見るだけで何を表しているか分かるからね
>データの更新・削除を認めないのは冗長かつ非効率な気もします。
「データの更新・削除を認めない」って書いてあるところが見つけられなかったんだけど、
どこから引用したの？
264:262
09/09/11 06:59:45 .net
>>263
レスありがとうございます。
書籍などではここまで言及してあるものを読んだことがなかったので、
どうなんだろうと思っていたのですが、正しい手法なのですね。
（「正しい」という表現が適切かわかりませんが）
> 「データの更新・削除を認めない」って書いてあるところが見つけられなかったんだけど、
> どこから引用したの？
これは少しコメントを端折り過ぎました。
「テーブル設計 データモデリングのエッセンス（２）」などに書かれているのですが
> ビジネスイベントは一度作成（インサート）したら、後から、更新や削除はしない。
> このテーブルに許される操作は、インサートと参照のみにする。
とあります。
また、ビジネスリソース系のテーブルについても同様の方法を取ることもあると書かれています。
ここに書かれている業務システムの例に合わせて言えば、
受注テーブルは最新の状態にしておき、更新や削除の記録が必要ならば別テーブルにログとして保持する。
受注テーブルにはキャンセルされた受注や変更前の受注は保持しない。
というのが主流だと自分は思っていました。
また、導出テーブルをトリガで作成するという手法も初めて知りました。
265:NAME IS NULL
09/09/12 11:16:27 .net
>>1
1. Excelのワークシートと勘違いしてるから。
2. 設計＆指揮者がコードに関心があるのにデータに関心がないから。
レベル低すぎ？
266:NAME IS NULL
09/09/12 11:25:44 .net
むしろコボラ上がりが、繰り返し項目を使いたくって、
正規化なんか理想論だ、実際は性能が落ちる原因だとか
トンデモ説を信仰している（ふりをする）からじゃん
267:NAME IS NULL
09/09/12 11:35:27 .net
コボラ上がり(かつRDBを知らん)奴なんて数えるほどだろ。
それよりも、RDBしか使ったことがなくても実はわかってない、ってのが
圧倒的じゃないか？>>265の言うexcelと勘違いしてるようなのとか。
268:NAME IS NULL
09/09/12 12:27:58 .net
ファイル設計の延長くらいにしか考えてない奴は多いな
269:NAME IS NULL
09/09/13 03:40:03 .net
コボルの本読むとそんな感じだしな。
正規化なんて全く記述無し。
270:NAME IS NULL
09/09/13 11:52:21 .net
そりゃ正規化はRDBでしか必要ないからな！固定長レコードで正規化
してもテーブルの連結がめんどくさかったら意味ねえ！
271:NAME IS NULL
09/09/13 12:47:27 .net
そういえば昔、上から全項目を固定長にしろとお達しがあって、嫌々やったら速度が上がった
（つーか、負荷テスト後もあんまり性能が落ちない）DBがあったなｗ
272:NAME IS NULL
09/09/13 13:25:37 .net
その昔の経験って、今も成り立っているのかな？
そこが曖昧なまま薦められても困るのよね。
273:NAME IS NULL
09/09/13 16:04:54 .net
今は一般的にはtext型みたいなのが一番速い
長さチェックも空白詰めもしないから
ただしOracleだけは固定長が速い
274:NAME IS NULL
09/09/13 18:09:22 .net
>>273
逆だろ。
Oracleには固定長の文字列型なんてないはず。
最小長と最大長が等しい可変長文字列を、便宜上固定長文字列型って騙ってるだけ。
まぁほとんどのDBMSで、列サイズが固定であるが故の速度的メリットは大きいから、
Oracleでも可変長文字列を入れていた項目を擬似固定長に変更した時の速度向上は
見込めるかもしれないって程度。
275:NAME IS NULL
09/09/13 18:15:13 .net
> 固定長の文字列型なんてない
> 列サイズが固定であるが故の速度的メリットは大きい
矛盾してないか？ 最初の文は、内部的には可変長文字列の特殊設定だと
言っているような気がするんだが。
276:NAME IS NULL
09/09/14 04:23:37 .net
CHAR型って固定長じゃないのか
277:NAME IS NULL
09/09/14 13:32:43 .net
DB2も固定長の方が速いけど。
text型みたいなのはある程度まではそこそこ速いけど、
ある閾値を越えると急に遅くなったりするので
処理系しだいだろうとは思う。
つか、Oracleとかの「こうすると速い」系のネタは都市伝説が多いよなー。
商品コードとかの長さが決まっている項目なら固定長で、
備考の様な長さが不確定な部分は可変長と素直に設計していけばいいのでは？
「速いから固定長」とかはなんか違うだろ。
「考えるのが嫌だから全て可変長」の方がまだスジが通っている。ｗ
278:NAME IS NULL
09/09/14 14:32:30 .net
>>275
Oracleは内部的には全部可変長扱いだって聞いたことがあるからそのことじゃね？
DB2とかだと内部的にCHAR型とVARCHAR型は別扱いなので、きちんと使い分けた
方が望ましいけど、Oracleはちょっと変態なのでムリにCHAR型にする必要はないと。
(全ての？)列サイズが固定で速くなるってのはまた別の話で、データの格納と言うか、
表領域の使われ方のことではないかと。まぁどっちかって言うと行サイズだが…。
HiRDBだとFIX表ってわざわざ宣言したりするね。
279:NAME IS NULL
09/09/14 17:34:21 .net
オラクルは昔と今では、だいぶ違うけどな。昔の経験なんて引きずってたらそれこそコボラ状態。
280:NAME IS NULL
09/09/14 18:09:35 .net
DB2とかは固定長・可変長は分けて処理するしNOT NULLな制約も考慮して
適切な設計にあわせて実スピードは上がっていく。
逆に設計がアレだとあんまし速度はでないRDBMSだな。
Oracleも昔の都市伝説と言うか、昔のヘンテコ小技を今のVerに持ち込むのは
ヤめてくれって感じるな。
普通に設計して普通にSQL書いてください。
281:NAME IS NULL
09/09/15 21:32:23 .net
Oracleの仕様がヘンテコだからな
282:NAME IS NULL
09/09/16 10:24:42 .net
何でOracleはヘンテコな仕様なのに普及したんだろうね？
M$やらIBMやらが注力しなかったからかな？
283:NAME IS NULL
09/09/16 13:25:20 .net
当時は癖のある DB しかなかったよ
284:NAME IS NULL
09/09/16 17:52:21 .net
おかげさまで今でもうっかり(+)とかやっちゃうぜ
285:NAME IS NULL
09/09/16 20:18:06 .net
>>282
ごめんね、キミの大好きなOracleを馬鹿にしちゃってｗｗｗ
286:NAME IS NULL
09/09/19 02:03:14 .net
今日もアホなテーブルとクエリを見てゲンナリした
○○○○○は遅いねってお前の設計が（ry
287:NAME IS NULL
09/09/19 18:16:28 .net
>>282
性能がいいものが売れるとは限らない。
大人の事情というのがあるんだよｗ
288:NAME IS NULL
09/09/20 07:47:11 .net
まあそれほどまでに当時のSQL鯖/サイベースとDB2が糞だった訳で。
オラクルの出現で競争が生まれ、それらも今やかなりマシになった功績は大きい。
周りのヘンテコDB仕様に合わせて客取り込んでいって成長したから、今でも名残が残るのはしょうがない。だんだん洗練してヘンテコ仕様もろとも下位互換は切ってくだろうけど。
289:NAME IS NULL
09/09/20 08:40:22 .net
そもそもまともに使えるRDBMSを最初に売り出したのがOracle。市場での競争が始まるのが
後発のInformix、Sybase、Ingres等が現れてから。DB2もあったけど、当時のIBMはIMSの
商売の方が重要でDB2はほとんど力を入れておらず、顧客がRDBMSを必要とする場合に
程度でSymfowareやHiRDBのような扱い。
MSのSQL Serverや、他社OSでも使えるDB2 UDB(の原型)が現れて現在のような競争状態に
なるのはそれよりもさらに後。
290:NAME IS NULL
09/09/20 11:46:31 .net
過去のことはいいから現在一番ましなRDBはなんなのさ。
291:NAME IS NULL
09/09/20 12:10:29 .net
今の製品はだいたいみんなまともだろ？あとはどのポイントを重視するか。
総合1位なんて点数のつけ方で変わるよ。
292:NAME IS NULL
09/09/20 12:13:25 .net
君の重視するポイントでよろしく頼むよ。
293:NAME IS NULL
09/09/20 12:17:20 .net
製品比較は別スレでやれ。
294:NAME IS NULL
09/09/20 12:23:38 .net
>>292
じゃあSQLiteが一番だな。これで満足か？
295:NAME IS NULL
09/09/20 12:31:17 .net
どのポイントを重要視したの？
296:NAME IS NULL
09/09/20 13:31:27 .net
サポート契約してるとOracleって結構不具合とかあるんだなぁ、
って感じますが、他のRDBMSでもあるんですかね？
297:NAME IS NULL
09/09/20 21:30:20 .net
DB2も不具合はある。
Oracleよりは少ないが、それだけDB2普及していない証明でもあるような希ガス。
別に不具合あってもいいんだけどさ、それの対応がタマに「我慢汁」とか「それはOSの不具合です」
とか解決に繋がらない回答を貰うと、「あー、Postgresでいいじゃん」とか思うな。
298:NAME IS NULL
09/09/20 23:21:46 .net
DB2は、「なんでいまだにこんなバグが？」と思うようなのがけっこうあるね。
インスタンスダウン→「次のFPで修正されます」のコンボに何回遭遇したか。
299:NAME IS NULL
09/09/21 00:11:44 .net
DB2ってiSeriesは鉄なみの硬さがあると思うが、それ以外のプラットフォームは・・・。
Oracleもよくインスタンス落ちるがiのDB2は落ちた事がない。
これもIBMの中の人とガチで仲良し(?)レベルで会話できる人が少ない性もあるんだろうな。
300:NAME IS NULL
09/09/21 12:39:41 .net
単にasはろくな処理してなくて使い込んでないから固く見えてるだけじゃ。
全部as内完結で、不安定になる様な秘穴を突けなくしてあるとも言うが。
オラは、いろいろ弄れる割に秘穴を突いてしまう確率が高くなるだけ。
ちゃんと組めばド安定で運用出来るよ。RACも組めるし。
ポスグレはサポート無いから、業務では選択肢に無いな。
マイエスはオラクルがサポートしてくれるなら、これから使う鴨田が。
301:NAME IS NULL
09/09/21 15:08:44 .net
結局なんだかんだ言いつつサポートの有無でプロダクトを選ぶという矛盾が
別にサポートあったって落ちたときに損害補償してくれるわけでもないんだし
金払うだけ無駄なのがサポートだぜ
パッチの提供なんて逆にPostgreSQLなんか速攻で修正されて出てくる
オープンソースだから原因も即バレで、仕様ですと隠される事もないしな
302:NAME IS NULL
09/09/21 15:42:44 .net
矛盾つーか、セルフサポートできるんならOSSも選べるってだけだろ。
一応サポート契約していれば、どんな障害/質問に対しても「マニュアル
読め」以上の何らかの回答を一定期間内にしてくれるし。
303:NAME IS NULL
09/09/21 16:42:14 .net
んでその回答って役に立つのか？
PostgreSQLの構築/運用実績あるSIにやって貰った方が
Oracleに無駄に500万払い続けるよりマシな気がする
304:NAME IS NULL
09/09/21 17:14:32 .net
おめーら別スレでやれよ
305:NAME IS NULL
09/09/21 17:54:54 .net
>>303
サポート契約してれば何か起きたときの事故対策会議で「サポートに問い合わせ中です」
って言える。もちろんその後は「原因不明なので再現待ちです」って逃げる。
DBMSに限らず、商用OS等でも良くあるが…運用担当者が泣く黄金パターンだよな。
まぁ実際問題として、サポートにまともな回答もらえるとはだれも思ってないんだよ。
ただ、実質使えないサポートであっても、それを望んでいる客がいるのもまた事実だから、
そういう提案してしまうのはしょうがないと思う。
306:NAME IS NULL
09/09/21 18:55:49 .net
>>303
そりゃ役に立つ人はいるだろうさ。
当然、Postgresでシステム構築したとしても、Postgresのサポートを
必要とする場合だってあるだろうし。
307:NAME IS NULL
09/09/21 23:09:15 .net
＞PostgreSQLの構築/運用実績あるSIにやって貰った方が
＞Oracleに無駄に500万払い続けるよりマシな気がする
ぶっちゃけその通りだけどな。
漏れの中ではOracleは言うほどマシなRDBMSじゃないと認識している。
Oracleが必要な業務があるのは事実だろうが、多くの導入例では
「Oracleはいらんだろ」的な納品されている現場は多い。
308:NAME IS NULL
09/09/22 09:05:44 .net
しかしPostgresのシステム構築やサポートできるSIなんて
付き合いある範囲じゃ見当たらないな。
309:NAME IS NULL
09/09/22 11:04:07 .net
オープンソースのDBすら自分で構築しようとしないエンジニアって・・
310:NAME IS NULL
09/09/22 11:39:52 .net
それは「システムを自分で開発しないエンジニアって」と言っているに等しいぞ。
内製するかどうかとオープンソースかどうかなんてあんま関係ない。ただ、開発を
SIに任せる場合にOSSで受けてくれる業者がほとんどないというだけ。
311:NAME IS NULL
09/09/22 12:29:28 .net
>>308
知り合いかどうか知らんがPostgresはNTTやらNEC系はやってるな。
別に漏れもヤれと言われれば並みのOracle程度には出来る。
つか漏れも社内のなんちゃってテスト環境用にはDreby使っている。
312:NAME IS NULL
09/09/22 12:56:37 .net
まぁ会社としてサポートするとなると、スキルのある要員の継続確保が問題になるな。
俺的には別に特殊なスキルが必要とは思えないのだが、商用/フリーに関わらず
調査すら出来ない人間ってのが意外といるわけで。
313:NAME IS NULL
09/09/22 14:38:29 .net
OSSは裾野の部分がまだ弱いからねぇ。研修制度とか、サードパーティの層の厚さとか。
Linuxは大メーカー自身が手がけるようになって大分よくなったけど。
314:NAME IS NULL
09/09/22 15:22:04 .net
オープンソースのサポートなんて遣るくらいならオラクル保守入って丸投げのほうが楽だな。
オープンソースで手厚いサポートできるようなスキルある香具師雇うなら、オラクル以上に金かかりそうだw
オラクルに損害賠償請求する馬鹿企業は居ないが、個人に損害賠償してくる馬鹿企業は山ほど居るだろうし。
315:NAME IS NULL
09/09/22 20:15:18 .net
>>314
凄い妄想だな。
底辺のオマエには知らん世界だろうが、Oracle使った案件でも契約書に
損害賠償跳ね除ける文面が契約事項としてあげてあるベンダーがほとんどだが。
316:NAME IS NULL
09/09/23 06:02:53 .net
Postgresにサポートが無いとか、お前らシロート？
317:NAME IS NULL
09/09/23 09:08:19 .net
比率で言うならOracle信者ほど素人が多いのは不思議な現実。
サポートが心の拠り所らしい。
318:NAME IS NULL
09/09/23 11:28:58 .net
ポスグレで自分で面倒見るのは自殺行為なんだよ。
319:NAME IS NULL
09/09/23 15:25:24 .net
別に「Oracleはインタンスが絶対に落ちなくてサポートが満足な製品で漏れは一度も苦労した事ない」
と言える製品ならそれはそれで構わんよ。
漏れはそんなOracle見た事ないが。年に１・２回はｲﾐﾌﾒｲに落ちる。
ただまあ、漏れの経験でｲﾐﾌﾒｲに落ちた場合サポートに問い合わせても「原因不明です。OSかハードに問題があると思われます」
の逃げ口上が出て終わりなんで、PostgresだろうとOracleだろうと能力のない人間が構築したシステムは
どれも自殺したくなる。
むしろ、上の発言で出てきた問題を全てIBMに投げられるiSeries、もしくはOSSだからと言う理由でPostgresを
選んだほうがラクになれる。
320:NAME IS NULL
09/09/24 07:36:57 .net
データやSRAは独自パッケージまで出してるのに
321:NAME IS NULL
09/09/25 13:21:23 .net
設計
322:NAME IS NULL
09/09/25 16:04:56 .net
今までで一番酷かったのがLinuxの8iだな
2000万払った挙げ句、使用は自己責任でとか言われたｗ
323:NAME IS NULL
09/09/26 15:26:21 .net
Linuxの8iって人柱Verだった頃のじゃね？
まあ、未だにそれで動いているトコはあるんだろうけど。
324:NAME IS NULL
09/09/26 20:34:26 .net
要するに人柱バージョンを2000万でうりつけてるのかｗ
325:NAME IS NULL
09/09/26 21:00:40 .net
値段は規模にもよるから、Linuxで8iで2000万が高いか安いか判断が難しいが。
HP-UXの8でもそれくらい取るベンダー見た事あるし。ただイニシャルはともかくランニングコストは
あんまし安くなかったが。年600万くらい。
Linuxの8iは自己責任と言うからにはランニングコストは０なんだろ。w
DB2(iSeries)だとイニシャルは下は300万で上は２億くらいの幅でランニングは100～600万くらい飛んでいく。
326:NAME IS NULL
09/09/27 03:34:04 .net
8iの頃はソラリスが鉄板だったので、リナックスなんて選んだほうが自殺行為なだけ。
東証がポスグレ採用なんて無謀な事はしないのと同じ。
IBMに丸投げ出来るぐらいの資金が有るなら、日電や不実に丸投げしてオラクルの面倒見てもらえるけどな。
うちはRACだけど意味不明に落ちてもリカバリは出来る仕組みにしてるよ。
そもそも絶対に落ちないなんてあり得ないし、ソフトのバグが無いのも信用してない。PGなんてバグ入りの欠陥品しか作れないし。製造業の品質管理に比べたら認識が甘過ぎるよ。
逆に、ポスグレは絶対落ちなくてサポートも満足と保証されてるの？
２億の案件でポスグレで組んで、損害賠償なんて喰らったら人生終わるなw
327:NAME IS NULL
09/09/27 04:40:49 .net
oracleは絶対落ちないなんてありえない前提なのにpostgreには要求するのかｗ
どんなdbを使おうがフェイルセーフな構成にすればいいって自分で答えだしてるじゃん
328:NAME IS NULL
09/09/27 19:50:33 .net
>>326
なんかあんまし大型案件やった事ないみたいなのでコメントだが。
規模と傾向もあるが基幹系ならIBM(i)とその他のベンダー＋Oracleの組み合わせだとIBMの方が半額くらいのコストで開発・運用が可能だ。
無論、Oracleの方がコスト安いケースもあるが、「IBM＝高い」と言うのは思い込みだ。
ある程度以上の資金がいるのは事実だが、>>326の意見は「安物買いの銭失い」な思考だ。
そして東証もけっこう落ちてるじゃねーかｗ
329:NAME IS NULL
09/09/27 20:40:49 .net
いいよな。天下りで仕事もらえるようなところは。
東証を落としてもお咎めなしだぜきっと。
330:NAME IS NULL
09/09/29 01:30:04 .net
逆にIで落ちてたら大変なんじゃねw
331:NAME IS NULL
09/09/30 01:32:27 .net
何故データベース設計は軽視されるのか？
332:NAME IS NULL
09/09/30 05:39:47 .net
痛い目に会うような複雑なシステムじゃないから or ( 痛い目は末端がくらって表に出ない and それが痛い目だと気が付いていない )
333:NAME IS NULL
09/09/30 16:53:59 .net
ちゃんとコスト計算が出来るまともなエンジニアが皆無。
334:NAME IS NULL
09/10/09 23:00:06 .net
アプローチ使ってるけど、アプリの使い方じゃなくて、データベース設計の初心者本てなんかないかな
335:NAME IS NULL
09/10/10 17:22:36 .net
>>334
デマルコ読め
336:NAME IS NULL
09/10/11 17:53:45 .net
URLﾘﾝｸ(www.amazon.co.jp)
これ読めばいいの？
337:NAME IS NULL
09/11/24 00:12:10 .net
賢者に聞いていいですか？
たとえば、２ｃｈとか「PC等」→「プログラム」→「【PHP】CakePHP」→「レス」って構成ですよね。
これってどういうDB設計になってるんですか？
実務経験がないのでわかりません。
「PC等（カテゴリID）」→「プログラム（カテゴリID＋サブカテゴリID）」→「【PHP】CakePHP（サブカテゴリID＋スレID）」→「レス（スレID＋レスID）」
→「デスクトップ（カテゴリID＋サブカテゴリID）」→「cpuをとっかえたい（サブカテゴリID＋スレID）」→「レス（スレID＋レスID）」
って感じですか？
１つのデータベースに、テーブルを1000個とか作ることとかあるんですか？
その場合、テーブルの名前を特定して探しにいく方法でしょうか？
338:NAME IS NULL
09/11/25 01:58:52 .net
2chはdbじゃないので(ry
ｽﾚﾘﾝｸ(db板)
SQL総合案内スレッド
ｽﾚﾘﾝｸ(db板)
姉歯DB設計
339:NAME IS NULL
09/11/25 20:11:39 .net
マジ？2chはファイル記憶なの？
340:NAME IS NULL
09/11/25 20:47:50 .net
普通に考えれば2chはファイルだし、事実そう。
RDBで実装する意味が解らん。
341:NAME IS NULL
09/11/25 23:19:21 wSmHcJvY.net
2ｃｈの量でもファイル入出力に耐えれるものなのか。
人間のイメージなんてちっぽけなものなんだな。
342:NAME IS NULL
09/11/25 23:34:29 .net
>>341
実務経験がないから仕方ないのかもしれんが、
RDBに不思議な幻想を持つのはヤめた方がいい。
2chの場合は要求される仕様が「追記オンリー、更新は基本なし、当然削除もなし
発言は1000もしくは512KB(板によるが)で、ブラウザを使うユーザーにはhtml変換し
専用ブラウザはdat直読み。
そして圧倒的な書き込み&ＰＶときたら並のRDBMSでは即死する。
343:NAME IS NULL
09/11/25 23:42:32 wSmHcJvY.net
ありがとう。ファイル入出力の方がいいんだね。
たしかに、DBは偉大ってイメージがあるかも。組み込みエンジニアだからDBに縁がなくて。
twitterと2chは同じようなものかと思ったの。twitterはDBだよね。メンバーの紐付けあるし。
無数にレコードが追加されるからどういう設計なのかなーって。
344:NAME IS NULL
09/11/26 00:17:44 .net
twitterは細かい事は知らんが、最初Rubyとデータベース使って結構落ちてなかったか？
そりゃ2chだってタマに落ちるけどな。
345:NAME IS NULL
09/11/27 00:30:39 .net
ファイル入出力のほうがいいというのは間違い。ISAMファイル直弄りのコボラーに成りたいならともかくw
ツイタはしばらくすると消えるからdbのほうが向いてる。
潤沢な資金力さえ有ればdbでも捌けると思うけどね。
東京証券取引所の売買銘柄数や売買高でもちゃんとdbで注文捌いて約定処理が出来てるし。
組み込みでも携帯のアドレス帳ぐらいはdbで作ってあると思うよ。テキストファイルで管理だと大変だし。
当然組み込み用のdbもある。
ｽﾚﾘﾝｸ(db板)
RDBMS比較総合スレ 【サーバ】
ｽﾚﾘﾝｸ(db板)
MSDEよりいいDB、ありませんか?
346:NAME IS NULL
09/11/27 00:59:55 kLScCozf.net
twitterの設計の想像がつかない。
347:NAME IS NULL
09/11/27 02:15:50 .net
＞ファイル入出力のほうがいいというのは間違い。ISAMファイル直弄りのコボラーに成りたいならともかくw
（略
＞潤沢な資金力さえ有ればdbでも捌けると思うけどね。
金かければなんでも出来るだろ。
コストパフォーマンス無視して「ＤＢの方が向いている」なんて・・・。
2chのサーバーと同じ導入コストでRDBMSを用いて実装し、
2ch以上のパフォーマンス出してから語ってくれ。
そして東証も派手に落ちてニュースになったんだが。
あれを「ちゃんとdbで注文捌いて約定処理が出来てるし。」とコメントできる神経が凄いな。
348:NAME IS NULL
09/11/27 02:49:00 .net
お前らDBDB言ってるけどRDBMSのことだろ
テキストファイルだってなんだってDBはDBだ
349:NAME IS NULL
09/11/27 14:26:38 .net
twitter は、元は Ruby on Rails じゃなかったっけ。今は知らないけど。
RoR は O/Rマッパーに ActiveRecord 使ってるから、多分バックエンドの DB は
RDBMS だとは思うけど、何を使ってるかまでは調べてない。
そういえば、ニコニコ動画のコメントサーバはバックエンドに MySQL 使ってるね。
更新頻度の高いテーブルと低いテーブルに選別して、InnoDBとMyISAMを
使い分けてると、どこかに書いてあった。あと memcached だったかの
キーバリューストアも併用して、パフォーマンス稼いでたはず。
ってか、この辺の話はDB設計と言うより、アーキテクチャ設計の話だね……
350:NAME IS NULL
09/11/27 14:40:31 .net
むしろバックエンドにDB使ってないシステムなどまずない
351:NAME IS NULL
09/11/27 20:55:10 .net
とりあえず、>>350が利用している2chはRDBは使っていない
352:NAME IS NULL
09/11/28 03:36:12 .net
いやだからRDBMSじゃなくてDBは使ってるだろ
テキストファイルに書き出すのだって独自DBなわけで
353:NAME IS NULL
09/11/28 07:31:54 .net
逆に東京証券取引所の規模でテキストファイルのほうが無茶だろ。
銀行の取り付け騒ぎで人が大量に押し寄せてATM操作するとISAMでがんばってるホストが堕ちるのと同じ。
テキストファイル自体はdbじゃないだろ。
354:NAME IS NULL
09/11/28 09:10:00 .net
＞ATM操作するとISAMでがんばってるホストが堕ちるのと同じ。
ナニ言ってんだ？コレ？
タイムアウトやら領域が足りなくてトランザクションがコケた事とISAMの関連が意味不明。
ISAMでなく、普通のRDBでも帯域＆領域足りなきゃ落ちるのは一緒なんだが。
テキストを独自ＤＢと言うのは痛いが、引き合いにホストを持ち出してトンデモ理論展開スナ。
355:NAME IS NULL
09/11/28 12:06:43 .net
>353-354
データベースの定義 ＠ Wikipedia
> 特定のテーマに沿ったデータを集めて管理し、容易に検索・抽出などの
> 再利用をできるようにしたもの。
> 狭義には、コンピュータによって実現されたものを言う。
広義には記録メディアが紙だろうが石版だろうがDBはDBなんだぜ。
テキストファイルは言わずもがな。
356:NAME IS NULL
09/11/28 14:30:13 .net
小学生は2chなんかせずに外で遊んでこいよ。
357:NAME IS NULL
09/11/28 15:04:45 .net
とりあえずテキストファイルがＤＢと言うヤツは
ニコ動とか東京証券取引所のシステムを「石版」で構築してから語ってくれ。
358:NAME IS NULL
09/11/28 15:22:55 WYkIZs31.net
MySQL CSVストレージエンジン・・・
359:NAME IS NULL
09/11/28 15:52:18 .net
テキストファイルだけならDBじゃないけどプログラムとしてテキストファイルを使うなら
それを読み出してデータストアとして利用するロジックがあるんだからDBと言えるだろうに
ただ石板は情報システム的にDBにはなり得ないから例えが悪い
360:NAME IS NULL
09/11/28 15:54:11 .net
テキストファイルはDBにならないって言ってる奴は、
ミドルエアとしてのDBMSと勝手に解釈して限定してるんだろ。
361:NAME IS NULL
09/11/28 16:25:41 WYkIZs31.net
>>359
追記専用で基本屋外設置かつメンテ頻度も大変低いという条件下では
中の人の名前が順に彫り込まれる墓石というデータメディアは大変に
優れたものだと思う。
何より墓石メディアを用いた墓場というDBは古くは古代メソポタミア
に始まる何千年もの利用実績があるわけで、侮れん。
362:NAME IS NULL
09/11/28 18:50:14 .net
必死に話をそらそうとしているのを見ると頭が可哀想な人なんだろうな。
常識でモノを考えて喋ってくれ。
会社でよく「コミュニケーション力が低い」と怒られている人だろうけど。
363:NAME IS NULL
09/11/28 18:57:49 .net
>357
指摘が全く意味不明だ。
石版メディアを使ったDBは読み書きが遅く電子処理に向かないので、
東京証券取引所では使えない。それだけの話がなんで理解できない？
おそらく君が「DB」と呼んでいるものは、正式には「RDBMS」だ。
364:NAME IS NULL
09/11/28 19:02:55 .net
いやだから現実的に情報システムで利用できる媒体のみで語れよ
テキストファイル、パンチカード、印刷物あたりまでは理解できるが
石板をシステムで読み書きするシステムなんて現実的に存在しないだろ
365:NAME IS NULL
09/11/28 19:09:00 .net
>>364
今は純粋に「データベース」という言葉の定義についての話をしてるんだろ？
情報システムで容易に媒体以外はデータベースにあらず、というのは単に君個人の
思い込みであって常識じゃない。
電話帳は電話番号のデータベース。これが常識レベルの解釈。
366:NAME IS NULL
09/11/28 19:10:15 .net
× 容易に媒体 ⇒ ○ 容易に扱える
そういう意味じゃ、石版がNGなら紙もNGだろ。
367:NAME IS NULL
09/11/28 19:30:53 .net
現実問題として紙に印刷しておいてあとでドキュメントスキャナで取り込むというデータの保存の仕方はあるけれど
石板に掘っておいてあとで読み込むなんて使い方をしている奴は誰もいないわけで
368:NAME IS NULL
09/11/28 19:36:05 .net
だから、昔は住所データベースが手書きだったりしたんだってば。
電子的に扱えるかどうかなんて問題じゃないんだって。
369:NAME IS NULL
09/11/28 19:43:07 .net
しかし、「データベース」の定義に照らしてもやっぱり2chはデータベースじゃないわな。
370:NAME IS NULL
09/11/28 19:56:06 .net
>>368
印刷物はDBとして使えるって言ってるじゃんみんな
否定されてるのは石版なんてとんでもない例でしょ？
371:NAME IS NULL
09/11/28 19:56:53 .net
>>369
372:NAME IS NULL
09/11/28 20:53:21 .net
>370
手書き文書は印刷物じゃないし、情報システムと親和性が無いのは石版と同じ。
石版の話は極端な例だけど間違いや嘘じゃない。
「データベースと呼べるかどうか」は、使いやすい／使いにくい、早い／遅いなんて
話とは別次元の問題だよ。
373:NAME IS NULL
09/11/28 20:57:48 .net
>言ってるじゃんみんな
「みんな」が誰を指してるのか知らんが、世の中の常識とは言葉の認識が乖離してるな。
374:NAME IS NULL
09/11/28 21:02:17 .net
紙も石板も単にメディアの一種にすぎない
データベースってのは、メディアは関係ない
ハンドリングの容易さとか管理のしやすさとかは別の話
ＤＢとＤＢＭＳの区別ついてない奴が多すぎるな
俺も普段はＤＢ＝（Ｒ）ＤＢＭＳの意味で使ってる場合が多いが
こういった議論のときはきっちり区別しろよ
375:NAME IS NULL
09/11/28 21:15:58 .net
テキスト/バイナリ、電子メディア/紙/石版wなんてのは単に実装方法の違いだけの
話なんだよね。DBかどうか、ってのは記録された情報の性質で決まる事なんだから、
「テキスト形式で保存したから」「記録媒体がアナログだから」なんて理由で
DBじゃなくなるという理屈は根本的におかしい。
376:NAME IS NULL
09/11/28 22:21:58 .net
うちの墓石にも幕末から死んだ先祖の名前と日付が掘ってあるけど、あれもDBだったんだな
377:NAME IS NULL
09/11/28 22:49:14 .net
「データの再利用を目的として、特定のテーマに沿ったデータを集めて管理したもの」では
ないので、墓石はDBとは呼びにくいな。
上記の目的で墓石にデータを記録したなら、それはDBと呼んで差し支えない。
378:NAME IS NULL
09/11/28 22:54:56 .net
>>377
>特定のテーマに沿ったデータを集めて
お墓の中に入っている人の名前しか入っていないけど。
>データの再利用を目的として
毎年お墓参りしないの?
379:NAME IS NULL
09/11/28 23:12:30 .net
>378
一般的には、墓石は単に故人の名前を残すこと自体が目的だと思うけど。
例えば「大量の先祖の中から特定の故人の名前を探す事を容易にする」のを目的に
墓石に名前を彫ったんだとしたらDBと呼べるんだろうけど。
目的がデータの再利用ならデータの構造も探索に適した構造になってる筈だけど、
故人の名前に見出しが付いてたりはしないだろ？
>毎年お墓参りしないの?
俺はしないw
つか、お墓参りはデータの再利用なのか？
380:NAME IS NULL
09/11/28 23:18:18 .net
没年でインデクシングされた故人データベースとして使う事は可能だなw
381:NAME IS NULL
09/11/28 23:27:29 .net
所詮墓石はデータメディアにしか過ぎない。
墓地の管理人さんも含めて初めてデータベース管理「システム」
と呼べる。
382:NAME IS NULL
09/11/28 23:36:57 .net
過去帳ならともかく、墓石そのものは集積されていないからなぁ。
383:NAME IS NULL
09/11/28 23:52:27 .net
墓石とか石版とかどうでもいいよｗｗｗ
384:NAME IS NULL
09/11/29 00:06:05 .net
>>383
しょうもない話だけど、本質を捉えていて面白いじゃないか。
こういう話を見てると、普段「データベース」という物がいかに
表面的かつ一面的にしか捉えられていないかが解るな。
385:NAME IS NULL
09/11/29 05:16:11 .net
しかし「データベース」の定義という知識が必要となることはまずないからなぁ。
今では博物学的意味しかないかもしれん。
386:NAME IS NULL
09/11/29 05:22:49 .net
テキストファイルや紙までなら理解できるけど
石版とかになるともうデータを取り出す目的で作ってるわけじゃないし
データベースじゃなくてストレージなんじゃないかと
387:NAME IS NULL
09/11/29 06:09:08 .net
ストレージがなければデータベースも実装できないのだが。
388:NAME IS NULL
09/11/29 06:31:32 .net
自動車にはタイヤが必要だがタイヤは自動車ではない
389:NAME IS NULL
09/11/29 07:40:55 .net
データベースは物質ではなくて概念の名前。
石版の例で言えば、厳密には石版そのものがデータベースなのでなく、石版に記録された情報が
データベースなの。
> 石版とかになるともうデータを取り出す目的で作ってるわけじゃないし
この話は「仮にデータの集積方法が石版への記述であったとしてもDBはDB」という例え話だろ。
データを取り出す目的で石版を作る事だって当然できる。
ほかのデバイスより読み書きの効率が悪いとか集積率が悪いとか、そんな事はここでは全く
問題ではない。
> しかし「データベース」の定義という知識が必要となることはまずないからなぁ。
知識以前に常識の問題だと思う。
データベースという言葉が何を指すのか知らないで日々その言葉を使うのか？
狭義のDB＝DBMSの中にもDBって言葉は入ってるんだぜ。
390:NAME IS NULL
09/11/29 08:23:41 .net
「DBMS」と「データベース」は異なる概念だというのは常識レベルの話だとしても、
あるAが「データベース」の定義にはてはまるかどうかという判断が求められることって
こんな議論の場でもなきゃまずないだろ。だいたい、「データベース」という言葉は
そもそもDBMSと比較して定義があいまいだし。
掲示板/BBSという用語を正確に定義付けられなくても2chやるのに何の支障も
ないってことよ。
391:NAME IS NULL
09/11/29 09:06:02 .net
なんでこんな現実性のない言葉遊びで熱くなれるんだ？
職場で「空気読めないヤツ」とか言われないか？＞石版データベース君
392:NAME IS NULL
09/11/29 09:06:16 .net
> あるAが「データベース」の定義にはてはまるかどうかという判断が求められる
日常的に行われている事だけど、当たり前過ぎて普通は意識しないだけだろ。
というか、そんな高尚な話か？
一から十まで常識レベルの話をとくとくと聞かせてるのに、まるで理解してるように
見受けられないから話が長引いてるだけだと思うんだけど。
> 掲示板/BBSという用語を正確に定義付けられなくても2chやるのに何の支障も
> ないってことよ。
エンジニアが仕事で使うならそんな訳にいかんだろ。ちゃんとしろよ。
393:NAME IS NULL
09/11/29 09:14:55 .net
>391
石版の話は単なる例え話だ。言葉の定義は単なる遊びでなく現実の問題だ。
散々感覚のズレを指摘されてるのに反省が見られんな。
こういういい加減な奴が技術者ってのが信じられん。
394:NAME IS NULL
09/11/29 09:20:20 .net
言葉遊び云々を言うなら、「テキストで保存したらもうDBじゃない」という
主張の方がよっぽど屁理屈だと思うんだ。
395:NAME IS NULL
09/11/29 09:44:03 .net
>>392
別に判断が必要じゃなきゃ仕事でもしないだろ。そもそも、データベースに該当するか
どうかという判断なんて、たとえばどういうケースで何のために行うの？
396:NAME IS NULL
09/11/29 09:58:23 .net
判断するというより、言葉の指す意味の範囲を知っておく事が重要だよ。
仕様書に「ログインユーザのデータベースを作成する」と書いてあったとして、
書いた側と受け手に共通認識が無いとおかしな事になる。
ぶっちゃけこういう時、勝手にRDBMSの準備をする奴は無能なエンジニアだと思う。
397:NAME IS NULL
09/11/29 10:17:09 .net
＞仕様書に「ログインユーザのデータベースを作成する」と書いてあったとして、
この場合は普通にDBMSを用いてログイン情報を管理する事を想定すると思うが。
要件に「ログインユーザの履歴を記録する」ならテキストに順次書き出しを想定する。
＞書いた側と受け手に共通認識が無いとおかしな事になる。
＞ぶっちゃけこういう時、勝手にRDBMSの準備をする奴は無能なエンジニアだと思う。
現実の仕事だとすり合わせとか会議があるからありえないケースだが、
そういう発想できる人の方がコミュニケーション能力と実務経験が欠如したエンジニアだと感じる。
398:NAME IS NULL
09/11/29 10:30:07 .net
DBを作成するけど、所謂DBMSを使わない案件だっていくらでもある。
DBが概念に過ぎない事を知っているエンジニアは、実装はどうするか？という発想になる。
そうでない人はDBMSを使う（仕様作成元は使いたがっている）と信じて疑わない。
> 現実の仕事だとすり合わせとか会議があるからありえないケースだが
勘違いしたまま実装まで行かないのは当然。
だだし、すり合わせの場でその話が出るまではずっと勘違いしてるわけだ。
仕事の仕方は全然違うと思うがね。
399:NAME IS NULL
09/11/29 10:31:32 .net
>>396
コミュニケーションミスの話はまた別のような。
「AはXである」
「『Iさんの言うA』はXである」
この2つの命題はは異なるからね。
データベースとDBMSは概念が異なるという常識があって、その上でその仕様書に
書かれた「データベース」がどちらを指しているのか明確でなく、さらにその違いが
実装する上で重要な違いなのであれば、普通は確認するよね。
そういう状況で、「『データベース』は必ずしもDBMSを必要としない」といって
勝手にテキストファイルで作ってしまうのも同様に困ったチャンだろうね。
後で客と「データベースを作れと言ったじゃん」「テキストファイルでもデータベースです」
みたいな押し問答になったりして。
400:NAME IS NULL
09/11/29 10:42:43 .net
石板DB否定派＝DBとは実装のこと。テキストがDBの実現手段に含まれる事を想像もしない。
石板DB肯定派＝DBとは概念のこと。DBの実装形態が様々あることを理解し、色々な可能性を想定している。
DBを概念として捉えている人は、実装について勝手な思い込みはしない。
> 勝手にテキストファイルで作ってしまうのも同様に困ったチャンだろうね。
その人はポジション的に石板DB否定派だと思う。
401:NAME IS NULL
09/11/29 10:46:30 .net
>>397
>この場合は普通にDBMSを用いてログイン情報を管理する事を想定すると思うが。
スタンドアロンや組み込みのシステムでもかい？
402:NAME IS NULL
09/11/29 10:55:39 .net
>>400
アンタさぁ、自分ひとりが後者、他の全員が前者だと思ってるだろw
403:NAME IS NULL
09/11/29 10:58:48 a+E7ORTb.net
既婚女性板はカルト団体の糖一教回や、そよ風などが支配し世論工作をしています。
既婚女性に成り済ましレスを繰り返してます。
残念だが既婚板の政治スレは全部カルトの工作スレです。
例えばこのスレ
↓
【民主党の政策に不安を感じる奥様の雑談室】その80
ｽﾚﾘﾝｸ(ms板)
web魚拓
URLﾘﾝｸ(s03.megalodon.jp)
404:400
09/11/29 11:01:08 .net
>402
いや、常識的な大半のエンジニアが後者、このスレにいる数名が前者だと思ってるが？
なんでそう思う？
405:NAME IS NULL
09/11/29 11:21:32 .net
その「数名」ってどこにいるの？
その話題でループしてんのアンタ一人じゃない？
406:400
09/11/29 11:28:21 .net
>405
そもそも石版の話を出したのは俺じゃないんだけどな。
テキストファイルはNGだ、紙ならセーフだ、墓石はどうだ、なんて話をしてた人は
明らかに前者だろ。石版DBの話にチャチャ入れてた奴も前者だと思ってるけど。
あ、君がどっちかは知らんよ。
407:NAME IS NULL
09/11/29 11:41:05 .net
どうせもう「前者」は居ないんだろうし、
>337以前の流れに戻そうや。面白かったけど、ちょっと引っ張りすぎ。
408:NAME IS NULL
09/11/29 11:43:41 .net
墓石のチャチャいれ？>>382なら俺だ。
つかその時点で既にデータベース≠DBMSが前提の議論じゃん。
409:NAME IS NULL
09/11/29 11:52:49 .net
>>408
>383 とか >391 のつもりだったんだが。
>382はそれもそうだなあ、と思いながら読んだよ。
> その時点で既にデータベース≠DBMSが前提の議論じゃん
君はそうかも知れんけども。
>386 とか >397 は理解してるようには見えん。
410:NAME IS NULL
09/11/29 12:45:50 .net
なんか休日に寂しい暇人が勝手に敵を作って「俺Sugeee」って言ってるスレだな。
定義厨は他人の意見を絶対に聞き入れないからカキコするだけ無駄だな。
411:NAME IS NULL
09/11/29 16:25:18 .net
馬鹿は反省しないから馬鹿なんだよね
412:NAME IS NULL
09/11/29 17:19:39 .net
DBとDBMSの区別もつかないレベルの人に仕事が回ってきちゃうぐらい
データベース設計が軽視されているという流れでOK？
413:NAME IS NULL
09/11/29 18:15:34 .net
DBってドラゴンボールですか？
414:NAME IS NULL
09/11/29 23:57:19 .net
墓石をデータの永続化対象として何がいけないのか、さっぱりわからん
415:NAME IS NULL
09/11/30 00:10:22 .net
曰く「実際にそういう実施例が存在するかどうか」が重要なんだそうだ。
頭が固いを通り越してアホとしか思えん。
416:NAME IS NULL
09/11/30 00:15:09 .net
DBってドラゴンボールではないんですね
417:NAME IS NULL
09/11/30 05:27:07 .net
ログイン認証の情報はテキストに保存しないって言ってる奴正気か？
htpasswd知らないとかないよな
418:NAME IS NULL
09/11/30 06:56:41 .net
このスレの本題はRDBMSのスキーマ設計の軽視だが、
実は軽視されてるのはデータ設計全般なんだろうか。
と、ここ数日のやりとりを見ていて思った。
2chのレベルが平均的とは思わないけれども。
419:NAME IS NULL
09/11/30 07:22:36 .net
一部のアフォが喚いているだけだろ
420:NAME IS NULL
09/11/30 22:20:31 .net
マジレスすると軽視されてるのは設計屋だお
421:NAME IS NULL
09/11/30 22:27:14 .net
マジレスすると開発＆運用屋は軽視されている
422:NAME IS NULL
09/12/01 00:41:31 .net
マジレスするとDBはデータベースだお
423:NAME IS NULL
09/12/01 01:33:05 .net
マジレスするとこの板が出来たときは8割のスレがドラゴンボール関連だった
424:NAME IS NULL
09/12/01 01:41:26 .net
過去レスみたら、>>19にワロタｗ
ひどいね
425:NAME IS NULL
09/12/01 02:04:03 .net
タイムスタンプにINT型でUNIX時間入れてるのが酷いと思ったけど超えたな
426:NAME IS NULL
09/12/01 10:05:12 .net
正しい知識を持った人間以外がプロになっているのがおかしい
一級建築士と同じように、充分な知識を学習した人間のみが、
システム設計に参画出来るようにするのが本来の正しい姿。
もう、遅いけどね。
427:NAME IS NULL
09/12/01 15:06:04 .net
機械設計だって回路設計だって人生設計だって資格はないけどな
428:NAME IS NULL
09/12/01 20:06:48 .net
十分な知識を学習とかって、実務経験に勝るモノはないんだが。
正確には「各行程を経験し死ぬまで学習意欲があり常に成長し続ける
コミュニケーション能力の高い人間」でないと設計はやるべきではない、
が正しいな。
知識なんてあって当たり前でなんの自慢にもならん。
まあ、免許制にして欲しいと思う事は多々あるがｗ
429:NAME IS NULL
09/12/01 21:25:31 .net
ペーパーでOracleのプラチナやPostgreSQLのゴールド持ってる奴より
無資格で現場で痛い目に遭ってる奴の方がまだいいだろうな
430:NAME IS NULL
09/12/01 21:55:33 .net
どっちが重要なんて比べるもんじゃないだろ。
知識も経験もどっちかが欠けてたらダメじゃん。
知識なんてあって当たり前。経験なんて勝手に積み上がる。
431:NAME IS NULL
09/12/01 22:20:12 .net
知識は幅広い視野を持つのに必要、経験はその上で必要。
スレチだが、ちまちま何かを作ったのに、それをカバーした上品なライブラリ見つけたらマジへこむ。
432:NAME IS NULL
09/12/01 22:32:55 .net
「知識より経験」って言う奴って、自慢できるのが本当に経験だけだったりするからな。
そういう奴は得てして怪しげなノウハウを振りかざしたり、理論的な話をするとなぜか怒ったり。
433:NAME IS NULL
09/12/01 22:48:16 .net
>>429
Platinumはペーパーでは取れんだろう。
434:NAME IS NULL
09/12/01 23:24:20 .net
>>432
資格もっててスマソｗ
つかDB関連の資格はペーパーはなくなないがある程度以上は実際に使った人間でないと
受かるのは辛いだろ。
現実には資格持ちは「古くて使えなくて胡散臭い都市伝説」を信じてるヤツ多いけどな。
「SQLはこう書くと・・・」とか「サロゲートキーが・・・」とか「こういう場合はストアドが・・・」とか、
「こうやって教えられた」とか、応用を知らんのかと小一時間(ry
実際やらしてみるとパフォーマンスでなかったり、JOBの再投入が不可能な論理設計したりとか。
資格取った後も最新動向やら勉強会やらニュースとか読め。
435:NAME IS NULL
09/12/02 00:43:57 .net
なんだその痛すぎる自己紹介はw
436:NAME IS NULL
09/12/02 01:12:12 .net
ペーパーでplatinum結構いるよ
goldだとやたらいる
437:NIN
09/12/02 01:52:02 .net
その先生方に確認したんだが、
テーブルの主キーの空きを管理するテーブルを作って、
主キーの空きを管理するっていうことを聞いたんだけど、ほんとかぬ？
438:NAME IS NULL
09/12/02 03:45:08 .net
OracleのGoldやPlatinumは講習会受けて取る資格だからな
難しいのは確かだけど時間と金がものを言う資格でもある
439:NAME IS NULL
09/12/02 04:26:21 .net
国家資格の情報処理試験が評価されてない現実。
440:NAME IS NULL
09/12/03 20:45:05 .net
>>425
1970年1月1日0時0分0秒からの経過秒数をDBに整数型で入れてるってこと？
…それはナイスな方法だな。今度使わせてもらうわ。
441:NAME IS NULL
09/12/03 21:21:06 .net
データ的には軽いけどトラブル対応時に人間が見て全く意味がわからないから死ねる
というか死んだ
442:NAME IS NULL
09/12/04 00:27:24 .net
その手の変換ツールぐらい準備しておくものだ。プログラマなら簡単にツールぐらい作れるだろ。
443:NAME IS NULL
09/12/04 01:15:07 .net
いやだから普通にtimestampでいいじゃんて話じゃないのか
プログラム上でだっていちいち変換して使わなきゃならんのだし
444:NAME IS NULL
09/12/04 07:26:50 .net
RDBMSによって実装が違うが、このケースでは普通にtimestampを使えばいいのでは？
そういう型がないRDBMSなら仕方ないと思うけど。
445:NAME IS NULL
09/12/04 08:09:50 .net
Unix系のアプリなら、time_t型を入れると出し入れが便利じゃん。
変換するコストもいらないし。
446:NAME IS NULL
09/12/04 09:21:40 .net
画面にそのまま出すのか
入力は？
447:NAME IS NULL
09/12/04 22:45:54 .net
まあUnix系なら「出し入れ」だけは便利な面はあると思う。
日付や時刻関連でGROUP BYするときにちょっと殺意が沸くくらいだな。
448:NAME IS NULL
10/03/21 14:22:04 7Pz5sOZx.net
age
449:NAME IS NULL
10/04/11 16:39:24 .net
ahe
450:NAME IS NULL
10/05/16 01:23:57 LQJdvEO0.net
有効期間のあるマスタテーブルの主キーってサロゲートキーにできるのかな？
451:NAME IS NULL
10/05/16 02:11:03 .net
できるよ
452:NAME IS NULL
10/07/31 21:47:51 IkDl9wDS.net
age
453:NAME IS NULL
10/10/30 13:29:21 .net
インデックス10個のテーブルに100万件のデータってやばいですか？
454:NAME IS NULL
10/10/30 14:23:02 .net
>>453
全然普通
455:NAME IS NULL
10/11/02 22:37:47 .net
それ殿くらいの鯖スペックでの話？
456:NAME IS NULL
10/11/03 08:21:23 .net
その辺の安鯖でも楽勝なレベル
要求性能にもよるが、10年前のハイエンドクラスだときついだろうね
457:NAME IS NULL
10/11/16 17:14:04 .net
atom 1.6GHz 2GBメモリで１００人ぐらいの共有鯖でもおk？
458:NAME IS NULL
10/11/23 16:06:12 lzgg56a3.net
余裕のヨーコゼッターランド
459:NAME IS NULL
10/11/24 16:00:20 .net
じゃあ問題出たら損害賠償請求するのでヨロw
460:NAME IS NULL
10/11/24 21:25:35 .net
じゃあ性能要件を満たす設計をしてあげたからその分の費用請求ヨロｗ
0.25人月で60万円でおｋ
461:NAME IS NULL
10/11/24 21:32:17 .net
単価安いなｗ
462:NAME IS NULL
10/11/26 21:57:49 .net
1人月240万だろ？充分高いだろ
俺のとこなんて1人月120万だよ基本orz
463:NAME IS NULL
10/11/27 02:10:26 .net
そんなボッタクリな所には仕事頼まないしw
464:NAME IS NULL
11/01/18 19:33:09 .net
プラズマクラスター効果なし
URLﾘﾝｸ(twitter.com)
465:NAME IS NULL
11/10/29 19:01:44.37 .net
大手ベンダーの標準的な人月って150万くらい？
466:NAME IS NULL
11/11/27 14:59:22.75 .net
>>439
国家資格（笑）の情報処理試験受けたことあんのかと
あんなもん実務に役立つのはどのポジションだろうが2割程度だろ
「プラズマテレビがガス放電で発光してます」とか知ってる必要あんの？
IPAは今年度になってようやく業界のゼネコン型に言及するレベル
お勉強しか出来ない無能集団の天下り先
国家自体が無能で仕事遅いしなｗ
ロジックとデータ（論理・物理）見てテストして
壁にぶち当たってマニュアルやら仕様書見て
ソースとデータ（論理・物理）見てｒｙ・・・・ループ
この作業以外で技術力を上げる方法なんか存在しない
467:NAME IS NULL
11/12/02 21:33:33.05 kohrfEHA.net
派遣で天才プログラマーが消えた
468:NAME IS NULL
11/12/03 00:57:01.54 .net
>>466
糞ﾜﾛﾀお前の情試の例はよりによってITパス/FEの午前かよｗ
高度のスペシャリスト系は良く出来てる
所詮知識なので合格即実務で出来る、ではないが
「この程度も知らずに実務やってないよね？」感はある
469:NAME IS NULL
11/12/03 12:43:57.30 .net
>>468
高度がよく出来てる？
アホか？回答速報当日出ないような奇問も混じってるわけだが？
470:NAME IS NULL
11/12/03 13:50:27.97 .net
>>469
お前はずっとFE午前レベルの「プラズマテレビの～」だけやってろｗ
お前みたいに高度もとれない程度の知識レベルの奴が設計してるシステムとか・・・
関わってる連中が可愛そうだわ。まさにスレタイにピッタリな人間ｗｗｗ
471:NAME IS NULL
11/12/04 00:16:08.13 .net
>>470
難易度低い時に受けてたまたま取れたヤツが偉そうにしてるの見ると痛々しくなるよな。
基本はわかってるが応用効かないし、製品個別の仕様部分を考慮できなかったりロクなヤツがいない。
472:NAME IS NULL
12/04/23 13:48:49.67 .net
専板のDB設計スレが保守の末落ちる程だから軽視も致し方ない
473:NAME IS NULL
12/07/15 16:24:28.05 .net
大本の設計程制約少ないから楽に作れるもんなんだが、
逆に末端がどんどん依存してくれるから後で変更するのがた～いへん。
わかってるとこだとDB設計にコストかけてくれる。
わかってないとこだと作る側の営業と使う側の購買が交渉にコストかけてくれる。
後者、会社関係単位で迷惑。
詳細テーブル全てに予めtempカラム群持たせるのって、
個人的にはかなりの糞だと思うんだが・・・
474:NAME IS NULL
12/07/22 12:59:18.94 .net
予備カラム…COBOL脳全開の設計ですな。
475:NAME IS NULL
12/07/22 14:06:03.40 C+pjCT8o.net
そこで列指向データーベースですよ
476:NAME IS NULL
12/07/23 19:43:57.61 .net
そうそう
ところで激安中古CAD専門店っていいの見つけた。
かなり安いし使える
477:NAME IS NULL
12/07/24 22:41:20.78 .net
>>474
何百万レコード級のテーブルを
使ったことはある？
ALTER TABLEだけで何十分とか
当たり前にかかったりするぞ。
それを思えば、ハナからバカにした
ものでもない。
478:NAME IS NULL
12/07/24 22:49:28.17 .net
>>477
レコード数が多いからこそ、カラム数を減らすべきだってことが分からないのか？
479:NAME IS NULL
12/07/24 22:55:57.42 .net
COBOL脳だとRDBにおいてはテーブルサイズが大きくなるとパフォーマンスが加速度的に劣化する場合があることを理解できない。
あいつらなんでもかんでも一行づつ処理しようとする。
処理時間=一行の処理時間(一定)×行数
はRDBじゃ通用しないんだよ
480:NAME IS NULL
12/07/24 23:29:57.10 qDs+O0CQ.net
某H関連会社に訪れた際、若手ＳＥが仕様レビューを受けていた
「ここでSQLのSUM関数で合計を取得します」
「それ信用できるの？ちゃんと一つずつ足さないとダメだよ」
２１世紀でこれかと驚いた
481:477
12/07/26 22:49:50.88 .net
>>478
ケースバイケースだと言ってるんだよ。
絶対どっちか、というものではない。
予備カラムがあっても、理由が充分なら、
それでよいではないか。
482:NAME IS NULL
12/07/26 23:25:44.93 .net
予備カラムなんて持たせたら、いざ使う時、意味合いとカラム名が乖離するよね。
検索パフォーマンスが必要無いならxml型にするって手もあるけど
483:NAME IS NULL
12/07/26 23:36:01.31 D083zD7I.net
DB変更は仕様変更になるから別契約だけど
予備項目を活用する分には保守の範囲内で出来るから
予備を多めに作っとくっていうのがあったな
クソだと言われてる設計でも事情でそうなってるのも結構あるよね
484:NAME IS NULL
12/07/27 00:24:21.29 .net
予備カラム多用すると、後々どの予備カラムが何の目的で使われてるか分からなくなるw
画面から予備カラムにセットする値にも制限掛からないから、変な値入ってバグってみたり。
485:NAME IS NULL
12/07/27 20:28:23.51 .net
そもそも可変長ランダム入出力が基本なRDBのレコードにおいて
予備カラムをあらかじめ作る必要性はうすい
COBOLだから予備カラムつくるんじゃなくて、それが動いているプラットフォームが
固定長バッファのシーケンシャル入出力を基本としてたから必要なだけ
486:NAME IS NULL
12/07/28 01:31:34.34 +zDhKkY8.net
>>439
あんな天下り先確保のための試験を
ボッタクリ価格で受けるとか、
怒りが湧いてくる。
487:NAME IS NULL
12/07/28 02:12:21.50 .net
まるで意味のない資格では無いだろ。
とはいえ午後1は酷い問題混じってることあるから、選択運の要素が強いけど。
488:NAME IS NULL
12/07/28 10:54:33.10 .net
>>486
安いので許せや
489:NAME IS NULL
12/07/28 10:55:35.76 .net
>>487
酷い問題のってどれですか
490:NAME IS NULL
12/08/04 09:12:32.99 .net
>>487-488
>>486 は取れなかった奴の言い訳じゃね (w
491:NAME IS NULL
13/10/13 20:53:47.26 4bhXtCWz.net
保守age
492:ＮＰＣさん
14/01/15 06:23:23.94 8z9mQXwT.net
66427727358778987766457232625+40=66427727358778987766457232665
www.2ch.net
toro.2ch.net/db/
toro.2ch.net/test/read.cgi/db/1228061247/
493:NAME IS NULL
14/01/29 00:39:34.78 .net
>>1
せっかく合意のとれた業務フローとテーブル設計を
180度ひっくり返しに来る奴（客・身内問わず）がいるから
それが最初からわかってるから軽視される
494:NAME IS NULL
14/01/29 01:16:58.43 .net
この前某中古ショップですごく安いパソコンを発見しました。
ちょうど私はその時新しいパソコンがほしいと思っていて本当に買おうかと悩みました。
というのも２０１１年製でCPUがCorei5、メモリも４ＧＢあるしHDDが１ＴＢもあってお値段がなんと３８０００円でした。
まだ発売日からあまり期間も経っていないしこのスペックでこの値段ならかなりお買い得かなと思ったのですが、問題は少スペース型というか拡張性がないタイプのものだったんです。
それにグラフィックボードもついておらず後々の事を考えるとやめといたほうがいいかなという結論に達しました。
結局ネットでBTOのパソコンを後で注文しました。
いやぁしかしまさか周りにあるパソコンの中で一番スペックが高いのに一番安い値段になってるとは思いませんでした。
ｽﾚﾘﾝｸ(hp板)
ｽﾚﾘﾝｸ(hp板)
495:NAME IS NULL
14/02/02 00:06:45.66 LwhyxpFz.net
自分で競馬データベースや競馬新聞を作りたいんだが
どんなプログラミング言語を学習すればいいですか？
競馬を通してプログラミングを勉強すれば楽しいと思うし、
仕事にも役立つとなれば一石二鳥。
データーソースは外部の物を利用。
496:NAME IS NULL
14/02/14 21:34:14.86 .net
↓こういう提供されたexcelデータがあるとします
日本小学校
１年 |２年
1組 ２組 | 1組 ２組
座席番号１安藤 伊藤|五十嵐 飯田
座席番号２臼井 榎本|上田 岡田
座席番号３０（全クラス３０で統一）
↑をデータベースに格納しようとすると
こういう風な感じになると思いますが
日本小学校 一年 1組 座席番号1 安藤
日本小学校 一年 1組 座席番号2 山田
日本小学校 ２年 1組 座席番号1 伊藤
視覚的に編集するには前者の方がやりやすいですよね
こういう前者のデータ構造は何か名称があったりしますでしょうか
また前者のテーブルの横にアメリカ小学校を追加する場合もあります
こういうデータを管理するために何かいいツールとかないでしょうか？
データベースに格納できるよう変換してくれたり
１年 |２年
1組 ２組 | 1組 ２組
日 座席番号１安藤 伊藤|五十嵐 飯田
本 座席番号２臼井 榎本|上田 岡田
小
ア 座席番号１ボブ トム
メ 座席番号２マリー
リ
カ
小
こんな風にしたり
497:NAME IS NULL
14/02/15 11:02:45.63 .net
>>496
そもそもそれはデータ構造と呼べる代物かが疑問なんだが
表現方法としては「マトリクス表」とか呼べばいいんじゃね？
ツール？excel使えばいいじゃん
excel VBAでcsvを出力するマクロを作れば終いだ
498:NAME IS NULL
14/02/15 20:26:44.89 .net
やっぱ自作ですかね
どうもです！
499:NAME IS NULL
14/07/22 14:35:32.25 AM7LzXqx.net
★2ch勢いランキングサイトリスト★
◎ +ニュース板
・ 2NN
・ 2chTimes
◎ +ニュース板新着
・ 2NN新着
・ Headline BBY
・ unker Headline
◎ +ニュース板他
・ Desktop2ch
・ 記者別一覧
◎ 全板
・ 全板縦断勢いランキング
・ スレッドランキング総合ランキング
・ ログ速
◎ 全板実況込み
・ 2勢
・ READ2CH
・ i-ikioi
※ 要サイト名検索
500:NAME IS NULL
14/07/23 19:35:38.12 .net
埼玉県警川口署は２０日、小学生の女児の下半身を触ったとして強制わいせつの疑いで、
同県蕨市南町、東大大学院博士課程の内藤慶一容疑者（２６）を逮捕した。
川口署によると、内藤容疑者は「研究が忙しく、ストレスがたまっていた。少女に興味があった」と供述している。
逮捕容疑は１月４日午後５時半ごろ、埼玉県川口市並木２丁目の書店１階の階段近くで、
当時９歳で小学４年だった女児の下半身を触った疑い。
書店の防犯カメラ画像を解析するなどして内藤容疑者が浮上した。
３月上旬に近くのスーパーで別の女児が下半身を触られる被害があり、関連を調べる。
URLﾘﾝｸ(www.47news.jp)
501:NAME IS NULL
15/02/08 18:11:12.29 .net
色々あるけど結論として
役に立たないんだよ。
まじで。
502:NAME IS NULL
15/08/22 10:22:18.62 .net
テーブル設計がきちんとしてるだけで
オプティマイザがいい仕事するんやで
503:NAME IS NULL
15/10/22 23:00:56.18 72sKbAfY.net
☆ 日本の核武装は早急に必須ですわ。☆
総務省の『憲法改正国民投票法』、でググってみてください。
日本国民の皆様方、2016年7月の『第24回 参議院選挙』で、日本人の悲願である
改憲の成就が決まります。皆様方、必ず投票に自ら足を運んでください。お願い致します。
504:NAME IS NULL
15/11/22 12:48:10.28 7pwbZA71.net
インターフェイスが決まってからデータベースを設計するのに今更気づいた。
505:NAME IS NULL
15/11/24 20:00:17.75 dq6F7Xc9.net
>>504
インターフェイスって何？
506:NAME IS NULL
15/11/24 21:21:06.03 bTXxqVP9.net
> 748 名前：名無しピーポ君 ：2015/11/24(火) 12:28:48.30
> 噂の日教組保育士がまた報復やったってさ
>
> 749 名前：名無しピーポ君 ：2015/11/24(火) 12:41:16.38
> あーーーー在日居住地にある能満幼稚園の
507:NAME IS NULL
15/12/10 17:38:16.52 9MpJNZja.net
>>504
システム間インターフェイスだとしても、ユーザーインターフェイスだとしても間違っているか？
508:NAME IS NULL
15/12/10 17:40:03.26 9MpJNZja.net
データをどう持つのかを初めから考えていないとUIもデータモデルも失敗する。
509:NAME IS NULL
16/01/21 04:46:50.28 .net
途中で持ち方換える事もあるけどな
510:NAME IS NULL
16/12/16 06:28:37.13 .net
柔軟に設計しろよ。ただしスタンダードはある。
511:NAME IS NULL
17/08/18 10:52:33.77 .net
>>216
Googleの検索システムがKVSの御時世に何言ってっだこいつ？
512:NAME IS NULL
17/08/18 13:05:23.32 .net
>>511
8年前の書き込みに何言ってっだこいつ？
513:NAME IS NULL
17/08/18 22:51:50.80 41NDIrx4.net
>>511
>>512
自演なのかも知れんがクッソワロタ
514:NAME IS NULL
17/08/22 21:43:07.29 .net
スレタイが気になっから来てみたが
データベース設計を「テーブルレイアウトを決める」という作業と捉えてる時点でDB設計を軽視してるんだよね
テーブル設計はDB設計の中でも末端作業だから、そういう認識から変えたほうがいい気がする
経験上、DB設計出来ますってやつのうち概念設計や論理設計がまともにできるやつは20人に1人いればいいほう
515:NAME IS NULL
17/08/23 00:07:55.54 xUh+Pb4A.net
論理設計とかについて偉そうに語れるほど
論理設計が出来るとは思ってないが
テーブルを正規化したり
適切なデータ型を決定したり
制約を定義するといったことを
末端作業と言って軽視すのは
どうかと思うよ
516:NAME IS NULL
17/08/23 01:15:21.19 .net
軽視してるってわけでもないんだがテーブルレイアウトを決めるのはDB設計全体の一部でしかなく
それも最後のほうにやる作業だって意味
ある業務に関わるデータをどういうデータ構造で管理するのが適切かを考えようとしてる時に
「Excelのフォーマットを決める」ような作業が、RDBなら「テーブルレイアウトを決める」という作業
「どういうExcelフォーマットにしようか」ってのと同じ観点から始めて
テーブル定義書と申し訳程度のER図を書くことがDB設計だと思ってる人がすごく多い
DB設計はテーブルレイアウトを決める作業じゃなくて、DB設計の結果としてテーブルレイアウトが決まる
517:NAME IS NULL
17/08/23 02:10:01.71 .net
システム設計を「クラスの定義を決める」作業として捉えてるのと同じって言ったほうがわかりやすいか
クラス図とクラス定義書を書くのが設計だと思ってる人はほとんどいないけど
DB設計においてはそのレベルの人がたくさんいるよね
518:NAME IS NULL
17/08/23 08:18:56.25 ZPvWL1rI.net
テーブルを正規化したり
適切なデータ型を決定したり
制約を定義するといったことが
最も大切だよ
それだけの話
それらを必要に応じて
敢えて崩すのはアリだけど
正規化をやらないとかはありえない
519:NAME IS NULL
17/08/23 22:05:49.25 .net
>>518
それって結局、DB設計をテーブルレイアウトを決める作業と捉えてて
テーブルレイアウトを決めるのにはそれらが最も大切だって言ってるんじゃねーの？
例えば正規化ってOOにおけるSRPやOCPみたいな設計原則に相当するものだよ
SRPに従ってクラスを分けることがシステムやプログラム全体の設計の中で最も大切だったりする？
クラス定義においてならまだ理解できるけどさ
それと同じで正規化の知識は必須だし、業務アプリなら当然その設計原則に従ったモデルを作るんだけど
DB設計において正規化することが最も大切なわけではないよ
520:NAME IS NULL
17/08/23 22:20:54.73 HAUVK0b0.net
>>519
テーブルを正規化したり
適切なデータ型を決定したり
制約を定義するといったことが
最も大切だよ
それより大切なことって何かな？
521:NAME IS NULL
17/08/23 22:52:53.62 .net
>>1
>何故データベース設計は軽視されるのか？
理由を考えてみたが、教育不足と経験不足が大きな原因だと思う
まず一般的なプログラムの設計に比べてDB設計はその機会自体が圧倒的に少ない
それはプログラムに比べてDBは数も少なくライフライクルも長いし、プログラム設計に比べればDB設計は一人で担当できる規模が大きいから
機会自体が少ないから、業務アプリに関わるエンジニアの中で繰り返し何度もDB設計の経験が積めるような人も当然少ないし
その中でも優れたDB設計者となるともっと少ない
だから一部のDB設計に特化した会社や部門を除くと、かなり大手でもDB設計に関してまともに後進の教育や育成ができるような人はすごく稀
そうでない人たちに教育・育成されたエンジニアが大多数を占めるからDB設計が軽視されることが自然と多くなる
DB設計能力の低いと、どうしてもプログラムの処理に重きを置きがちで
プログラムからデータをどう使いたいかという観点でDBを設計しちゃう人が多い(=DB設計の軽視)
そういうやり方を見てきた人たちはそれが当たり前だと考えるからDB設計軽視が再生産される
個人レベルでは優れた教育を受けたり、数多くの経験を積むことで負の連鎖からは抜け出せそう
会社レベルではDB設計の機会の少なさと重要性を認識して、優れた育成者を多く育てる努力が必須かな
522:NAME IS NULL
17/08/23 22:56:37.93 .net
>>520
DB設計において最も重要なことは
ビジネスドメインと要求を深く理解して適切なデータモデルを作ること
523:NAME IS NULL
17/08/23 23:33:45.34 HAUVK0b0.net
>>522
ビジネスドメインと要求を深く理解するというのは
そもそもデータベース設計レベルの話かい？
524:NAME IS NULL
17/08/24 00:54:44.89 .net
>>523
そうだよ
ちゃんとしたデータベース設計には必須だよ
対象のドメインと要求を深く理解しないと適切なデータモデルは作れないから
だからプログラムの実装に近い人がDB設計するよりも
要求分析をする人で技術力もある人がDB設計をしたほうがまともな設計ができることが多いよ
後者の場合は組織や責任者がDB設計にとって何が重要か理解しててDB設計を軽視してないっていう理由も大きいけどね。