何故データベース設計は軽視されるのか？
何故データベース設計は軽視されるのか？
ここでいうデータベース設計とは、
特定の業務システムにおける
テーブルレイアウトを設計し、決める作業であるとします。
業務システムにおいては、
このデータベース設計（テーブル設計）は仕様そのものを定義する作業にも
近いと思いますし、この設計は開発工程やその後の運用における品質を
絶対的に左右するものだと思っています。
逆にこの設計があまりにも実現すべき仕様と比較し不整合なため、
その後の開発工程がデスマーチに陥ることも少なくないのではないでしょうか？
にも関わらず、正規化程度も理解できないような担当者が
この設計を行っていたり、業務システムの受託開発において、
「テーブルレイアウトを決める」という作業が、あまりにも軽視されているような
気がしています。
みなさんの現場ではどうでしょうか？
ご意見などお聞かせください。
賢者に聞いていいですか？
たとえば、２ｃｈとか「PC等」→「プログラム」→「【PHP】CakePHP」→「レス」って構成ですよね。
これってどういうDB設計になってるんですか？
実務経験がないのでわかりません。
「PC等（カテゴリID）」→「プログラム（カテゴリID＋サブカテゴリID）」→「【PHP】CakePHP（サブカテゴリID＋スレID）」→「レス（スレID＋レスID）」
→「デスクトップ（カテゴリID＋サブカテゴリID）」→「cpuをとっかえたい（サブカテゴリID＋スレID）」→「レス（スレID＋レスID）」
って感じですか？
１つのデータベースに、テーブルを1000個とか作ることとかあるんですか？
その場合、テーブルの名前を特定して探しにいく方法でしょうか？ 普通に考えれば2chはファイルだし、事実そう。
RDBで実装する意味が解らん。 2ｃｈの量でもファイル入出力に耐えれるものなのか。
人間のイメージなんてちっぽけなものなんだな。 >>341
実務経験がないから仕方ないのかもしれんが、
RDBに不思議な幻想を持つのはヤめた方がいい。
2chの場合は要求される仕様が「追記オンリー、更新は基本なし、当然削除もなし
発言は1000もしくは512KB(板によるが)で、ブラウザを使うユーザーにはhtml変換し
専用ブラウザはdat直読み。
そして圧倒的な書き込み&ＰＶときたら並の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でも捌けると思うけどね。
金かければなんでも出来るだろ。
コストパフォーマンス無視して「ＤＢの方が向いている」なんて・・・。
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でも帯域＆領域足りなきゃ落ちるのは一緒なんだが。
テキストを独自ＤＢと言うのは痛いが、引き合いにホストを持ち出してトンデモ理論展開スナ。 >353-354
データベースの定義 ＠ Wikipedia
> 特定のテーマに沿ったデータを集めて管理し、容易に検索・抽出などの
> 再利用をできるようにしたもの。
> 狭義には、コンピュータによって実現されたものを言う。
広義には記録メディアが紙だろうが石版だろうがDBはDBなんだぜ。
テキストファイルは言わずもがな。 とりあえずテキストファイルがＤＢと言うヤツは
ニコ動とか東京証券取引所のシステムを「石版」で構築してから語ってくれ。 テキストファイルだけならDBじゃないけどプログラムとしてテキストファイルを使うなら
それを読み出してデータストアとして利用するロジックがあるんだからDBと言えるだろうに
ただ石板は情報システム的にDBにはなり得ないから例えが悪い テキストファイルはDBにならないって言ってる奴は、
ミドルエアとしてのDBMSと勝手に解釈して限定してるんだろ。 >>359
追記専用で基本屋外設置かつメンテ頻度も大変低いという条件下では
中の人の名前が順に彫り込まれる墓石というデータメディアは大変に
優れたものだと思う。
何より墓石メディアを用いた墓場というDBは古くは古代メソポタミア
に始まる何千年もの利用実績があるわけで、侮れん。 必死に話をそらそうとしているのを見ると頭が可哀想な人なんだろうな。
常識でモノを考えて喋ってくれ。
会社でよく「コミュニケーション力が低い」と怒られている人だろうけど。 >357
指摘が全く意味不明だ。
石版メディアを使ったDBは読み書きが遅く電子処理に向かないので、
東京証券取引所では使えない。それだけの話がなんで理解できない？
おそらく君が「DB」と呼んでいるものは、正式には「RDBMS」だ。
いやだから現実的に情報システムで利用できる媒体のみで語れよ
テキストファイル、パンチカード、印刷物あたりまでは理解できるが
石板をシステムで読み書きするシステムなんて現実的に存在しないだろ >>364
今は純粋に「データベース」という言葉の定義についての話をしてるんだろ？
情報システムで容易に媒体以外はデータベースにあらず、というのは単に君個人の
思い込みであって常識じゃない。
電話帳は電話番号のデータベース。これが常識レベルの解釈。
× 容易に媒体 ⇒ ○ 容易に扱える
そういう意味じゃ、石版がNGなら紙もNGだろ。 現実問題として紙に印刷しておいてあとでドキュメントスキャナで取り込むというデータの保存の仕方はあるけれど
石板に掘っておいてあとで読み込むなんて使い方をしている奴は誰もいないわけで だから、昔は住所データベースが手書きだったりしたんだってば。
電子的に扱えるかどうかなんて問題じゃないんだって。 しかし、「データベース」の定義に照らしてもやっぱり2chはデータベースじゃないわな。 >>368
印刷物はDBとして使えるって言ってるじゃんみんな
否定されてるのは石版なんてとんでもない例でしょ？ >370
手書き文書は印刷物じゃないし、情報システムと親和性が無いのは石版と同じ。
石版の話は極端な例だけど間違いや嘘じゃない。
「データベースと呼べるかどうか」は、使いやすい／使いにくい、早い／遅いなんて
話とは別次元の問題だよ。 >言ってるじゃんみんな
「みんな」が誰を指してるのか知らんが、世の中の常識とは言葉の認識が乖離してるな。 紙も石板も単にメディアの一種にすぎない
データベースってのは、メディアは関係ない
ハンドリングの容易さとか管理のしやすさとかは別の話
ＤＢとＤＢＭＳの区別ついてない奴が多すぎるな
俺も普段はＤＢ＝（Ｒ）ＤＢＭＳの意味で使ってる場合が多いが
こういった議論のときはきっちり区別しろよ テキスト/バイナリ、電子メディア/紙/石版wなんてのは単に実装方法の違いだけの
話なんだよね。DBかどうか、ってのは記録された情報の性質で決まる事なんだから、
「テキスト形式で保存したから」「記録媒体がアナログだから」なんて理由で
DBじゃなくなるという理屈は根本的におかしい。 うちの墓石にも幕末から死んだ先祖の名前と日付が掘ってあるけど、あれもDBだったんだな 「データの再利用を目的として、特定のテーマに沿ったデータを集めて管理したもの」では
ないので、墓石はDBとは呼びにくいな。
上記の目的で墓石にデータを記録したなら、それはDBと呼んで差し支えない。 >>377
>特定のテーマに沿ったデータを集めて
お墓の中に入っている人の名前しか入っていないけど。
>データの再利用を目的として
毎年お墓参りしないの? >378
一般的には、墓石は単に故人の名前を残すこと自体が目的だと思うけど。
例えば「大量の先祖の中から特定の故人の名前を探す事を容易にする」のを目的に
墓石に名前を彫ったんだとしたらDBと呼べるんだろうけど。
目的がデータの再利用ならデータの構造も探索に適した構造になってる筈だけど、
故人の名前に見出しが付いてたりはしないだろ？
>毎年お墓参りしないの?
俺はしないw
つか、お墓参りはデータの再利用なのか？ 没年でインデクシングされた故人データベースとして使う事は可能だなw 所詮墓石はデータメディアにしか過ぎない。
墓地の管理人さんも含めて初めてデータベース管理「システム」
と呼べる。 過去帳ならともかく、墓石そのものは集積されていないからなぁ。 >>383
しょうもない話だけど、本質を捉えていて面白いじゃないか。
こういう話を見てると、普段「データベース」という物がいかに
表面的かつ一面的にしか捉えられていないかが解るな。 しかし「データベース」の定義という知識が必要となることはまずないからなぁ。
今では博物学的意味しかないかもしれん。 テキストファイルや紙までなら理解できるけど
石版とかになるともうデータを取り出す目的で作ってるわけじゃないし
データベースじゃなくてストレージなんじゃないかと ストレージがなければデータベースも実装できないのだが。 データベースは物質ではなくて概念の名前。
石版の例で言えば、厳密には石版そのものがデータベースなのでなく、石版に記録された情報が
データベースなの。
> 石版とかになるともうデータを取り出す目的で作ってるわけじゃないし
この話は「仮にデータの集積方法が石版への記述であったとしてもDBはDB」という例え話だろ。
データを取り出す目的で石版を作る事だって当然できる。
ほかのデバイスより読み書きの効率が悪いとか集積率が悪いとか、そんな事はここでは全く
問題ではない。
> しかし「データベース」の定義という知識が必要となることはまずないからなぁ。
知識以前に常識の問題だと思う。
データベースという言葉が何を指すのか知らないで日々その言葉を使うのか？
狭義のDB＝DBMSの中にもDBって言葉は入ってるんだぜ。
「DBMS」と「データベース」は異なる概念だというのは常識レベルの話だとしても、
あるAが「データベース」の定義にはてはまるかどうかという判断が求められることって
こんな議論の場でもなきゃまずないだろ。だいたい、「データベース」という言葉は
そもそもDBMSと比較して定義があいまいだし。
掲示板/BBSという用語を正確に定義付けられなくても2chやるのに何の支障も
ないってことよ。 なんでこんな現実性のない言葉遊びで熱くなれるんだ？
職場で「空気読めないヤツ」とか言われないか？＞石版データベース君 > あるAが「データベース」の定義にはてはまるかどうかという判断が求められる
日常的に行われている事だけど、当たり前過ぎて普通は意識しないだけだろ。
というか、そんな高尚な話か？
一から十まで常識レベルの話をとくとくと聞かせてるのに、まるで理解してるように
見受けられないから話が長引いてるだけだと思うんだけど。
> 掲示板/BBSという用語を正確に定義付けられなくても2chやるのに何の支障も
> ないってことよ。
エンジニアが仕事で使うならそんな訳にいかんだろ。ちゃんとしろよ。 >391
石版の話は単なる例え話だ。言葉の定義は単なる遊びでなく現実の問題だ。
散々感覚のズレを指摘されてるのに反省が見られんな。
こういういい加減な奴が技術者ってのが信じられん。 言葉遊び云々を言うなら、「テキストで保存したらもうDBじゃない」という
主張の方がよっぽど屁理屈だと思うんだ。 >>392
別に判断が必要じゃなきゃ仕事でもしないだろ。そもそも、データベースに該当するか
どうかという判断なんて、たとえばどういうケースで何のために行うの？ 判断するというより、言葉の指す意味の範囲を知っておく事が重要だよ。
仕様書に「ログインユーザのデータベースを作成する」と書いてあったとして、
書いた側と受け手に共通認識が無いとおかしな事になる。
ぶっちゃけこういう時、勝手にRDBMSの準備をする奴は無能なエンジニアだと思う。
＞仕様書に「ログインユーザのデータベースを作成する」と書いてあったとして、
この場合は普通にDBMSを用いてログイン情報を管理する事を想定すると思うが。
要件に「ログインユーザの履歴を記録する」ならテキストに順次書き出しを想定する。
＞書いた側と受け手に共通認識が無いとおかしな事になる。
＞ぶっちゃけこういう時、勝手にRDBMSの準備をする奴は無能なエンジニアだと思う。
現実の仕事だとすり合わせとか会議があるからありえないケースだが、
そういう発想できる人の方がコミュニケーション能力と実務経験が欠如したエンジニアだと感じる。 DBを作成するけど、所謂DBMSを使わない案件だっていくらでもある。
DBが概念に過ぎない事を知っているエンジニアは、実装はどうするか？という発想になる。
そうでない人はDBMSを使う（仕様作成元は使いたがっている）と信じて疑わない。
> 現実の仕事だとすり合わせとか会議があるからありえないケースだが
勘違いしたまま実装まで行かないのは当然。
だだし、すり合わせの場でその話が出るまではずっと勘違いしてるわけだ。
仕事の仕方は全然違うと思うがね。 >>396
コミュニケーションミスの話はまた別のような。
「AはXである」
「『Iさんの言うA』はXである」
この2つの命題はは異なるからね。
データベースとDBMSは概念が異なるという常識があって、その上でその仕様書に
書かれた「データベース」がどちらを指しているのか明確でなく、さらにその違いが
実装する上で重要な違いなのであれば、普通は確認するよね。
そういう状況で、「『データベース』は必ずしもDBMSを必要としない」といって
勝手にテキストファイルで作ってしまうのも同様に困ったチャンだろうね。
後で客と「データベースを作れと言ったじゃん」「テキストファイルでもデータベースです」
みたいな押し問答になったりして。 石板DB否定派＝DBとは実装のこと。テキストがDBの実現手段に含まれる事を想像もしない。
石板DB肯定派＝DBとは概念のこと。DBの実装形態が様々あることを理解し、色々な可能性を想定している。
DBを概念として捉えている人は、実装について勝手な思い込みはしない。
> 勝手にテキストファイルで作ってしまうのも同様に困ったチャンだろうね。
その人はポジション的に石板DB否定派だと思う。 >>397
>この場合は普通にDBMSを用いてログイン情報を管理する事を想定すると思うが。
スタンドアロンや組み込みのシステムでもかい？ >>400
アンタさぁ、自分ひとりが後者、他の全員が前者だと思ってるだろw >402
いや、常識的な大半のエンジニアが後者、このスレにいる数名が前者だと思ってるが？
なんでそう思う？ その「数名」ってどこにいるの？
その話題でループしてんのアンタ一人じゃない？ >405
そもそも石版の話を出したのは俺じゃないんだけどな。
テキストファイルはNGだ、紙ならセーフだ、墓石はどうだ、なんて話をしてた人は
明らかに前者だろ。石版DBの話にチャチャ入れてた奴も前者だと思ってるけど。
あ、君がどっちかは知らんよ。 どうせもう「前者」は居ないんだろうし、
>337以前の流れに戻そうや。面白かったけど、ちょっと引っ張りすぎ。 墓石のチャチャいれ？>>382なら俺だ。
つかその時点で既にデータベース≠DBMSが前提の議論じゃん。 >>408
>383 とか >391 のつもりだったんだが。
>382はそれもそうだなあ、と思いながら読んだよ。
> その時点で既にデータベース≠DBMSが前提の議論じゃん
君はそうかも知れんけども。
>386 とか >397 は理解してるようには見えん。 なんか休日に寂しい暇人が勝手に敵を作って「俺Sugeee」って言ってるスレだな。
定義厨は他人の意見を絶対に聞き入れないからカキコするだけ無駄だな。 DBとDBMSの区別もつかないレベルの人に仕事が回ってきちゃうぐらい
データベース設計が軽視されているという流れでOK？ 墓石をデータの永続化対象として何がいけないのか、さっぱりわからん 曰く「実際にそういう実施例が存在するかどうか」が重要なんだそうだ。
頭が固いを通り越してアホとしか思えん。 ログイン認証の情報はテキストに保存しないって言ってる奴正気か？
htpasswd知らないとかないよな このスレの本題はRDBMSのスキーマ設計の軽視だが、
実は軽視されてるのはデータ設計全般なんだろうか。
と、ここ数日のやりとりを見ていて思った。
2chのレベルが平均的とは思わないけれども。 マジレスするとこの板が出来たときは8割のスレがドラゴンボール関連だった タイムスタンプにINT型でUNIX時間入れてるのが酷いと思ったけど超えたな 正しい知識を持った人間以外がプロになっているのがおかしい
一級建築士と同じように、充分な知識を学習した人間のみが、
システム設計に参画出来るようにするのが本来の正しい姿。
もう、遅いけどね。 機械設計だって回路設計だって人生設計だって資格はないけどな 十分な知識を学習とかって、実務経験に勝るモノはないんだが。
正確には「各行程を経験し死ぬまで学習意欲があり常に成長し続ける
コミュニケーション能力の高い人間」でないと設計はやるべきではない、
が正しいな。
知識なんてあって当たり前でなんの自慢にもならん。
まあ、免許制にして欲しいと思う事は多々あるがｗ ペーパーでOracleのプラチナやPostgreSQLのゴールド持ってる奴より
無資格で現場で痛い目に遭ってる奴の方がまだいいだろうな どっちが重要なんて比べるもんじゃないだろ。
知識も経験もどっちかが欠けてたらダメじゃん。
知識なんてあって当たり前。経験なんて勝手に積み上がる。 知識は幅広い視野を持つのに必要、経験はその上で必要。
スレチだが、ちまちま何かを作ったのに、それをカバーした上品なライブラリ見つけたらマジへこむ。 「知識より経験」って言う奴って、自慢できるのが本当に経験だけだったりするからな。
そういう奴は得てして怪しげなノウハウを振りかざしたり、理論的な話をするとなぜか怒ったり。 >>429
Platinumはペーパーでは取れんだろう。 >>432
資格もっててスマソｗ
つかDB関連の資格はペーパーはなくなないがある程度以上は実際に使った人間でないと
受かるのは辛いだろ。
現実には資格持ちは「古くて使えなくて胡散臭い都市伝説」を信じてるヤツ多いけどな。
「SQLはこう書くと・・・」とか「サロゲートキーが・・・」とか「こういう場合はストアドが・・・」とか、
「こうやって教えられた」とか、応用を知らんのかと小一時間(ry
実際やらしてみるとパフォーマンスでなかったり、JOBの再投入が不可能な論理設計したりとか。
資格取った後も最新動向やら勉強会やらニュースとか読め。 ペーパーでplatinum結構いるよ
goldだとやたらいる 
