何故データベース設計は軽視されるのか？

**NAME IS NULL** · 2009/08/22(土) 18:01:32

>>214
>・SQLがきわめて単純になる。
>・DB構造に頭を悩ませる必要がなくなる。
ちゃんとしたDB設計もできない設計者、SQLもかけないようなプログラマにとってはメリットかもしれんがな
>・スケールアウトしやすい。
クラウドに適した形式だから、莫大なデータ量で通常ではハンドリングできなくて
クラウドにするってならわかるが、クラウド考慮しないなら関係ないんじゃない？

>複雑なSQLなんて見たくもない。バグの原因＆パフォーマンス劣化の原因になりやすい。
すくなくとも複雑なSQLがパフォーマンス劣化の原因ではなく、（SQLにより実行される）複雑な処理が原因なわけで
>・今まで1つのSQLで取得できてたものが複数回のSQLになる。
>・今まで1行で帰ってきたものが複数行になるのでコードでループでまわしてレコードを組み立てる必要がある。
ような状況で、パフォーマンス劣化は避けられるどころか余計悪くなると思うがな

>多くの部分はこの型におさめられるのではなかろうか。そうすれば余計な頭を使わなくて済む箇所が一つ減る。
頭使わなくて済む個所が減ったらダメだろｗ
いままでSQL書いただけでやってくれてたことを、全部自前で実装するんだぞ？
プログラムしないといけないことも増えるし、頭使うとこも増えると思うがな

>今でも一部はそういう作りはあるけど（汎用マスタ等）、それを可能な限り全てのテーブルでやる。（
いまのRDBMSでも、やろうと思えばそういう風にできるわけだ
でも普通はみんなそんなことはやらない。それが答えだと思うがな

メリットデメリットってのは、何に対してなのかはっきりさせてから評価してくれないか
このままだと頭使わない奴にとってメリットがあるって結論になるなｗ

**NAME IS NULL** · 2009/08/22(土) 18:50:31

>>216

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

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

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

SQLだとちょっと書き方変えるだけで10倍、100倍もパフォーマンスが違う事ってありますよね。みんながみんなSQLのエキスパートであれば問題ないのですが。それに比べればましかなと思ってます。もちろん処理内容によりますが。

>頭使わなくて済む個所が減ったらダメだろｗ

”余計な頭を使う箇所が減る”の間違いでした。

>メリットデメリットってのは、何に対してなのかはっきりさせてから評価してくれないか

メリット、デメリットは一般的なテーブル構造（先の例での前者）に対する、KVS的なテーブル構造のメリット、デメリットです。

>このままだと頭使わない奴にとってメリットがあるって結論になるなｗ

おっしゃるとおりで、このスレッドの趣旨には反しますがこれが一番のメリットと思います。頭を使う必要が少なければ、設計する人によって品質がバラバラという可能性が減るのではないのでしょうか（こういう構造で業務を満たせるのであれば）。

職人頼りなシステム開発が工業製品へと一歩前に進めるような気がします。

**NAME IS NULL** · 2009/08/22(土) 19:11:02

>>214
こんなことしなくても
みんなお前ほど頭悪くないから大丈夫だよ

**NAME IS NULL** · 2009/08/22(土) 21:45:36

開発効率が３０年前に逆戻りすることだけは確実だな…

**NAME IS NULL** · 2009/08/22(土) 22:12:18

馬鹿でも扱えるようにしたら色んなところで問題が出るってなぜわからんのだ。
カスレベルの人材でも働けるのは業界にとって大きなマイナスだ。

**NAME IS NULL** · 2009/08/22(土) 22:19:41

>>217
>職人頼りなシステム開発が工業製品へと一歩前に進めるような気がします。

逆だ。DBでやらない分アプリでやることが増えて、
プログラマの腕頼みになるだけだ
みんなが言ってるとおり、時代に逆行しているよ

**NAME IS NULL** · 2009/08/23(日) 00:47:33

カスは時給安くても働くから、時給高い熟練は不要になるしな。熟練にしか出来ない正規化とかの無駄な仕事が必要ｗｗｗ

単にDB使いこなせないからアプリでがんばるよ的発想だよな。
SQLを使ってたほうが遥かにパフォーマンスが良い現実。
これまでの歴史で今の状況に成ってるのを理解しないと。

オブジェクト廚が、オブジェクトDBなら便利になるぜとかのたまってたけど遅くて結局は消えてるし。
また馬鹿が湧いて、無駄な事を繰り返すのかな。

**216** · 2009/08/23(日) 01:05:42

>>217

>最初は考慮してなかったが後からやっぱ必要だった！（見積もりが甘い？）って時にはメリット
クラウドにしやすい、ゆえにスケールアウトしやすいメリットがあるっていうならわかるが
クラウド云々関係なしにってのはお前の出した前提条件だが？
クラウドにしないでスケールアウトってんならデータ形式はあんまり関係ないだろ
あくまでクラウドに適してるのがメリットであって、スケールアウトは副次的な話だ

>SQLだとちょっと書き方変えるだけで10倍、100倍もパフォーマンスが違う事ってありますよね。
オプティマイザが入るSQL処理でさえ簡単にそれだけの差がでる。
自前アプリでその処理をやるわけだ
みんながみんなSQLのオプティマイザより賢くプログラム組めるのか？
>みんながみんなSQLのエキスパートであれば問題ないのですが。それに比べればましかなと思ってます。
みんながみんなプログラムのエキスパートであれば問題ないのですが。
それに比べれば(SQLの方がオプティマイザある分)ましかなと思ってます

>メリット、デメリットは一般的なテーブル構造（先の例での前者）に対する、KVS的なテーブル構造のメリット、デメリットです。
いやだからその２者をくらべたときに、誰にとってメリットデメリットだと？
ほんとに頭使わないシステム開発者にとってのメリットでいいのかよ

>品質がバラバラという可能性が減るのではないのでしょうか
減るかもしれんな。頭使わない安価粗悪な物によってまともな物が駆逐されてな
全体のレベルを下げるだけだ。品質低い方に統一してどうする

>職人頼りなシステム開発が工業製品へと
工芸品が工業製品になるためには、その職人の技が一般化されてることが必要なわけで
一部の人しかできないことを、だれにでもできる事だけで作ったとしてもそれは単なる粗悪品
一部の人しかできなかったことを、誰にでもできるようにしないと意味がない
そのために論理や技法があり、それを学んだり論議したりしてるんだよ

お前の主張は、
工業製品ならだれでも作れないとダメでしょ。
馬鹿にはシステム開発できないんで、システム開発は工業製品じゃないよね
ってことだ

**NAME IS NULL** · 2009/08/23(日) 01:25:59

>>214袋叩きワロタw

**NAME IS NULL** · 2009/08/23(日) 02:35:18

>>217
> みんながみんなSQLのエキスパートであれば問題ないのですが。

SQLのエキスパートはそんなにいらない。
もちろん、一見優秀そうなゴミでは何の役にも立たないが…。

**NAME IS NULL** · 2009/08/23(日) 03:11:11

おっ！最近レス多いですねぇ。いいじゃないですか。
スレの趣旨に合っていれば、DB技術者の意見を気軽に言い合ってもいいんじゃない。
レスが一つ入ると反応する方が結構居そうなので。

それぞれ扱ってるシステムの規模や影響、会社の風土とが違うでしょうから、
一概に良いか悪いかは言えませんが。

**NAME IS NULL** · 2009/08/23(日) 04:28:10

>>214
とりあえず、「KVS的な構造」といって後者はないだろう。

**NAME IS NULL** · 2009/08/23(日) 07:11:42

>>214
COBOLやRPGの時代にそういうテーブル設計しているのありました。

今SQLで実装している業務を試しにCOBOLで実装してみたほうがいい。

まあ、あの時代はある種夢の時代だったな。
「おれ５０００ステップのプログラム作っちゃったぜ！」と
無駄に長いプログラムを作れば儲かった頃だし。

ちなみにSQLより速い処理が組めるRPGやCOBOLのプログラマなんて
ツチノコ並みの珍獣だと思うが。

**NAME IS NULL** · 2009/08/23(日) 10:56:13

>>228
COBOLやRPGは知らないけど、「処理の速さ」という点では
プログラムでゴリゴリ書いたほうが良いこともある
DB側（リレーション、制約、ストアド、SQL）に機能を持たせる
一番のメリットはやはり保守性だろう

**NAME IS NULL** · 2009/08/23(日) 13:45:30

サーバーでやるかクライアントでやるかの違いだろうね。>>214

メリット・デメリットは>>214の他に
メリット
自分で最適化できる。
デメリット
サーバー/クライアント間のデータ転送量が多くなる。（高速LANなら無視できる）

かな？

**NAME IS NULL** · 2009/08/23(日) 14:32:06

>>229
ストアドの速さに勝てるの？ありえなくないか？
DBに機能をもたせると保守性は落ちるとおもうが。

**NAME IS NULL** · 2009/08/23(日) 15:05:03

ストアドにしたからといっては飛躍的に高速になるわけではない。

**NAME IS NULL** · 2009/08/23(日) 16:21:00

処理の種類によるけど遅くなることはないだろｗ

**NAME IS NULL** · 2009/08/23(日) 21:31:35

データをどこに持っているかにもよる
DBMSに格納されているなら、そのDBMSに特化したストアドより早く外部プログラムが
実行できるとは思えない。
ストアドでも外部プログラムでも、ロジックは同じように作れるわけだからな

保守性については、システムの保全とか改修のしやすさとか、
何を主眼として保守性とするかによって変わると思うが

**NAME IS NULL** · 2009/08/23(日) 21:33:12

遅いクエリーはストアドであっても遅い

**229** · 2009/08/23(日) 21:54:10

>>234
「保守性」っていうのは、改修の効率の良さ、再利用性の高さ、
論理的整合性の保ちやすさなどをひっくるめた意味で書いた
曖昧な定義でごめんね

**NAME IS NULL** · 2009/08/24(月) 00:12:00

>>235
だったら外部プログラムならなお一層遅いだろ？
論理性がまったくないようだけど本業のほうは大丈夫？

**NAME IS NULL** · 2009/08/24(月) 04:53:27

他のクラウドで処理したデータも拾ってこなきゃならんから遅いだろうね。
全クラウドが、光ファイバーで繋がってて、膨大なクエリ処理しても、遅延は最大でも数百ナノ秒だぜってわけじゃないだろうし。

**NAME IS NULL** · 2009/08/24(月) 06:28:52

サーバーサイドの処理と限定して話をするけど

>COBOLやRPGは知らないけど、「処理の速さ」という点では
>プログラムでゴリゴリ書いたほうが良いこともある

SQLの実行エンジンの最適化処理でブロックI/Oやらをやられると
プログラムで１行FETCHや1行WRITEしている
これらの言語は太刀打ちできないワケだが。

そりゃ、OSのAPIを直打ちするレベルになれば別だけどな…。

今時のRDBMSは統計情報を元にSQLの実行プランを最適化するが、
一般プログラマにコレを越えるプログラム組めって言っても
かなり辛い。

むろんプログラマが書いた方が良いこともあるだろう。
どんな例か知らんけど。

**NAME IS NULL** · 2009/08/24(月) 17:29:10

なんかストアドよりインデックスが速いよスレの二番煎じな流れだな。

詭弁のガイドライン
2.ごくまれな反例をとりあげる
「だが、RDBよりプログラマが書いた方が良いこともある」
15.新しい概念が全て正しいのだとミスリードする
「クラウドで使われているKVSを使わぬ限りシステム構築に明日はない」

**NAME IS NULL** · 2009/08/24(月) 21:15:01

>>239
> 今時のRDBMSは統計情報を元にSQLの実行プランを最適化するが、
> 一般プログラマにコレを越えるプログラム組めって言っても
> かなり辛い。
腐るほどあるよ。

**NAME IS NULL** · 2009/08/24(月) 22:02:49

>>241
腐ったSQLを平気で書くプログラマのプログラムを想像した。
北へと旅に出たくなった・・・

**NAME IS NULL** · 2009/08/24(月) 22:27:07

>>241
腐るほどある。と言われても、AS/400みたいなマシンで無い限りSQLと他の言語の
速度比較とかは出来んはずだが、AS/400なんざ普及していないだろ。

RDBMSでSQL使うよりもC++でコレクションクラスを使った方が速いよ、なんて
議論無意味だしな。

**NAME IS NULL** · 2009/08/24(月) 23:03:22

ちょっと議論の的がズレていってない？
>>214は、処理の速さについては
メリットとしてもデメリットとしても挙げてないんだし
問題の本質はそこじゃなくない？

**NAME IS NULL** · 2009/08/25(火) 00:03:36

単に屑PGが適当に組んでも速度が出ないと困るってか？
SQL覚えるのが一番の近道。

**NAME IS NULL** · 2009/08/25(火) 02:06:15

>>244

問題の本質とは?
確かに、214さんが処理の速さについては
言及しておられないようです。

ただ、私見ですが214さんがSQLを良く
理解しておられないのは感じます。

開発側とすれば画面に表示する情報を
1SQLで取得できるように設計するべきで、
その方が楽だと思いますがね。
遅かったら運用のせいにも出来るしね。

>>242
まぁ、そんなこと言わないで、がんばって行きましょ。
分かるけどね…

**NAME IS NULL** · 2009/08/25(火) 02:50:49

>>246
クエリの知識しかないアプリ屋のくせに
えらく上から目線だなオイ

**NAME IS NULL** · 2009/08/25(火) 03:07:51

>>247
いえいえ、とんでもない。
そんなお褒めの言葉、
こちらこそありがとうございます。

**NAME IS NULL** · 2009/08/25(火) 04:14:41

単に複雑なSQL組めない屑PGだろ。
select *だけで全部済む様にしたいとか言いそうだし。
まるでオープン系コボラｗｗｗ

**NAME IS NULL** · 2009/08/25(火) 07:07:25

>>246
情報を1SQLでとれないってのは、どっちが？

**NAME IS NULL** · 2009/08/25(火) 09:54:39

まだまだＤＢのオプティマイザはアホだから、実行プランやトータルコスト考えながらクエリやＰＧ書けない奴はダメだな。
下請けソフトハウスのアプリ屋なんてそんな奴ばっか…
何のためにキーやインデックスがあるのかちょっとは考えてくれよ

**NAME IS NULL** · 2009/08/25(火) 10:08:13

>>249
複雑なSQLはそれ自体のメンテが大変かもね。アクセスパスは不変じゃないし
無理矢理SQLに詰め込まれても、常に効率が良いとは限らない。
要はバランスだと思う。ちょっと頑張ればSQLのみで済むからSQLに詰め込もうとか、
どうせUAPで処理必要なんだから、SQLでは無理せずにUAP側にロジック入れようとか
いろいろ状況もあるだろうし、適材適所で臨機応変に使って行きゃ良い。
まぁ同一システム内でばらばらだと困るので、ある程度の取り決めは必須だが。

ところで、組み込みSQLで select * 使う人はいないはずだけど…。
さすがにそんな人にはコード書かせないでしょ。

**NAME IS NULL** · 2009/08/25(火) 14:02:27

>>252
>ところで、組み込みSQLで select * 使う人はいないはずだけど…。
>適材適所で臨機応変に使って行きゃ良い。

**NAME IS NULL** · 2009/08/26(水) 02:19:56

>>250
こんばんは。246で発言した者です。

どちらかとの御質問ですが、どれとどれのことか分かりませんでした。
私が不出来なもので申し訳ございません。
先に私が発言した主旨としては以下の様になります。

開発側の人としては画面に表示するデータが1SQLで(select * は論外ですが)、
もちろんジョイン、必要であればサブクエリーを使用し取得したデータ群を、
使用する言語によったデータセットで使った方が楽なのではないかと思った次第です。
(それぞれの環境次第なので一概に言えないのは分かっております。)

214さんはそれぞれ必要な都度SQLを発行し、表示するデータを構築される
ように思われたので上記の様な発言を致しました。
ただ、214さんがデメリットでそのことを挙げておられることを見過ごしておりました。
申し訳ございません。
先に私が発言しました「214さんがSQLを～]の発言は撤回させてください。

その後の「遅かったら運用の～」は私の過去に受けた経験から発言したものです。
開発より、運用に従事している期間が長いものですから。

>>247
お気を悪くされましたらお詫びいたします。

**NAME IS NULL** · 2009/08/26(水) 07:13:53

遅いのは開発側、というよりDB設計者のせいだよ。

**NAME IS NULL** · 2009/08/26(水) 15:34:09

>>254
そもそもの発端はKVS的な設計はどうだろうって論題で、
KVS的な設計では１SQLでデータ取るのは不可能だって話だ
それを前提にしてるから
>214さんはそれぞれ必要な都度SQLを発行し、表示するデータを構築される
ようになってるわけで
１SQLでデータ取れるような設計しろってのは、議論の前提がおかしいだろうが

>>255
その言い方だとDB設計者は開発側の人間じゃないように聞こえるが

**NAME IS NULL** · 2009/08/26(水) 16:03:01

>>214は、この設計を既存のRDBに割り当てて使うって言ってんのかな。

それなら駄目すぎて話しにならんと思うが。

**NAME IS NULL** · 2009/08/27(木) 00:00:34

そもそも「KVS的」といって>>214みたいなのが出てくるのがおかしいし、
あれが1SQLでデータが取得できないというのも変。
いったいオマエラ何の議論をしているの？

**NAME IS NULL** · 2009/08/27(木) 00:27:25

もう>>252がベストアンサーって事で良くね？

**NAME IS NULL** · 2009/08/27(木) 07:01:17

>>259
自演乙

**NAME IS NULL** · 2009/08/29(土) 00:37:35

具体的に1sqlってどこまで許すのか示されてないしな。
まあdb知らない人みたいだから無茶言いそうだが。

**NAME IS NULL** · 2009/09/10(木) 16:45:52

こちらの方がおっしゃっている設計指針についてどう思われるでしょうか。
http://masuda220.jugem.jp/?cid=11
・テーブルの役割・用途は一つ
・（極力？）データに対する更新・削除は行わない
など
なるほどとも思うのですが、役割に応じて分割すると
あまりに細かく分割しすぎて見通しが悪くなりそうな気もしますし、
データの更新・削除を認めないのは冗長かつ非効率な気もします。
実務による、というお答えが返ってきそうですが、一般的な設計指針として
ご意見をお聞かせいただければ幸いです。

**NAME IS NULL** · 2009/09/10(木) 23:30:01

>>262
モデリングの手法としては合ってると思う
ただこの後の工程で、パフォーマンスや効率性を考慮して
冗長化、非正規化することは必要だけど

>あまりに細かく分割しすぎて見通しが悪くなりそうな気もしますし、
モデル上は、細かくテーブル分割してあるほうが分かりやすいよ
テーブル名とリレーション見るだけで何を表しているか分かるからね

>データの更新・削除を認めないのは冗長かつ非効率な気もします。
「データの更新・削除を認めない」って書いてあるところが見つけられなかったんだけど、
どこから引用したの？

**262** · 2009/09/11(金) 06:59:45

>>263
レスありがとうございます。
書籍などではここまで言及してあるものを読んだことがなかったので、
どうなんだろうと思っていたのですが、正しい手法なのですね。
（「正しい」という表現が適切かわかりませんが）

> 「データの更新・削除を認めない」って書いてあるところが見つけられなかったんだけど、
> どこから引用したの？
これは少しコメントを端折り過ぎました。
「テーブル設計　データモデリングのエッセンス（２）」などに書かれているのですが
> ビジネスイベントは一度作成（インサート）したら、後から、更新や削除はしない。
> このテーブルに許される操作は、インサートと参照のみにする。
とあります。
また、ビジネスリソース系のテーブルについても同様の方法を取ることもあると書かれています。

ここに書かれている業務システムの例に合わせて言えば、
受注テーブルは最新の状態にしておき、更新や削除の記録が必要ならば別テーブルにログとして保持する。
受注テーブルにはキャンセルされた受注や変更前の受注は保持しない。
というのが主流だと自分は思っていました。
また、導出テーブルをトリガで作成するという手法も初めて知りました。

**NAME IS NULL** · 2009/09/12(土) 11:16:27

>>1
1. Excelのワークシートと勘違いしてるから。
2. 設計＆指揮者がコードに関心があるのにデータに関心がないから。

レベル低すぎ？

**NAME IS NULL** · 2009/09/12(土) 11:25:44

むしろコボラ上がりが、繰り返し項目を使いたくって、
正規化なんか理想論だ、実際は性能が落ちる原因だとか
トンデモ説を信仰している（ふりをする）からじゃん

**NAME IS NULL** · 2009/09/12(土) 11:35:27

コボラ上がり(かつRDBを知らん)奴なんて数えるほどだろ。
それよりも、RDBしか使ったことがなくても実はわかってない、ってのが
圧倒的じゃないか？>>265の言うexcelと勘違いしてるようなのとか。

**NAME IS NULL** · 2009/09/12(土) 12:27:58

ファイル設計の延長くらいにしか考えてない奴は多いな

**NAME IS NULL** · 2009/09/13(日) 03:40:03

コボルの本読むとそんな感じだしな。
正規化なんて全く記述無し。

**NAME IS NULL** · 2009/09/13(日) 11:52:21

そりゃ正規化はRDBでしか必要ないからな！固定長レコードで正規化
してもテーブルの連結がめんどくさかったら意味ねえ！

**NAME IS NULL** · 2009/09/13(日) 12:47:27

そういえば昔、上から全項目を固定長にしろとお達しがあって、嫌々やったら速度が上がった
（つーか、負荷テスト後もあんまり性能が落ちない）DBがあったなｗ

**NAME IS NULL** · 2009/09/13(日) 13:25:37

その昔の経験って、今も成り立っているのかな？
そこが曖昧なまま薦められても困るのよね。

**NAME IS NULL** · 2009/09/13(日) 16:04:54

今は一般的にはtext型みたいなのが一番速い
長さチェックも空白詰めもしないから
ただしOracleだけは固定長が速い

**NAME IS NULL** · 2009/09/13(日) 18:09:22

>>273
逆だろ。
Oracleには固定長の文字列型なんてないはず。
最小長と最大長が等しい可変長文字列を、便宜上固定長文字列型って騙ってるだけ。
まぁほとんどのDBMSで、列サイズが固定であるが故の速度的メリットは大きいから、
Oracleでも可変長文字列を入れていた項目を擬似固定長に変更した時の速度向上は
見込めるかもしれないって程度。

**NAME IS NULL** · 2009/09/13(日) 18:15:13

> 固定長の文字列型なんてない
> 列サイズが固定であるが故の速度的メリットは大きい
矛盾してないか？最初の文は、内部的には可変長文字列の特殊設定だと
言っているような気がするんだが。

**NAME IS NULL** · 2009/09/14(月) 04:23:37

CHAR型って固定長じゃないのか

**NAME IS NULL** · 2009/09/14(月) 13:32:43

DB2も固定長の方が速いけど。

text型みたいなのはある程度まではそこそこ速いけど、
ある閾値を越えると急に遅くなったりするので
処理系しだいだろうとは思う。

つか、Oracleとかの「こうすると速い」系のネタは都市伝説が多いよなー。

商品コードとかの長さが決まっている項目なら固定長で、
備考の様な長さが不確定な部分は可変長と素直に設計していけばいいのでは？

「速いから固定長」とかはなんか違うだろ。
「考えるのが嫌だから全て可変長」の方がまだスジが通っている。ｗ

**NAME IS NULL** · 2009/09/14(月) 14:32:30

>>275
Oracleは内部的には全部可変長扱いだって聞いたことがあるからそのことじゃね？
DB2とかだと内部的にCHAR型とVARCHAR型は別扱いなので、きちんと使い分けた
方が望ましいけど、Oracleはちょっと変態なのでムリにCHAR型にする必要はないと。

(全ての？)列サイズが固定で速くなるってのはまた別の話で、データの格納と言うか、
表領域の使われ方のことではないかと。まぁどっちかって言うと行サイズだが…。
HiRDBだとFIX表ってわざわざ宣言したりするね。

**NAME IS NULL** · 2009/09/14(月) 17:34:21

オラクルは昔と今では、だいぶ違うけどな。昔の経験なんて引きずってたらそれこそコボラ状態。

**NAME IS NULL** · 2009/09/14(月) 18:09:35

DB2とかは固定長・可変長は分けて処理するしNOT NULLな制約も考慮して
適切な設計にあわせて実スピードは上がっていく。
逆に設計がアレだとあんまし速度はでないRDBMSだな。

Oracleも昔の都市伝説と言うか、昔のヘンテコ小技を今のVerに持ち込むのは
ヤめてくれって感じるな。

普通に設計して普通にSQL書いてください。

**NAME IS NULL** · 2009/09/15(火) 21:32:23

Oracleの仕様がヘンテコだからな

**NAME IS NULL** · 2009/09/16(水) 10:24:42

何でOracleはヘンテコな仕様なのに普及したんだろうね？
M$やらIBMやらが注力しなかったからかな？

**NAME IS NULL** · 2009/09/16(水) 13:25:20

当時は癖のある DB しかなかったよ

**NAME IS NULL** · 2009/09/16(水) 17:52:21

おかげさまで今でもうっかり(+)とかやっちゃうぜ

**NAME IS NULL** · 2009/09/16(水) 20:18:06

>>282
ごめんね、キミの大好きなOracleを馬鹿にしちゃってｗｗｗ

**NAME IS NULL** · 2009/09/19(土) 02:03:14

今日もアホなテーブルとクエリを見てゲンナリした
○○○○○は遅いねってお前の設計が（ry

**NAME IS NULL** · 2009/09/19(土) 18:16:28

>>282
性能がいいものが売れるとは限らない。
大人の事情というのがあるんだよｗ

**NAME IS NULL** · 2009/09/20(日) 07:47:11

まあそれほどまでに当時のSQL鯖/サイベースとDB2が糞だった訳で。
オラクルの出現で競争が生まれ、それらも今やかなりマシになった功績は大きい。
周りのヘンテコDB仕様に合わせて客取り込んでいって成長したから、今でも名残が残るのはしょうがない。だんだん洗練してヘンテコ仕様もろとも下位互換は切ってくだろうけど。

**NAME IS NULL** · 2009/09/20(日) 08:40:22

そもそもまともに使えるRDBMSを最初に売り出したのがOracle。市場での競争が始まるのが
後発のInformix、Sybase、Ingres等が現れてから。DB2もあったけど、当時のIBMはIMSの
商売の方が重要でDB2はほとんど力を入れておらず、顧客がRDBMSを必要とする場合に
程度でSymfowareやHiRDBのような扱い。
MSのSQL Serverや、他社OSでも使えるDB2 UDB(の原型)が現れて現在のような競争状態に
なるのはそれよりもさらに後。

**NAME IS NULL** · 2009/09/20(日) 11:46:31

過去のことはいいから現在一番ましなRDBはなんなのさ。

**NAME IS NULL** · 2009/09/20(日) 12:10:29

今の製品はだいたいみんなまともだろ？あとはどのポイントを重視するか。
総合1位なんて点数のつけ方で変わるよ。

**NAME IS NULL** · 2009/09/20(日) 12:13:25

君の重視するポイントでよろしく頼むよ。

**NAME IS NULL** · 2009/09/20(日) 12:17:20

製品比較は別スレでやれ。

**NAME IS NULL** · 2009/09/20(日) 12:23:38

>>292
じゃあSQLiteが一番だな。これで満足か？

**NAME IS NULL** · 2009/09/20(日) 12:31:17

どのポイントを重要視したの？

**NAME IS NULL** · 2009/09/20(日) 13:31:27

サポート契約してるとOracleって結構不具合とかあるんだなぁ、
って感じますが、他のRDBMSでもあるんですかね？

**NAME IS NULL** · 2009/09/20(日) 21:30:20

DB2も不具合はある。
Oracleよりは少ないが、それだけDB2普及していない証明でもあるような希ガス。

別に不具合あってもいいんだけどさ、それの対応がタマに「我慢汁」とか「それはOSの不具合です」
とか解決に繋がらない回答を貰うと、「あー、Postgresでいいじゃん」とか思うな。

**NAME IS NULL** · 2009/09/20(日) 23:21:46

DB2は、「なんでいまだにこんなバグが？」と思うようなのがけっこうあるね。
インスタンスダウン→「次のFPで修正されます」のコンボに何回遭遇したか。

**NAME IS NULL** · 2009/09/21(月) 00:11:44

DB2ってiSeriesは鉄なみの硬さがあると思うが、それ以外のプラットフォームは・・・。
Oracleもよくインスタンス落ちるがiのDB2は落ちた事がない。

これもIBMの中の人とガチで仲良し(?)レベルで会話できる人が少ない性もあるんだろうな。

**NAME IS NULL** · 2009/09/21(月) 12:39:41

単にasはろくな処理してなくて使い込んでないから固く見えてるだけじゃ。
全部as内完結で、不安定になる様な秘穴を突けなくしてあるとも言うが。

オラは、いろいろ弄れる割に秘穴を突いてしまう確率が高くなるだけ。
ちゃんと組めばド安定で運用出来るよ。RACも組めるし。

ポスグレはサポート無いから、業務では選択肢に無いな。
マイエスはオラクルがサポートしてくれるなら、これから使う鴨田が。

**NAME IS NULL** · 2009/09/21(月) 15:08:44

結局なんだかんだ言いつつサポートの有無でプロダクトを選ぶという矛盾が
別にサポートあったって落ちたときに損害補償してくれるわけでもないんだし
金払うだけ無駄なのがサポートだぜ
パッチの提供なんて逆にPostgreSQLなんか速攻で修正されて出てくる
オープンソースだから原因も即バレで、仕様ですと隠される事もないしな

**NAME IS NULL** · 2009/09/21(月) 15:42:44

矛盾つーか、セルフサポートできるんならOSSも選べるってだけだろ。
一応サポート契約していれば、どんな障害/質問に対しても「マニュアル
読め」以上の何らかの回答を一定期間内にしてくれるし。

**NAME IS NULL** · 2009/09/21(月) 16:42:14

んでその回答って役に立つのか？
PostgreSQLの構築/運用実績あるSIにやって貰った方が
Oracleに無駄に500万払い続けるよりマシな気がする

**NAME IS NULL** · 2009/09/21(月) 17:14:32

おめーら別スレでやれよ

**NAME IS NULL** · 2009/09/21(月) 17:54:54

>>303
サポート契約してれば何か起きたときの事故対策会議で「サポートに問い合わせ中です」
って言える。もちろんその後は「原因不明なので再現待ちです」って逃げる。
DBMSに限らず、商用OS等でも良くあるが…運用担当者が泣く黄金パターンだよな。

まぁ実際問題として、サポートにまともな回答もらえるとはだれも思ってないんだよ。
ただ、実質使えないサポートであっても、それを望んでいる客がいるのもまた事実だから、
そういう提案してしまうのはしょうがないと思う。

**NAME IS NULL** · 2009/09/21(月) 18:55:49

>>303
そりゃ役に立つ人はいるだろうさ。
当然、Postgresでシステム構築したとしても、Postgresのサポートを
必要とする場合だってあるだろうし。

**NAME IS NULL** · 2009/09/21(月) 23:09:15

＞PostgreSQLの構築/運用実績あるSIにやって貰った方が
＞Oracleに無駄に500万払い続けるよりマシな気がする

ぶっちゃけその通りだけどな。

漏れの中ではOracleは言うほどマシなRDBMSじゃないと認識している。

Oracleが必要な業務があるのは事実だろうが、多くの導入例では
「Oracleはいらんだろ」的な納品されている現場は多い。

**NAME IS NULL** · 2009/09/22(火) 09:05:44

しかしPostgresのシステム構築やサポートできるSIなんて
付き合いある範囲じゃ見当たらないな。

**NAME IS NULL** · 2009/09/22(火) 11:04:07

オープンソースのDBすら自分で構築しようとしないエンジニアって・・

**NAME IS NULL** · 2009/09/22(火) 11:39:52

それは「システムを自分で開発しないエンジニアって」と言っているに等しいぞ。
内製するかどうかとオープンソースかどうかなんてあんま関係ない。ただ、開発を
SIに任せる場合にOSSで受けてくれる業者がほとんどないというだけ。

**NAME IS NULL** · 2009/09/22(火) 12:29:28

>>308
知り合いかどうか知らんがPostgresはNTTやらNEC系はやってるな。

別に漏れもヤれと言われれば並みのOracle程度には出来る。

つか漏れも社内のなんちゃってテスト環境用にはDreby使っている。

**NAME IS NULL** · 2009/09/22(火) 12:56:37

まぁ会社としてサポートするとなると、スキルのある要員の継続確保が問題になるな。
俺的には別に特殊なスキルが必要とは思えないのだが、商用/フリーに関わらず
調査すら出来ない人間ってのが意外といるわけで。

**NAME IS NULL** · 2009/09/22(火) 14:38:29

OSSは裾野の部分がまだ弱いからねぇ。研修制度とか、サードパーティの層の厚さとか。
Linuxは大メーカー自身が手がけるようになって大分よくなったけど。

**NAME IS NULL** · 2009/09/22(火) 15:22:04

オープンソースのサポートなんて遣るくらいならオラクル保守入って丸投げのほうが楽だな。
オープンソースで手厚いサポートできるようなスキルある香具師雇うなら、オラクル以上に金かかりそうだw

オラクルに損害賠償請求する馬鹿企業は居ないが、個人に損害賠償してくる馬鹿企業は山ほど居るだろうし。

**NAME IS NULL** · 2009/09/22(火) 20:15:18

>>314
凄い妄想だな。

底辺のオマエには知らん世界だろうが、Oracle使った案件でも契約書に
損害賠償跳ね除ける文面が契約事項としてあげてあるベンダーがほとんどだが。

**NAME IS NULL** · 2009/09/23(水) 06:02:53

Postgresにサポートが無いとか、お前らシロート？

**NAME IS NULL** · 2009/09/23(水) 09:08:19

比率で言うならOracle信者ほど素人が多いのは不思議な現実。
サポートが心の拠り所らしい。

**NAME IS NULL** · 2009/09/23(水) 11:28:58

ポスグレで自分で面倒見るのは自殺行為なんだよ。

**NAME IS NULL** · 2009/09/23(水) 15:25:24

別に「Oracleはインタンスが絶対に落ちなくてサポートが満足な製品で漏れは一度も苦労した事ない」
と言える製品ならそれはそれで構わんよ。

漏れはそんなOracle見た事ないが。年に１・２回はｲﾐﾌﾒｲに落ちる。

ただまあ、漏れの経験でｲﾐﾌﾒｲに落ちた場合サポートに問い合わせても「原因不明です。OSかハードに問題があると思われます」
の逃げ口上が出て終わりなんで、PostgresだろうとOracleだろうと能力のない人間が構築したシステムは
どれも自殺したくなる。

むしろ、上の発言で出てきた問題を全てIBMに投げられるiSeries、もしくはOSSだからと言う理由でPostgresを
選んだほうがラクになれる。

**NAME IS NULL** · 2009/09/24(木) 07:36:57

データやSRAは独自パッケージまで出してるのに

**NAME IS NULL** · 2009/09/25(金) 13:21:23

設計

**NAME IS NULL** · 2009/09/25(金) 16:04:56

今までで一番酷かったのがLinuxの8iだな
2000万払った挙げ句、使用は自己責任でとか言われたｗ

**NAME IS NULL** · 2009/09/26(土) 15:26:21

Linuxの8iって人柱Verだった頃のじゃね？

まあ、未だにそれで動いているトコはあるんだろうけど。

**NAME IS NULL** · 2009/09/26(土) 20:34:26

要するに人柱バージョンを2000万でうりつけてるのかｗ

**NAME IS NULL** · 2009/09/26(土) 21:00:40

値段は規模にもよるから、Linuxで8iで2000万が高いか安いか判断が難しいが。

HP-UXの8でもそれくらい取るベンダー見た事あるし。ただイニシャルはともかくランニングコストは
あんまし安くなかったが。年600万くらい。

Linuxの8iは自己責任と言うからにはランニングコストは０なんだろ。w

DB2(iSeries)だとイニシャルは下は300万で上は２億くらいの幅でランニングは100～600万くらい飛んでいく。

**NAME IS NULL** · 2009/09/27(日) 03:34:04

8iの頃はソラリスが鉄板だったので、リナックスなんて選んだほうが自殺行為なだけ。
東証がポスグレ採用なんて無謀な事はしないのと同じ。

IBMに丸投げ出来るぐらいの資金が有るなら、日電や不実に丸投げしてオラクルの面倒見てもらえるけどな。

うちはRACだけど意味不明に落ちてもリカバリは出来る仕組みにしてるよ。
そもそも絶対に落ちないなんてあり得ないし、ソフトのバグが無いのも信用してない。PGなんてバグ入りの欠陥品しか作れないし。製造業の品質管理に比べたら認識が甘過ぎるよ。
逆に、ポスグレは絶対落ちなくてサポートも満足と保証されてるの？

２億の案件でポスグレで組んで、損害賠償なんて喰らったら人生終わるなw

**NAME IS NULL** · 2009/09/27(日) 04:40:49

oracleは絶対落ちないなんてありえない前提なのにpostgreには要求するのかｗ
どんなdbを使おうがフェイルセーフな構成にすればいいって自分で答えだしてるじゃん

**NAME IS NULL** · 2009/09/27(日) 19:50:33

>>326
なんかあんまし大型案件やった事ないみたいなのでコメントだが。
規模と傾向もあるが基幹系ならIBM(i)とその他のベンダー＋Oracleの組み合わせだとIBMの方が半額くらいのコストで開発・運用が可能だ。
無論、Oracleの方がコスト安いケースもあるが、「IBM＝高い」と言うのは思い込みだ。
ある程度以上の資金がいるのは事実だが、>>326の意見は「安物買いの銭失い」な思考だ。

そして東証もけっこう落ちてるじゃねーかｗ

**NAME IS NULL** · 2009/09/27(日) 20:40:49

いいよな。天下りで仕事もらえるようなところは。
東証を落としてもお咎めなしだぜきっと。

**NAME IS NULL** · 2009/09/29(火) 01:30:04

逆にIで落ちてたら大変なんじゃねw

**NAME IS NULL** · 2009/09/30(水) 01:32:27

何故データベース設計は軽視されるのか？

**NAME IS NULL** · 2009/09/30(水) 05:39:47

痛い目に会うような複雑なシステムじゃないから or ( 痛い目は末端がくらって表に出ない and それが痛い目だと気が付いていない )

**NAME IS NULL** · 2009/09/30(水) 16:53:59

ちゃんとコスト計算が出来るまともなエンジニアが皆無。

**NAME IS NULL** · 2009/10/09(金) 23:00:06

アプローチ使ってるけど、アプリの使い方じゃなくて、データベース設計の初心者本てなんかないかな

**NAME IS NULL** · 2009/10/10(土) 17:22:36

>>334
デマルコ読め

**NAME IS NULL** · 2009/10/11(日) 17:53:45

http://www.amazon.co.jp/dp/4822281116

これ読めばいいの？

**NAME IS NULL** · 2009/11/24(火) 00:12:10

賢者に聞いていいですか？

たとえば、２ｃｈとか「PC等」→「プログラム」→「【PHP】CakePHP」→「レス」って構成ですよね。
これってどういうDB設計になってるんですか？
実務経験がないのでわかりません。

「PC等（カテゴリID）」→「プログラム（カテゴリID＋サブカテゴリID）」→「【PHP】CakePHP（サブカテゴリID＋スレID）」→「レス（スレID＋レスID）」
　　　　　　　　　　　　　→「デスクトップ（カテゴリID＋サブカテゴリID）」→「cpuをとっかえたい（サブカテゴリID＋スレID）」→「レス（スレID＋レスID）」
って感じですか？

１つのデータベースに、テーブルを1000個とか作ることとかあるんですか？
その場合、テーブルの名前を特定して探しにいく方法でしょうか？

**NAME IS NULL** · 2009/11/25(水) 01:58:52

2chはdbじゃないので(ry

http://pc11.2ch.net/test/read.cgi/db/1056967775/
SQL総合案内スレッド
http://pc11.2ch.net/test/read.cgi/db/1133798099/
姉歯DB設計

**NAME IS NULL** · 2009/11/25(水) 20:11:39

マジ？2chはファイル記憶なの？

**NAME IS NULL** · 2009/11/25(水) 20:47:50

普通に考えれば2chはファイルだし、事実そう。
RDBで実装する意味が解らん。

**NAME IS NULL** · 2009/11/25(水) 23:19:21

2ｃｈの量でもファイル入出力に耐えれるものなのか。
人間のイメージなんてちっぽけなものなんだな。

**NAME IS NULL** · 2009/11/25(水) 23:34:29

>>341
実務経験がないから仕方ないのかもしれんが、
RDBに不思議な幻想を持つのはヤめた方がいい。

2chの場合は要求される仕様が「追記オンリー、更新は基本なし、当然削除もなし
発言は1000もしくは512KB(板によるが)で、ブラウザを使うユーザーにはhtml変換し
専用ブラウザはdat直読み。

そして圧倒的な書き込み&ＰＶときたら並のRDBMSでは即死する。

**NAME IS NULL** · 2009/11/25(水) 23:42:32

ありがとう。ファイル入出力の方がいいんだね。
たしかに、DBは偉大ってイメージがあるかも。組み込みエンジニアだからDBに縁がなくて。

twitterと2chは同じようなものかと思ったの。twitterはDBだよね。メンバーの紐付けあるし。
無数にレコードが追加されるからどういう設計なのかなーって。

**NAME IS NULL** · 2009/11/26(木) 00:17:44

twitterは細かい事は知らんが、最初Rubyとデータベース使って結構落ちてなかったか？

そりゃ2chだってタマに落ちるけどな。

**NAME IS NULL** · 2009/11/27(金) 00:30:39

ファイル入出力のほうがいいというのは間違い。ISAMファイル直弄りのコボラーに成りたいならともかくw

ツイタはしばらくすると消えるからdbのほうが向いてる。

潤沢な資金力さえ有ればdbでも捌けると思うけどね。
東京証券取引所の売買銘柄数や売買高でもちゃんとdbで注文捌いて約定処理が出来てるし。

組み込みでも携帯のアドレス帳ぐらいはdbで作ってあると思うよ。テキストファイルで管理だと大変だし。
当然組み込み用のdbもある。

http://pc11.2ch.net/test/read.cgi/db/1207476744/
RDBMS比較総合スレ【サーバ】
http://pc11.2ch.net/test/read.cgi/db/1063716668/
MSDEよりいいDB、ありませんか?

**NAME IS NULL** · 2009/11/27(金) 00:59:55

twitterの設計の想像がつかない。

**NAME IS NULL** · 2009/11/27(金) 02:15:50

＞ファイル入出力のほうがいいというのは間違い。ISAMファイル直弄りのコボラーに成りたいならともかくw
（略
＞潤沢な資金力さえ有ればdbでも捌けると思うけどね。

金かければなんでも出来るだろ。
コストパフォーマンス無視して「ＤＢの方が向いている」なんて・・・。

2chのサーバーと同じ導入コストでRDBMSを用いて実装し、
2ch以上のパフォーマンス出してから語ってくれ。

そして東証も派手に落ちてニュースになったんだが。
あれを「ちゃんとdbで注文捌いて約定処理が出来てるし。」とコメントできる神経が凄いな。

**NAME IS NULL** · 2009/11/27(金) 02:49:00

お前らDBDB言ってるけどRDBMSのことだろ
テキストファイルだってなんだってDBはDBだ

**NAME IS NULL** · 2009/11/27(金) 14:26:38

twitter は、元は Ruby on Rails じゃなかったっけ。今は知らないけど。
RoR は O/Rマッパーに ActiveRecord 使ってるから、多分バックエンドの DB は
RDBMS だとは思うけど、何を使ってるかまでは調べてない。

そういえば、ニコニコ動画のコメントサーバはバックエンドに MySQL 使ってるね。
更新頻度の高いテーブルと低いテーブルに選別して、InnoDBとMyISAMを
使い分けてると、どこかに書いてあった。あと memcached だったかの
キーバリューストアも併用して、パフォーマンス稼いでたはず。

ってか、この辺の話はDB設計と言うより、アーキテクチャ設計の話だね……

**NAME IS NULL** · 2009/11/27(金) 14:40:31

むしろバックエンドにDB使ってないシステムなどまずない

**NAME IS NULL** · 2009/11/27(金) 20:55:10

とりあえず、>>350が利用している2chはRDBは使っていない

**NAME IS NULL** · 2009/11/28(土) 03:36:12

いやだからRDBMSじゃなくてDBは使ってるだろ
テキストファイルに書き出すのだって独自DBなわけで

**NAME IS NULL** · 2009/11/28(土) 07:31:54

逆に東京証券取引所の規模でテキストファイルのほうが無茶だろ。
銀行の取り付け騒ぎで人が大量に押し寄せてATM操作するとISAMでがんばってるホストが堕ちるのと同じ。

テキストファイル自体はdbじゃないだろ。

**NAME IS NULL** · 2009/11/28(土) 09:10:00

＞ATM操作するとISAMでがんばってるホストが堕ちるのと同じ。

ナニ言ってんだ？コレ？

タイムアウトやら領域が足りなくてトランザクションがコケた事とISAMの関連が意味不明。
ISAMでなく、普通のRDBでも帯域＆領域足りなきゃ落ちるのは一緒なんだが。

テキストを独自ＤＢと言うのは痛いが、引き合いにホストを持ち出してトンデモ理論展開スナ。

**NAME IS NULL** · 2009/11/28(土) 12:06:43

>353-354
データベースの定義＠ Wikipedia
> 特定のテーマに沿ったデータを集めて管理し、容易に検索・抽出などの
> 再利用をできるようにしたもの。
> 狭義には、コンピュータによって実現されたものを言う。

広義には記録メディアが紙だろうが石版だろうがDBはDBなんだぜ。
テキストファイルは言わずもがな。

**NAME IS NULL** · 2009/11/28(土) 14:30:13

小学生は2chなんかせずに外で遊んでこいよ。

**NAME IS NULL** · 2009/11/28(土) 15:04:45

とりあえずテキストファイルがＤＢと言うヤツは
ニコ動とか東京証券取引所のシステムを「石版」で構築してから語ってくれ。

**NAME IS NULL** · 2009/11/28(土) 15:22:55

MySQL CSVストレージエンジン・・・

**NAME IS NULL** · 2009/11/28(土) 15:52:18

テキストファイルだけならDBじゃないけどプログラムとしてテキストファイルを使うなら
それを読み出してデータストアとして利用するロジックがあるんだからDBと言えるだろうに
ただ石板は情報システム的にDBにはなり得ないから例えが悪い

**NAME IS NULL** · 2009/11/28(土) 15:54:11

テキストファイルはDBにならないって言ってる奴は、
ミドルエアとしてのDBMSと勝手に解釈して限定してるんだろ。

**NAME IS NULL** · 2009/11/28(土) 16:25:41

>>359
追記専用で基本屋外設置かつメンテ頻度も大変低いという条件下では
中の人の名前が順に彫り込まれる墓石というデータメディアは大変に
優れたものだと思う。
何より墓石メディアを用いた墓場というDBは古くは古代メソポタミア
に始まる何千年もの利用実績があるわけで、侮れん。

**NAME IS NULL** · 2009/11/28(土) 18:50:14

必死に話をそらそうとしているのを見ると頭が可哀想な人なんだろうな。
常識でモノを考えて喋ってくれ。
会社でよく「コミュニケーション力が低い」と怒られている人だろうけど。

**NAME IS NULL** · 2009/11/28(土) 18:57:49

>357
指摘が全く意味不明だ。
石版メディアを使ったDBは読み書きが遅く電子処理に向かないので、
東京証券取引所では使えない。それだけの話がなんで理解できない？

おそらく君が「DB」と呼んでいるものは、正式には「RDBMS」だ。

**NAME IS NULL** · 2009/11/28(土) 19:02:55

いやだから現実的に情報システムで利用できる媒体のみで語れよ
テキストファイル、パンチカード、印刷物あたりまでは理解できるが
石板をシステムで読み書きするシステムなんて現実的に存在しないだろ

**NAME IS NULL** · 2009/11/28(土) 19:09:00

>>364
今は純粋に「データベース」という言葉の定義についての話をしてるんだろ？
情報システムで容易に媒体以外はデータベースにあらず、というのは単に君個人の
思い込みであって常識じゃない。
電話帳は電話番号のデータベース。これが常識レベルの解釈。

**NAME IS NULL** · 2009/11/28(土) 19:10:15

× 容易に媒体 ⇒ ○ 容易に扱える

そういう意味じゃ、石版がNGなら紙もNGだろ。

**NAME IS NULL** · 2009/11/28(土) 19:30:53

現実問題として紙に印刷しておいてあとでドキュメントスキャナで取り込むというデータの保存の仕方はあるけれど
石板に掘っておいてあとで読み込むなんて使い方をしている奴は誰もいないわけで

**NAME IS NULL** · 2009/11/28(土) 19:36:05

だから、昔は住所データベースが手書きだったりしたんだってば。
電子的に扱えるかどうかなんて問題じゃないんだって。

**NAME IS NULL** · 2009/11/28(土) 19:43:07

しかし、「データベース」の定義に照らしてもやっぱり2chはデータベースじゃないわな。

**NAME IS NULL** · 2009/11/28(土) 19:56:06

>>368
印刷物はDBとして使えるって言ってるじゃんみんな
否定されてるのは石版なんてとんでもない例でしょ？

**NAME IS NULL** · 2009/11/28(土) 19:56:53

>>369

**NAME IS NULL** · 2009/11/28(土) 20:53:21

>370
手書き文書は印刷物じゃないし、情報システムと親和性が無いのは石版と同じ。
石版の話は極端な例だけど間違いや嘘じゃない。
「データベースと呼べるかどうか」は、使いやすい／使いにくい、早い／遅いなんて
話とは別次元の問題だよ。

**NAME IS NULL** · 2009/11/28(土) 20:57:48

>言ってるじゃんみんな
「みんな」が誰を指してるのか知らんが、世の中の常識とは言葉の認識が乖離してるな。

**NAME IS NULL** · 2009/11/28(土) 21:02:17

紙も石板も単にメディアの一種にすぎない
データベースってのは、メディアは関係ない

ハンドリングの容易さとか管理のしやすさとかは別の話

ＤＢとＤＢＭＳの区別ついてない奴が多すぎるな
俺も普段はＤＢ＝（Ｒ）ＤＢＭＳの意味で使ってる場合が多いが
こういった議論のときはきっちり区別しろよ

**NAME IS NULL** · 2009/11/28(土) 21:15:58

テキスト/バイナリ、電子メディア/紙/石版wなんてのは単に実装方法の違いだけの
話なんだよね。DBかどうか、ってのは記録された情報の性質で決まる事なんだから、
「テキスト形式で保存したから」「記録媒体がアナログだから」なんて理由で
DBじゃなくなるという理屈は根本的におかしい。

**NAME IS NULL** · 2009/11/28(土) 22:21:58

うちの墓石にも幕末から死んだ先祖の名前と日付が掘ってあるけど、あれもDBだったんだな

**NAME IS NULL** · 2009/11/28(土) 22:49:14

「データの再利用を目的として、特定のテーマに沿ったデータを集めて管理したもの」では
ないので、墓石はDBとは呼びにくいな。
上記の目的で墓石にデータを記録したなら、それはDBと呼んで差し支えない。

**NAME IS NULL** · 2009/11/28(土) 22:54:56

>>377
>特定のテーマに沿ったデータを集めて
お墓の中に入っている人の名前しか入っていないけど。

>データの再利用を目的として
毎年お墓参りしないの?

**NAME IS NULL** · 2009/11/28(土) 23:12:30

>378
一般的には、墓石は単に故人の名前を残すこと自体が目的だと思うけど。
例えば「大量の先祖の中から特定の故人の名前を探す事を容易にする」のを目的に
墓石に名前を彫ったんだとしたらDBと呼べるんだろうけど。
目的がデータの再利用ならデータの構造も探索に適した構造になってる筈だけど、
故人の名前に見出しが付いてたりはしないだろ？

>毎年お墓参りしないの?
俺はしないw
つか、お墓参りはデータの再利用なのか？

**NAME IS NULL** · 2009/11/28(土) 23:18:18

没年でインデクシングされた故人データベースとして使う事は可能だなw

**NAME IS NULL** · 2009/11/28(土) 23:27:29

所詮墓石はデータメディアにしか過ぎない。
墓地の管理人さんも含めて初めてデータベース管理「システム」
と呼べる。

**NAME IS NULL** · 2009/11/28(土) 23:36:57

過去帳ならともかく、墓石そのものは集積されていないからなぁ。

**NAME IS NULL** · 2009/11/28(土) 23:52:27

墓石とか石版とかどうでもいいよｗｗｗ

**NAME IS NULL** · 2009/11/29(日) 00:06:05

>>383
しょうもない話だけど、本質を捉えていて面白いじゃないか。
こういう話を見てると、普段「データベース」という物がいかに
表面的かつ一面的にしか捉えられていないかが解るな。

**NAME IS NULL** · 2009/11/29(日) 05:16:11

しかし「データベース」の定義という知識が必要となることはまずないからなぁ。
今では博物学的意味しかないかもしれん。

**NAME IS NULL** · 2009/11/29(日) 05:22:49

テキストファイルや紙までなら理解できるけど
石版とかになるともうデータを取り出す目的で作ってるわけじゃないし
データベースじゃなくてストレージなんじゃないかと

**NAME IS NULL** · 2009/11/29(日) 06:09:08

ストレージがなければデータベースも実装できないのだが。

**NAME IS NULL** · 2009/11/29(日) 06:31:32

自動車にはタイヤが必要だがタイヤは自動車ではない

**NAME IS NULL** · 2009/11/29(日) 07:40:55

データベースは物質ではなくて概念の名前。
石版の例で言えば、厳密には石版そのものがデータベースなのでなく、石版に記録された情報が
データベースなの。

> 石版とかになるともうデータを取り出す目的で作ってるわけじゃないし
この話は「仮にデータの集積方法が石版への記述であったとしてもDBはDB」という例え話だろ。
データを取り出す目的で石版を作る事だって当然できる。
ほかのデバイスより読み書きの効率が悪いとか集積率が悪いとか、そんな事はここでは全く
問題ではない。

> しかし「データベース」の定義という知識が必要となることはまずないからなぁ。
知識以前に常識の問題だと思う。
データベースという言葉が何を指すのか知らないで日々その言葉を使うのか？
狭義のDB＝DBMSの中にもDBって言葉は入ってるんだぜ。

**NAME IS NULL** · 2009/11/29(日) 08:23:41

「DBMS」と「データベース」は異なる概念だというのは常識レベルの話だとしても、
あるAが「データベース」の定義にはてはまるかどうかという判断が求められることって
こんな議論の場でもなきゃまずないだろ。だいたい、「データベース」という言葉は
そもそもDBMSと比較して定義があいまいだし。
掲示板/BBSという用語を正確に定義付けられなくても2chやるのに何の支障も
ないってことよ。

**NAME IS NULL** · 2009/11/29(日) 09:06:02

なんでこんな現実性のない言葉遊びで熱くなれるんだ？

職場で「空気読めないヤツ」とか言われないか？＞石版データベース君

**NAME IS NULL** · 2009/11/29(日) 09:06:16

> あるAが「データベース」の定義にはてはまるかどうかという判断が求められる
日常的に行われている事だけど、当たり前過ぎて普通は意識しないだけだろ。

というか、そんな高尚な話か？
一から十まで常識レベルの話をとくとくと聞かせてるのに、まるで理解してるように
見受けられないから話が長引いてるだけだと思うんだけど。

> 掲示板/BBSという用語を正確に定義付けられなくても2chやるのに何の支障も
> ないってことよ。
エンジニアが仕事で使うならそんな訳にいかんだろ。ちゃんとしろよ。

**NAME IS NULL** · 2009/11/29(日) 09:14:55

>391
石版の話は単なる例え話だ。言葉の定義は単なる遊びでなく現実の問題だ。
散々感覚のズレを指摘されてるのに反省が見られんな。
こういういい加減な奴が技術者ってのが信じられん。

**NAME IS NULL** · 2009/11/29(日) 09:20:20

言葉遊び云々を言うなら、「テキストで保存したらもうDBじゃない」という
主張の方がよっぽど屁理屈だと思うんだ。

**NAME IS NULL** · 2009/11/29(日) 09:44:03

>>392
別に判断が必要じゃなきゃ仕事でもしないだろ。そもそも、データベースに該当するか
どうかという判断なんて、たとえばどういうケースで何のために行うの？

**NAME IS NULL** · 2009/11/29(日) 09:58:23

判断するというより、言葉の指す意味の範囲を知っておく事が重要だよ。
仕様書に「ログインユーザのデータベースを作成する」と書いてあったとして、
書いた側と受け手に共通認識が無いとおかしな事になる。
ぶっちゃけこういう時、勝手にRDBMSの準備をする奴は無能なエンジニアだと思う。

**NAME IS NULL** · 2009/11/29(日) 10:17:09

＞仕様書に「ログインユーザのデータベースを作成する」と書いてあったとして、

この場合は普通にDBMSを用いてログイン情報を管理する事を想定すると思うが。

要件に「ログインユーザの履歴を記録する」ならテキストに順次書き出しを想定する。

＞書いた側と受け手に共通認識が無いとおかしな事になる。
＞ぶっちゃけこういう時、勝手にRDBMSの準備をする奴は無能なエンジニアだと思う。

現実の仕事だとすり合わせとか会議があるからありえないケースだが、
そういう発想できる人の方がコミュニケーション能力と実務経験が欠如したエンジニアだと感じる。

**NAME IS NULL** · 2009/11/29(日) 10:30:07

DBを作成するけど、所謂DBMSを使わない案件だっていくらでもある。
DBが概念に過ぎない事を知っているエンジニアは、実装はどうするか？という発想になる。
そうでない人はDBMSを使う（仕様作成元は使いたがっている）と信じて疑わない。

> 現実の仕事だとすり合わせとか会議があるからありえないケースだが
勘違いしたまま実装まで行かないのは当然。
だだし、すり合わせの場でその話が出るまではずっと勘違いしてるわけだ。

仕事の仕方は全然違うと思うがね。

**NAME IS NULL** · 2009/11/29(日) 10:31:32

>>396
コミュニケーションミスの話はまた別のような。

「AはXである」
「『Iさんの言うA』はXである」
この2つの命題はは異なるからね。

データベースとDBMSは概念が異なるという常識があって、その上でその仕様書に
書かれた「データベース」がどちらを指しているのか明確でなく、さらにその違いが
実装する上で重要な違いなのであれば、普通は確認するよね。
そういう状況で、「『データベース』は必ずしもDBMSを必要としない」といって
勝手にテキストファイルで作ってしまうのも同様に困ったチャンだろうね。
後で客と「データベースを作れと言ったじゃん」「テキストファイルでもデータベースです」
みたいな押し問答になったりして。

**NAME IS NULL** · 2009/11/29(日) 10:42:43

石板DB否定派＝DBとは実装のこと。テキストがDBの実現手段に含まれる事を想像もしない。
石板DB肯定派＝DBとは概念のこと。DBの実装形態が様々あることを理解し、色々な可能性を想定している。

DBを概念として捉えている人は、実装について勝手な思い込みはしない。

> 勝手にテキストファイルで作ってしまうのも同様に困ったチャンだろうね。
その人はポジション的に石板DB否定派だと思う。

**NAME IS NULL** · 2009/11/29(日) 10:46:30

>>397
>この場合は普通にDBMSを用いてログイン情報を管理する事を想定すると思うが。
スタンドアロンや組み込みのシステムでもかい？

**NAME IS NULL** · 2009/11/29(日) 10:55:39

>>400
アンタさぁ、自分ひとりが後者、他の全員が前者だと思ってるだろw

**NAME IS NULL** · 2009/11/29(日) 10:58:48

既婚女性板はカルト団体の糖一教回や、そよ風などが支配し世論工作をしています。
既婚女性に成り済ましレスを繰り返してます。
残念だが既婚板の政治スレは全部カルトの工作スレです。
例えばこのスレ
↓
【民主党の政策に不安を感じる奥様の雑談室】その80
http://hideyoshi.2ch.net/test/read.cgi/ms/1259420965/
web魚拓
http://s03.megalodon.jp/2009-1129-0505-19/hideyoshi.2ch.net/test/read.cgi/ms/1259420965/

**400** · 2009/11/29(日) 11:01:08

>402
いや、常識的な大半のエンジニアが後者、このスレにいる数名が前者だと思ってるが？
なんでそう思う？

**NAME IS NULL** · 2009/11/29(日) 11:21:32

その「数名」ってどこにいるの？
その話題でループしてんのアンタ一人じゃない？

**400** · 2009/11/29(日) 11:28:21

>405
そもそも石版の話を出したのは俺じゃないんだけどな。
テキストファイルはNGだ、紙ならセーフだ、墓石はどうだ、なんて話をしてた人は
明らかに前者だろ。石版DBの話にチャチャ入れてた奴も前者だと思ってるけど。
あ、君がどっちかは知らんよ。

**NAME IS NULL** · 2009/11/29(日) 11:41:05

どうせもう「前者」は居ないんだろうし、
>337以前の流れに戻そうや。面白かったけど、ちょっと引っ張りすぎ。

**NAME IS NULL** · 2009/11/29(日) 11:43:41

墓石のチャチャいれ？>>382なら俺だ。
つかその時点で既にデータベース≠DBMSが前提の議論じゃん。

**NAME IS NULL** · 2009/11/29(日) 11:52:49

>>408
>383 とか >391 のつもりだったんだが。
>382はそれもそうだなあ、と思いながら読んだよ。

> その時点で既にデータベース≠DBMSが前提の議論じゃん
君はそうかも知れんけども。
>386 とか >397 は理解してるようには見えん。

**NAME IS NULL** · 2009/11/29(日) 12:45:50

なんか休日に寂しい暇人が勝手に敵を作って「俺Sugeee」って言ってるスレだな。

定義厨は他人の意見を絶対に聞き入れないからカキコするだけ無駄だな。

**NAME IS NULL** · 2009/11/29(日) 16:25:18

馬鹿は反省しないから馬鹿なんだよね

**NAME IS NULL** · 2009/11/29(日) 17:19:39

DBとDBMSの区別もつかないレベルの人に仕事が回ってきちゃうぐらい
データベース設計が軽視されているという流れでOK？

**NAME IS NULL** · 2009/11/29(日) 18:15:34

DBってドラゴンボールですか？

**NAME IS NULL** · 2009/11/29(日) 23:57:19

墓石をデータの永続化対象として何がいけないのか、さっぱりわからん

**NAME IS NULL** · 2009/11/30(月) 00:10:22

曰く「実際にそういう実施例が存在するかどうか」が重要なんだそうだ。
頭が固いを通り越してアホとしか思えん。