何故データベース設計は軽視されるのか?
何故データベース設計は軽視されるのか? ここでいうデータベース設計とは、 特定の業務システムにおける テーブルレイアウトを設計し、決める作業であるとします。 業務システムにおいては、 このデータベース設計(テーブル設計)は仕様そのものを定義する作業にも 近いと思いますし、この設計は開発工程やその後の運用における品質を 絶対的に左右するものだと思っています。 逆にこの設計があまりにも実現すべき仕様と比較し不整合なため、 その後の開発工程がデスマーチに陥ることも少なくないのではないでしょうか? にも関わらず、正規化程度も理解できないような担当者が この設計を行っていたり、業務システムの受託開発において、 「テーブルレイアウトを決める」という作業が、あまりにも軽視されているような 気がしています。 みなさんの現場ではどうでしょうか? ご意見などお聞かせください。 今日もアホなテーブルとクエリを見てゲンナリした ○○○○○は遅いねってお前の設計が(ry >>282 性能がいいものが売れるとは限らない。 大人の事情というのがあるんだよw まあそれほどまでに当時の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も組めるし。 ポスグレはサポート無いから、業務では選択肢に無いな。 マイエスはオラクルがサポートしてくれるなら、これから使う鴨田が。 結局なんだかんだ言いつつサポートの有無でプロダクトを選ぶという矛盾が 別にサポートあったって落ちたときに損害補償してくれるわけでもないんだし 金払うだけ無駄なのがサポートだぜ パッチの提供なんて逆にPostgreSQLなんか速攻で修正されて出てくる オープンソースだから原因も即バレで、仕様ですと隠される事もないしな 矛盾つーか、セルフサポートできるんならOSSも選べるってだけだろ。 一応サポート契約していれば、どんな障害/質問に対しても「マニュアル 読め」以上の何らかの回答を一定期間内にしてくれるし。 んでその回答って役に立つのか? PostgreSQLの構築/運用実績あるSIにやって貰った方が Oracleに無駄に500万払い続けるよりマシな気がする >>303 サポート契約してれば何か起きたときの事故対策会議で「サポートに問い合わせ中です」 って言える。もちろんその後は「原因不明なので再現待ちです」って逃げる。 DBMSに限らず、商用OS等でも良くあるが…運用担当者が泣く黄金パターンだよな。 まぁ実際問題として、サポートにまともな回答もらえるとはだれも思ってないんだよ。 ただ、実質使えないサポートであっても、それを望んでいる客がいるのもまた事実だから、 そういう提案してしまうのはしょうがないと思う。 >>303 そりゃ役に立つ人はいるだろうさ。 当然、Postgresでシステム構築したとしても、Postgresのサポートを 必要とする場合だってあるだろうし。 >PostgreSQLの構築/運用実績あるSIにやって貰った方が >Oracleに無駄に500万払い続けるよりマシな気がする ぶっちゃけその通りだけどな。 漏れの中ではOracleは言うほどマシなRDBMSじゃないと認識している。 Oracleが必要な業務があるのは事実だろうが、多くの導入例では 「Oracleはいらんだろ」的な納品されている現場は多い。 しかしPostgresのシステム構築やサポートできるSIなんて 付き合いある範囲じゃ見当たらないな。 オープンソースのDBすら自分で構築しようとしないエンジニアって・・ それは「システムを自分で開発しないエンジニアって」と言っているに等しいぞ。 内製するかどうかとオープンソースかどうかなんてあんま関係ない。ただ、開発を SIに任せる場合にOSSで受けてくれる業者がほとんどないというだけ。 >>308 知り合いかどうか知らんがPostgresはNTTやらNEC系はやってるな。 別に漏れもヤれと言われれば並みのOracle程度には出来る。 つか漏れも社内のなんちゃってテスト環境用にはDreby使っている。 まぁ会社としてサポートするとなると、スキルのある要員の継続確保が問題になるな。 俺的には別に特殊なスキルが必要とは思えないのだが、商用/フリーに関わらず 調査すら出来ない人間ってのが意外といるわけで。 OSSは裾野の部分がまだ弱いからねぇ。研修制度とか、サードパーティの層の厚さとか。 Linuxは大メーカー自身が手がけるようになって大分よくなったけど。 オープンソースのサポートなんて遣るくらいならオラクル保守入って丸投げのほうが楽だな。 オープンソースで手厚いサポートできるようなスキルある香具師雇うなら、オラクル以上に金かかりそうだw オラクルに損害賠償請求する馬鹿企業は居ないが、個人に損害賠償してくる馬鹿企業は山ほど居るだろうし。 >>314 凄い妄想だな。 底辺のオマエには知らん世界だろうが、Oracle使った案件でも契約書に 損害賠償跳ね除ける文面が契約事項としてあげてあるベンダーがほとんどだが。 Postgresにサポートが無いとか、お前らシロート? 比率で言うならOracle信者ほど素人が多いのは不思議な現実。 サポートが心の拠り所らしい。 別に「Oracleはインタンスが絶対に落ちなくてサポートが満足な製品で漏れは一度も苦労した事ない」 と言える製品ならそれはそれで構わんよ。 漏れはそんなOracle見た事ないが。年に1・2回はイミフメイに落ちる。 ただまあ、漏れの経験でイミフメイに落ちた場合サポートに問い合わせても「原因不明です。OSかハードに問題があると思われます」 の逃げ口上が出て終わりなんで、PostgresだろうとOracleだろうと能力のない人間が構築したシステムは どれも自殺したくなる。 むしろ、上の発言で出てきた問題を全てIBMに投げられるiSeries、もしくはOSSだからと言う理由でPostgresを 選んだほうがラクになれる。 今までで一番酷かったのがLinuxの8iだな 2000万払った挙げ句、使用は自己責任でとか言われたw Linuxの8iって人柱Verだった頃のじゃね? まあ、未だにそれで動いているトコはあるんだろうけど。 要するに人柱バージョンを2000万でうりつけてるのかw 値段は規模にもよるから、Linuxで8iで2000万が高いか安いか判断が難しいが。 HP-UXの8でもそれくらい取るベンダー見た事あるし。ただイニシャルはともかくランニングコストは あんまし安くなかったが。年600万くらい。 Linuxの8iは自己責任と言うからにはランニングコストは0なんだろ。w DB2(iSeries)だとイニシャルは下は300万で上は2億くらいの幅でランニングは100〜600万くらい飛んでいく。 8iの頃はソラリスが鉄板だったので、リナックスなんて選んだほうが自殺行為なだけ。 東証がポスグレ採用なんて無謀な事はしないのと同じ。 IBMに丸投げ出来るぐらいの資金が有るなら、日電や不実に丸投げしてオラクルの面倒見てもらえるけどな。 うちはRACだけど意味不明に落ちてもリカバリは出来る仕組みにしてるよ。 そもそも絶対に落ちないなんてあり得ないし、ソフトのバグが無いのも信用してない。PGなんてバグ入りの欠陥品しか作れないし。製造業の品質管理に比べたら認識が甘過ぎるよ。 逆に、ポスグレは絶対落ちなくてサポートも満足と保証されてるの? 2億の案件でポスグレで組んで、損害賠償なんて喰らったら人生終わるなw oracleは絶対落ちないなんてありえない前提なのにpostgreには要求するのかw どんなdbを使おうがフェイルセーフな構成にすればいいって自分で答えだしてるじゃん >>326 なんかあんまし大型案件やった事ないみたいなのでコメントだが。 規模と傾向もあるが基幹系ならIBM(i)とその他のベンダー+Oracleの組み合わせだとIBMの方が半額くらいのコストで開発・運用が可能だ。 無論、Oracleの方がコスト安いケースもあるが、「IBM=高い」と言うのは思い込みだ。 ある程度以上の資金がいるのは事実だが、>>326 の意見は「安物買いの銭失い」な思考だ。 そして東証もけっこう落ちてるじゃねーかw いいよな。天下りで仕事もらえるようなところは。 東証を落としてもお咎めなしだぜきっと。 痛い目に会うような複雑なシステムじゃないから or ( 痛い目は末端がくらって表に出ない and それが痛い目だと気が付いていない ) ちゃんとコスト計算が出来るまともなエンジニアが皆無。 アプローチ使ってるけど、アプリの使い方じゃなくて、データベース設計の初心者本てなんかないかな 賢者に聞いていいですか? たとえば、2chとか「PC等」→「プログラム」→「【PHP】CakePHP」→「レス」って構成ですよね。 これってどういうDB設計になってるんですか? 実務経験がないのでわかりません。 「PC等(カテゴリID)」→「プログラム(カテゴリID+サブカテゴリID)」→「【PHP】CakePHP(サブカテゴリID+スレID)」→「レス(スレID+レスID)」 →「デスクトップ(カテゴリID+サブカテゴリID)」→「cpuをとっかえたい(サブカテゴリID+スレID)」→「レス(スレID+レスID)」 って感じですか? 1つのデータベースに、テーブルを1000個とか作ることとかあるんですか? その場合、テーブルの名前を特定して探しにいく方法でしょうか? 普通に考えれば2chはファイルだし、事実そう。 RDBで実装する意味が解らん。 2chの量でもファイル入出力に耐えれるものなのか。 人間のイメージなんてちっぽけなものなんだな。 >>341 実務経験がないから仕方ないのかもしれんが、 RDBに不思議な幻想を持つのはヤめた方がいい。 2chの場合は要求される仕様が「追記オンリー、更新は基本なし、当然削除もなし 発言は1000もしくは512KB(板によるが)で、ブラウザを使うユーザーにはhtml変換し 専用ブラウザはdat直読み。 そして圧倒的な書き込み&PVときたら並のRDBMSでは即死する。 ありがとう。ファイル入出力の方がいいんだね。 たしかに、DBは偉大ってイメージがあるかも。組み込みエンジニアだからDBに縁がなくて。 twitterと2chは同じようなものかと思ったの。twitterはDBだよね。メンバーの紐付けあるし。 無数にレコードが追加されるからどういう設計なのかなーって。 twitterは細かい事は知らんが、最初Rubyとデータベース使って結構落ちてなかったか? そりゃ2chだってタマに落ちるけどな。 ファイル入出力のほうがいいというのは間違い。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、ありませんか? >ファイル入出力のほうがいいというのは間違い。ISAMファイル直弄りのコボラーに成りたいならともかくw (略 >潤沢な資金力さえ有ればdbでも捌けると思うけどね。 金かければなんでも出来るだろ。 コストパフォーマンス無視して「DBの方が向いている」なんて・・・。 2chのサーバーと同じ導入コストでRDBMSを用いて実装し、 2ch以上のパフォーマンス出してから語ってくれ。 そして東証も派手に落ちてニュースになったんだが。 あれを「ちゃんとdbで注文捌いて約定処理が出来てるし。」とコメントできる神経が凄いな。 お前らDBDB言ってるけどRDBMSのことだろ テキストファイルだってなんだってDBはDBだ twitter は、元は Ruby on Rails じゃなかったっけ。今は知らないけど。 RoR は O/Rマッパーに ActiveRecord 使ってるから、多分バックエンドの DB は RDBMS だとは思うけど、何を使ってるかまでは調べてない。 そういえば、ニコニコ動画のコメントサーバはバックエンドに MySQL 使ってるね。 更新頻度の高いテーブルと低いテーブルに選別して、InnoDBとMyISAMを 使い分けてると、どこかに書いてあった。あと memcached だったかの キーバリューストアも併用して、パフォーマンス稼いでたはず。 ってか、この辺の話はDB設計と言うより、アーキテクチャ設計の話だね…… むしろバックエンドにDB使ってないシステムなどまずない とりあえず、>>350 が利用している2chはRDBは使っていない いやだからRDBMSじゃなくてDBは使ってるだろ テキストファイルに書き出すのだって独自DBなわけで 逆に東京証券取引所の規模でテキストファイルのほうが無茶だろ。 銀行の取り付け騒ぎで人が大量に押し寄せてATM操作するとISAMでがんばってるホストが堕ちるのと同じ。 テキストファイル自体はdbじゃないだろ。 >ATM操作するとISAMでがんばってるホストが堕ちるのと同じ。 ナニ言ってんだ?コレ? タイムアウトやら領域が足りなくてトランザクションがコケた事とISAMの関連が意味不明。 ISAMでなく、普通のRDBでも帯域&領域足りなきゃ落ちるのは一緒なんだが。 テキストを独自DBと言うのは痛いが、引き合いにホストを持ち出してトンデモ理論展開スナ。 >353-354 データベースの定義 @ Wikipedia > 特定のテーマに沿ったデータを集めて管理し、容易に検索・抽出などの > 再利用をできるようにしたもの。 > 狭義には、コンピュータによって実現されたものを言う。 広義には記録メディアが紙だろうが石版だろうがDBはDBなんだぜ。 テキストファイルは言わずもがな。 とりあえずテキストファイルがDBと言うヤツは ニコ動とか東京証券取引所のシステムを「石版」で構築してから語ってくれ。 テキストファイルだけならDBじゃないけどプログラムとしてテキストファイルを使うなら それを読み出してデータストアとして利用するロジックがあるんだからDBと言えるだろうに ただ石板は情報システム的にDBにはなり得ないから例えが悪い テキストファイルはDBにならないって言ってる奴は、 ミドルエアとしてのDBMSと勝手に解釈して限定してるんだろ。 >>359 追記専用で基本屋外設置かつメンテ頻度も大変低いという条件下では 中の人の名前が順に彫り込まれる墓石というデータメディアは大変に 優れたものだと思う。 何より墓石メディアを用いた墓場というDBは古くは古代メソポタミア に始まる何千年もの利用実績があるわけで、侮れん。 必死に話をそらそうとしているのを見ると頭が可哀想な人なんだろうな。 常識でモノを考えて喋ってくれ。 会社でよく「コミュニケーション力が低い」と怒られている人だろうけど。 >357 指摘が全く意味不明だ。 石版メディアを使ったDBは読み書きが遅く電子処理に向かないので、 東京証券取引所では使えない。それだけの話がなんで理解できない? おそらく君が「DB」と呼んでいるものは、正式には「RDBMS」だ。 いやだから現実的に情報システムで利用できる媒体のみで語れよ テキストファイル、パンチカード、印刷物あたりまでは理解できるが 石板をシステムで読み書きするシステムなんて現実的に存在しないだろ >>364 今は純粋に「データベース」という言葉の定義についての話をしてるんだろ? 情報システムで容易に媒体以外はデータベースにあらず、というのは単に君個人の 思い込みであって常識じゃない。 電話帳は電話番号のデータベース。これが常識レベルの解釈。 × 容易に媒体 ⇒ ○ 容易に扱える そういう意味じゃ、石版がNGなら紙もNGだろ。 現実問題として紙に印刷しておいてあとでドキュメントスキャナで取り込むというデータの保存の仕方はあるけれど 石板に掘っておいてあとで読み込むなんて使い方をしている奴は誰もいないわけで だから、昔は住所データベースが手書きだったりしたんだってば。 電子的に扱えるかどうかなんて問題じゃないんだって。 しかし、「データベース」の定義に照らしてもやっぱり2chはデータベースじゃないわな。 >>368 印刷物はDBとして使えるって言ってるじゃんみんな 否定されてるのは石版なんてとんでもない例でしょ? >370 手書き文書は印刷物じゃないし、情報システムと親和性が無いのは石版と同じ。 石版の話は極端な例だけど間違いや嘘じゃない。 「データベースと呼べるかどうか」は、使いやすい/使いにくい、早い/遅いなんて 話とは別次元の問題だよ。 >言ってるじゃんみんな 「みんな」が誰を指してるのか知らんが、世の中の常識とは言葉の認識が乖離してるな。 紙も石板も単にメディアの一種にすぎない データベースってのは、メディアは関係ない ハンドリングの容易さとか管理のしやすさとかは別の話 DBとDBMSの区別ついてない奴が多すぎるな 俺も普段はDB=(R)DBMSの意味で使ってる場合が多いが こういった議論のときはきっちり区別しろよ テキスト/バイナリ、電子メディア/紙/石版wなんてのは単に実装方法の違いだけの 話なんだよね。DBかどうか、ってのは記録された情報の性質で決まる事なんだから、 「テキスト形式で保存したから」「記録媒体がアナログだから」なんて理由で DBじゃなくなるという理屈は根本的におかしい。 うちの墓石にも幕末から死んだ先祖の名前と日付が掘ってあるけど、あれもDBだったんだな 「データの再利用を目的として、特定のテーマに沿ったデータを集めて管理したもの」では ないので、墓石はDBとは呼びにくいな。 上記の目的で墓石にデータを記録したなら、それはDBと呼んで差し支えない。 >>377 >特定のテーマに沿ったデータを集めて お墓の中に入っている人の名前しか入っていないけど。 >データの再利用を目的として 毎年お墓参りしないの? >378 一般的には、墓石は単に故人の名前を残すこと自体が目的だと思うけど。 例えば「大量の先祖の中から特定の故人の名前を探す事を容易にする」のを目的に 墓石に名前を彫ったんだとしたらDBと呼べるんだろうけど。 目的がデータの再利用ならデータの構造も探索に適した構造になってる筈だけど、 故人の名前に見出しが付いてたりはしないだろ? >毎年お墓参りしないの? 俺はしないw つか、お墓参りはデータの再利用なのか? 没年でインデクシングされた故人データベースとして使う事は可能だなw 所詮墓石はデータメディアにしか過ぎない。 墓地の管理人さんも含めて初めてデータベース管理「システム」 と呼べる。 過去帳ならともかく、墓石そのものは集積されていないからなぁ。 >>383 しょうもない話だけど、本質を捉えていて面白いじゃないか。 こういう話を見てると、普段「データベース」という物がいかに 表面的かつ一面的にしか捉えられていないかが解るな。 しかし「データベース」の定義という知識が必要となることはまずないからなぁ。 今では博物学的意味しかないかもしれん。 テキストファイルや紙までなら理解できるけど 石版とかになるともうデータを取り出す目的で作ってるわけじゃないし データベースじゃなくてストレージなんじゃないかと read.cgi ver 07.5.1 2024/04/28 Walang Kapalit ★ | Donguri System Team 5ちゃんねる