何故データベース設計は軽視されるのか？
何故データベース設計は軽視されるのか？ ここでいうデータベース設計とは、テーブルレイアウトを決める作業を指し、 プログラムのデザインも、正規化も知らない奴がSEを名乗ってるからだろ。 むしろDBの設計でPGが大きく変わって組みやすくなる可能性もあるというのに・・・・ >>3 の言う通りだと思う とりあえず今保守してるシステムのテーブル名とカラム名に >>7 納品時のテストデータでかろうじて動作はするものの いまだに綱渡り的な設計とかが存在してるのな(；´∀｀) いまだに「テーブル名・カラム名は全てID制です！」ってとこもあるからな。 そろそろ今のPJが終わるので今度入る予定のPJチームに挨拶行った。 SYOHIN ど素人でＤＢに興味あるものですが、 つうかね会社の方針が変わったり条例が変わったり法律が変わったりするたびに変更しなきゃならないシステムもたくさんあるわけよ >>1 >>3 のような技術力の不足、利用シーンを考えない独り善がりな設計など。 とりあえず >>18 >>19 >>20 そういえば、社会保険庁が提供している申請用ソフトも >>22 >>20 >>1 DB屋が論理設計途中でトンズラされたPJ。 >>19 >>19 >>28 >>30 まあ、たしかにＤＢ屋の地位とかは低いよな。。 年月日を和暦で格納するとか、 建築に例えれば、DBとかネットワークは土台、地盤にあたる部分だよね。 この板には最近来るようになった新参者ですが 稼働システムでDB設計がおかしくてPGで何とかしようとするのはいい 今は昔よりサクサク作れるんでしょ？ アプリケーションはサクサクと使い捨てられることも多いけど、 遅いかねえ 昔IBMの博士がRDBの基礎理論を発表してから、常に進歩・進化していると思うが。 RDBMSの実装自体は猛烈な勢いで進化していますが、 LINQがどうなるのかってところか。＞クエリ拡張 xml関係の拡張(?)も凄いと思うし、モバイル対応とか、組み込みとか >>43 そりゃまあ、COBOLerには縁がないから、価値を感じないだろうなぁ。 COBOLは全然分からないが、DB設計の立場で見ると、 ポトペタな画面アプリ作る時には実際、O/Rマッパって必須だと思うけど。 不要ってことは無いけど、重要視されてないのは事実。 むしろテーブル設計よりも、糞クエリを書く奴をなんとかして欲しい 俺の経験だとSQLで出来ることを >>52 クロス集計って、アプリ側、DB側、どちらで頑張っていたのでしょうか？ >>51 テーブル設計が問題なのか、 モバオクみたいに１人のスーパーエンジニアに全部ヤらせればいいんだよ。 一人はそいつが飛んだら終わりだけどな。 さらっと「飛んだら」と書かれてちょっとビクっとした。 「レコード数が少ないから主キーはいらない」 >>59 全てのテーブルが外部結合を必要なく設計されてるシステムってある？ >全てのテーブルが外部結合を必要なく設計されてるシステムってある？ Oracleで対象非対象をレコードが有るか無いかで設計してあるのはやっぱ間違いだよね。 >対象非対象をレコードが有るか無いかで設計してある ジョインされる２つのテーブルのキーが1:nになっているべきか1,0:nを前提に設計するかって話だよ >>64 ちがう、1:nを守るためにマスタにレコード追加しようとしたら引かれたの。意味無いとか言われて。 レコード番号 | 存在フラグ あー頭死んでた。 >>72 >>72 >>63 >>67 １さんの言うことはまったくもって正しいんだけど、 制約を強くするとデータを入れにくいじゃない？とか平気で言うPLがいるとやる気0だよね～ そうそう、そんな感じｗｗ >>81 39+3 ： すずめちゃん(catv?) [] ：2009/01/20(火) 00:55:46.00 ID:5lC2DwfT (2/2) 取引先の「偉い上司」デター！ データベース設計が軽視されているのではなく、 >>89 そもそもちゃんと仕事できてないから人間的に信頼されて無いとか？ ここ読んでて恐ろしいのは自分の関わったシステムではDB設計軽視して無いって メガバンのＭ菱サイドの方がオープン系とかにシフトする勇気がないんだろうし。 Mでは実績が無いだけでしょ。いわゆる前例がないってやつだ。 >>92 DBAが満足する、実績の無い新しいシステムで、銀行ATM止めて大迷惑かけてしまうのと、 しかしあのメガバンってアフォみたいにATMを停止させてる現実があるんだが。 それでもまだ復旧の見込みがあるぶんだけ優位だろ。 あれくらいの仕事する案件では「失敗した時の復旧プラン」もちゃんと計画に入っているんだがな･･･。 >>95 いつも自分の意見が取り入れなくてストレス溜め込んでるのだろうな。 >>101 >実務やってる現場は、結局システムの中身なんてどうでも良いし。ちゃんとシステムが動く実績がある事が重要。 噂によく聞くコボラーってやつか。 >>100 >>104 プロセス中心で考えるエンジニアとデータ中心で考えるエンジニアが お互いに相手の領域を理解すれば効率が何倍もあがるというのに。 >>109 というか、 >>1 によると、ここでは「業務システム」についての設計の話だそうだから、 >>109 >>112 業務システムをプロセス中心で開発するってのは かくしてエンジニアのオナニー状態の使えないシステムが作られて行く訳だな。 >>115 >>115 見えにくい部分だけあって理解も無いから。 >>116 >>1 会社で昼休みにテクデの勉強してたら資格オタク扱いされたなぁ >>120 >>120 でも地頭は大事。新卒の場合、出身大学のランクを元に、見込みで採用してるだけ。 釣りか？！データモデル設計とテストデータ実装、本番データの実装、ACCESSのクエリーなりでＵＩ概要とすれば 正規化も3層スキーマの考え方も身についていないような奴が 問題を指摘されたらググって言い訳を探す医者や自動車設計者が でも使ってるうちに正規化が崩れていくのも事実。 DBの組みなおしは簡単に出来るよ。それこそ制約に従ったSQL書ければ簡単だよ。 >>132 だからPGはあとまわしでPGによる調整が必要ないところまで >>132 １０年使ってきたDBの変更と、１０年使ってきたウェブアプリの変更どっちが簡単か自明だと思うけどな。 利用者の顔色を伺って利用者と良好な関係を保つのが仕事をうまくすすめるコツだな 老害コボラー臭のするヤツがいるな >>138 >>137 への反論なのか？ >>132 はある意味、「真理」に近いと思う… 実務の世界の人間ではないのですが、「使っているうちに正規化が 「正規系が」業務内容に上手くマッチしなかったんだろｊｋ スキーマ改変したら、アプリ側の改変しないと駄目で、予算的に膨大になるでしょ。 お客さんに、「いちいち明細なんて入力するの面倒くさいし >>146 >>147 が言う、既存部分の変更を嫌がるのが一番の要因だとおもう >>148 のいう、外部要求に合わせるためか。 >>149 >>148 の繋がる相手に合わせる、というのはよく分かる >>147 はまだちょっと難しいです。 データってのは、ただ溜め込むだけじゃなくて、いろいろな事に使われて応用されていくもの。 accessと汎用系DBとでは、設計手法が異なると聞きましたが本当ですか？ どこまでを指して設計手法としてるかにもよると思うが、 >>152 正規化されてないDBを見て >>1 は、特定の部署でしか使わない、今まで手でやってた仕事を >>155 >>1 は何も正規化だけを問題にしてるんじゃなくて、 >>153 正規化しといても、どんどん拡張していくうちに崩れてくるしな。 http://pc11.2ch.net/test/read.cgi/db/1116097001/ 突然ですがアドバイス下さい。 データベースのテーブルとアクセスログは全く同じ形式じゃないか アクセスログをどう使いたいのか、要件がわからないままなら、ログのフォーマットそのものなテーブル１つで終わる。 もし、運用目的の話ではなく、純粋に情報の構成をER図であらわせ、って話をしているのなら、大雑把に言うと 課題だとしても実用的じゃなさすぎる。 すみません。オッケーウェブで質問して、回答ももらったのですが、回答が１件だけだったので なんでマルチが嫌われるのかと言えばだな、回答した香具師に失礼だからさ。 結局、 >>161 も>>168 も音沙汰無しなんだな。 今にちゃんでの回答に納得出来なくて、他所で訊いてる所だろ。 えーと、初めてのオラクル案件でマスタテーブルを すまん、それは漏れが感じたテーブルのイメージ名。 特別だからってどうなるの？ 指定なら対応するしか選択肢無いと思うが。 >>174 単にテーブルだけ出してきて、それが特別かどうか聞かれてもな 消費税なんて変わりそうなものは別に分けたいね。 >>178 >>179 >>180 しかしその何がどう問題なのか、正しく指摘できる者はいないのであった。 コボルにも対応出来るのが普通だしな。 すいません、正規化を俺が望まなければちょっとの修正ですんだものを、 >>188 金がかかったそもそもの原因は正規化のせいじゃなくて 表層に現れるのは「修正にコストかかった」ってことだけだからな >>188 しかし、コスト至上を理由に次々とパッチワークしていったシステムはひじょうに脆く、改定に対する耐性が格段に低くなる。 元々の設計のままでのコストの発生具合による。 >>193 >>192 を受けていってるのか？ >>194 だから設計でちゃんとコストが変わる事を設計担当がアピールするのが大事。 >>196 上級SEぐらいおさえられないでどうする 常に人減らせないか、安い人材に出来ないか考えてるからね。 逆に考えて、 理解しなくても、会社の資本金を出してたり、出資者から任命されてたりするから権限持ってる。 どんなまずい設計のシステムでも、 まずさ加減に寄るな。 もちろん問題点の把握はしておかなければいけない。 誤動作する時点て致命的じゃないのかなあ。 >>203 =205は >>206 完璧主義者の集まりが作ったシステムなら あっさりデータなくなるだろうけど むやみに正規化できないケースはいくつもあるぞ。 >>209 その辺は正規化してちゃんと効果有るの？ >>211 最近、クラウド絡みでKVSって聞くけど、別にクラウド云々関係なしにKVS的な構造ってどうなんだろ？ >>214 >>216 >>214 開発効率が３０年前に逆戻りすることだけは確実だな… 馬鹿でも扱えるようにしたら色んなところで問題が出るってなぜわからんのだ。 >>217 カスは時給安くても働くから、時給高い熟練は不要になるしな。熟練にしか出来ない正規化とかの無駄な仕事が必要ｗｗｗ >>217 >>217 おっ！最近レス多いですねぇ。いいじゃないですか。 >>214 >>214 >>228 サーバーでやるかクライアントでやるかの違いだろうね。>>214 >>214 の他に >>229 ストアドにしたからといっては飛躍的に高速になるわけではない。 データをどこに持っているかにもよる >>234 >>235 他のクラウドで処理したデータも拾ってこなきゃならんから遅いだろうね。 サーバーサイドの処理と限定して話をするけど なんかストアドよりインデックスが速いよスレの二番煎じな流れだな。 >>239 >>241 >>241 ちょっと議論の的がズレていってない？ >>214 は、処理の速さについては 単に屑PGが適当に組んでも速度が出ないと困るってか？ >>244 >>242 >>246 >>247 単に複雑なSQL組めない屑PGだろ。 >>246 まだまだＤＢのオプティマイザはアホだから、実行プランやトータルコスト考えながらクエリやＰＧ書けない奴はダメだな。 >>249 >>252 >>250 >>247 >>254 >>255 >>214 は、この設計を既存のRDBに割り当てて使うって言ってんのかな。 そもそも「KVS的」といって>>214 みたいなのが出てくるのがおかしいし、 具体的に1sqlってどこまで許すのか示されてないしな。 こちらの方がおっしゃっている設計指針についてどう思われるでしょうか。 http://masuda220.jugem.jp/?cid=11 >>262 >>263 >>1 むしろコボラ上がりが、繰り返し項目を使いたくって、 コボラ上がり(かつRDBを知らん)奴なんて数えるほどだろ。 >>265 の言うexcelと勘違いしてるようなのとか。 ファイル設計の延長くらいにしか考えてない奴は多いな コボルの本読むとそんな感じだしな。 そりゃ正規化はRDBでしか必要ないからな！固定長レコードで正規化 そういえば昔、上から全項目を固定長にしろとお達しがあって、嫌々やったら速度が上がった その昔の経験って、今も成り立っているのかな？ 今は一般的にはtext型みたいなのが一番速い >>273 > 固定長の文字列型なんてない DB2も固定長の方が速いけど。 >>275 オラクルは昔と今では、だいぶ違うけどな。昔の経験なんて引きずってたらそれこそコボラ状態。 DB2とかは固定長・可変長は分けて処理するしNOT NULLな制約も考慮して 何でOracleはヘンテコな仕様なのに普及したんだろうね？ >>282 今日もアホなテーブルとクエリを見てゲンナリした >>282 まあそれほどまでに当時のSQL鯖/サイベースとDB2が糞だった訳で。 そもそもまともに使えるRDBMSを最初に売り出したのがOracle。市場での競争が始まるのが 過去のことはいいから現在一番ましなRDBはなんなのさ。 今の製品はだいたいみんなまともだろ？あとはどのポイントを重視するか。 >>292 サポート契約してるとOracleって結構不具合とかあるんだなぁ、 DB2も不具合はある。 DB2は、「なんでいまだにこんなバグが？」と思うようなのがけっこうあるね。 DB2ってiSeriesは鉄なみの硬さがあると思うが、それ以外のプラットフォームは・・・。 単にasはろくな処理してなくて使い込んでないから固く見えてるだけじゃ。 結局なんだかんだ言いつつサポートの有無でプロダクトを選ぶという矛盾が 矛盾つーか、セルフサポートできるんならOSSも選べるってだけだろ。 んでその回答って役に立つのか？ >>303 >>303 ＞PostgreSQLの構築/運用実績あるSIにやって貰った方が しかしPostgresのシステム構築やサポートできるSIなんて オープンソースのDBすら自分で構築しようとしないエンジニアって・・ それは「システムを自分で開発しないエンジニアって」と言っているに等しいぞ。 >>308 まぁ会社としてサポートするとなると、スキルのある要員の継続確保が問題になるな。 OSSは裾野の部分がまだ弱いからねぇ。研修制度とか、サードパーティの層の厚さとか。 オープンソースのサポートなんて遣るくらいならオラクル保守入って丸投げのほうが楽だな。 >>314 Postgresにサポートが無いとか、お前らシロート？ 比率で言うならOracle信者ほど素人が多いのは不思議な現実。 別に「Oracleはインタンスが絶対に落ちなくてサポートが満足な製品で漏れは一度も苦労した事ない」 今までで一番酷かったのがLinuxの8iだな Linuxの8iって人柱Verだった頃のじゃね？ 要するに人柱バージョンを2000万でうりつけてるのかｗ 値段は規模にもよるから、Linuxで8iで2000万が高いか安いか判断が難しいが。 8iの頃はソラリスが鉄板だったので、リナックスなんて選んだほうが自殺行為なだけ。 oracleは絶対落ちないなんてありえない前提なのにpostgreには要求するのかｗ >>326 >>326 の意見は「安物買いの銭失い」な思考だ。 いいよな。天下りで仕事もらえるようなところは。 痛い目に会うような複雑なシステムじゃないから or ( 痛い目は末端がくらって表に出ない and それが痛い目だと気が付いていない ) ちゃんとコスト計算が出来るまともなエンジニアが皆無。 アプローチ使ってるけど、アプリの使い方じゃなくて、データベース設計の初心者本てなんかないかな 賢者に聞いていいですか？ 普通に考えれば2chはファイルだし、事実そう。 2ｃｈの量でもファイル入出力に耐えれるものなのか。 >>341 ありがとう。ファイル入出力の方がいいんだね。 twitterは細かい事は知らんが、最初Rubyとデータベース使って結構落ちてなかったか？ ファイル入出力のほうがいいというのは間違い。ISAMファイル直弄りのコボラーに成りたいならともかくw http://pc11.2ch.net/test/read.cgi/db/1207476744/ http://pc11.2ch.net/test/read.cgi/db/1063716668/ ＞ファイル入出力のほうがいいというのは間違い。ISAMファイル直弄りのコボラーに成りたいならともかくw お前らDBDB言ってるけどRDBMSのことだろ twitter は、元は Ruby on Rails じゃなかったっけ。今は知らないけど。 むしろバックエンドにDB使ってないシステムなどまずない とりあえず、>>350 が利用している2chはRDBは使っていない いやだからRDBMSじゃなくてDBは使ってるだろ 逆に東京証券取引所の規模でテキストファイルのほうが無茶だろ。 ＞ATM操作するとISAMでがんばってるホストが堕ちるのと同じ。 >353-354 とりあえずテキストファイルがＤＢと言うヤツは テキストファイルだけならDBじゃないけどプログラムとしてテキストファイルを使うなら テキストファイルはDBにならないって言ってる奴は、 >>359 必死に話をそらそうとしているのを見ると頭が可哀想な人なんだろうな。 >357 いやだから現実的に情報システムで利用できる媒体のみで語れよ >>364 × 容易に媒体 ⇒ ○ 容易に扱える 現実問題として紙に印刷しておいてあとでドキュメントスキャナで取り込むというデータの保存の仕方はあるけれど だから、昔は住所データベースが手書きだったりしたんだってば。 しかし、「データベース」の定義に照らしてもやっぱり2chはデータベースじゃないわな。 >>368 >370 >言ってるじゃんみんな 紙も石板も単にメディアの一種にすぎない テキスト/バイナリ、電子メディア/紙/石版wなんてのは単に実装方法の違いだけの うちの墓石にも幕末から死んだ先祖の名前と日付が掘ってあるけど、あれもDBだったんだな 「データの再利用を目的として、特定のテーマに沿ったデータを集めて管理したもの」では >>377 >378 没年でインデクシングされた故人データベースとして使う事は可能だなw 所詮墓石はデータメディアにしか過ぎない。 過去帳ならともかく、墓石そのものは集積されていないからなぁ。 >>383 しかし「データベース」の定義という知識が必要となることはまずないからなぁ。 テキストファイルや紙までなら理解できるけど ストレージがなければデータベースも実装できないのだが。 データベースは物質ではなくて概念の名前。 「DBMS」と「データベース」は異なる概念だというのは常識レベルの話だとしても、 なんでこんな現実性のない言葉遊びで熱くなれるんだ？ > あるAが「データベース」の定義にはてはまるかどうかという判断が求められる >391 言葉遊び云々を言うなら、「テキストで保存したらもうDBじゃない」という >>392 判断するというより、言葉の指す意味の範囲を知っておく事が重要だよ。 ＞仕様書に「ログインユーザのデータベースを作成する」と書いてあったとして、 DBを作成するけど、所謂DBMSを使わない案件だっていくらでもある。 >>396 石板DB否定派＝DBとは実装のこと。テキストがDBの実現手段に含まれる事を想像もしない。 >>397 >>400 >402 その「数名」ってどこにいるの？ >405 どうせもう「前者」は居ないんだろうし、 墓石のチャチャいれ？>>382 なら俺だ。 >>408 なんか休日に寂しい暇人が勝手に敵を作って「俺Sugeee」って言ってるスレだな。 DBとDBMSの区別もつかないレベルの人に仕事が回ってきちゃうぐらい 墓石をデータの永続化対象として何がいけないのか、さっぱりわからん 曰く「実際にそういう実施例が存在するかどうか」が重要なんだそうだ。 ログイン認証の情報はテキストに保存しないって言ってる奴正気か？ このスレの本題はRDBMSのスキーマ設計の軽視だが、 マジレスするとこの板が出来たときは8割のスレがドラゴンボール関連だった タイムスタンプにINT型でUNIX時間入れてるのが酷いと思ったけど超えたな 正しい知識を持った人間以外がプロになっているのがおかしい 機械設計だって回路設計だって人生設計だって資格はないけどな 十分な知識を学習とかって、実務経験に勝るモノはないんだが。 ペーパーでOracleのプラチナやPostgreSQLのゴールド持ってる奴より どっちが重要なんて比べるもんじゃないだろ。 知識は幅広い視野を持つのに必要、経験はその上で必要。 「知識より経験」って言う奴って、自慢できるのが本当に経験だけだったりするからな。 >>429 >>432 ペーパーでplatinum結構いるよ その先生方に確認したんだが、 OracleのGoldやPlatinumは講習会受けて取る資格だからな >>425 データ的には軽いけどトラブル対応時に人間が見て全く意味がわからないから死ねる その手の変換ツールぐらい準備しておくものだ。プログラマなら簡単にツールぐらい作れるだろ。 いやだから普通にtimestampでいいじゃんて話じゃないのか RDBMSによって実装が違うが、このケースでは普通にtimestampを使えばいいのでは？ Unix系のアプリなら、time_t型を入れると出し入れが便利じゃん。 まあUnix系なら「出し入れ」だけは便利な面はあると思う。 有効期間のあるマスタテーブルの主キーってサロゲートキーにできるのかな？ インデックス10個のテーブルに100万件のデータってやばいですか？ その辺の安鯖でも楽勝なレベル atom 1.6GHz 2GBメモリで１００人ぐらいの共有鯖でもおk？ じゃあ性能要件を満たす設計をしてあげたからその分の費用請求ヨロｗ 1人月240万だろ？充分高いだろ >>439 >>466 >>468 >>469 >>470 専板のDB設計スレが保守の末落ちる程だから軽視も致し方ない 大本の設計程制約少ないから楽に作れるもんなんだが、 そうそう >>474 >>477 COBOL脳だとRDBにおいてはテーブルサイズが大きくなるとパフォーマンスが加速度的に劣化する場合があることを理解できない。 某H関連会社に訪れた際、若手ＳＥが仕様レビューを受けていた >>478 予備カラムなんて持たせたら、いざ使う時、意味合いとカラム名が乖離するよね。 DB変更は仕様変更になるから別契約だけど 予備カラム多用すると、後々どの予備カラムが何の目的で使われてるか分からなくなるw そもそも可変長ランダム入出力が基本なRDBのレコードにおいて >>439 まるで意味のない資格では無いだろ。 >>487-488 >>486 は取れなかった奴の言い訳じゃね (w 66427727358778987766457232625+40=66427727358778987766457232665 >>1 この前某中古ショップですごく安いパソコンを発見しました。 http://toro.2ch.net/test/read.cgi/hp/1382021349/ http://toro.2ch.net/test/read.cgi/hp/1352858999/ 自分で競馬データベースや競馬新聞を作りたいんだが ↓こういう提供されたexcelデータがあるとします >>496 ★2ch勢いランキングサイトリスト★ 埼玉県警川口署は２０日、小学生の女児の下半身を触ったとして強制わいせつの疑いで、 http://www.47news.jp/CN/201407/CN2014072001001585.html 色々あるけど結論として テーブル設計がきちんとしてるだけで ☆ 日本の核武装は早急に必須ですわ。☆ インターフェイスが決まってからデータベースを設計するのに今更気づいた。 > 748 名前：名無しピーポ君 ：2015/11/24(火) 12:28:48.30 >>504 データをどう持つのかを初めから考えていないとUIもデータモデルも失敗する。 >>216 >>511 >>511 >>512 スレタイが気になっから来てみたが 論理設計とかについて偉そうに語れるほど 軽視してるってわけでもないんだがテーブルレイアウトを決めるのはDB設計全体の一部でしかなく システム設計を「クラスの定義を決める」作業として捉えてるのと同じって言ったほうがわかりやすいか テーブルを正規化したり >>518 >>519 >>1 >>520 >>522 >>523 >>524 >>523 >>522 兼 >>520 ww >>526 正規化も、データ型の決定も、それより上位の工程がちゃんとできてれば DB設計と、要件定義やモデリングとかとを同一視しすぎてるような気もするな。 >>528 >>529 >>531 >>530 >>531 >>534 概念モデルに正規化もなにも無いと思うけど >>534 >>535 の言うとおり、どこかで正規化の工程があるというよりは 誰でも簡単にパソコン1台で稼げる方法など そういえば、昔、DB仕様が悪くて、日次夜間バッチ処理が2日かかるシステムがあったな。 今の現場にも「正規化！正規化！」キチがおる、確かに少し歪んだところもあるが、締めのバッチなどでやむを得ず放置されている わかってないやつほど正規化と言ってしまう。用語で知ったかぶりをする典型例。 「良い設計」を専門用語で言うと「正規化」だと思ってるような奴がこの板にも多いよね いまどきまったく正規化されていない表を思いつく方が難しい。 それが難しいようじゃあデータベース設計に向いてないんじゃないかねぇ。 >>545 すべてを2次元の表であらわしているデータなんて、Excelでも見たことない。 テーブルのことを表、インデックスを索引と呼ぶのはいまだに違和感がある 軽視していないけど、人間の脳には難しいからだよ。 設計のどの部分をディープラーニングに任せるって話なんだろうか >>550 >>550 軽視したくないけどさ、設計が良いかどうかってどうやって見分けるの？ RDBに関して言えば正規化ほど体系化されててわかりやすい観点は他にはないね 正規化は非正規形で起きる問題(更新異常等)を防ぐものであってそれ以上ではない。 >>559 >ソースデータの正規形をベースに特定の分析用途に特化させて非正規化してるだけ >>561 更新異常が発生しにくいだけで >>561 はエアプが即バレして煙に巻きたいのだろう >ソースデータの正規形 >>560 は正しくない。 >>557 RDBと関係ないRやPython使った統計処理の分野でも そういうのごっちゃにすると話が発散するからやめて。 それに統計解析向けの加工って、クレンジングは最初に必要かもしれないけどあとは解析しやすいようにJOINしまくるのがふつう。 エアプDWHの次はエアプ統計解析かよw データベース設計は軽視されるの原因と >>571 エアプ素人さんはスタースキーマのファクトとディメンションがそれぞれ第何正規形か考えると良いと思うよ >>565 の言葉を借りれば正規化すら理解してないのにドヤ顔で語ろうとしてるのが丸わかりだから ど底辺の土方グラマーだけどDB設計させられて「なんでちゃんとしたDB屋に頼まないんだよ、DBって根幹部分で大切だろ！」って疑問だったけどここ見て納得。 ある意味当たってる。 >>575 ホンマにうわさ以上に凄いのが金さんの億様株レシピて投資ブログ。 プログラム組まないやつが設計すると保守性重視になるよな… >>579 >>580 >>579 は「保守性」と言っちゃってるが、実はたぶん保守性の話やないな。 そうすると保守性を理解してない>>579 が困ったちゃんってことになる すまん、保守性って言葉が悪かったな 人間にとっての見やすさというかわかりやすさも重要な品質要素だからね パッと見理解しやすくて保守性も高いならいいことずくめに読めるが。 >>585 だから、そこで自然キーの欠点や人工キーの利点を説明しなきゃ何を言いたいのかわからんだろ。 >>587 こうやってブレイクダウンするとどこに誤解があるか見えてくる。 >>589 >>589 >そんな話じゃなかったやろ。。。 呼び名はともかく人工キーは80~90年代でも普通に使われてただろうから年配だろうが知らないわけない >>593 同じ型の単純キー同士なら、それが自然キーか人工キーかで扱いやすさが変わることはないやね。 >>593 >>557 >>593 >>598 >>599 ははは・・・ >>606 もし関係者が見たら、特定できそうやな。ｗ データベースのテーブル設計書ってどうしてる? >>609 データベーススペシャリストでよく問われるページサイズとか空き容量率とかどのメーカーのDBをターゲットにしてるんや？ 特にどのDBMSをターゲットにしてるとかないぞ プロジェクトが燃え尽きたから別の案件に燃料しに行ったんだが、TEXT（可変長文字列）をPKにしてINDEX張ってて「パフォーマンス出ねぇ！」ってやってんですけど・・・ 遅いのがTEXTのせいだってどうやって判断したの？ >>614 >>614 >>614 >>617 俺の思い込みが解消されないレベルの現場という前提を認識ください m(_ _)m charやvarcharの文字列って意味でtextって言ってるんじゃなくtext型って話だったのか・・ >>620 よくわかってないクライアントがよくわかってないSEに文句言って >>626 まあ、最近はフルSSDのストレージで構築したからsqlがとても早いです。statpack見るととんでもなくディスクREADしてるアホsqlあるけど、システム影響なし、いいんだか悪いんだかですねー >>628 お前ら和歌山県出身の下村拓郎様（35歳独身、元自衛隊）をご存知か、この方は将来素晴しい人物になるから覚えておいて損はないぞ スキーマの意味よくわかってないけどスキーマ設計書にテーブル構成書いてるよ スキーマの概念が後付けの製品しか知らないんだろうな ER図を見てもよくわからない設計は典型的なダメパターン 今月から、某メーカー系の現場入り。 よくある話。 正規化って概念がないんだろうな 検索が重いとしか書かれていないのに正規化が出てくる人もどっこいどっこい。 >ちなみに、私はデータベーススペシャリスト餅。 こぼらーがなぜ嫌われるかをこぼらー自身は検証もしないし、俺流正義マンで権力まで持ってたら。。。。 いまどきCOBOL知ってる人も少ないだろうしどこがどのように問題かという具体的な指摘もないから RDBをよく知らない構造化ファイル時代のコボラーはJOINを嫌い 「コボラー」と言っとけば多分反論は来ないしお手軽にマウントとった気分になれる便利なワード。 このスレなんてそれが生き甲斐のやつばかりじゃん 処理速度の遅さが頻繁に問題になっていても、めちゃくちゃな設計とめちゃくちゃなSQLを使うのが優秀な開発者なのがITの世界ではエリートだったりするからなあ アプリ開発者がただの入れ物として設計してしまうからなあ 
