何故データベース設計は軽視されるのか？
何故データベース設計は軽視されるのか？
ここでいうデータベース設計とは、
特定の業務システムにおける
テーブルレイアウトを設計し、決める作業であるとします。
業務システムにおいては、
このデータベース設計（テーブル設計）は仕様そのものを定義する作業にも
近いと思いますし、この設計は開発工程やその後の運用における品質を
絶対的に左右するものだと思っています。
逆にこの設計があまりにも実現すべき仕様と比較し不整合なため、
その後の開発工程がデスマーチに陥ることも少なくないのではないでしょうか？
にも関わらず、正規化程度も理解できないような担当者が
この設計を行っていたり、業務システムの受託開発において、
「テーブルレイアウトを決める」という作業が、あまりにも軽視されているような
気がしています。
みなさんの現場ではどうでしょうか？
ご意見などお聞かせください。
理解しなくても、会社の資本金を出してたり、出資者から任命されてたりするから権限持ってる。
文句有るなら自分の資金で設計遣ってれば良い。 どんなまずい設計のシステムでも、
実際に運用されていて問題のないものはあまりいじらないものだよ。 まずさ加減に寄るな。
致命的なのや、将来的に問題になりそうなのは苦労してでも弄らないと後で困るよ。
弄らないまでも、報告だけはしてシステム関係者の中で共通認識は築いておくべき。
後で、問題が起きてからDB担当の個人の責任にされたほうが割喰うよ。 もちろん問題点の把握はしておかなければいけない。
あと、問題が発生して誤動作したときのリカバリーの手順とかもマニュアル化しておく。 誤動作する時点て致命的じゃないのかなあ。
データ失うよね？ >>203=205は
もっともらしい事言いたいだけの
他の板に居場所がない老害コボラー
>>206 完璧主義者の集まりが作ったシステムなら あっさりデータなくなるだろうけど
多少の開発経験がある人が居れば DB経験がなくても バックアップや履歴、ログは残るはずだよ
スムーズに復旧できるかどうかは別の問題だが… むやみに正規化できないケースはいくつもあるぞ。
顧客コードとそれに対応する顧客名称などがテーブルにあっても、
実はマスタ化するまでもない一見の顧客の場合、特定のコードを使って、
顧客名称のみ画面から入力したいという与件があったりするケース。
ＥＤＩで顧客からマスタと依頼データをもらっていて、
依頼データをもらった時点のマスタの値を依頼データに付加して保持しないと
いけないケース。
複雑な料金計算の設定マスタなど、既存のデータと処理をそのまま移行する
必要があって、下手にデータの持ち方を変えてしまうと、
明確に仕様化されていない部分の動作が保障できなくなってしまうケースなど。
>>209
>顧客コードとそれに対応する顧客名称などがテーブルにあっても、
>実はマスタ化するまでもない一見の顧客の場合、特定のコードを使って、
>顧客名称のみ画面から入力したいという与件があったりするケース。
>ＥＤＩで顧客からマスタと依頼データをもらっていて、
>依頼データをもらった時点のマスタの値を依頼データに付加して保持しないと
>いけないケース。
これは別に全然問題ない
「顧客名称のみの登録もできる」
「依頼データをもらった時点の値を保持する」
という仕様のもとに設計して正規化すればいいだけの話
>複雑な料金計算の設定マスタなど、既存のデータと処理をそのまま移行する
>必要があって、下手にデータの持ち方を変えてしまうと、
>明確に仕様化されていない部分の動作が保障できなくなってしまうケースなど。
これはありがちな話で、実際妥協してしまうことも多いんだけど
そもそも「明確に仕様化されていない部分」があることが問題なわけで
正規化できない理由にはしてほしくない
その辺は正規化してちゃんと効果有るの？
正規化したいだけの自己満足程度？ >>211
正規化することに理由を求められてもな・・
逆に「正規化しないこと」にこそ理由が必要だと思うんだが
逆に質問していい？
「君の会社の開発標準において、論理データモデルを
作成するという工程はないの？」 最近、クラウド絡みで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なんて見たくもない。バグの原因＆パフォーマンス劣化の原因になりやすい。
もちろん、全てのケースでこの形でうまくいくとは思えないが多くの部分はこの型におさめられるのではなかろうか。そうすれば余計な頭を使わなくて済む箇所が一つ減る。
今でも一部はそういう作りはあるけど（汎用マスタ等）、それを可能な限り全てのテーブルでやる。（究極的にはテーブルは一つで全レコードがそのテーブルの中。レコードを区別する為のコードがさらに必要にはなるけど） >>214
>・SQLがきわめて単純になる。
>・DB構造に頭を悩ませる必要がなくなる。
ちゃんとしたDB設計もできない設計者、SQLもかけないようなプログラマにとってはメリットかもしれんがな
>・スケールアウトしやすい。
クラウドに適した形式だから、莫大なデータ量で通常ではハンドリングできなくて
クラウドにするってならわかるが、クラウド考慮しないなら関係ないんじゃない？
>複雑なSQLなんて見たくもない。バグの原因＆パフォーマンス劣化の原因になりやすい。
すくなくとも複雑なSQLがパフォーマンス劣化の原因ではなく、（SQLにより実行される）複雑な処理が原因なわけで
>・今まで1つのSQLで取得できてたものが複数回のSQLになる。
>・今まで1行で帰ってきたものが複数行になるのでコードでループでまわしてレコードを組み立てる必要がある。
ような状況で、パフォーマンス劣化は避けられるどころか余計悪くなると思うがな
>多くの部分はこの型におさめられるのではなかろうか。そうすれば余計な頭を使わなくて済む箇所が一つ減る。
頭使わなくて済む個所が減ったらダメだろｗ
いままでSQL書いただけでやってくれてたことを、全部自前で実装するんだぞ？
プログラムしないといけないことも増えるし、頭使うとこも増えると思うがな
>今でも一部はそういう作りはあるけど（汎用マスタ等）、それを可能な限り全てのテーブルでやる。（
いまのRDBMSでも、やろうと思えばそういう風にできるわけだ
でも普通はみんなそんなことはやらない。それが答えだと思うがな
メリットデメリットってのは、何に対してなのかはっきりさせてから評価してくれないか
このままだと頭使わない奴にとってメリットがあるって結論になるなｗ >>216
>クラウドに適した形式だから、莫大なデータ量で通常ではハンドリングできなくて
>クラウドにするってならわかるが、クラウド考慮しないなら関係ないんじゃない？
最初は考慮してなかったが後からやっぱ必要だった！（見積もりが甘い？）って時にはメリットになると思います。
>ような状況で、パフォーマンス劣化は避けられるどころか余計悪くなると思うがな
SQLだとちょっと書き方変えるだけで10倍、100倍もパフォーマンスが違う事ってありますよね。みんながみんなSQLのエキスパートであれば問題ないのですが。それに比べればましかなと思ってます。もちろん処理内容によりますが。
>頭使わなくて済む個所が減ったらダメだろｗ
”余計な頭を使う箇所が減る”の間違いでした。
>メリットデメリットってのは、何に対してなのかはっきりさせてから評価してくれないか
メリット、デメリットは一般的なテーブル構造（先の例での前者）に対する、KVS的なテーブル構造のメリット、デメリットです。
>このままだと頭使わない奴にとってメリットがあるって結論になるなｗ
おっしゃるとおりで、このスレッドの趣旨には反しますがこれが一番のメリットと思います。頭を使う必要が少なければ、設計する人によって品質がバラバラという可能性が減るのではないのでしょうか（こういう構造で業務を満たせるのであれば）。
職人頼りなシステム開発が工業製品へと一歩前に進めるような気がします。 >>214
こんなことしなくても
みんなお前ほど頭悪くないから大丈夫だよ 開発効率が３０年前に逆戻りすることだけは確実だな… 馬鹿でも扱えるようにしたら色んなところで問題が出るってなぜわからんのだ。
カスレベルの人材でも働けるのは業界にとって大きなマイナスだ。 >>217
>職人頼りなシステム開発が工業製品へと一歩前に進めるような気がします。
逆だ。DBでやらない分アプリでやることが増えて、
プログラマの腕頼みになるだけだ
みんなが言ってるとおり、時代に逆行しているよ カスは時給安くても働くから、時給高い熟練は不要になるしな。熟練にしか出来ない正規化とかの無駄な仕事が必要ｗｗｗ
単にDB使いこなせないからアプリでがんばるよ的発想だよな。
SQLを使ってたほうが遥かにパフォーマンスが良い現実。
これまでの歴史で今の状況に成ってるのを理解しないと。
オブジェクト廚が、オブジェクトDBなら便利になるぜとかのたまってたけど遅くて結局は消えてるし。
また馬鹿が湧いて、無駄な事を繰り返すのかな。 >>217
>最初は考慮してなかったが後からやっぱ必要だった！（見積もりが甘い？）って時にはメリット
クラウドにしやすい、ゆえにスケールアウトしやすいメリットがあるっていうならわかるが
クラウド云々関係なしに ってのはお前の出した前提条件だが？
クラウドにしないでスケールアウトってんならデータ形式はあんまり関係ないだろ
あくまでクラウドに適してるのがメリットであって、スケールアウトは副次的な話だ
>SQLだとちょっと書き方変えるだけで10倍、100倍もパフォーマンスが違う事ってありますよね。
オプティマイザが入るSQL処理でさえ簡単にそれだけの差がでる。
自前アプリでその処理をやるわけだ
みんながみんなSQLのオプティマイザより賢くプログラム組めるのか？
>みんながみんなSQLのエキスパートであれば問題ないのですが。それに比べればましかなと思ってます。
みんながみんなプログラムのエキスパートであれば問題ないのですが。
それに比べれば(SQLの方がオプティマイザある分)ましかなと思ってます
>メリット、デメリットは一般的なテーブル構造（先の例での前者）に対する、KVS的なテーブル構造のメリット、デメリットです。
いやだからその２者をくらべたときに、誰にとってメリットデメリットだと？
ほんとに頭使わないシステム開発者にとってのメリットでいいのかよ
>品質がバラバラという可能性が減るのではないのでしょうか
減るかもしれんな。頭使わない安価粗悪な物によってまともな物が駆逐されてな
全体のレベルを下げるだけだ。品質低い方に統一してどうする
>職人頼りなシステム開発が工業製品へと
工芸品が工業製品になるためには、その職人の技が一般化されてることが必要なわけで
一部の人しかできないことを、だれにでもできる事だけで作ったとしてもそれは単なる粗悪品
一部の人しかできなかったことを、誰にでもできるようにしないと意味がない
そのために論理や技法があり、それを学んだり論議したりしてるんだよ
お前の主張は、
工業製品ならだれでも作れないとダメでしょ。
馬鹿にはシステム開発できないんで、システム開発は工業製品じゃないよね
ってことだ
>>217
> みんながみんなSQLのエキスパートであれば問題ないのですが。
SQLのエキスパートはそんなにいらない。
もちろん、一見優秀そうなゴミでは何の役にも立たないが…。 おっ！最近レス多いですねぇ。いいじゃないですか。
スレの趣旨に合っていれば、DB技術者の意見を気軽に言い合ってもいいんじゃない。
レスが一つ入ると反応する方が結構居そうなので。
それぞれ扱ってるシステムの規模や影響、会社の風土とが違うでしょうから、
一概に良いか悪いかは言えませんが。
>>214
とりあえず、「KVS的な構造」といって後者はないだろう。 >>214
COBOLやRPGの時代にそういうテーブル設計しているのありました。
今SQLで実装している業務を試しにCOBOLで実装してみたほうがいい。
まあ、あの時代はある種夢の時代だったな。
「おれ５０００ステップのプログラム作っちゃったぜ！」と
無駄に長いプログラムを作れば儲かった頃だし。
ちなみにSQLより速い処理が組めるRPGやCOBOLのプログラマなんて
ツチノコ並みの珍獣だと思うが。 >>228
COBOLやRPGは知らないけど、「処理の速さ」という点では
プログラムでゴリゴリ書いたほうが良いこともある
DB側（リレーション、制約、ストアド、SQL）に機能を持たせる
一番のメリットはやはり保守性だろう
サーバーでやるかクライアントでやるかの違いだろうね。>>214
メリット・デメリットは>>214の他に
メリット
自分で最適化できる。
デメリット
サーバー/クライアント間のデータ転送量が多くなる。（高速LANなら無視できる）
かな？
>>229
ストアドの速さに勝てるの？ありえなくないか？
DBに機能をもたせると保守性は落ちるとおもうが。
ストアドにしたからといっては飛躍的に高速になるわけではない。 データをどこに持っているかにもよる
DBMSに格納されているなら、そのDBMSに特化したストアドより早く外部プログラムが
実行できるとは思えない。
ストアドでも外部プログラムでも、ロジックは同じように作れるわけだからな
保守性については、システムの保全とか改修のしやすさとか、
何を主眼として保守性とするかによって変わると思うが
>>234
「保守性」っていうのは、改修の効率の良さ、再利用性の高さ、
論理的整合性の保ちやすさなどをひっくるめた意味で書いた
曖昧な定義でごめんね >>235
だったら外部プログラムならなお一層遅いだろ？
論理性がまったくないようだけど本業のほうは大丈夫？ 他のクラウドで処理したデータも拾ってこなきゃならんから遅いだろうね。
全クラウドが、光ファイバーで繋がってて、膨大なクエリ処理しても、遅延は最大でも数百ナノ秒だぜってわけじゃないだろうし。 サーバーサイドの処理と限定して話をするけど
>COBOLやRPGは知らないけど、「処理の速さ」という点では
>プログラムでゴリゴリ書いたほうが良いこともある
SQLの実行エンジンの最適化処理でブロックI/Oやらをやられると
プログラムで１行FETCHや1行WRITEしている
これらの言語は太刀打ちできないワケだが。
そりゃ、OSのAPIを直打ちするレベルになれば別だけどな…。
今時のRDBMSは統計情報を元にSQLの実行プランを最適化するが、
一般プログラマにコレを越えるプログラム組めって言っても
かなり辛い。
むろんプログラマが書いた方が良いこともあるだろう。
どんな例か知らんけど。 なんかストアドよりインデックスが速いよスレの二番煎じな流れだな。
詭弁のガイドライン
2.ごくまれな反例をとりあげる
「だが、RDBよりプログラマが書いた方が良いこともある」
15.新しい概念が全て正しいのだとミスリードする
「クラウドで使われているKVSを使わぬ限りシステム構築に明日はない」 >>239
> 今時のRDBMSは統計情報を元にSQLの実行プランを最適化するが、
> 一般プログラマにコレを越えるプログラム組めって言っても
> かなり辛い。
腐るほどあるよ。 >>241
腐ったSQLを平気で書くプログラマのプログラムを想像した。
北へと旅に出たくなった・・・ >>241
腐るほどある。と言われても、AS/400みたいなマシンで無い限りSQLと他の言語の
速度比較とかは出来んはずだが、AS/400なんざ普及していないだろ。
RDBMSでSQL使うよりもC++でコレクションクラスを使った方が速いよ、なんて
議論無意味だしな。 ちょっと議論の的がズレていってない？
>>214は、処理の速さについては
メリットとしてもデメリットとしても挙げてないんだし
問題の本質はそこじゃなくない？
単に屑PGが適当に組んでも速度が出ないと困るってか？
SQL覚えるのが一番の近道。 >>244
問題の本質とは?
確かに、214さんが処理の速さについては
言及しておられないようです。
ただ、私見ですが214さんがSQLを良く
理解しておられないのは感じます。
開発側とすれば画面に表示する情報を
1SQLで取得できるように設計するべきで、
その方が楽だと思いますがね。
遅かったら運用のせいにも出来るしね。
>>242
まぁ、そんなこと言わないで、がんばって行きましょ。
分かるけどね…
>>246
クエリの知識しかないアプリ屋のくせに
えらく上から目線だなオイ >>247
いえいえ、とんでもない。
そんなお褒めの言葉、
こちらこそありがとうございます。
単に複雑なSQL組めない屑PGだろ。
select *だけで全部済む様にしたいとか言いそうだし。
まるでオープン系コボラｗｗｗ >>246
情報を1SQLでとれないってのは、どっちが？ まだまだＤＢのオプティマイザはアホだから、実行プランやトータルコスト考えながらクエリやＰＧ書けない奴はダメだな。
下請けソフトハウスのアプリ屋なんてそんな奴ばっか…
何のためにキーやインデックスがあるのかちょっとは考えてくれよ >>249
複雑なSQLはそれ自体のメンテが大変かもね。アクセスパスは不変じゃないし
無理矢理SQLに詰め込まれても、常に効率が良いとは限らない。
要はバランスだと思う。ちょっと頑張ればSQLのみで済むからSQLに詰め込もうとか、
どうせUAPで処理必要なんだから、SQLでは無理せずにUAP側にロジック入れようとか
いろいろ状況もあるだろうし、適材適所で臨機応変に使って行きゃ良い。
まぁ同一システム内でばらばらだと困るので、ある程度の取り決めは必須だが。
ところで、組み込みSQLで select * 使う人はいないはずだけど…。
さすがにそんな人にはコード書かせないでしょ。 >>252
>ところで、組み込みSQLで select * 使う人はいないはずだけど…。
>適材適所で臨機応変に使って行きゃ良い。
>>250
こんばんは。246で発言した者です。
どちらかとの御質問ですが、どれとどれのことか分かりませんでした。
私が不出来なもので申し訳ございません。
先に私が発言した主旨としては以下の様になります。
開発側の人としては画面に表示するデータが1SQLで(select * は論外ですが)、
もちろんジョイン、必要であればサブクエリーを使用し取得したデータ群を、
使用する言語によったデータセットで使った方が楽なのではないかと思った次第です。
(それぞれの環境次第なので一概に言えないのは分かっております。)
214さんはそれぞれ必要な都度SQLを発行し、表示するデータを構築される
ように思われたので上記の様な発言を致しました。
ただ、214さんがデメリットでそのことを挙げておられることを見過ごしておりました。
申し訳ございません。
先に私が発言しました「214さんがSQLを〜]の発言は撤回させてください。
その後の「遅かったら運用の〜」は私の過去に受けた経験から発言したものです。
開発より、運用に従事している期間が長いものですから。
>>247
お気を悪くされましたらお詫びいたします。
>>254
そもそもの発端はKVS的な設計はどうだろうって論題で、
KVS的な設計では１SQLでデータ取るのは不可能だって話だ
それを前提にしてるから
>214さんはそれぞれ必要な都度SQLを発行し、表示するデータを構築される
ようになってるわけで
１SQLでデータ取れるような設計しろってのは、議論の前提がおかしいだろうが
>>255
その言い方だとDB設計者は開発側の人間じゃないように聞こえるが >>214は、この設計を既存のRDBに割り当てて使うって言ってんのかな。
それなら駄目すぎて話しにならんと思うが。 そもそも「KVS的」といって>>214みたいなのが出てくるのがおかしいし、
あれが1SQLでデータが取得できないというのも変。
いったいオマエラ何の議論をしているの？ 具体的に1sqlってどこまで許すのか示されてないしな。
まあdb知らない人みたいだから無茶言いそうだが。 こちらの方がおっしゃっている設計指針についてどう思われるでしょうか。
http://masuda220.jugem.jp/?cid=11
・テーブルの役割・用途は一つ
・（極力？）データに対する更新・削除は行わない
など
なるほどとも思うのですが、役割に応じて分割すると
あまりに細かく分割しすぎて見通しが悪くなりそうな気もしますし、
データの更新・削除を認めないのは冗長かつ非効率な気もします。
実務による、というお答えが返ってきそうですが、一般的な設計指針として
ご意見をお聞かせいただければ幸いです。 >>262
モデリングの手法としては合ってると思う
ただこの後の工程で、パフォーマンスや効率性を考慮して
冗長化、非正規化することは必要だけど
>あまりに細かく分割しすぎて見通しが悪くなりそうな気もしますし、
モデル上は、細かくテーブル分割してあるほうが分かりやすいよ
テーブル名とリレーション見るだけで何を表しているか分かるからね
>データの更新・削除を認めないのは冗長かつ非効率な気もします。
「データの更新・削除を認めない」って書いてあるところが見つけられなかったんだけど、
どこから引用したの？
>>263
レスありがとうございます。
書籍などではここまで言及してあるものを読んだことがなかったので、
どうなんだろうと思っていたのですが、正しい手法なのですね。
（「正しい」という表現が適切かわかりませんが）
> 「データの更新・削除を認めない」って書いてあるところが見つけられなかったんだけど、
> どこから引用したの？
これは少しコメントを端折り過ぎました。
「テーブル設計 データモデリングのエッセンス（２）」などに書かれているのですが
> ビジネスイベントは一度作成（インサート）したら、後から、更新や削除はしない。
> このテーブルに許される操作は、インサートと参照のみにする。
とあります。
また、ビジネスリソース系のテーブルについても同様の方法を取ることもあると書かれています。
ここに書かれている業務システムの例に合わせて言えば、
受注テーブルは最新の状態にしておき、更新や削除の記録が必要ならば別テーブルにログとして保持する。
受注テーブルにはキャンセルされた受注や変更前の受注は保持しない。
というのが主流だと自分は思っていました。
また、導出テーブルをトリガで作成するという手法も初めて知りました。 >>1
1. Excelのワークシートと勘違いしてるから。
2. 設計＆指揮者がコードに関心があるのにデータに関心がないから。
レベル低すぎ？ むしろコボラ上がりが、繰り返し項目を使いたくって、
正規化なんか理想論だ、実際は性能が落ちる原因だとか
トンデモ説を信仰している（ふりをする）からじゃん コボラ上がり(かつRDBを知らん)奴なんて数えるほどだろ。
それよりも、RDBしか使ったことがなくても実はわかってない、ってのが
圧倒的じゃないか？>>265の言うexcelと勘違いしてるようなのとか。 ファイル設計の延長くらいにしか考えてない奴は多いな コボルの本読むとそんな感じだしな。
正規化なんて全く記述無し。 そりゃ正規化はRDBでしか必要ないからな！固定長レコードで正規化
してもテーブルの連結がめんどくさかったら意味ねえ！ そういえば昔、上から全項目を固定長にしろとお達しがあって、嫌々やったら速度が上がった
（つーか、負荷テスト後もあんまり性能が落ちない）DBがあったなｗ その昔の経験って、今も成り立っているのかな？
そこが曖昧なまま薦められても困るのよね。 今は一般的にはtext型みたいなのが一番速い
長さチェックも空白詰めもしないから
ただしOracleだけは固定長が速い >>273
逆だろ。
Oracleには固定長の文字列型なんてないはず。
最小長と最大長が等しい可変長文字列を、便宜上固定長文字列型って騙ってるだけ。
まぁほとんどのDBMSで、列サイズが固定であるが故の速度的メリットは大きいから、
Oracleでも可変長文字列を入れていた項目を擬似固定長に変更した時の速度向上は
見込めるかもしれないって程度。 > 固定長の文字列型なんてない
> 列サイズが固定であるが故の速度的メリットは大きい
矛盾してないか？ 最初の文は、内部的には可変長文字列の特殊設定だと
言っているような気がするんだが。 DB2も固定長の方が速いけど。
text型みたいなのはある程度まではそこそこ速いけど、
ある閾値を越えると急に遅くなったりするので
処理系しだいだろうとは思う。
つか、Oracleとかの「こうすると速い」系のネタは都市伝説が多いよなー。
商品コードとかの長さが決まっている項目なら固定長で、
備考の様な長さが不確定な部分は可変長と素直に設計していけばいいのでは？
「速いから固定長」とかはなんか違うだろ。
「考えるのが嫌だから全て可変長」の方がまだスジが通っている。ｗ >>275
Oracleは内部的には全部可変長扱いだって聞いたことがあるからそのことじゃね？
DB2とかだと内部的にCHAR型とVARCHAR型は別扱いなので、きちんと使い分けた
方が望ましいけど、Oracleはちょっと変態なのでムリにCHAR型にする必要はないと。
(全ての？)列サイズが固定で速くなるってのはまた別の話で、データの格納と言うか、
表領域の使われ方のことではないかと。まぁどっちかって言うと行サイズだが…。
HiRDBだとFIX表ってわざわざ宣言したりするね。 オラクルは昔と今では、だいぶ違うけどな。昔の経験なんて引きずってたらそれこそコボラ状態。 DB2とかは固定長・可変長は分けて処理するしNOT NULLな制約も考慮して
適切な設計にあわせて実スピードは上がっていく。
逆に設計がアレだとあんまし速度はでないRDBMSだな。
Oracleも昔の都市伝説と言うか、昔のヘンテコ小技を今のVerに持ち込むのは
ヤめてくれって感じるな。
普通に設計して普通にSQL書いてください。 何でOracleはヘンテコな仕様なのに普及したんだろうね？
M$やらIBMやらが注力しなかったからかな？ >>282
ごめんね、キミの大好きなOracleを馬鹿にしちゃってｗｗｗ 今日もアホなテーブルとクエリを見てゲンナリした
○○○○○は遅いねってお前の設計が（ry >>282
性能がいいものが売れるとは限らない。
大人の事情というのがあるんだよｗ まあそれほどまでに当時のSQL鯖/サイベースとDB2が糞だった訳で。
オラクルの出現で競争が生まれ、それらも今やかなりマシになった功績は大きい。
周りのヘンテコDB仕様に合わせて客取り込んでいって成長したから、今でも名残が残るのはしょうがない。だんだん洗練してヘンテコ仕様もろとも下位互換は切ってくだろうけど。 そもそもまともに使えるRDBMSを最初に売り出したのがOracle。市場での競争が始まるのが
後発のInformix、Sybase、Ingres等が現れてから。DB2もあったけど、当時のIBMはIMSの
商売の方が重要でDB2はほとんど力を入れておらず、顧客がRDBMSを必要とする場合に
程度でSymfowareやHiRDBのような扱い。
MSのSQL Serverや、他社OSでも使えるDB2 UDB(の原型)が現れて現在のような競争状態に
なるのはそれよりもさらに後。 過去のことはいいから現在一番ましなRDBはなんなのさ。 今の製品はだいたいみんなまともだろ？あとはどのポイントを重視するか。
総合1位なんて点数のつけ方で変わるよ。 >>292
じゃあSQLiteが一番だな。これで満足か？ サポート契約してるとOracleって結構不具合とかあるんだなぁ、
って感じますが、他のRDBMSでもあるんですかね？
DB2も不具合はある。
Oracleよりは少ないが、それだけDB2普及していない証明でもあるような希ガス。
別に不具合あってもいいんだけどさ、それの対応がタマに「我慢汁」とか「それはOSの不具合です」
とか解決に繋がらない回答を貰うと、「あー、Postgresでいいじゃん」とか思うな。 DB2は、「なんでいまだにこんなバグが？」と思うようなのがけっこうあるね。
インスタンスダウン→「次のFPで修正されます」のコンボに何回遭遇したか。 DB2ってiSeriesは鉄なみの硬さがあると思うが、それ以外のプラットフォームは・・・。
Oracleもよくインスタンス落ちるがiのDB2は落ちた事がない。
これもIBMの中の人とガチで仲良し(?)レベルで会話できる人が少ない性もあるんだろうな。 単にasはろくな処理してなくて使い込んでないから固く見えてるだけじゃ。
全部as内完結で、不安定になる様な秘穴を突けなくしてあるとも言うが。
オラは、いろいろ弄れる割に秘穴を突いてしまう確率が高くなるだけ。
ちゃんと組めばド安定で運用出来るよ。RACも組めるし。
ポスグレはサポート無いから、業務では選択肢に無いな。
マイエスはオラクルがサポートしてくれるなら、これから使う鴨田が。 
