■DBについて語ろう■

DBについて語り合ってみるスレッドです

IBMのDB2はテーブルを表と呼ぶので
マニュアルなどを見ると違和感有りますけど
どうですか？

一般的にＲＤＢＭＳと呼ばれるものはテーブルを表と呼びます。

違和感あるということは今までＡＣＣＥＳＳみたいなファイル
共有型の簡易ＤＢ、またはホスト出身者ですか？

どちらにしろ、表記が変わったくらいで違和感感じてると
開発ツールが変わると何もできない頭の固いエンジニアと
思われます。

私は、逆に、ＲＤＢＭＳの方がわかりやすい。
逆に、階層型の方が違和感あり

一番最初にやったのが構造型ＤＢだった。
セット関係っていうのが良く理解できんかったな。
ＲＤＢでは「平坦な表イメージでデータが格納〜」というのが
印象に残ってる。

>2
そうですか
確かに最初にさわったのはACCESSですが(いまはHiRDBを主にさわってます)
他のデータベースの書籍などを読んでも
テーブルと記述してある書籍が多く感じられます

「表を作成して」と言われるのと
「テーブルを作成して」と言われるのでは
後者の方が意味合いが取りやすいと思っただけです
業務に支障をきたす訳では無いし

//もちろん「テーブルを作成して」と言われて
//机を作ろうとする人もいるかもしれませんが（ｗ

>>5
いねーよ！そんなヤツ！
ネタならネタらしく面白いこと言え！
まったく、ドキュンは何やってもドキュンだな。

DDL書くときゃ、「CREATE TABLE」て書くくらいだから、
別に"テーブル"と呼称してもいーんじゃねーの？
十分通じる。

>>1
IBM って、Keyboard を 鍵盤 とか、ま、そんな具合に翻訳をしてるだけです。
表 をふつうの英語に直すと table になりますです。

SQL-Serverを4年程使ってます。
理論的に正しいはずのSQLが、動かすと激遅かったりして、
変なSQL文を書くクセがついちゃってます。
そういう人いますか？

処理件数が1万件を越えると、ちょっと動きが怪しくなってきて、
10万とか100万件のデータだと、動かすまで判らなかったりして・・

同僚は、Oracleはちゃんと動くぞ！と言ってますが、
このままSQL-Serverばっかやるのもちょっと不安。

>>9
SQL-ServerはMSがSybaseから買ったモンで、テクノロジーは
他のＲＤＢＭＳと比較するとかなり遅れているように感じる。
数年前は大量バッチを行うとインデックスが破損してしまい
バッチ処理が中断するという信じられんバグもあったくらい
だし。

ＭＳの製品は覚えやすいのだが、どうも業務で重要な数字を
扱うような部分には使えないなぁという印象が強い。
俺もSQL−Serverの経験者だが、Oracleと比較すると本当に
簡単だよね。
俺んとこのエンドユーザーなんて、俺の勤務先が開発した
Oracleサーバのインスタンスの仕様書を参考にしてそのま
んま同じ要件のサーバをSQL-Serverで作れるくらいだもん。

会社のシステム部門が独立してシステム会社として分社す
るケースをよく聞くがそういうところ程、このSQL-Server
を使うなぁ。

まぁこんな会社のエンジニアはMS一辺倒になるのが多いので
将来的に使い物にならんヤツが多い。

>>9
それってソート領域とかワーク領域とかのチューニングが甘々なので
HIT件数によって動作が変わるだけなのでは？？
optimizerの動きを予測して、それでもそこから外れるようならば、
そこではじめて「SQL-Serverはだめだなぁ」って言えると思いますよ。
がんばれがんばれ。
MS製品だろうがOracle製品だろうがDBエンジンに変わりなし。

理論的には正しくても、実行プラン吐かせてみると予想とまったく
違う動きすることはどんなDBMS使っててもあることですよね。

今までで一番ひどかったのはSybase。オプティマイザがまったく
信用できません。

おれはオプティマイザがなかった頃からのユーザだからあるだけでも驚異だね。
昔は全部一々アクセス方法を自分で設定してたよ。

汎用機のＤＢは、わけのわからないエラーがでる
から嫌い。
ＡＣＣＥＳＳとか、オラクルとか、ＳＱＬの方の
クラサバ系の方が得意。
でも、仕方なく、汎用やってるが。

>>14
汎用機の方がエラーコード体系がシステム全体で統一されているからわかりやすいはずだぜ。

OPEN系のはOSとDBがそれぞれ別々のエラーコード体系だからけっこうめんどいよ。
てーか、おたくはカタカナでオラクルなんて書いてる時点で駄目駄目君だな。

>>15
内部的には、そういうのでめんどくさかったことはないよ。
OPEN系だったら、OSとDBのエラーコード体系が別々でも客文句いわないじゃん。
それを客が監視するようなメッセージログかなにかに出力するときに
はじめて困る話であって。

研究室でフリーのPostgresqlを使ってます。
DBの勉強には持ってこいです。

>>13
ほー・・・そんな時代があったんだ。
それって汎用機ですか？？
ヒント句みたいなものでアクセスパスを指定するのかな。
ちょっと興味がそそられますね。

>>17
PostgreSQLどうですか？
リカバリまわりの動きなんかは雑誌でもあまり書いてくれないので
教えていただけるとウレシイですね

やはりOracleの案件は多いみたいですね
オレもOracle学ぼうかな

結構めんどいよ。
ＯＳエラーだからそっちを調べろとかいう場合でも
ＯＳ側がエラー切り分けしてなかったりするのよ。

汎用機は統一してるからどっちかで必ず切り分けてるのさ。

思うんだが「訳がわからん」とかいうのは君が慣れていないだけでは？
もうちょっとやればわかるよ。
俺もopenに移ったときはそう感じたよ。

うーん、時代を感じるね・・・。SQLしかしらない世代なのかな？
SQLの初期の売り文句には「データの物理構造に依存せず、アクセスを行え〜」というのがあってね
それ以前は物理構造に依存するのが当然だったのさ
技術の進歩はすごいね、その内オプティマイザが勝手に索引張ったり消したり
再編成したりするようになるかもな

#俺のSQL歴は十年ちかいよ、汎用機でもSQLを使ってたからね

>>1
ＤＢ２スレだ。
http://mentai.2ch.net/test/read.cgi?bbs=infosys&key=985472067&ls=50

>>19
派遣カンケーの仕事や転職市場ではＯｒａｃｌｅ知っていた方というより
Ｏｒａｃｌｅ経験者の方がいいぞ。
俺は派遣でも先日の転職でもＯｒａｃｌｅ６〜８までの構築経験が
あったお陰で何とか転職も自分の希望通りの会社に入れたから。

どう転んでもOracleは15年はなくなることはない。
そう考えると俺らの年代が技術者と生きて行く年代においてはOracleは
知っているにこしたことはない。

>>20
UNIXやNTなどのOSが出すエラーは、エラー内容そのものでは十分見きることができないので、
最後は「カンで見きる（笑）」作業がでてくる、
というのが面倒かつ弁明の難しいところかもしれません。
彼らは寡黙なので、、、

汎用機の最大の利点は、
障害時に、必要な情報が漏れなく、きちんと整理されてでてくるところ
でしょうね、、、UNIXやNTでは逆立ちしたってかないっこありません。

# カンの部分を正確に述べると、別途トレースなり統計情報なりを見て最終判断、みたいな


>>21
なるほど、そういうことでしたか、、、
私の初めて使ったデータベースはINFORMIXだったので、
SQL=データベース　という認識です。

>>23
INFORMIXとSQL-Serverとファミ通のSymfoWAREだけじゃダメかな（笑）

補足するとだね、たとえばＤＢをアクセスする前にOPENする訳だが
その時にどの索引を使うかとか指定するの。
でもCOMMITとかROLLBACKとかいう概念は当時からちゃんとあった。
ROLLFORWORDもな、今考えるとおもちゃみたいなもんだが・・・・。
＃ちなみに各DBMSで微妙に違うのでよろしく

順編成、索引付き順編成…。まあ、余計なこともしないし、
個人的に理解しやすいから嫌いじゃない。＞汎用系DB
ちなみに、COBOLerがオープンに転向するとカーソルばっかり使いたがる(笑)

>>27
なるほど、、、ISAM系のDBで見たことがあるような。
COMMIT/ROLLBACKがあるのは存じてます。
とはいえ汎用機は某ファミ通のMSPしか知らないので何ともいえませんが、、、

>>28
インデックスサーチのコストはカーソルの方が低くていいですよー
でもどんなSQLを飛ばすか、によりますけどね、、、
OLTP系ならやはりカーソルでしょう　FETCH行をUPDATE

>>28
COBOLで埋め込み式ＳＱＬ使うとそうなるのよ。
しってた？やってみればわかるよ。

>>30
あれ、、、直接SQL実行もできませんか？？
COBOLといえどもRDBMSなら確かできるはず

皆RDB以外のＤＢはしってるかな？
おいらが最初に使ったのはCODASYL式(?)の構造型DBであったぞ。
セット関係を利用してＤＢが成り立っているのであった。

それではCOBOLで作る意味がないと思われ〜

あんたいくつよ？

最近はかなりの数のDBが
Linux上で動くようになってきましたね
どんどんSQLserverの守備範囲が狭くなってような

>>29
RDBに向けたOLTPでカーソルなんぞ使うな！

>>30
COBOLではSQLじゃなくてインデックスファイルをオープン、がメインでした。
SQLプロセッサって重いもんで。

>>32
NDBをRDBに移行するので死にました。
設計はできてもデータ移行の作業が(汗)

>>36
基本はそうかもね。でも現実は…。
ホストを移行して無理矢理RDBに組み込んだシステムだと
SQLが使えない/使いにくいもんで。
＠マルチレコードレイアウトとか。残すなよ、RDBに(笑)

>>29
ISAM-DBという用語には違和感がある。
あれはただの索引順編成ファイルと違うか？
どこのベンダの用語なんですかい？

>>36
2回以上同一レコードにアクセスするんだったら
カーソルの方がCPUパワー食わなくていいですよ

>>38
同じ

私は経験年数5年くらいのペーペーですが、ずっとPCでRDBしか
やったことありません。

んで、COBOLerからPCに転向した先輩達のテーブル設計に
すごく違和感を覚える事があります。

例えば、実績データのテーブルを作成するとき、我々は
日付と時間をKeyにしたレイアウトにしますが、元COBOLerは
1つの日付レコードに複数の時間帯を直列に格納するような
レイアウトにします。
（オカーズ？とか言ってました。）

表の正規化の概念も無いみたいですが、それはその人が
不勉強なだけですかね？（笑）

ＳＱＬＳｅｒｖｅｒがＬｉｎｕｘ上で動くからと豪語していた銀行系エンジニアたちがいた。
神田にあるところなんだが。

>>40

>んで、COBOLerからPCに転向した先輩達のテーブル設計に
>すごく違和感を覚える事があります。

転向が不十分なので、再教育が必要と思われ。
http://www8.pekori.to/~zoma/kanki_t.html

>>41
Sybaseとの勘違いかと思われ。

>>42

>>>>41
>>Sybaseとの勘違いかと思われ。

どうちがうの？(藁

いや、ネタだから気にしないでね。

過去の資産や他システムとの絡みでそうなる可能性もあるでよ。
一概に善し悪しはいえない。
てーか、聞いてみそ。

>>44
かなり偏ってる。44も転向不十分な故鯔ーかな？

SQLを不自由にする非RDBなデータ構造を
わざわざRDBで構築することもなかろう。

なんでもかんでもRDBにする必要は無いんだよ、
でもRDBを使うならRDBの流儀に従うほうが自然だと思う。

てーか、そのＲＤＢの部分のみでシステムが完結するわけではないので〜
実務はそうそう理屈通りにはいかないのであった。

＞４５
あおりはよそへいきな。

>>46

「学術板」の「DBを語る」スレで「実務」がどーのって愚痴垂れてるヤツ
他所でどうぞ。

確かに、第１正規化くらいは貫徹したいな。

>>47
学術派の君にはこういうゴミすれがお似合いです。
お願いですから、スレを汚さないでください。(はぁと
http://mentai.2ch.net/test/read.cgi?bbs=infosys&key=989442677

それはそうなんだが
出来ない場合もありうるわな

>>47
ここはDB2とかの実務ネタのスレなんだからお門違いだよ。
１をよんでんの？

>>47

このスレでは
現実、実務を完全に無視した理論の話だけしろと言う事？
理論的な話をしている際に、
その理論通りにいかない現実の話が出てくるのも
話として自然な流れだと私は思いますが。
ある技術の
理論的な事とそれが使われている実務での現実の両方を考えながら
”理論的に”話をする事はスレ違いですかねえ？
貴方みたいなのがつまらないレスをつけるから
結局学術的な話のスレが盛り上がらなくなるんですよ。

>47
1の名前は捨てたのですが（ｗ
まだ書き込んでますけど・・・
実務ネタは大いに良いじゃないですか
立てた本人が言うのは何ですが
就職スレに負けずにがんばってると思いますよこのスレ

わざわざ非正規化しなければならない現実って、そんなに多いのかしら？

>>51
理論は正論として認めるけど、実務じゃどーにもならんってんじゃ理論的に負けてるぞ。
実務での正論というか非正規形（だっけ？）のメリットを語ってくれないか？

なんか、現実に打ちのめされてる負け犬みたいだぞ。

そんなに多くはないがあることはある。

>>54
表を引くときのパフォーマンスとか、
DBMSが分散してるときのネットのトラフィックとか、
経験的に壊れやすいテーブルなんかがあって、隔離したいとか。

非正規化はジョインのパフォーマンスに依存する場合が
多いんじゃないかな。
最近のDBは賢くなってきてるから、昔ほど非正規化
することは少なくなってきたと思われ。
あと、正規化すると、キー項目と１バイト文字列の行になる
フラグ情報みたいな場合かな。

そんで結局本題はどうなった？

おれが使ったＤＢをあげてみる
ADBS,RIQS-II,INQ,MS-SQL-SERVER,oracle
　

>>59
Ｎ系？

DBあげ

正規化は、検索コスト・アプリの組みやすさと二律背反なところがあるので、
必要に応じて、、、じゃないですかね？
JOINのパフォーマンスも、アクセスプランによるところ大だし。

ちなみにつかったことがあるのは、
INFORMIX、Oracle、SQL-Server(MS)、、、とSymfoWARE(笑

READY CREATE xxxxx　.
でどかん。

次ヒターチさん、カモン！
HIRDB経験者求む！

>>39
いわゆるＤＢとファイルの違いはなんだろう？
ふと思ったんだが・・・。
情報処理の教科書にありそうだな。

IBMってビューを「視点」って訳すだろ。面白いと思う。
DB2って表領域のデフラグもできるんだよな。REORGとかってコマンド。

アプリケーションは「適用業務」だし。

>>65
DBといってもRDBMSやらISAMやらいろいろありますので
十把ひとからげに書くならば、
・レコード間の関連付けというものがあるかどうか？
というのが端的な違いですね

COMMIT/ROLLBACKやリカバリー機構がなくても
データベースであるので、それは特色にいれられない、、、かもしれません。

原子性とか、一貫性とか・・・なんかアルファベットであったよね、なんだっけ？
気になって調べたけどわかんなかった…　どなたか誰か教えてください。

でーぶ

>>68
ACIDのこと言ってる？
どちらかといえば、トランザクションに関しての定義だね。

>>70
thaks!

で、当人が暗記（？！）しているデータベースの特徴

アプリケーション独立、保存場所独立、ACID ^^; 、内部構造独立（SQL）、セキュリティ、オンライン
です。

ネットで使うことを前提にしてます。

>>67
>・レコード間の関連付けというものがあるかどうか
これって、RDBの特色の様な気がするんですけど・・・
それとも、索引等の事でしょうか。
オブジェクト指向DBなんかは、どうなるんでしょ？

>COMMIT/ROLLBACKやリカバリー機構がなくても
昨今では必須の機能だと思いますけど、
確かに定義としては必要ないような気もしますね。

何気に優良スレになってるな・・。

ＡＣＩＤ特性

ACID（atomicity,consistncy,isolation,durability）characteristic トランザクション処理が最低限満たすべき4つの条件。すなわち、原子性（atmicity）、一貫性（consistncy）、独立性（isolation）、耐久性（durability）のそれぞれの頭文字をつなげたもの。
トランザクション処理に要求される「多くの利用者、多種のアプリケーションがデータを矛盾無く共有でき、以上から復旧できる」という条件を、より明確に規定したもの。

共有/排他制御機能がＤＢの要件の一つかとも思ったが
一人でつかうパーソナルＤＢなんてのもあるしな・・。

デッドロックとかデマンドロック待ちとかってわかる？

>>74
トランザクションに限って言うところの、
原子性と一貫性の違いがわかりません、同じことじゃないの？

>>76
デッドロックやデマンドロック待ちは何もDBに限った話じゃないよ
それは排他ロジックに関するおはなしだ

>>78
でも、まぁ、極論すると技術の寄せ集めですから。DBって。
ＤＢに限らず、どれがオリジナルかなんて考えなければ、全ての製品は
技術の寄せ集めじゃない？

所詮はOSのファイルシステムの上に乗っかってるだけです。

>>80
rawデバイスしらんの？

>>53,54
ジャーナル的な情報はとりあえず冗長化させておくけどなー。
正規化することのメリットが見つからないし。

正規化は、更新（データメンテナンス）系処理に都合のよいもの
冗長化は、参照系処理に都合のよいもの
って単純に考えてるんだが。

SQLserverの大規模版て有るみたいだけど
どなたか使用された方いますか？
それくらい規模がでかいならoracle使いますかね？

>>77
一貫性を保証するには原子性が要るんでそ

>>83
W2kでーたせんたさーば？あれはOSの名前だけど…。
やっとWinも６４CPU扱えるようになりました。
これで自社システムをPureWinで構築し続けることができます。
おめでとう、MS。
(非DBネタなのでsage)

ＣＯＢＯＬＥもえ

83>>
規模がでかいものには安定稼動を優先してAS/400がお勧め。
OSレベルでDBMS(DB/400)が実装されているせいか速度も
最も優れていると思います
(DB/400,Oracle,SQL-Server,ACCESSを使用した経験から)

どこまで正規化するよ？

完全に正規化したら、勘定系なんか動かねーだろ実際？どーよ？

>>88
第３までやってそこから冗長化が妥当でわ？

正確に第１正規化なんてふつーやんないよねえ。
テーブル多いの嫌い。

>>90
第一正規化もしないでどうやってテーブルにデータ入れるんですか？

>>90
徹底的に正規化した後の正規化崩しを無意識に深読みした後の発言なのか、
まともにRDBMSを使えない珍COBOLERの発言なのかわからん。
90の「ふつー」についての定義きぼん。

漏れにとっての「ふつー」は、第３くらいまで正規化しといて、
業務要件やマシンスペック等を加味して徐々に崩していって「落しどころ」を探る。
簡単なベンチマークをやってみて参考資料にしてみたりもする。
まずは正規化→実情に合わせて現実的に「崩し」
って感じだけど、90はどうよ？

age

一般的に、正規化をどこまで厳密にやっているものなのか知りたし
オープン系はたぶん全滅

>>94
オープン系だが、第1正規化は厳守。
それ以降は、結構なぁなぁだな。
よく使う検索パターンにあわせてテーブルのJOIN数を減らしたり。
パフォーマンス要件をクリアできるなら、JOINしたViewをいくつか定義しておいたりもする。
一般的かどうかは不明。

SQLserverにenterprise Edtionって無かったっけ？

EnterpriseManagerならある

中小企業向けのERPシステムあるじゃないですか、だいたい2千万程度の
あのチューブファイルのマニュアルよんんでDB勉強しようと思うのですが、
無謀でしょうか？

学生っす。
PostgreSQLで勉強中です。
就職スレが乱立する中、このスレッドは良い刺激を与えてくれます。
自分も修行して、このスレに貢献できるようになりたいと思います。

# 製品よりもメタな意味でのDBについて語って欲しいなぁ（ワガママ

優良age

ＨｉＲＤＢ　あげ

HiRDB今俺的に旬だ
age

>>91
第３正規形と第１正規形をまちがえて憶えてました。
逝って来ます。

意図していたのは92の後者です。
第３正規形は完全にやらないでとっかかってしまうことが多いので。
ちなみにオープン系。

ＤＢは、ＭＳのＡＣＣＥＳＳが一番好き。
どうも、ホスト系のＤＢは、苦手だ。

AIMDB　大嫌い

ＡＣＣＥＳＳをＤＢに含めるかで悩むな。
ＡＩＭは今後無くなるだろ。浮痔痛はオラクルとかSynfoware？とか
いろいろ手を出してるけど、何をやりたいんだろ？
少なくともＡＩＭに力入れていないことだけは確か。

AccessをDBMSって言うの止めない？
どう考えてもおかしいよ、せめて「AccessのJet」とまで
いわなきゃ。

第二正規化と第三正規化の違いが良く分かりません。
第三正規化は「2回目の第二正規化」にしか思えないのですが・・・

識者のご教授きぼん。

>>107
データベースエンジンの話ならそれでもいいけど、
単にデータベースの話をするんだったらそれに従属する
環境も含めてはなしてもかまわんとおもうけど。

>>108
主キーに対して、非主キーに対してかでなかったっけ

例えば、第二正規化を行った結果。

鯖番号：鯖名：IP Address
1：cocoa ：Address A
2：mentai：Address B
3：pizza ：Address C

のようなテーブルが出来た場合。
鯖名は主キーである鯖番号に完全従属する。
IP Addressは、鯖番号に従属しているように見えるが、実際は
「鯖番号→鯖名→IP Address」
というように、間接的に従属するため、

「鯖番号：鯖名」
というテーブルと
「鯖名：IP Address」
というテーブルを作成するのが第三正規化。


...というように解釈したのですが、大体あってるでしょうか?

業務でやってても第三正規化なんてやったことないよ

>>112
自社が低レベルである事をこんなところで自白しなくても
いいのに。

第三正規化→アクセス要件分析して冗長化検討
が普通じゃないの？

>>112
結果的にやらなくてもいいから
第三正規化をやるべきかどうかは、検討しときなさい

>>111
>「鯖番号→鯖名→IP Address」
>というように、間接的に従属するため、

「間接的に従属」ってのがイマイチ不明だが、鯖名→IP Address に従属関係が
あって、鯖名は主キーの一部では無いんだからそれは第３正規化であってる

主キーが連結キーでなければ第２正規形違反はあり得ないよ

>>115

＞「間接的に従属」ってのがイマイチ不明だが
鯖番号→鯖名 に従属関係があって、さらに鯖名→IP Address
と考えたんですが、別問題のようですね（＾＾；

＞主キーが連結キーでなければ第２正規形違反はあり得ないよ
あ、また分からない事が・・・もうちょっと勉強します。

>>116
ガンバレ

今勉強しているんですが、MRPの所要量計算とこだけ、なんと
PRO＊Cでやってるみたいだ。
まあマニュアルみればロジックが書いてあるんで、これをよめばいいんだろうけど

オラクルのリレーション　（＋）
をアクセスのクエリー（SQL)で表現しようとすると大変だ。
inner join ,outer join ,

オラクルの方がSQLは書きやすいが、何かORACLEのリレーションを
Accessで表現するのにいい方法あるだろうか＞？

ORACLEの(+)のほうがへなちょこ記述なんだけど、まあいいか。
inner/outer joinは、別に難しくも何ともないので慣れようね。

(+)って、オラクルの方言ですよね？
たしか、ライバルであるMS-SQLは、(+)も、
標準である"LEFT JOIN"も両方使えると聞いています。
MS-Accessでは、LEFT JOINでOKでしょ？

私は、InterBase派です。ご存知ですか？
（そんなに、マイナーではないですよね？）

(+)は、テーブルを三つくらい絡めたときの挙動を明確に書けないから
あまりおすすめできないぞよ。

SQL Serverのは *= じゃない？
単一文で、安全なように見えても、viewを組み合わせてたりすると
こっそり不明瞭な結合が紛れ込んでたりしてはまる。
きをつけよう。

あ、ごみん、interbaseは聞いたことあるけど、中身知らない

>SQL Serverのは *= じゃない？

Sybaseからひきずってるやつですね。
抽出条件と結合条件は分けた方が理解しやすいので、私も標準SQL
形式で記述できるほうがうれしいです。

＃ なんでサポートしないんだ？ > Oracle、Sybase

複数のテーブルを使ってオラクルのセレクト分で、
where 条件で
5種類の　(+)
条件をつけたものを

Accessのquery のデザインビューでデザインしても
件数が同じにならない。
Accessの場合はリレーションの矢印で表現。

Oracleの(+)ってOuter Joinですよね？
Accessの方はOuter Joinになってますか？

5種類とはこりゃまた豪勢に使ってるね。
なぜ数が合わないかを論理的に説明するのは疲れるし
合わないことがわかったからといってどうするわけでもないよね。

inner/outer つかえるなら、こっちを使おう。

oracleならー。
んー、
PL/SQLあたりのカーソルループでなんとかしよう。

で、このスレの本題って何？

IBMは20年近くも前からせっせと日本語マニュアル作ってたから、
リレーショナル・データベースを「関係データベース」って訳したり、
大まじめにすべての英単語の日本語訳をつくっていただけだよね。
功績も随分とあると思うけど。
違和感云々よりも、そういう言葉を使っている人と話しているときに、
正確に言葉の置き換えができればいいだけじゃないの？

IBMの若い技術者はあまり古い翻訳語に拘っていないみたいだし。

>>128
スレタイトルにあるだろ。
「■DBについて語ろう■」

DBのネタをﾏﾀｰﾘと話せばいいんじゃねえの?

読んでて第１正規化ってなんだったっけ？
思われた方もいるはず。
ttp://www.st.rim.or.jp/~ryoma/tips/seikika.htm

話ははずれるが、最近話題のBitmapIndexってどう？
RedBrickとか評判良いらしいけど。

oracle　のすべてのリレーションをAaccessですべて表現できるの？

>>131
フラグ的な列を含む検索なんかにはつかえるんじゃないかなと最近思う。


>>132
制約をリレーションとして捉えた場合はすべて表現できないだろうね。
親子とか

浮動小数点型を主キーに入れるのってどうなの？
機器ID, 測定周波数, 測定値 みたいなテーブルになりそうなんだが

>>134
日付型がつまり実数型なんだが、
浮動小数点型とは..

その例では、いまいちぴんと来ないんだが
あまり使わないと思うよ

誰かSAP ORACLEの　DBについて何か教えてください。

>>136
意味がわかりませんので、もう少し近くの人に基礎を教えてもらってください。

壊れたときにリカバリーが簡単なのはどこのＤＢ？

>>138
壊れ方を限定してくれませんか？

>>139
では、データベースファイルの一部のファイルが壊れちゃったとき
と
ミスオペレーションでテーブルを消しちゃったとき
でお願いします。

DB2 ,Oracle, Sybase, Symphowareぜんぶできるよ。
運用次第だけどどれでも同じ気がする

>>139
いずれの場合もSymfoWAREの場合はrdbdmpコマンドでバックアップをとっておいて、
イっちゃったらrdbrcvコマンドで、バックアップとアーカイブから戻しでOK。

え、聞いてない？

＞142
蛇足だがアーカイブをrdblogコマンドで抜いておくのを忘れてると思う

中小企業向けのERPシステムでオラクルのダンプファイルが約１G
これをCPU　セレロン７００MHZ、メモリ３００MHZ（テスト機）
にimport するとどれくらいかかりますか？
ドスからimp コマンドついかいます

DOSってことはサーバと別端末から？
それで1Gは正気の沙汰じゃないからやめといた方がいいよ。

CPUなんかもっとへぼくていいから
サーバ上で、rollbackセグメントとredo logたっぷり用意して
やりな。
メモリ300MHzもわけわかんないけど、すごいの？

>>144
ディスクの速度は？
（1GB÷ディスクの速度）×1.5くらいでおわるだろ。
速度わかんなかったら、でっかいファイルつくって別のディスクにコピーしてみれ。
それで大体わかる。

>>146
ディスクじゃないよ。ネットワークの速度で割ってくれ TT

DBってディスクでずいぶん性能が変わるけど
ボリューム配置って、どう考えます？

　Ora使って基幹系のDB(細かい更新が多い。全部で数百GBクラス)の場合
Volume1 RAID-1 ReDoLog(主-1)
Volume2 RAID-1 ReDoLog(主-2)
Volume3 RAID-1 RollBack
Volume4 RAID-5 Data(TableSpace)
Volume5 RAID-1 ArchiveLog貯め

　ってな感じが本来かと思うんですが、ここで現実レベルへの
「妥協」がいろいろ入ってきます。その優先順位ってどう考えますか？

・正直ロールバック専用でボリューム割く事なんてあんまりない
・ログのソフトミラー(by Oracle)って、RAIDかけてても設定します？意味ない気がする。
・archieプロセスとlogwtrプロセスのディスクアクセス競合の影響はやっぱり大きいですか？
・データベース自身の領域のRAIDレベルは1か5か？
　5の読み込み速度は魅力だけど、ランダムアクセスじゃメリット薄？
　（あえて0+1は入れてません。そんなお金持ちじゃないから:笑）

みなさんどうしてんでしょ？

まず、業務による。

人の命か会社の生命がかかってるなら、
control filesとredo logだけはmilloringする。

基本は全部1。パフォーマンスがどうでもよくて容量が気になるなら 5。
要領が問題なら予算によって0+1か5。6は使ったことない。

トランザクションが遅くて死にそうならrollbackは別にとれ。
logは親が死んでもmirror化しとけ
5の書き込みが速いかどうかも業務による。
5をやるならraidのキャッシュは狂ったように積んでおけ。

で、1か5かわからなかったら、素直に、取っ替えながら計れ。

Volume3もRAID5にしたいところじゃのー
あと、RAID5とか0+1の速度はちゃんと測ろう！
ランダムアクセス入るとあとはキャッシュだのみになっちゃうよ。

DML発行しただけでアクセスが入るボリュームは
RAID5がいいでしょう。
そういう意味では、制御ファイルとREDOとRBSとインデックスを置いてる
ボリュームをRAID5にしたいところ。
表置いてるところは、、、大きさもあるので臨機応変。
REDOの退避ファイル（アーカイブ）はミラー程度でいいかなと。

基幹で小規模の更新つーとOLTPのことか。
しかも100GBオーダーなんね、、、
結構むずかしいな　当たり前のことしか怖くて書けない（ｗ

1.インデックスのヒット率を9割つーか限りなく10割

2.表のヒット率は
　　a)1クライアントにユニークなレコードは9割つーか限りなく10割
　　b)それ以外の表は7割以上

3.ログへの書きこみはタンザクかつIOPSが多くなるので
　ストライピング必至

4.アーカイブ退避ファイルへの吐き出しは夜間に。
　吐き出し先はミラーされてれば十分。
　別にされてなくてもいい（そういう場合はすぐテープに落とすこと）

5.削除追加キー更新の多いテーブルは夜間にアナライズしましょう
　そうでなければ放っておいてもいいけど

6.大規模バッチ処理はリラン可能な設計にしておいて、NoArchive運用
　処理終了後に厳かにバックアップ

・端末くくりつけもの
・大量レコードで端末間で共用するもの（口座情報など）
・レコードに入るデータ自体がでっかいレコードもの
の3つのチューニングポリシーをきちんとわけないとキツいね。
上から順に
・ヒット率100%めざす
・70%以上はほしいな
・キャッシュはI/Oのワーク領域とみなす

常識論としてはこんなもんでしょうか・・・

Analyzeは月一くらいで(・∀・)イイ!!

大規模バッチでアーカイブログを捨てるなら代わりに
バッチ用のテンポラリをそっちのディスクに置くと(・∀・)イイ!!

raid5は思ったより速くないから
millorringで足りるならそっちの方がやすくて安全で(・∀・)イイ!!

業務ポリシーがかわんなかったら年2回程度でもよさげ < アナル

>>153 >>154 >>155
ｾｲｶﾂﾉﾁｴﾀﾞﾈ　(・∀・)ｲｲ!!

RAID5は書き込みが遅い。
むしろRAID1の方が軽い感じだ。
RAID0+1のほうがベンチマーク的には圧倒的に速かろう。
HDDが安いイマドキなら、迷わずRAID0+1で組んだほうが幸せになれる。

えー、人件費の次に高いのストレージ代じゃない？

でも、0+1使えるなら、RBSとredo logだね。
他は1でいいよ。壊れなきゃいいのさ。

>>159

漏れの環境が恵まれてるのかな？
36GBのHDDを50個ほどまとめ買いして湯水のように使う予定だが。
人件費に較べれば、棄てるほどのコストだ。

ストレージ代って言い回しだとメインフレームかな？
そっちだとHDDは高いのか？
スマソ。漏れはUNIX/NTが守備範囲だから．．．．

まったりと異文化交流きぼん。

Analyzeなんかして、アクセスパスが変わると面倒なんで、
ヒント付きのSQL文で最適化したほうが良さげ

DB=ドラゴンボール
ドラゴンボールについて語り合ってくださいよ

>>162
いや、データベースの略ですよ

ボラクル

>>160
んじゃ、異文化っつーことでひとつ。

メインフレームだと
記憶装置を1万台以上つなげてるとこもあります。

でも、50個積んであるってのもいいね。
Raid装置とケースも、山積み状態？

倉庫代かかりそうだ。

MySQL !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
へへへ

>>160
基盤系だとアリなんでは？（0+1）×２の4重化で
100GBオーダーなんかだと結構ありありよ

>>165
メインフレームにはバスネックってないのかな・・・？
イヤ、マジで感覚がピンとこないのです < 1万個

>>161
インデックスがシーソーゲームにならない構造なら
ヒント句の方がいいよねー
そうではない場合、逆に性能試験で想定パターンを通しておいて、
意図的にAnalyzeしてぎっこんばったんやっちゃうっていう荒業もアリよ。

>>167
チャネルの速度が速いからそこそこいけるよ

でもチャネルは256までしか作れないのが悩みらしいよ

さらにチャネル->ストレージ間の混雑ぶりは確かに頭が痛いよ

>>165
1万以上か、さすがに桁違いだね。
記憶装置＝HDDだよね？
1個の記憶容量ってどのくらいなの？

>>170
DASDだからいわゆるPCのHDDとは形も記録方式違うよん。

でも容量まではしらぬ。すまにゅ。
知ってても客先の環境だから勝手にはなせぬ。

もちろんいっぺんにアクセスするんじゃなくて、
走らせる業務ごとにこれとこれとこれ、みたいな
やり方してるけどね。

PC版だから、板違いかなあ。

しんふぉうぇあ/RDB TREE　マンセー!!

rdb tree ってなあに？

おらくるを使った後に、ぽすぐれはきつい。

以下の書籍どうですか
まじめにやって力つきますか？
変な癖つきませんか？



http://www.oreilly.co.jp/

Oracle PL/SQLワークブック
好評発売中!!!

Steven Feuerstein、Andrew Odewahn 著
石井 史子 監訳
有限会社福龍興業 訳
2001年6月発行
680ページ
本体価格5,800円
ISBN4-87311-045-9

Oracleのシステム運用においてベースとなる言語、PL/SQLのプログラミング問題集です。前半が問題部で後半がそれに対応する解答集となっています。ひとつの章に20前後の問題が含まれ、それぞれ初心者、中級者、上級者向けの区分がされているので、自分のレベルに合った問題を選択してプログラミング能力を向上させることができます。プログラマが日々の業務で直面しそうな問題が多数掲載され非常に実用的です。サンプルコード集としての利用価値も高い一冊です。

>>174
学生なんで ぽすぐれ 使って勉強中なんですが、何がつらいんでしょう
JOINが怪しいとか、外部キーが動かないという話でしょうか?
それとも、パフォーマンスの話でしょうか
後学のためにご教授いただけると幸いです。

もちろん、私は おらくる使ったこと無いです。

商用RDBに慣れた身にはMySQLもきついぞ

age

オラクルをやった後にposgre がきついっていうのが良く分からない。
同じSQLではないのか?

あーげ

>>179
プログラム言語が変わったり、メンテとか細かいとこまで考えると、
製品ごとの勉強が必要だからね。

psgre しかやってない人がオラクルやると
なると、どんなにベテランでも、PL/SQLは参考書
みて勉強しなければわからなかったりするもんでしょうか

動けばそれでいい程度なら、ポスグレ→おらくるへの移行は難しくなかろ。
ただオラクルは独自SQLが多いがね。

性能追いこむとか、レプリカやるとか、高信頼性運用やるとか、
バックアップリカバリだとかをきっちりやるとかいう向きでは
おべんきょ大変だけど

>>183
じゃあ、逆がつらいってのは 機能がpoorだから って事？

>>184
それまでに培ってきたOracleチューニング技法が
さっぱり通用しないのはつらいね。

ど素人SQL書きに転身〜☆

>>184
やれることが多いから選択に苦しむのと、
「Oracleだったらできるよね？」的に追いこまれて逃げ場を失うのが
そもそもの苦難の始まりなんよ

PoorならPoorなりの「ここまでしかムリ！」って線ひけるからね

RDBMSというからには、
・SQL翻訳結果キャッシュ
・テーブル、インデックスのキャッシュ
・ログのキャッシュ
・テーブル、インデックスの断片化
・テーブル、インデックスの読み書き競合
・ログの書きこみ競合
・排他競合
なんてのはあると思うんだけど、、、ポスグレはどうなんでしょうね

>>183
Oracleしか知らないんだけど、どこらへんが独自なん？
#そういえばSQLServerな人にDECODEの説明で苦労した覚えがあるな。

age

>>187
DBMSといいつつ、DBMSの機能全てが必要とされるシチュエーションも多くない、というか必要ないシチュエーションも多いからね。

どうも、私は現在学生で情報処理の仕事をしたいと思っています
オラクルシルバーになんとか合格できました
仕事としてはプログラマーから初めてSEになるというように考えていたのですが
プログラマーは逃げ出したくなるほど大変だという話を聞きデータベース
の仕事のほうがいいかな...と考えたりしています
DBの仕事でPGに比べていい点、悪い点を教えてください

>>191
激しくスレ違いだ。
同じ学生として恥かしい・・・・

DB屠るのもSEかPGの仕事のうちの一つです
としか言いようが無い。

DBで生きていくには、、、
やっぱsarとmpstatとiostatを1分眺めて
「終わってるね（ぼそ）」
くらい言えないとダメだな。

>>191

しるば程度じゃ使えーん

>>191

プラチナ獲ってからそういうこと言いなさい。
それ以上に、DBのチューニングは大変よ。

>>194

マシンがプアだね。いいの買えば？
なら言ったことある。

ふう、おまえらは学生時代にプラチナもってたのかい
アルバイトと女のケツ追っかけるのに夢中でオラクルさえ知らん
かったくせに、中学生が小学生に向かってお前ら「小学校通ってんのか
ダセェなあ」っていってるレベルだな

>>197=191
漏れの学生時代はOracleMasterなんて無かったよ。
代わりに、旧情報処理1種だったがダメか？

その程度で逆ギレしてるようじゃ社会人としての適性がなさそうだな。

暴力団の構成員になりたいです、ようやく前科1犯になったんですけど、
若頭の仕事で鉄砲玉に比べていい点、悪い点を教えてください

て質問に、「ヴァカ」って言ってるだけだよ。

殺伐とした中微妙にほほえましいのでage

>>197
ﾜﾗﾀ

社会人というのは年食えば馬鹿でも自動的になれるからね。まさに厨房。

少しは >>192 を見習えよ（ｗ

>>194
それだけではまだまだシロート。
w [enter]　だけで善悪判断を下せないようではプロと言えないね。

>>191
マジレス。
ＳＥかＰＧか、ＤＢかネットワークか、
会社によってどういう人がどういう内容を担当するかは
まったくことなるから職制としてはこう違う、
というように答えられる人はいないぞ。
まさに会社の数だけ答えがある。
ＤＢ専任でつくなんてよっぽど大規模か金に恵まれてるかだよね。

でも学生のうちから勉強してるんでしょ。
たとえスレ違いだとしても最終的に実力つくのはそういう人だって。
天狗にならなきゃいいんじゃない。

どっちかというと煽る方が大人気無くてイタイぞ。

>>191
DB専門職？
いけるいける大丈夫、大抵のPG・SEはDBを良く知らないから。
SQLを良く知ってるだけの年寄だけだよ。

最近、就活の学生がペーパーOracleMaster取りまくってるよ。
試験会場行ったら分かるけど、「個人」で受けている人は多く
がそうみたい(受付のねーちゃんに聞いた)。Oracle Silverな
んて価値低いのにね。取っている人には悪いけど3万円も出し
て取る程でもないよ。

＞やっぱsarとmpstatとiostatを1分眺めて
詳しく教えて！

オラクルもどんどん簡単になってきているぞ。
だれでも使えるようになるよ。

発注元から、Solaris、Sybaseを指定されているのだけど、Oracleを使わない
理由ってなんなんだろう？

>>208
日経なんとかにDBの比較記事がタイムリーに載ってたから

自分等の作ったソフトの試験をユーザに受けさせるなんて
傲慢だ！ふざけるな！と、俺は言いたい。
でも、若いやつはシルバー取ってうれしそうだよなあ。

みんなRDBの話ばっかですけど、
そろそろODBに行きませんか？
質問がけっこうあるので。

ObjectStore、Vasant、Objectivityに詳しい人。。。。。

>>208
高いからだろ

それは無いと思う。
人件費やファイルサーバ費用に比べたらゴミだから。

>>172
おまえも社保か。
まぁがんばろうや。

じゃオラクル嫌いなんだろ

>>208
そのユーザさんが昔使ってたとかでないの？

>>208
その発注元さんが
sybaseの代理店なんちゃう？

>>216
同意。

ODB使っている人、いる？

いない

age

ObjectStore使ってるけど、何か？

>>222
どういう業務に使っているのですか？
やっぱりservletから利用しているの？
ODBを使うメリットは出ていますか？

Oracle9iはどうよ。
大本営発表な宣伝メールがきてたが

ageeee

>どういう業務に使っているのですか？

それはちょっと秘密。

>やっぱりservletから利用しているの？

クライアントはC++で書いています。

>ODBを使うメリットは出ていますか？

今のところデメリットの方が大きいです。

>>226　ﾚｽありがとうございます。
世間一般がﾈｯﾄﾜｰｸ型からRDBに乗り換えていったようにRDBから
ODBに乗り換えってあるのかな。

OO自体が開発者を選ぶ（理解してないと取り組めない）感じがするので
やはりだれでも簡単にﾒﾘｯﾄを享受できる、
ってわけにはいかないんでしょうか・・・。

age

移行の必然性が無いので、ODBはニッチのままでしょう

ＯＯＳＱＵＡＲＥ ＭＬでＯＤＢの崇拝者が最近いたがあの宮●ってやつは
どうしようも無い奴で転籍させられたんだ。（藁
エクセロンもＯＤＢだというような奴を相手にしないように。エクセロンは
内部でＯＤＢを使っているけどＯＤＢにあらず。

Object系DBって、言われたほどは導入例が増えてないような気がしますねぇ。
今後の動向なんですが、

たとえばMSはExchange(ディレクトリ系)とSQLserver(RDBMS)を
住み分ける戦略にでてきたりしてます。

Oracle9iの資料ナナメ読みした感じじゃこちらは
「なんでもRDBMS」にしちゃおうとしてるように見えます。
＠ラージオブジェクト型をRDBMSとして扱うのはどうよ？って気も結構しますが。

　DBのすすむ方向ってどうなるんでしょう？

Object系DBはCA社のＪａｓｍｉｎってのがあったけど、これは最悪だった。
バグ多いし、使用用途もはっきししていなかったしね。

age

>> 232
そこですよね〜。NDBからRDBは意図が明快だから移行していくのは
わかるけど、RDBからODBに移るﾒﾘｯﾄがそれだけあるのかどうか。
自社でOOの資産を溜め込んでいる会社なら開発高率アップの為に
有効に使えるのかもしらんけど、多数があつまるような大ﾌﾟﾛｼﾞｪｸﾄで
そんなもん他社がメンテできるのか？って気がする。

一生自社でお守していくシステムならいかもしれないが・・・
個人的にはOOが普及していくとは思えない。

×OOが
○ODBが

>>232
ＣＡが珍しく自社開発(と言っても不実と共同開発)したやつね。
確かに分からんかった。
ＣＡ社は買収に買収を重ねて大きなった
会社だから社内で競合製品たくさん持ってる。
ＤＡＴＡＣＯＭだっけ！ＲＤＢ製品は？
でもツール系はオラクルやＤＢ２対応版ばかりだもんね。
まだ使ってる会社あるのかなぁ？

アクセスがＣ／Ｓに対応したのはいつですか？

ODBでキャッシュしてパフォーマンスを上げるんだよ。

初心者の学生です。
研究室で画像データベースを作ることになったのですが、DBの基本から勉強中です。
作成にあたって注意することとか、オススメの参考書もしくはWEBってありますか？
フリーのPostgreSQLで作ろうと思ってます。

>>237
MDBでという話なら、してない。じき壊れる（こともあるらしい）
ADPでMSDEやSQL鯖を使うんなら2000からだ。

PostgreSQLはXMLに対応してるの？

>>241
ﾎﾚ
ttp://xmlpgsql.mediafront.co.jp/

　

age

age

＞２２６

すべてC++で書いてあるのですか？
MFC使っていますか？

ORACLE、MSSQLServer、SYBASEを使ったけど(やっぱOracleが長いね)、
MSSQLServer、SYBASEはクエリが楽！
Win上ではORACLEもMSSQLServerも信頼性は似たようなもんかな。

金融系のシステムではSYBASEは馬鹿にできん。
SYBASEしか対応してないアプリがあったりする・・・
かつ、SYBASEががんがん動いているらしい？?

>>247
MilitarySpecを満たした商用DBはSYBASEだけってﾎﾝﾄｹ???

フリーのOODBってあるんですか？

>MFC使っていますか？

MFCと何の関係があるんですか？

age

XMLが増えてきたらODBは流行るのか？

>247
トランザクション処理に向いていたから。
特定目的に作られたものに多く、仕組みとして販売されているもの
に多い（金融情報とか）。そのままきているというところでしょうか。
他の処理を考える必要ないし、作っている方もシステムの
専門会社ではないので、もともと汎用的には考えられていものが多い。
そのため、sybaseのまま。

>>253
金融情報って何？
アプリの組み込みDBとしてなら
遥かにOracleのほうが多いぞ。

＞＞２５４
２５３です。そうですよ。
Sybaseの法が多いなんて、誰も言ってない。
昔から残っているものがSybaseのままだと
言っているの。
トランザクション向きだったので、取引情報サービス
なんかで使って、そのまま使ってるという感じ。

ibm のdb2どうですか？
これからくるとおもうのですが

>>255
dbがsybaseってきいて、「えっ？？？」て思ったことが何度かあるけど
そんな理由ナノカ

DB2ばんざーい！

age

db２ てアシュトンの？

>>260
あ！DBASE2だとか言うのあったね。

http://dblp.uni-trier.de/db/books/dbtext/Gray93.html

どうよ

Postgresが世界を席捲する日が近い

Postgres のソース読んでｄｂ勉強しようよ

なぜINDEXをつけるとはやくなるの？

>>265
索引検索するからです。(案内板あると迷わないよね)

災ベース

何か良い資料ないですかね。
ＸＭＬみたいだなとは思っているのですが。

ＯＤＢＣってなんですか？
別にＯＤＢＣが無くてもデータベースにアクセスできますよね？

>>269
出来ますよ。
今はＡＤＯが主力です。

>269
他ならＯＲＡＣＬＥならｏｏ４ｏとか、
他のＤＢならＪＤＢＣ（ＯＤＢＣもどきだけど）とかかな。
どうにでもなるよ。

>>270
ようするになんなんでしょ？
TCP/IP＋SQLより下位層のプロトコルのモジュールって捉えていいのですか？

telnetでも十分アクセスできますしね。

>>272
ODBC(Open Database Connectivity)とは抽象的なAPIで、
様々なRDBMSサーバと協調動作するアプリケーションを書くことができます。
ODBCは、フロントエンドアプリケーションとデータベースサーバの間に、
製品に依存しないインタフェースを提供し、ユーザや開発者が異った
製造者のサーバ間で汎用性の有る アプリケーションの作成を可能としています。

# つまり、共通に見せ掛けたインターフェイスだったことね。（汗"
# だから、対象のデータベースごとに実インターフェイスのドライバーが必要だったりします。

>>271 >>273
どうもどうも。

mysql

オラクルはインデックスにB-TREE
ACCESS2000は？

そんな事より１よ、ちょいと聞いてくれよ。スレと少しは関係あるからさ。
このあいだ、うちの会社で４Ｄ使ったんです。４Ｄ。
そしたらなんかバグがめちゃくちゃいっぱいで大変なんです。
よく見たらなんか別テーブルのフィールドが出てきて、一旦違うテーブルを
選ばないと
正しいフィールドが選択できないんです。
もうね、アホかと。馬鹿かと。
１５０件ぐらいの明細をまとめてトランザクションかけたぐらいで止まるん
じゃねーよ、ボケが。
１５０件だよ、１５０件。
なんかプロパティリストでオブジェクト名長くすると飛ぶし。そんなチェッ
クもできてねえの。おめでてーな。
しかも日本語使ったオブジェクト名や変数名を編集すると位置によっては文
字化け。もう見てらんない。
４Ｄ社、頼むからなんとかしてくれと。
データベースってのはな、もっときちんとしてるべきなんだよ。
テーブルのフィールド設定でいちいちわずらわさず、スムーズに設定でき
る、
そうでないとめんどくさいじゃねーか。あとでまとめて編集する時辛いんだ
よ。
で、やっと動いたかと思って、印刷かけてみたら、内部的なエラー吐いてフ
リーズするんです。
そこでまたぶち切れですよ。
あのな、旧版からコピペしてきたフォーム印刷するだけでフリーズすんな
よ。ボケが。
高い金とっといて何で、こんなんでフリーズすんだ。
お前ら本当にやる気があるのかと問いたい。問い詰めたい。小１時間問い詰
めたい。
お前ら、「小さく生んで大きく育てる」って言いたいだけちゃうんかと。
４Ｄ通の俺から言わせてもらえば今、４Ｄ通の間での最新流行はやっぱり、
４Ｄ　Ｉｎｓｉｄｅｒ、これだね。
できる限り４Ｄ　Ｉｎｓｉｄｅｒで開発。これが通の開発のやり方。
ところで４Ｄの四則演算には優先順位がない！普通はカッコだらけになる。
これ。
で、あらゆるところでコピペ連発。これ最凶。
これをやると確実にデスマーチに陥るという、自殺行為。
普通の神経の持ち主にはお薦め出来ない。
まあ、大規模開発には４Ｄは向いてないってこった。

>>277
ﾜﾗﾀ
情シス板で初めて笑ったコピペを見たよ

ODBCもADOも重要だが
業務には大事なのはモデリングでは。
むずかし。

postgres+jdbcでlisten/notifyを使った非同期通知って
できないでしょうか？

http://www.f2.dion.ne.jp/~goldman/

ところでDBチューニングの要ってなんだい？おしえろごるあぁぁ

ディスクアクセスとその競合を極力まで減らすこと

ところでコン猿の先生のつくったゲージツ品のろじかる設計DBをどーやってそのまま物理におとすんだい？正規化崩しはご法度だ（そうだ）！マ痔おしえろゴルアｱｱ！！

>>284
omowazu warata

9iの話はなかなか出ませんな

２８６
９iは単なるファイルサーバーだよ

>286-287
別すれたってます

>>270

>出来ますよ。
>今はＡＤＯが主力です。

うそだぁ〜
ＡＤＯが主力？

>>289
主力ですよ♪

oo4oのほうが主力。少なくとも漏れのいるところでは。
あと、ＯＤＢＣも未だ健在・・・

AGE

データベースという概念が大きく変わるよ。
将来的に全てＸＭＬに取って代わられる。

>>293
> データベースという概念が大きく変わるよ。
> 将来的に全てＸＭＬに取って代わられる。

ん？
ちょっと情報が遅れてるような気がするのは私だけか？
Webサーバー技術は確かに便利だけれど閉鎖環境での業務も多く存在するよ。(むしろ此方が主力！)
で、ITを利用したWan接続サービスが充実する傾向にあるので専用線の淘汰は既に始まっている。
分散処理でのメリットも多いしWebサーバー技術はそれ程主力になるとは思えない。
まあ、バーチャルストア系だとそれなりに使える技術だけどね。
幾ら進化したところで小回りは効かないよ。

>>294
>>293は、既存のリレーショナルデータベースというものが廃れていく
と言いたいのでは？
俺は同意しないけど。

>>295
> 既存のリレーショナルデータベースというものが廃れていく
> と言いたいのでは？

そうなのかなぁ？
実は293の投稿を読み切れないで居るんだよね。
ＤＢの仮想実装技術に付いて発言したいのだと思うのだけど．．．
それって所詮枝葉なんだよね。
まあ、固有のＤＢ性能を競ってる時代じゃないのは理解出来るんだけど．．．

# 出来れば293さんにもう一度真意を語って頂きたいと思ってます。

>>296
>そうなのかなぁ？
だって、それ以外に読めないじゃない。

単に、既存のRDBやORDBが廃れて、XMLが台頭するという予測を293が
持ってるという、個人的見解の発表なんでしょ。

っていうか、俺は>>294の方が読みきれないで居るんだけど。

「将来的にデータベースがXMLになる」という予測は、古い情報に基づいた予測で、
その予測は間違っているということを言いたいのかな？

現在はWebサーバ技術というものが目に付き、そして、そこではXMLが
使われているけど、それは本筋じゃないので、XMLの台頭はありえないってこと？

ちょっと言い方がまずかった。

「将来的にデータベースがXMLになる」
↓
「将来的にXMLがデータベースに取って代わる」

> 単に、既存のRDBやORDBが廃れて、XMLが台頭するという予測を293が
> 持ってるという、個人的見解の発表なんでしょ。

そりゃそうだけと、ＤＢとXMLとを比較する意味って一体なにさ？
そこが意味不明なんだな。

> 現在はWebサーバ技術というものが目に付き、そして、そこではXMLが
> 使われているけど、それは本筋じゃないので、XMLの台頭はありえないってこと？

ってか、競合するって考え方自体が不思議なんですよ。
XMLを一体どんなものって理解してるの？

>>299
>そりゃそうだけと、ＤＢとXMLとを比較する意味って一体なにさ？
比較はしてないのでは？

「将来的にXMLがデータベースに取って代わる」
と主張しているだけで、これは当たるか外れるかの二者択一問題。
293は、そうなると思っているというだけのことでしょ。

>ってか、競合するって考え方自体が不思議なんですよ。
>XMLを一体どんなものって理解してるの？
と、俺に聞かれても困るけど｡

データの保存というものが、全てXMLで行われるようになるっていう主張なんだから、
その通りに読めばいいのでは？
そして293はその通りになると考えている。それだけでしょ。

俺は同意しないけど。

ACCESSで見たORACLEのデータをEXCELに持ってくるとき、文字化けしないように
するにはどーすればいいですか？

みんなレベル低すぎ。

302> くそ

お前ら、Jim Gray の「Transaction Processing: Concepts and Techniques」
の日本語訳が出ていますが、どうよ？

発掘あげ

正規化すればデータの冗長性が無くなって良いなんて話は、
教科書に書いてあることで、
金融系や公共のでかいシステム（１表のデータ件数が５０００万件超とか）では性能を重視した設計をするので、正規化は普通やらない。
（最近は、ＵＮＩＸでＣ＋＋、ＤＢは汎用機ってパターンが多いな。両方売りつけられるし）
コーディング工程から入ってくる、小さい会社の奴らは、口をそろえて「何で正規化し無いんですか？」なんてぬかす。
ＤＢＭＳの定義自体も大規模なら構文ベースだし、コストベースではあまり定義したシステム見たこと無い。

>>306
正規化はやらない、じゃなくて一旦正規化したあと
実際の運用を勘案してあえて冗長性をもたせる、ではないの？
少なくとも漏れのとこはそうしてたよ。ちなみに某都銀の
情報系システム

>>307
確かにそうすることもありまする。
（大規模だとＤＢ定義変更が大変作業量、時間等）
分かりきっているものはというう意味です。
ちなみに私も都銀情報系と、数年前まで某官公庁システム

>>306

お前、正規化したことあって言ってるのか？

俺は某都銀の正規化されてないDBを正規化してdisk容量:1/3、
パフォーマンスも半分に縮小してやったぞ。しかし、これは
トランザクション系のDBだ（情報系では確かに一概に正規化が
正しい設計とは言い切れんがな）。

正規化を普通やらないとまで言うのは、ちょっと言い過ぎじゃねぇか？

もしくは正規化すると動かなくなるDBMS(ex.Oracle)しか
使ったことねぇだろ。

>>306
ただ単にチューニング知らないだけと思われ

>>309
ホントに都銀？ちなみに都銀の何システム？
ＰＣサーバとか中小規模程度のUNIXサーバで構築されたシステム
だよね？じゃないと、ちょっと「？」って部分があったもんで。
あ、自分は某都銀の元・システム部所属の者です（今は全く別の会社）

>>306
単に設計者が元COBOLERなだけでしょ。
パフォーマンスを考慮しないモデリングでは、正規化するのは当然。
非正規化とは、正規化しないことではない（これ知らない奴も多いね）。

>>307
>コーディング工程から入ってくる、小さい会社の奴らは、口をそろえて「何で正規化し無いんですか？」なんてぬかす。

あたりまえでしょ。
文句の出ない非正規化ならともかく、正規化してないんだから。

>ＤＢＭＳの定義自体も大規模なら構文ベースだし、コストベースではあまり定義したシステム見たこと無い。

Oracleは普通コストベース。
ルールベースにするには、特にそうと意識しなければいけない（ヒントとか）。
「DBMSの定義をコストベースでやる」なんて表現はしないが。

オプティマイザに勝てる設計が常にできるなんて、無知もいいとこだね。

誤）>>307
正）>>306
ｽﾏｿ

>>309
>お前、正規化したことあって言ってるのか？
当然ある
>もしくは正規化すると動かなくなるDBMS(ex.Oracle)しか
>使ったことねぇだろ。
逆に.Oracleは使用したこと無し。
DB2,XDM/RD,HiRDB等

>>311
>ホントに都銀？ちなみに都銀の何システム？
>ＰＣサーバとか中小規模程度のUNIXサーバで構築されたシステム
情報系の顧客管理です。
全店展開でUNIXサーバ＋XDM/RD（←日立汎用機RDB）
総データ量で、５ＴByte程度です。（年間成長率１０％）

>>312
　開発言語はＣ＋＋

>>313
ルールベースだと、ﾄﾞｷｭﾝPGが巨大な作業表を作る無茶なSQLを発行することが多々あるため。が主たる理由

まあ一般論を言った訳でなく、今の私の担当システムの話をしただけですので、あまりつっこまれても。
私自身、以前はＤＢ部（ＤＢＭＳを作る部署）に所属していたし
当たり前のことは知っているつもりです。

>>315
XDM/RD?　聞いたこと無いな。
ＤＢ２なら知ってるが。
HiRDBはどっかのスレで叩かれてたが、
そのXDM/RDってのはどうよ？

>>316
日立メインフレーム系のRDBMSですな。
うろ覚えでスペルは間違えているかも知れませんが、
XDM/RD E2→eXtensible Data Manager/Relational Database
Extended version 2
最近は、同じく日立のオープン系HiRDBとの連携機能があって
PCからtelnetとかで操作可能だが、
機能的にはたたかれていたHiRDBと基本は同じはずなので．．．
メインフレーム系なので、過去の資産、大容量データ位にしか
有効ではないのかと思いますが？

詳しい方、補足願います。

ＡＤＡＢＡＳ(for メインフレーム)ってどうよ？

Ｆ　ＡＤＡＢＡＳ，ＡＤＡＥＮＤ
ドドド、ドーーーン！
逝ってよし

￥ＳＨＵＴＤＯＷＮ　ＬＶ３

RMAN>run{
allocate channel ch2 type disk;
set until tyme '2002-11-21:18:07:00';
restore database;
recover database;
sql 'alter database open resetlogs';
}

お前ら、オラクルのバックアップは普通ＯＳコマンドですか？
それともＲＭＡＮですか？

おれにゃ、面倒でＲＭＡＮ使いこなせないよ。

丸善からでているデータベース概論1万8千円どうよ？

>>322
Date のやつ？ 借りて読んだけど、よー分らん。
じっくり読める時間が欲しい…

DB?
オブジェクトストアがあれば、事足りる。

今は沢山本が出てるからDateのじゃなくてもいいでしょ。
だけど日本語の本というと限られてくるか。。。
にしてもその値段は買うなと言ってるようなもんだな。。。

★お小遣い稼ぎ★
簡単・安全
在宅ワーク可能！！
興味のある方は下記へＧＯ！！
http://members.aol.com/hnworld/

保全age

非常にいいスレだage

といいながらageてなかった鬱だage

ついでに揚げといてあげよう

IBMでもオラクルで提案してくるんだね
確かに運用の人間からすると同じマシンや同じＤＢの方が扱いやすいか

>>331
そりゃ，なんでもかんでもDB2とはいいませんよ
#そうしたいのはやまやまでしょうけど

ただ，個人的な経験からいくとAIXならDB2，SolarisならOracleが
いいように思います。純粋にS/Wのサポートや保守性からいうと。
実際には開発・運用・保守する人のスキル・経験の問題で
決まることが多いでしょうけど。

最近はxmlをマッピングなしに扱えるDBがありますよね。
使ったことないけど。
ttp://www.dbxml.org/
あたり試してみた方います？

よーしパパageちゃうぞー

保守sage

hage

>>333
　「ソフトウェア・デザイン」の記事にも載ってたね。
　パパ、今度の休みに試しちゃおーかな♪

まあ 素人はアダバスでも使いなさいってことだ。

アプリケーション組み込み用って何がいいんでしょう。
できるだけメンテナンスフリーにしやすいもの。
あんまし単価の高くないWindowsのパッケージソフトに組み込むとして
ライセンス体系とかも考えてです。
それに大規模とかシビアな環境での性能は重視しないとして。

hage

[h] = 保全
+
[age] = あげ

（＾＾）

MSDE（SQLServer）がベストと思われ。
勘定奉行とか使ってるしな。

> 344
組み込みするのに開発と配布が安くついただけだろうよ。
こないだのSlammerみたいなことがまたあるだろうから
危なくてつかえねえよ。Accessも同じだ。

質問１
　　ADOでJETをアクセスするんだけど、検索スピードが無茶遅い。
　どうしたら、速くできるかおしえて。
質問２
　同じく、正規化した場合、テーブルから１つレコードを消したい場合、
　参照しているテーブルのレコードは全部検索して消さなければならない？
　　レコード削除の原理がいまいちよくわらん。おしえて。

>>346
質問１
A:アクセスする対象がSQLデータベースだったら、パススルークエリ使ったら？
質問２
A:カスケード使ったら？

オブジェクト指向DBでフリーのものってある？

関係モデルのテーブルだったら既に第1正規化されてることが前提でしょう。
デイトの『データベースシステム概論　第6版』に書いてある。

ごめん。すごい昔のレス見てた。

>>347
ADOアクセスって、クエリ投げてるんじゃないんだ？

（＾＾）

ＤＢ　Ｎｏ．１　は　ロータスノーツだ

>>351
ADO-OLEDBでJetにアクセスするとオーバーヘッド少ないというけれど
ADOX使ってパススルーしたほうが早いってこと

（＾＾）

　　 ∧＿∧
　　（　　＾＾ ）＜ ぬるぽ（＾＾）

あぼーん

あぼーん

　　　 　∧＿∧
ﾋﾟｭ.ｰ　(　　＾＾ ） ＜これからも僕を応援して下さいね（＾＾）。
　　＝〔~∪￣￣〕
　　＝ ◎――◎ 　　　　　　　　　　　　　　　　　　　　　山崎渉

良ｽﾚはげ

教えてｸｿで申し訳ありません。
IMSとか階層型DBの設計について、参考になる本・HPとかありませんか？

RDBに関してはいろいろ本が出てるのは見かけるんですが、階層型DBについて
は「こんなのもあるよ」程度しか出てこないのです。

　　　 (⌒V⌒)
　　　│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
　　⊂|　　　　|つ
　　　（＿）（＿）　　　　　　　　　　　　　　　　　　　　　　山崎パン

>>361
そんな旧石器時代のDB使ってる香具師はﾌﾞﾅｼﾒｼﾞ

>>361
コボラーの板行けば誰か教えてくれるぞ

IMSを旧石器時代DBというなら、infomixとかORACLE7なんかも充分に化石
になってしまいますが・・・
システム保守をしたことがない痛い人だね・・・

構造化プログラミングのコーディングだとフローチャートやPAD図。
オブジェクト指向だとこれに足してUMLの各図でドキュメント化できます。
ではSQL文をドキュメントに残すにはどうすれば、と考えているところに
(SQL文をまんま貼り付ければ、てのは無しとして)
テクニカルエンジニアのデータベース試験の教科書で関係演算を知り、これかも！？と思いました。
選択、射影はもとより、外部結合に至るまでSQL文と絡めて解説している
本というのは無いでしょうか。

自己レス〜
あれから色々と本を漁ってみたけれど、

"データベース" 昭晃堂　北川博之
"データベースがわかる本" オーム社 鈴木　健司

とかが関係代数やら関係演算やらとSQL文の関係を考察するにはいいのかも。
↓の様に考えた
・システム開発におけるSQL文のドキュメント化という当初の目的にどこまで使えるかビミョー・・・
→ぱっと見、関係代数ってUMLやPAD図ほど分かりやすくないし。。
→関係代数がSQL文のドキュメント化に使えると仮定しても、職場の皆にそれを広める、って、できるの？自己満足？
・ちこっとは役に立つかも
→問い合わせ処理についての記述で、問い合わせの最適化(実行計画みたくな話）は面白い。高速な結果を戻すselect文作るときの役に立つ。
→関係代数に関する定理は、経験と頭の切れに頼った、袋小路にぶち当りまくりな複雑なselect文作成の苦痛を少しは和らげる事ができるはず。


まじめに取り組めばモノにできるかも知れないけど、学生でも研究者でもないのにそんな悠長な事してられないし

Ｄ：デー
Ｂ：ブー

　　　　／￣￣￣￣＼　
　　　（　　＿＿＿＿＿）　　　　　
　　　 |ミ/　　ー□-□-）
　　　（６　　　　　(_　_)　）
　　　 ｜　∴　ノ　　３　ﾉ
　　　 ノ＼＿＿＿＿_ノ､
俺は偉大な事業部長だ！
DB？ドラゴンボールのことか？

370

>>369
けっこうおもろかったので。

DeBuの略称ですか？

死にたい

>>346
Jetのデータベースエンジンは特殊なんだよ。
高速にアクセスしたいのならJet固有の索引検索を使えば良いだけだ。
もちろん、一般のSQLは通じない。

保守

DB板ってなかったっけ？

イキロ

【SRA】PostgreSQL技術者認定制度【荒稼ぎ】
http://school4.2ch.net/test/read.cgi/lic/1094040519/

独自のSQL仕様作ったら汎用性なくなるよな。何のための規格なんだか。

MSにしてみればSQLServerを沢山売りたいのであろうね。
その為にはAccessのDBは汎用性の乏しい規格にして置きたいってことだろうね。
もちろん、汎用性の高いSQL文もある程度は処理出来るようにしておかないと最初からそっぽを向かれるので
それなりに制約を課して使えるようにしている。
その罠というべきものに嵌ると>>346さんのようになる訳だ。

まぁ、SQLServerのシェア率を上げる為に更にMSDE等の無償供与も始めた訳だし・・・
そろそろAccessのMDBはローカルDBとしての機能に限定した利用にすべきだと思うぞ！
つまりは、作表の為に存在するDBとして位置付ければ良いだろうね。

ドラクエ８買いに行くか

さげ

age

hoshu

データベース技術者試験だっけ？受けようと思うんだけど、受かった香具師コメントちょうだい。
俺の会社にひとりいるけど、仕事は全然できない勉強くんですた。

DB管理は非常に地味な仕事。

結局なんだかんだ言ってOracleの勝ちなんだよな、結局さ。

やっぱりSQLServer2000は使えねーな。

age

>>385
DDLがコロコロ変わると大変な気もするが。

　　　　　　　　　梅にぎりワッショイ！！
　　　　　　＼＼　 梅にぎりワッショイ！！　／／
　　+　　　+　＼＼　梅にぎりワッショイ！！／+
　　　　　　　　　　　　ｽﾊﾟｰ　　　ｽﾊﾟｰ　　　ｽﾊﾟｰ　　+
　 　　　　+　　 ／梅＼ 　／梅＼　 ／梅＼　　+
　　　　　　　　（.*´＊｀∩（´＊｀∩）（´＊｀.*）
　　　+　　（(　（つ　　　ノ（つ　　丿（つ　　つ　)）　　+
　　　　　　　　 ヽ　 （　ノ　（　ヽノ　　）　）　）
　　　　　　　　　（＿）し'　し（＿）　 （＿）＿）

あげ

MSDEでテーブルにTRANCATEをかけようとしたんですが、エラーとなってしまいました。
もしかすると、TRANCATEがサポートされてないんですかね？

すいません。スペルミスでした（汗

age

永宗　ぷーーーーーーーーーーーぷぷぷぷぷぷっ

>>395逮捕

いよいよ

質問なのですがDBで管理システムを作る場合は
Access単独で作るのと
VBやASPをインターフェイスにしてAccessはDBとしてだけ利用して連携させるのとでは
どっちで作った方がDBのレスポンス速いですか？

>>400
何をやりたいのかわからんので、作ってみれ。

DB単体のレスポンスで見るのであれば、エンジンが同じなので、
同じでは？
ただ、Accessはどのバージョンを使う、ＶＢで使うにしろ、
ADOなのか、ODBCなのかなどで全体のパフォーマンスは変わりそうだけど。
そもそもAccessをＤＢとして使うって、
エンジンとしてJetを使うってことでいいんだよね。

そもそもＶＢとＶＢＡではできることも違うと思うけどね。
やりたいことがどちらでやるべきなのかを考えて、
プロトタイプを作ってみてもよいのでは？
単純な計算＋ＤＢアクセスを１０万回繰り返すとかすれば、
レスポンスも体感できそうだし。

俺もあまり詳しくはない。的外れならすまん。

名前sageてもね・・・。

>>401
どーもです、試しに作ってテストしてみます。