何故データベース設計は軽視されるのか？
- 1 ：NAME IS NULL：2008/12/01(月) 01:07:27 ID:X6n/IiFX.net
- 何故データベース設計は軽視されるのか？
ここでいうデータベース設計とは、
特定の業務システムにおける
テーブルレイアウトを設計し、決める作業であるとします。
業務システムにおいては、
このデータベース設計（テーブル設計）は仕様そのものを定義する作業にも
近いと思いますし、この設計は開発工程やその後の運用における品質を
絶対的に左右するものだと思っています。
逆にこの設計があまりにも実現すべき仕様と比較し不整合なため、
その後の開発工程がデスマーチに陥ることも少なくないのではないでしょうか？
にも関わらず、正規化程度も理解できないような担当者が
この設計を行っていたり、業務システムの受託開発において、
「テーブルレイアウトを決める」という作業が、あまりにも軽視されているような
気がしています。
みなさんの現場ではどうでしょうか？
ご意見などお聞かせください。
- 2 ：NAME IS NULL：2008/12/01(月) 01:09:40 ID:???.net
- ここでいうデータベース設計とは、テーブルレイアウトを決める作業を指し、
データベースとは、リレーショナルデータベースを指しています。
- 3 ：NAME IS NULL：2008/12/02(火) 01:24:11 ID:???.net
- プログラムのデザインも、正規化も知らない奴がSEを名乗ってるからだろ。
驚くぐらい何も知らない。
- 4 ：NAME IS NULL：2008/12/04(木) 15:02:51 ID:n/7HAnFW.net
- むしろDBの設計でPGが大きく変わって組みやすくなる可能性もあるというのに・・・・
確かに>>3の言う通りだと思う
- 5 ：NAME IS NULL：2008/12/04(木) 21:48:53 ID:???.net
- ERDのこと？
- 6 ：NAME IS NULL：2008/12/04(木) 22:10:28 ID:???.net
- とりあえず今保守してるシステムのテーブル名とカラム名に
日本語を使ってるのやめさせたい。それからコボラーの薫陶を
受けたVBA使いの作ったシステムを全て作り直したい。
- 7 ：NAME IS NULL：2008/12/05(金) 08:38:19 ID:???.net
- 動きゃいい、と思ってるからですかね。
- 8 ：NAME IS NULL：2008/12/05(金) 23:36:44 ID:???.net
- >>7
動けばいいとすら思ってない。
作って納品しちまえばおｋと思ってるw
- 9 ：NAME IS NULL：2008/12/08(月) 09:10:39 ID:???.net
- 納品時のテストデータでかろうじて動作はするものの
本運用に入ったら誤作動しまくり落ちまくりってのはもう
狙ってそう組んでるとしか思えなくなってきた・・・
- 10 ：NAME IS NULL：2008/12/09(火) 09:24:10 ID:???.net
- いまだに綱渡り的な設計とかが存在してるのな(；´∀｀)
- 11 ：NAME IS NULL：2008/12/09(火) 20:00:03 ID:???.net
- いまだに「テーブル名・カラム名は全てID制です！」ってとこもあるからな。
IDが何なのかってのを記憶してる人間が技術力高いつて重宝されとる……
- 12 ：NAME IS NULL：2008/12/10(水) 04:46:06 ID:???.net
- そろそろ今のPJが終わるので今度入る予定のPJチームに挨拶行った。
若手のSEがDB設計中だったので覗いたら、テーブル名・カラム名を日本語で書いてる・・・
んで、それはやめようよと言ったら、マニュアルのどこにダメって書いてあるんですか！日本語は使えるはずですよね！
と言われたので、その場でPJから外してもらうよう上司に頼みに行った。
送り仮名で嵌るんだよ・・・
- 13 ：NAME IS NULL：2008/12/10(水) 09:36:26 ID:???.net
- SYOHIN
SHOHIN
SHOUHIN
前任のアフォが設計したDBでこれらが混在してたから
全部「商品」で統一して新規で作り直す仕事何べんもやってるw
- 14 ：NAME IS NULL：2008/12/10(水) 20:38:31 ID:???.net
- ど素人でＤＢに興味あるものですが、
このスレ読んでおれもＤＢ設計してみようかなと思った
- 15 ：NAME IS NULL：2008/12/11(木) 01:23:12 ID:???.net
- つうかね会社の方針が変わったり条例が変わったり法律が変わったりするたびに変更しなきゃならないシステムもたくさんあるわけよ
そのたびに一から作ってたら間に合わんし客も予算出せないでしょ
実稼働中の物を今日まではこれ、でも明日からはこのシステムで
なんて無茶な用件はたくさんある
だからある程度の遊びフィールド作ったり妙な拡張して過去の残骸が残ってたりする物が出来てくるわけ
それを最初見た奴にとっては謎いシステムかもしれないけどさ
簡単に言うとガチガチに設計すると馬鹿を見る事も多いんだよ
- 16 ：NAME IS NULL：2008/12/11(木) 01:34:09 ID:???.net
- >>15
コボラ？
- 17 ：NAME IS NULL：2008/12/11(木) 05:04:21 ID:???.net
- >>1
データベース屋がまともな仕事をしないからだろ。
>>3のような技術力の不足、利用シーンを考えない独り善がりな設計など。
むやみに正規化してりゃいいってもんじゃないし。
- 18 ：NAME IS NULL：2008/12/11(木) 14:30:58 ID:T35oVHMe.net
- とりあえず
2008/11/12
を画面上でH.20.11.12
とかで表現するのはいいけど
DBにまで
H.20.11.12
として保存する仕様は勘弁してください。
- 19 ：NAME IS NULL：2008/12/11(木) 22:15:44 ID:???.net
- >>18
そんなのまだまし。
3601112←これ昭和60年な
3201112←これ平成20年な
4011112←これ西暦2001年な
和暦は3で西暦は4な。
- 20 ：NAME IS NULL：2008/12/12(金) 00:02:36 ID:???.net
- >>19
平成22年とベビーブームが始まる昭和22年はバッティングしないのでせうか( ﾟдﾟ)
- 21 ：NAME IS NULL：2008/12/12(金) 09:51:04 ID:???.net
- >>20
生年月日とかでなければバッティングしないんじゃない？
それにしても、その仕様は無いなw
- 22 ：NAME IS NULL：2008/12/12(金) 09:58:47 ID:???.net
- そういえば、社会保険庁が提供している申請用ソフトも
データが和暦格納で使いにくいな。
スレとは関係ないけど、そいつが吐き出すCSVはクォーテーションが付いてないので
うっかりExcelなんかで開くと、コードの頭のゼロが取れていたりする糞仕様。(0001→1)
- 23 ：NAME IS NULL：2008/12/12(金) 12:18:20 ID:???.net
- >>22
心配するな。「"」付きでもExcelはゼロサプレスしてくれるよ。
んで、うっかりExcelで開いて保存しちゃったCSVを本番に突っ込んじゃった
アホがいたもんだから、マスタが一切引けなくなってえらい目にあった。
…DB設計の問題じゃないけど。
- 24 ：NAME IS NULL：2008/12/12(金) 22:23:04 ID:???.net
- >>20
バッティングする。しかし詳細はばれるので明かせないが、３０年の期限が
管理できればいいので、生きてるデータは最古でも1978年。
死んでるデータはもうグダグダ。ゴミ。
- 25 ：NAME IS NULL：2008/12/13(土) 13:01:20 ID:???.net
- >>22
可能です。
以上。
↓次どうぞ
- 26 ：NAME IS NULL：2008/12/13(土) 13:45:18 ID:???.net
- >>1
経営者や管理職や客は、目に見えるものしか評価できないから、
DB屋よりもJava屋の意見を聞く。
↓
Java屋は、O/Rマッパを使いまくって、DBをオブジェクトの永続化ストレージ
としか考えない。DB設計？なにそれ？おいしいの？
↓
それでも動く。
↓
Java屋
「ほら見ろ、俺のやり方が正しい」
「DB屋の言うことなんか聞いてたら開発おわんねw」
↓
数年後： DBあぼ(ry
↓
開発当時の人間いない。だれのせいか分からない。
DBがダメになったから、DB屋が悪かったに違いないという判断。
↓
DB屋、ますます発言力低下。
↓
以下、ループ。
- 27 ：NAME IS NULL：2008/12/14(日) 12:59:31 ID:???.net
- DB屋が論理設計途中でトンズラされたPJ。
既に実装スタートしてたから皆でオンデマンドでDB設計やってたぜw
- 28 ：NAME IS NULL：2008/12/15(月) 09:48:21 ID:???.net
- >>19
明治は１，大正は２，昭和は３，西暦は４，
てなのを大昔にコボルさんが組んでて、
昭和天皇の崩御で困った困ったって話？
- 29 ：NAME IS NULL：2008/12/15(月) 10:16:58 ID:???.net
- >>19
つっか、マジな話、
今の天皇が幾久しく健康でありますようにと、お祈りする必要があるね。
- 30 ：NAME IS NULL：2008/12/17(水) 10:16:13 ID:???.net
- >>28
まさに文系乙の、非論理的な設計ですね。
文系の声がでかいのも、論理的な正しい設計が軽視される原因と見た。
- 31 ：NAME IS NULL：2008/12/17(水) 19:46:04 ID:???.net
- >>30
文系とか関係ないだろ。見通しの甘さが全ての原因だ。
ようするにバカなんだよ。
- 32 ：NAME IS NULL：2008/12/17(水) 20:52:39 ID:???.net
- ＳＥの机にデーターベース入門とか並んでて吹いた
- 33 ：NAME IS NULL：2008/12/18(木) 00:42:35 ID:???.net
- まあ、たしかにＤＢ屋の地位とかは低いよな。。
俺は運用側なので、開発側が主催する
システムリリースの打ち合わせに呼ばれる。
開発側の説明を受けた後で、運用上、設計上の問題をあげ、
改定を提案すると、いつも返答はこれだ。
「リリースしないと業務に支障がでる！」
だったら、システム設計のころから打ち合わせに呼べよ。
割を食うのはいつもこっちだ。
すまん、愚痴った。
- 34 ：1：2008/12/18(木) 00:42:43 ID:CvpxRnbY.net
- 年月日を和暦で格納するとか、
カラム名が日本語や日本語をローマ字にしたものであるとか、
運用を続けていくうえで仕様変更が続き過去の残骸データが残っているとか、
このあたりはもうしょうがないというか、諦めています。
我慢できます。
問題にしたいのは、論理性（純粋な意味での設計）です。
例えば1対nの関係にある情報を2テーブルに格納すべきところを
1側の情報を多側にn個格納したり、
候補キーが不十分で対象のレコードを特定できないケースがあるテーブルがあったり、
日々追加削除が発生するテーブルが第3正規形になっていなかったり、
（ケースバイケースがあることは承知しています）
こういった問題のほうがデスマーチに陥りやすいと思います。
で、デスマーチに陥ったら陥ったで何故かプログラムで対応しようとする。
設計に立ち戻らないんですね。ここが問題だと思っています。
- 35 ：NAME IS NULL：2008/12/18(木) 14:25:33 ID:???.net
- 建築に例えれば、DBとかネットワークは土台、地盤にあたる部分だよね。
それが緩い、いい加減なところの上でシステムを構築することが、
いかにリスクが高いか、判らないのかねぇ。
判らないんだろうなぁ。
システムは目に見えないからねぇ。
- 36 ：NAME IS NULL：2008/12/19(金) 07:52:58 ID:H7TAHI1+.net
- この板には最近来るようになった新参者ですが
このスレは書き込み少ないけど非常に参考になります。
- 37 ：NAME IS NULL：2008/12/25(木) 09:38:42 ID:Y/SoMNRd.net
- 稼働システムでDB設計がおかしくてPGで何とかしようとするのはいい
もう稼働してしまっているから大きな改造などは怖いので出来るだけやりたくないという理由
でも・・・なんであいつ等それを教訓にして次の土台の硬め方を変えようとしないのか
同じような設計して同じようなトラブル産んで・・・・
追伸
正規化とかもやりすぎは使いにくさにつながるかもしれないけど、適度な正規化くらいかけてください。
- 38 ：NAME IS NULL：2008/12/25(木) 18:39:06 ID:???.net
- 今は昔よりサクサク作れるんでしょ？
ＤＢも使い捨ての時代じゃないの？
- 39 ：NAME IS NULL：2008/12/25(木) 21:37:48 ID:???.net
- アプリケーションはサクサクと使い捨てられることも多いけど、
DBは後々、受け継がれて残っていくからなぁ。
アプリケーションの進化に比べると、SQLやRDBの進化は遅いしね。
っていうか全角でＤＢ www
- 40 ：NAME IS NULL：2008/12/27(土) 00:32:30 ID:???.net
- 遅いかねえ
最新のDBの機能なんて誰も使いこなしてねーじゃねーか
- 41 ：NAME IS NULL：2008/12/27(土) 01:02:18 ID:???.net
- 昔IBMの博士がRDBの基礎理論を発表してから、常に進歩・進化していると思うが。
OracleやDB2なんかは使いこなしている奴の方が極レアだろうに。
- 42 ：NAME IS NULL：2008/12/27(土) 02:11:29 ID:???.net
- RDBMSの実装自体は猛烈な勢いで進化していますが、
スキーマ設計手法やクエリ言語に関しては案外ゆっくりと
しているのではないかと。
SQL92以降の拡張って実際どの程度使われていますか？
- 43 ：NAME IS NULL：2008/12/27(土) 03:50:52 ID:???.net
- LINQがどうなるのかってところか。＞クエリ拡張
あとは、ORマッピングの活用とかそっちも全然進んでなくね？＞特に日本
- 44 ：NAME IS NULL：2008/12/27(土) 08:06:29 ID:???.net
- xml関係の拡張(?)も凄いと思うし、モバイル対応とか、組み込みとか
あれこれ頑張っていると感じる。
- 45 ：NAME IS NULL：2008/12/27(土) 08:52:24 ID:???.net
- >>43
O/Rマッピングにそんなに価値を感じてるのですか？
流行に踊らされていませんか？
- 46 ：NAME IS NULL：2008/12/27(土) 09:23:03 ID:???.net
- そりゃまあ、COBOLerには縁がないから、価値を感じないだろうなぁ。
- 47 ：NAME IS NULL：2008/12/27(土) 10:59:58 ID:???.net
- COBOLは全然分からないが、DB設計の立場で見ると、
O/Rマッパには、
DB「設計」不要の簡易システムなら画面プログラマだけで作れる、
という以上の価値は感じられない。
- 48 ：NAME IS NULL：2008/12/27(土) 13:56:21 ID:???.net
- ポトペタな画面アプリ作る時には実際、O/Rマッパって必須だと思うけど。
簡単なものが簡単に作れるのは実際ありがたいし。
ちなみにDB設計不要ってくだりはｲﾐﾌﾒｲだな。
そりゃＤＢ設計者と思い込んでいる運用チームの人間が言っているなら
なんとなくわかるが。ｗ
- 49 ：NAME IS NULL：2008/12/28(日) 04:56:16 ID:???.net
- 不要ってことは無いけど、重要視されてないのは事実。
糞なテーブル設計でも、一応動くし、速度も糞高い鯖でも買えば力技で何とかなるのも事実。
PGの学習能力は、そもそも糞なPGなのか、予算的問題で優秀なPGが確保できてないのか、営業的問題で長期運用を前提として無いとかだろう。
営業的には４年程度なんとか動いて、定期的に新しいシステムに更新してもらうのが儲かる。データ移行という名目でぼろ儲けしているのをわざわざ無くす必要は無いし。
運用ならもうちょっと強く逝ってもいいと思うぞ。開発の尻拭いも大変だろうし。
そのままリリースしてしまうと業務に支障がでる！
と強く逝ってやれ。実際、業務に支障が出るのは毎度の事だし。
ある程度汎用的に使おうとすると、結局は最新機能は使わずに終わってしまう事が多い。
このアプリケーションでは対応して無いとかで最大公約数的に使える機能が絞られて行く。
- 50 ：NAME IS NULL：2008/12/28(日) 07:46:38 ID:???.net
- むしろテーブル設計よりも、糞クエリを書く奴をなんとかして欲しい
SELECT一文で数KBとか馬鹿もいいとこ
このマシン遅いとか、冗談きついわ
アプリで処理すべきことをDBにやらせて遅くしてるのはお前だ
- 51 ：NAME IS NULL：2008/12/29(月) 02:43:23 ID:???.net
- 俺の経験だとSQLで出来ることを
アプリにやらせて遅くしてるやつの方が多い。
とても遅くなって困る。
- 52 ：NAME IS NULL：2008/12/29(月) 17:57:30 ID:???.net
- http://capsctrl.que.jp/kdmsnr/wiki/bliki/?DomainLogicAndSQL
- 53 ：NAME IS NULL：2008/12/30(火) 04:17:20 ID:???.net
- >>52
なつかしいなそれ。割引金額をアプリで持ってるから
割引率変更になった時点で過去売り上げの改ざんになるのな。
揚げ足取りはさておき、ドメインロジックはまだいいんだけど
クロス集計とか頑張ってやってたのを見てびっくりした事ありますよ。
- 54 ：NAME IS NULL：2008/12/30(火) 18:59:03 ID:???.net
- クロス集計って、アプリ側、DB側、どちらで頑張っていたのでしょうか？
今はSQL/OLAPが使えるようになってきて随分楽ですね。
- 55 ：NAME IS NULL：2009/01/02(金) 13:44:40 ID:???.net
- >>51
テーブル設計がよろしくなくて、アプリ側でエラい苦労させられたことがある。
SQL書けねえやつに設計させるなと。
- 56 ：1：2009/01/04(日) 02:15:37 ID:???.net
- テーブル設計が問題なのか、
SQLが問題なのか、
アプリが問題なのか…についてですが、
結論からいって、全てにおいてまずテーブル設計の問題だと思います。
理由はそれが土台だからです。
テーブル設計がおかしいという理由で、
おかしなSQLを書かざるを得ない状況に陥ることは多々あるし、
テーブル設計がおかしいから、
アプリでおかしな制御をせざるを得なくなったりするんです。
それと、「正規化もやりすぎると使いづらくなる」などという意見がありましたが、
自分は何があっても、どんなシステムあっても、どんな利用用途であっても
RDBでデータを管理する以上、必ず全てを第三正規形まで落とす必要があると思います。
正しくはその正規系を業務や仕様にあわせて（敢えて）「崩す」のです。
だから「正規化はしないほうがいい場合もある」というのは語弊があります。
正しくは「正規化は必ずしなければならない。その上で（状況に応じて）崩すことは構わない」
ということです。
- 57 ：NAME IS NULL：2009/01/04(日) 08:45:00 ID:???.net
- モバオクみたいに１人のスーパーエンジニアに全部ヤらせればいいんだよ。
要件定義から設計～実装～テストまで自前でやればドコがおかしいか
自分で気がつくだろうに。
時々、老害が自分の立場を守るためにくだらねぇ自己主張
しまくるから、設計がグダグダになっていくケースがあるしなぁ。
- 58 ：NAME IS NULL：2009/01/05(月) 21:02:37 ID:???.net
- 一人はそいつが飛んだら終わりだけどな。
二人一組ぐらいにはするべき。
- 59 ：NAME IS NULL：2009/01/06(火) 03:30:29 ID:???.net
- さらっと「飛んだら」と書かれてちょっとビクっとした。
「意識が途切れる」「遠いところに逃げる」「宙を舞う」。含意は色々ですが。
- 60 ：NAME IS NULL：2009/01/07(水) 01:26:04 ID:XvNxYhBN.net
- 「レコード数が少ないから主キーはいらない」
と真顔でのたまう、うちのSE。。。
- 61 ：NAME IS NULL：2009/01/07(水) 21:14:01 ID:???.net
- >>59
飛ぶっていうのは逃げるとか逃亡するとか辞めるとかの意味。
- 62 ：NAME IS NULL：2009/01/07(水) 22:49:47 ID:???.net
- まず、Tか島平団地で飛ぶとか、そっちを考えたわｗ
- 63 ：NAME IS NULL：2009/01/11(日) 12:18:16 ID:???.net
- 全てのテーブルが外部結合を必要なく設計されてるシステムってある？
あるコードに対して対象か対象じゃないかをマスタのレコードが有るか無いか
で判定するのはRDBとしては誤っていると思うんだけど。
RDB設計をまともにやればシステムの便利さは格段に向上するのは間違いない
システムへの要求も高度化するだろう。RDB設計をまともにしない人には
低度な要求を解決する仕事を続けるためにRDB設計を軽視し続ける
べきだ、保身のために。
日本は現場の国だ。現場以外は糞。そしてシステムに関する決定権は
現場には無い。使う側の現場力と開発する側の現場力が糞によって
互いに相反する方向へ注力させられている。まったく無駄なことよ。
- 64 ：NAME IS NULL：2009/01/12(月) 02:57:32 ID:???.net
- http://www.google.co.jp/search?q=result+site%3Acerema.co.jp
設計を軽視するとこうなる
- 65 ：NAME IS NULL：2009/01/12(月) 10:22:11 ID:???.net
- >全てのテーブルが外部結合を必要なく設計されてるシステムってある？
>あるコードに対して対象か対象じゃないかをマスタのレコードが有るか無いか
>で判定するのはRDBとしては誤っていると思うんだけど。
RDBでないDBはそうするしかないと思うが。
RDBでそうしているオマエの現場が糞と言うなら「そうだろうな」としかいい様がないわけだが。
「システムに関する決定権は現場には無い」ってオマエがオペレーターみたいな
現場といっても最底辺だとないだろうとは思うが、普通の開発現場なら
あからさまにイカれている設計なんかはレビューや評価で却下すればいいんじゃねーか？
- 66 ：NAME IS NULL：2009/01/12(月) 11:47:45 ID:???.net
- >>65
そのレビューとやらに呼ばれないｗ
- 67 ：NAME IS NULL：2009/01/12(月) 17:55:09 ID:???.net
- Oracleで対象非対象をレコードが有るか無いかで設計してあるのはやっぱ間違いだよね。
Oracleやってる奴も汎用機COBOLで経験つんだエンジニアばっか。COBOL流のシステム
設計をむりやりOracleに載せてる。それが常識で考えた標準らしいですよ。何も言えねえ。
- 68 ：NAME IS NULL：2009/01/12(月) 18:43:00 ID:???.net
- >対象非対象をレコードが有るか無いかで設計してある
こいつはどういう状態のことだ？
つうか、>67はどんな対案が正論だと言いたいんだ？
- 69 ：NAME IS NULL：2009/01/12(月) 19:02:10 ID:???.net
- ジョインされる２つのテーブルのキーが1:nになっているべきか1,0:nを前提に設計するかって話だよ
- 70 ：NAME IS NULL：2009/01/12(月) 20:12:57 ID:???.net
- んーっと
1:n設計は間違いだっていう主張？
- 71 ：NAME IS NULL：2009/01/13(火) 00:00:54 ID:???.net
- >>64
ひどいｗ
これは損害請求レベルじゃないのか
- 72 ：NAME IS NULL：2009/01/15(木) 03:02:24 ID:???.net
- ちがう、1:nを守るためにマスタにレコード追加しようとしたら引かれたの。意味無いとか言われて。
- 73 ：NAME IS NULL：2009/01/15(木) 07:27:58 ID:???.net
- レコード番号 | 存在フラグ
---------------------------
1 | 存在する
2 | 存在しない
3 | 存在する
or
レコード番号 | 存在フラグ
---------------------------
1 | 存在する
3 | 存在する
の違いって事？
- 74 ：NAME IS NULL：2009/01/15(木) 07:30:37 ID:???.net
- あー頭死んでた。
レコード番号 | 対象フラグ
---------------------------
1 | 対象
2 | 非対象
3 | 対象
※フラグ見て対象かどうか判断
or
レコード番号
-----------
1
3
※レコードの存在の有無で対象かどうか判断
の違いって事？
- 75 ：NAME IS NULL：2009/01/15(木) 08:30:46 ID:???.net
- >>72
どういう状況でどんなテーブルに何をしようとしたのか端的に説明してくれ。
とにかく状況が小出しじゃ何も判断できん。
- 76 ：NAME IS NULL：2009/01/16(金) 00:24:21 ID:aohFMQX5.net
- >>72
あと、「引く」という言葉の意味が分かりません。
- 77 ：NAME IS NULL：2009/01/16(金) 03:48:45 ID:???.net
- はぁ？
ひくわ
- 78 ：NAME IS NULL：2009/01/16(金) 06:15:57 ID:???.net
- >>63
なにか、ＲＤＢがあるからデータ入れよう的な考え方に聞こえるぞ
まったく結合するものがないなら、「Ｒ」ＤＢである必要はないわな
レコードがあるかないかで判断するか、（結合された）レコードに書かれてる内容で判断するかは、
それがどういった情報を格納してるかで決定するべきで、ＲＤＢなのだから
必要ない結合先のレコード（や、もしかするとそのテーブルそのものも）を作らないといけないということはないだろう
>そしてシステムに関する決定権は現場には無い
現場は必要もないＲＤＢを使いたくなく使ってるのかもしれないな
そして必要もないのに、ＲＤＢだからどうのこうのという、
現場の空気を読まない原理主義者みたいなやつがさらに話をややこしくするんだ
>>67
口調が違うが同一人物じゃないのか？
ちなみに、ＲＤＢ使った開発でＳＱＬを書いてるやつでも、
exists使ったことないってやつは結構いるだろう
ＲＤＢだから、ＯＲＡＣＬＥだから、レコードのあるなしで判断するのは間違ってるだろうとか
その判断基準がおかしいとしか思えん
まあ、現実的なＤＢの選択としてはＲＤＢＭＳしかない現状もあるがな
- 79 ：NAME IS NULL：2009/01/17(土) 12:17:11 ID:???.net
- １さんの言うことはまったくもって正しいんだけど、
実際にこういうことを口に出しちゃうと
「頭でっかちで現場じゃ使えない」って評価になるんだよね
おれがそうだからよく分かるwww
- 80 ：NAME IS NULL：2009/01/17(土) 13:23:40 ID:???.net
- 制約を強くするとデータを入れにくいじゃない？とか平気で言うPLがいるとやる気0だよね～
それで親の無い子レコードや、不正なデータが山のようにあるんじゃ世話ねーよ
- 81 ：NAME IS NULL：2009/01/18(日) 01:12:13 ID:???.net
- そうそう、そんな感じｗｗ
設計と製造の現場はまさに自分はDB設計を軽視してませんって顔して
キーマンの顔色を伺って程度をあわせる世界だよね。アホすぎｗｗ
ここもそんなもんだね。あ～あ
- 82 ：NAME IS NULL：2009/01/18(日) 01:57:28 ID:???.net
- >>81
ここもそんなもんだねとか達観した気になる前にここで吐き出せよ。>80みたいに。
それすらできないくせに嘆くな。
- 83 ：NAME IS NULL：2009/01/18(日) 13:16:55 ID:???.net
- お前何言ってんの？
- 84 ：NAME IS NULL：2009/01/18(日) 14:47:36 ID:???.net
- 俺？俺は何も言ってないよ。
- 85 ：NAME IS NULL：2009/01/18(日) 15:08:45 ID:???.net
- オレも何も言ってない。
>>86はどう？
- 86 ：NAME IS NULL：2009/01/18(日) 23:18:56 ID:???.net
- 俺も。
- 87 ：NAME IS NULL：2009/01/20(火) 01:39:08 ID:???.net
- 39+3 ： すずめちゃん(catv?) [] ：2009/01/20(火) 00:55:46.00 ID:5lC2DwfT (2/2)
市況２のスレを読んだら、どうも
データベースがぶっこわれたみたいで、金曜の取引データが飛んだみたい
で、約定メールから復旧させようとしてるとか
- 88 ：NAME IS NULL：2009/01/23(金) 23:30:34 ID:???.net
- 取引先の「偉い上司」デター！
ぼくの考えたデータベース持ってキター！
さて、どうすっかな・・・
- 89 ：NAME IS NULL：2009/01/24(土) 11:34:33 ID:???.net
- データベース設計が軽視されているのではなく、
データベース設計に携わる人間が軽視されているのだ。
という命題をたててみる。
- 90 ：NAME IS NULL：2009/01/28(水) 20:45:41 ID:???.net
- >>89
それは、その人間の行う作業が軽視されてるから、
その人間が軽視されてるじゃないか
そうでないなら、別の人間が代わりにその作業をすることになるだろう
- 91 ：NAME IS NULL：2009/01/30(金) 17:19:32 ID:???.net
- そもそもちゃんと仕事できてないから人間的に信頼されて無いとか？
データベース以前の問題だな。
結局、現場の意見のほうが採用されて、ボンクラDBA涙目。
組織で仕事するという条件で目標を達成するためのスキームをちゃんと考えたほうがいいよ。
- 92 ：NAME IS NULL：2009/01/31(土) 16:21:56 ID:???.net
- ここ読んでて恐ろしいのは自分の関わったシステムではDB設計軽視して無いって
本気で思ってそうな人がいることだ。RDB的な不備が出るのは現実的に
仕方の無いことだが、あくまでも例外であって、あるシステムの中で数個の
数少ない心残りとして記憶されてしかるべきもの。
こんなバカだらけではキーマンの顔色を伺ってISAMバカ基準でシステムを組んだほうが
計画は立てやすいだろう。RDBMSを使ったPK、ソート、VSAMユーティリティと考える。
だいたいRDBMSをPK、ソート、VSAMユーティリティとしてシステム組んだ経験がある
人だとそれで正解だと誤解しちゃうんだろうな。それで動くから。
底辺会社の底辺システムの目標としてはそれでもいいだろう。動けば底辺客も
文句言わないから。しかし、そんな設計してRDBの特徴を活かさなかったら
RBD以前の非生産性を引きずったシステムが出来上がるわけだよ。しかし、
その非生産性は1円入札して保守で儲けるビジネスモデルでは工数が稼げる
かもしれんよ。いつか関わりたいなRDBのシステム。。。
そういえば某メガバン統合でCOBOLアホシステムで統合決定してるのが象徴的だねえ。
COBOLアホシステム準拠が日本では巻かれるべき長いものと決定したようなもんだ。
- 93 ：NAME IS NULL：2009/01/31(土) 20:03:29 ID:???.net
- メガバンのＭ菱サイドの方がオープン系とかにシフトする勇気がないんだろうし。
ああいうのは変に金があるから、コスト度外視の設計しても疑問に思わずに、
「こういうもんだ」と納得してんだろう。
- 94 ：NAME IS NULL：2009/02/01(日) 04:06:38 ID:???.net
- Mでは実績が無いだけでしょ。いわゆる前例がないってやつだ。
提案してるベンダもリスク回避として、今のシステム踏襲路線てのも悪く無い決断だと思うけどな。
まずは確実に統合して不具合を出さない事が第一目標だろう。一気に欲張って失敗するくらいなら、落ち着いてじっくり今後を考えればいい。
RDB的に正しい正規化した設計と、現場が把握し易い伝票ベースの設計のどちらがいいかは力関係も大きいし。
- 95 ：NAME IS NULL：2009/02/01(日) 04:31:52 ID:???.net
- >>92
お前の考え方は、道具に合わせてものを作れって考え方だ。
それはそれで否定しないが、その考え方だけが唯一の正解のごとく、
他の考え方を貶めるのはやめたほうがいいぞ
- 96 ：NAME IS NULL：2009/02/01(日) 06:47:01 ID:???.net
- DBAが満足する、実績の無い新しいシステムで、銀行ATM止めて大迷惑かけてしまうのと、
DBAは不満だけど、実績のある既存のシステムで、銀行ATM止めずに問題なく使えるのと、
どちらを決断するって話だろ。
DBA様の首斬って損害賠償請求逝ってもよければ、勝負もあり。
- 97 ：NAME IS NULL：2009/02/01(日) 09:20:00 ID:???.net
- しかしあのメガバンってアフォみたいにATMを停止させてる現実があるんだが。
単に突然使えないのが事前に「メンテナンス」と言う言葉で停止させるかの
違いなんだろうけど、その「メンテナンス」が予定時間オーバーも珍しくないワケで、
利用者としては「アレ？朝には使えるって言っていたのに･･･」ってクレームも
たくさんあるんだが。
結果論からすると「COBOLでも十分に失敗する」と言う前例は今回の合併だけでなく
以前から繰り返されている予定調和な感があるけどな。
U○Jの以前の倒壊＆惨羽の合併ではそんなに混乱は起きていないけど、
ＭとU○Jではこんなにゴタゴタしているのは、両者の技術レベルのギャップが
凄いんだろうなぁ。Ｍは特に悪評高いパッケージだし。
- 98 ：NAME IS NULL：2009/02/01(日) 14:01:11 ID:???.net
- それでもまだ復旧の見込みがあるぶんだけ優位だろ。
DBAの提案聞いてオープソ系とか導入して何日も復旧できなかったら終わる。
- 99 ：NAME IS NULL：2009/02/01(日) 17:25:49 ID:???.net
- あれくらいの仕事する案件では「失敗した時の復旧プラン」もちゃんと計画に入っているんだがな･･･。
「○時時点でこのチェックポイントをクリアできない場合は戻す」と言う具合に。
そこまでしておいて、それでも予定時間オーバーってのは、
COBOLを前提とするシステムと言うのは性善説に成り立っている仕組みが多いという事だな。
逆にオープン系なんかは性悪説(?)に成り立っている感があるので、
JOBの再投入もやりやすいように設計する人おおいからなぁ。
そして何日も復旧できない事態なんて存在しない。
オープン系が優位とは言わんが、COBOLが実績があって安定性云々なんて
寝言を言う人間は間違いなく現場の金融系の実体を知らん厨房だと思う。
- 100 ：NAME IS NULL：2009/02/01(日) 22:31:46 ID:???.net
- >>95
君は知識的にコンプレックスがあるだけだと思うよ。勉強不足だからホントの事いわれると
貶められたような誤解をするんだと思う。スコップをちりとり代わりに使用しても不便だ、
三角より平型スコップならちりとり性もupするよね。実際、いくつかのOracleのバージョン
アップはISAMシステム実装のしやすさも機能強化されていってると思う。
おれはDBAらしい仕事は一度もしたこと無いが、SEのRDBコンプレックスは見苦しい。
もっと使いこなさないと関係モデルは組めん。半端な知識だから破綻してISAMに
逃げることになんだよ。そんなISAMやりたいんならRDBMSを開発する側に回るべき
だね。そこに食い込めないなら引退すべきだよ。老害なのかなと思う。
- 101 ：NAME IS NULL：2009/02/01(日) 23:10:46 ID:???.net
- ISAMシステムに逃げるってどういうこと？
- 102 ：NAME IS NULL：2009/02/02(月) 00:45:23 ID:???.net
- いつも自分の意見が取り入れなくてストレス溜め込んでるのだろうな。
だれもオープン系のシステムにしてくれないｗｗｗ
Mが従来通りの路線で行くのを理解できないほうが、現場の金融系の実体を知らん厨房でしょ。
だからオープン系のシステムにこだわり続ける。
実務やってる現場は、結局システムの中身なんてどうでも良いし。ちゃんとシステムが動く実績がある事が重要。
オープン系って何日も復旧できない事態って本当に存在しないの？
全部のオープン系システムの事態を把握してるのも怪しいが。
- 103 ：NAME IS NULL：2009/02/02(月) 06:44:35 ID:???.net
- >>101
1つの長大なテーブルをいくつものPGでいくつもいくつも作るシステムといえば伝わるかな？
- 104 ：NAME IS NULL：2009/02/02(月) 21:13:41 ID:???.net
- >実務やってる現場は、結局システムの中身なんてどうでも良いし。ちゃんとシステムが動く実績がある事が重要。
現に動いてないと言う実態を知らんのか？
あのメガバンのメンテナンスと言う名の停止っぷりは半端ないが。
当初のスケジュールがどんどん遅延して何年かけて統合するつもりなのか知らんが、
現場はいい迷惑だ。
- 105 ：NAME IS NULL：2009/02/02(月) 21:55:10 ID:???.net
- 噂によく聞くコボラーってやつか。
本当にそんな人種いるの？
それならExcelでいいじゃんよｗ
- 106 ：95：2009/02/02(月) 22:46:33 ID:???.net
- >>100
俺は別にコンプレックスをもって言ってる気はないんだがな
お前のいうホントのことって何だ？
まあ、お前がＲＤＢ使ってないのはバカ基準で底辺のアホシステムだと
考えてるというのはよくわかった
まあ、思っててもあんまり簡単に他人をバカだアホだ底辺だといわんほうが良いよ
- 107 ：NAME IS NULL：2009/02/03(火) 01:53:50 ID:???.net
- >>104
オープンだろうが大型汎用機だろうが関係なく、あんな大規模なシステム統合を本気で丁寧に障害なく
進めるならあれくらいは当然だと思うよ。
見切り発車のＭとみっちり石橋たたきのＭ。どちらがいいか経営者には良い判断サンプルになったんじゃないか？
石橋を叩くのを選べるほど金が使えるのはＭくらいだろうけど。システム部長は石橋を叩けるだけ叩くのが仕事だわな
- 108 ：NAME IS NULL：2009/02/03(火) 23:24:57 ID:???.net
- プロセス中心で考えるエンジニアとデータ中心で考えるエンジニアが
理解し合うのははっきり言って無理
- 109 ：NAME IS NULL：2009/02/04(水) 06:37:55 ID:???.net
- お互いに相手の領域を理解すれば効率が何倍もあがるというのに。
- 110 ：NAME IS NULL：2009/02/04(水) 23:06:33 ID:???.net
- >>109
いや相容れないだろ。このスレ読んでもわかるように
それぞれの優先順位が違いすぎるもの。
プログラム言語の違い以上に深い隔たりがあると思う。
新人の時からデータ中心アプローチをたたきこまれた俺としては、
９２さんの文章は少し挑発的だけど、内容はけっこう共感できるよ。
- 111 ：NAME IS NULL：2009/02/04(水) 23:09:25 ID:???.net
- 自演乙
- 112 ：NAME IS NULL：2009/02/05(木) 00:48:16 ID:raK4Q0Jb.net
- というか、
>>1によると、ここでは「業務システム」についての設計の話だそうだから、
データ中心で考えるのが正解ではないのか？
- 113 ：NAME IS NULL：2009/02/06(金) 15:01:56 ID:???.net
- >>109
理解するだけではだめだな。妥協が必要
ただ、その妥協点は、かなりどっちかよりでないと成立しない
実際は設計するときにどっちの考え方でやるか統一しとかないとだめだな
>>112
業務システムの設計だから、データ中心が正解だという理由を説明してほしいもんだが
プロセス中心の設計は間違いなのか？
データーベース設計の話だから、データ中心の方が良いというのなら理解できるんだがな
- 114 ：NAME IS NULL：2009/02/07(土) 02:03:06 ID:???.net
- 業務システムをプロセス中心で開発するってのは
たいがいにおいて業務プロセス中心に開発するんじゃなくて
システムプロセス中心に開発するの意だからな
- 115 ：NAME IS NULL：2009/02/11(水) 13:36:01 ID:???.net
- かくしてエンジニアのオナニー状態の使えないシステムが作られて行く訳だな。
そして次の契約が取れず淘汰されて行く。
- 116 ：NAME IS NULL：2009/02/11(水) 15:45:17 ID:???.net
- >>115
いや、逆でエンジニアにオナニーさせたほうがいいものができるぜ。
マネージャのオナニーの結果、よくないものができてるのが現状でしょ？
マネージャとエンジニアのセックスなんてありえないでしょ？
- 117 ：NAME IS NULL：2009/02/11(水) 16:50:55 ID:???.net
- >>115
DB設計は家を建てるのに例えれば基礎工事みたいなもんでしょ
外観や内装に注文つける客はいても、基礎工事に注文つける客はいないでしょ
- 118 ：NAME IS NULL：2009/02/11(水) 17:54:21 ID:???.net
- 見えにくい部分だけあって理解も無いから。
ここは地盤が緩いから事前にこれだけアンカー打ち込んでおけと
指示しても施工出来る人がいないとか後での設計変更が云々とか。
DB設計軽視はシステム開発の耐震偽装みたいなものかな。
- 119 ：NAME IS NULL：2009/02/11(水) 18:26:50 ID:???.net
- >>116
一番怖いのは、営業と客のオナニー
日本ではマネージメント専門の人はプロジェクトにいないのが普通
そういう意味では真のマネージャーなぞ存在しない
- 120 ：NAME IS NULL：2009/02/14(土) 02:52:52 ID:???.net
- >>1
情報系の人間がただでさえ軽んじられてててさ、
当社では工学部おっけ～、文系でもおっけ～、だれでもおっけ～みたいな会社ばっかで
まともに学校でDBについて勉強したことないやつが多すぎるからだろ
情報系はもっとも理解されてない学科
- 121 ：NAME IS NULL：2009/02/14(土) 03:20:54 ID:???.net
- 会社で昼休みにテクデの勉強してたら資格オタク扱いされたなぁ
- 122 ：1：2009/02/15(日) 13:28:47 ID:???.net
- >>120
文系、理系の問題ではないと思います。
私は文系ですし。
- 123 ：NAME IS NULL：2009/02/19(木) 23:58:36 ID:???.net
- >>120
ふむ。
今の情報系の学科がどのようなカリキュラムか知らないが、
大学出の者を戦力と考える会社はいまどき居ないだろ。
会社としては2,3年掛けてようやく戦力として使えるかな？
という人間を探しとているということではないかなぁ。
それには出身の大学、学部、学科はあまり考慮されないと思う。
- 124 ：NAME IS NULL：2009/02/20(金) 15:11:09 ID:???.net
- でも地頭は大事。新卒の場合、出身大学のランクを元に、見込みで採用してるだけ。
中途なら、出身大学のランク高くても、経験や実績無ければゴミだろ。
IT系は専門知識不要で採用してしまうからな。そして現場で不良施工状態のデスマ。
ちゃんとIT理解してる理系が、人嫌いでPCにばっかり向かっていて、客との対話を営業任せで放棄してるのも、低コストで短納期で突貫工事的な変な仕様で迷走する理由の一つだと思う。
客は住み易さとか快適性能に重点置いてるのに、施工してる側は基礎工事だけに専念していいものが出来たってオナニーを満足してちゃ意味無いだろ。
家は３回建て直さないとまともなものが出来ないように、システムも１回で使えるものが出てこないのは、理系のオナニーのため。
- 125 ：NAME IS NULL：2009/02/20(金) 19:30:18 ID:???.net
- 釣りか？！データモデル設計とテストデータ実装、本番データの実装、ACCESSのクエリーなりでＵＩ概要とすれば
ＰＧ無しで開発できる。プロトタイピングからスパイラルモデルで進めれる
２サイクル目でＰＧの帳尻合わせなんかしないリモデルリトライだ
だいたい物理的組み立て積み上げで作る家なんかと比較してるなんて現実にあるシステムの機能を
知らな過ぎ
- 126 ：NAME IS NULL：2009/02/21(土) 01:48:51 ID:???.net
- まあ
二人ともモノ知らなさ過ぎな事はわかるがｗ
- 127 ：NAME IS NULL：2009/02/21(土) 10:45:09 ID:???.net
- >>125
突っ込みどころ満載だなwww
- 128 ：NAME IS NULL：2009/02/22(日) 21:31:56 ID:???.net
- できるのに大学行かないやつも迷惑だよな
- 129 ：NAME IS NULL：2009/02/26(木) 09:29:54 ID:???.net
- 底辺大卒の悲壮ですか？
- 130 ：NAME IS NULL：2009/02/28(土) 16:59:28 ID:hnW2hUJ8.net
- 正規化も3層スキーマの考え方も身についていないような奴が
DB技術者を名乗っちゃうから嫌になる。
自称DB技術者のおっさんが主キーがどれかすらはっきりしない
テーブルもどきの何かを作ってきたんで正規化してくれと頼んだら
しばらくネットで何かを調べた後にテーブル数が増えてわかりにくくなるから
正規化しなかったと言い訳してきた。
よくネットでテーブル数が増えるから正規化はしなくていいなんていう
無茶苦茶なことを書いてる似非DB入門サイトがあるが、それに騙されちゃったんだろうな。
- 131 ：NAME IS NULL：2009/02/28(土) 18:29:31 ID:???.net
- 問題を指摘されたらググって言い訳を探す医者や自動車設計者が
いたら結構イヤン。
- 132 ：NAME IS NULL：2009/03/01(日) 00:06:37 ID:???.net
- でも使ってるうちに正規化が崩れていくのも事実。
データベースがどのような事に使われていくかはシステム稼働後にしか分からないし。
呼び出してるDBアプリほど、柔軟には、DB側は組み直しとか出来ないし。
簡単に正規化組み直しとか出来る機能が付けばいいけどね。
- 133 ：NAME IS NULL：2009/03/01(日) 09:56:25 ID:???.net
- DBの組みなおしは簡単に出来るよ。それこそ制約に従ったSQL書ければ簡単だよ。
組み直しが難しいのはPG
- 134 ：NAME IS NULL：2009/03/01(日) 11:37:45 ID:???.net
- >>132
使う、っていうのが、システムの変更も含めているのならまあそうかもしれん
だが意図して正規化を崩すのでなければ、変更した技術者のスキルの問題だろう
普通はシステム稼働まえに、設計の段階でどのように使われるか考えるものだろう
DBの変更はプログラムの変更に比べれば簡単だと思う
簡単であるが故に、設計がおろそかになってるんじゃないかと思うな
- 135 ：NAME IS NULL：2009/03/01(日) 15:12:16 ID:???.net
- そこでスレタイですね
- 136 ：NAME IS NULL：2009/03/01(日) 23:46:49 ID:???.net
- だからPGはあとまわしでPGによる調整が必要ないところまで
データモデルを作り上げてインプットとアウトプットを固めないと
糞PGになんじゃん
- 137 ：130：2009/03/02(月) 08:43:58 ID:aM7tqfv0.net
- >>132
何を言ってるんだか。
おまえは半年仕事を休んでデータベーススペシャリスト試験を
本気で合格する気で勉強してみろ。
言っておくがオラクルなんかのベンダー資格なんてとっても意味はないぞ。
基本が身についていない奴が製品に依存した知識を持ったところで意味はないからな。
まったく、嫌になる。
- 138 ：NAME IS NULL：2009/03/02(月) 19:08:00 ID:???.net
- １０年使ってきたDBの変更と、１０年使ってきたウェブアプリの変更どっちが簡単か自明だと思うけどな。
１０年後まで考えてデータベース設計するのは無理。
最初は在庫管理で作ったのに、拡張で顧客管理も入って、更に拡張で売り上げや経営財務管理まで入ってくるし。
アナログ的に言うと、社内帳簿フォーマット変えるのと、利用してる現場担当者入れ替えるのとどっちが簡単かって話。
- 139 ：NAME IS NULL：2009/03/03(火) 23:10:30 ID:???.net
- 利用者の顔色を伺って利用者と良好な関係を保つのが仕事をうまくすすめるコツだな
問題は糞利用者が使ってる糞帳簿を改善することではないんだよ。デジドカの鉄則だ
- 140 ：NAME IS NULL：2009/03/03(火) 23:53:30 ID:???.net
- 老害コボラー臭のするヤツがいるな
他の板に居場所ないのか？
- 141 ：NAME IS NULL：2009/03/04(水) 03:34:01 ID:???.net
- ↑うまくいってる？
- 142 ：NAME IS NULL：2009/03/04(水) 14:46:46 ID:???.net
- >>141
ちゃんと安価書けよこのうんこ
- 143 ：134：2009/03/04(水) 17:38:20 ID:???.net
- >>138
自明って、お前の主張はどっちなんだ？>>137への反論なのか？
- 144 ：NAME IS NULL：2009/03/13(金) 01:10:06 ID:???.net
- >>132はある意味、「真理」に近いと思う…
最近は単純に「上流」工程だの、「下流」工程だのと、
誰かが宣伝したテンプレに従い過ぎだ…
んなもん、ケースによって全然違うんじゃ～い！
- 145 ：NAME IS NULL：2009/03/13(金) 02:07:07 ID:???.net
- 実務の世界の人間ではないのですが、「使っているうちに正規化が
崩れる」というのは具体的にどういう状況を指すのかちょっと興味が
あります。
更新のコストが馬鹿にならないので非正規化する、というケースは
理解できるのですが、例えば業務内容に上手くマッチしなくなった
のでスキーマを改変する、というケースであれば、なんで改変後も
正規形を満たすように改変しないのかな、と素人考えでは思って
しまいます。
もし宜しければ簡単な例など教えていただけないでしょうか。
- 146 ：NAME IS NULL：2009/03/13(金) 09:11:07 ID:???.net
- 「正規系が」業務内容に上手くマッチしなかったんだろｊｋ
- 147 ：NAME IS NULL：2009/03/13(金) 13:28:46 ID:???.net
- スキーマ改変したら、アプリ側の改変しないと駄目で、予算的に膨大になるでしょ。
スキーマ改変なんて現実は、なかなか遣れない。スキーマ改変について来れるようにアプリ側で対応してるのも見た事無いし。
- 148 ：NAME IS NULL：2009/03/13(金) 15:08:04 ID:???.net
- お客さんに、「いちいち明細なんて入力するの面倒くさいし
そもそも決まった数以下しかないから」っていわれて
しかも見出し・明細が1行のレコードとして
外部と連携したりなどなどで正規化やめたことはある。
- 149 ：NAME IS NULL：2009/03/14(土) 19:50:11 ID:???.net
- >>146
それはその技術者のスキルが低いからうまくマッチングできないんだろ
>>147が言う、既存部分の変更を嫌がるのが一番の要因だとおもう
あとは>>148のいう、外部要求に合わせるためか。
こっちはできれば、ビューとか外部出力するアプリでの操作で回避したいとこではある
- 150 ：NAME IS NULL：2009/03/14(土) 21:37:15 ID:???.net
- >>149
なるほど。>>148の繋がる相手に合わせる、というのはよく分かる
気がします。
>>147はまだちょっと難しいです。
既存のスキーマを改変するのはなかなか難しいというところまでは
理解出来るのですが、スキーマを改変しないならそもそも正規形も
崩れようが無いのでは？と思ってしまいます。
これは例えば住所を2件持てるようにしたいので一つの住所カラムに
タブ区切りで2個住所を入れちゃうぞとか、スキーマはそのままでも
入れるデータによって正規形が崩れてしまうような状況を指している
のでしょうか。
- 151 ：NAME IS NULL：2009/03/15(日) 01:02:31 ID:???.net
- データってのは、ただ溜め込むだけじゃなくて、いろいろな事に使われて応用されていくもの。
いろいろなデータが追加されていくと、正規化が崩れていく。
１０年拡張もせずに動かすというシステムなら、正規化は当初のまま有効だろうね。
- 152 ：NAME IS NULL：2009/04/07(火) 23:03:52 ID:AzDX/Nl7.net
- accessと汎用系DBとでは、設計手法が異なると聞きましたが本当ですか？
- 153 ：NAME IS NULL：2009/04/08(水) 03:28:48 ID:???.net
- どこまでを指して設計手法としてるかにもよると思うが、
たとえばアクセスだとトリガやストアドプロシジャが使えない
そういった、アクセスではできないことを考慮した設計は必要
テーブル設計での正規化とか、そういった基本はあんまり大差ないとは思うが
- 154 ：NAME IS NULL：2009/04/08(水) 07:26:18 ID:???.net
- >>152
その人の言う「汎用系DB」って、IMSとかのことだったりしてな。
- 155 ：NAME IS NULL：2009/04/08(水) 08:52:29 ID:+UUt8naG.net
- 正規化されてないDBを見て
それを非難するやつがいたとしたら
そうなるまでには経緯とレベルがあるなんて
理解出来ひんねやろうな。
DBがあります。それが正規化されてるとします。
その場合は
１仕様策定の主導権がDB側にある
２パッケージソフト
３数人で作った小規模システム
４出来たてのシステム
５システム仕様が業務効率化など低レベルなもの
かな。
>>1は、特定の部署でしか使わない、今まで手でやってた仕事を
システム化しましたみたいな
入門者みたいなシステムしか作ってないんちゃうかな
- 156 ：NAME IS NULL：2009/04/08(水) 11:18:57 ID:???.net
- うわー盛大なバカが出た。
- 157 ：NAME IS NULL：2009/04/08(水) 12:54:06 ID:???.net
- >>155
正規化されてないDBに経緯があるのは理解できるがな、
レベルってのはなんだ？レベルが低いから正規化されてないのか？
そんなの非難されて当然だろう
お前の言い分だと、正規化されていないのが当然のように聞こえるが、
お前こそ入門者みたいなシステムしか作ってないんじゃないのか？
>>1は何も正規化だけを問題にしてるんじゃなくて、
設計が大事なのになぜ軽視されてるんだろう、って話だが
お前みたいなやつがいるからなんだと思ったぜ
- 158 ：NAME IS NULL：2009/04/08(水) 21:25:23 ID:pRRCN4Xu.net
- >>153
遅くなりましたが、
ありがとうございます。
ﾄﾘｶﾞ、ｽﾄｱﾄﾞﾌﾟﾛｼｼﾞｬ、頑張って調べます。
- 159 ：NAME IS NULL：2009/04/08(水) 23:28:49 ID:???.net
- さすがに>>155は釣りだろｗ
- 160 ：NAME IS NULL：2009/04/08(水) 23:33:40 ID:???.net
- 正規化しといても、どんどん拡張していくうちに崩れてくるしな。
正規化したくても全部のアプリ作り直しは無理。
http://pc11.2ch.net/test/read.cgi/db/1116097001/
頼むから正規化しろよ 第二正規形
- 161 ：ER図：2009/04/28(火) 01:30:12 ID:???.net
- 突然ですがアドバイス下さい。
アパッチのアクセルログで取れる情報のER図をかけといわれたのですがどんな感じのものをかけばよいでしょうか？
一応アクセスログの仕様については調べたのでログフォーマットとかカスタムログとかの記述方法はわかるのですが
これをER図にしろと言われたらよく意味が分かりません
データベースのテーブルでもないのにこんなもんをER図に出来るもんなのでしょうか
よろしるおねがいします
- 162 ：NAME IS NULL：2009/04/28(火) 21:50:03 ID:???.net
- データベースのテーブルとアクセスログは全く同じ形式じゃないか
- 163 ：NAME IS NULL：2009/04/30(木) 01:51:22 ID:???.net
- アクセスログをどう使いたいのか、要件がわからないままなら、ログのフォーマットそのものなテーブル１つで終わる。
でも、きっとそんなことは無いはずなので指示者に一応確認してみる。
うまく聞き出せないなら、指示者が長期休暇中なら、貴方が｢こういう使い方したら便利だよね｣と思う使い方を想像し、それにあわせた構成でER図を描けばおｋ。
あとはログフォーマットの各項目をそれぞれ配置する、と。
ついでに｢こういうことするならこんなデータも無きゃいけませんよね｣ってな要素を付け加えて提案してみるのも良いのではないかしらん。
例えば、IPアドレスのブラックリストを準備して、ログテーブルとIPアドレスをキーにジョインして｢ブラックリストのIPからのアクセスだ｣とわかるような仕組みを入れてみるとか。
- 164 ：NAME IS NULL：2009/04/30(木) 02:27:37 ID:???.net
- もし、運用目的の話ではなく、純粋に情報の構成をER図であらわせ、って話をしているのなら、大雑把に言うと
・IPアドレス
・ユーザ
・アクセス日時
・発行メソッド(参照URL)
・ステータス
・他もろもろ
がどういった関連を持っているか書け、と言う事なのでしょうね。
例えば、URLを中心において
・そのURLに紐づくユーザ
・そのURLに紐づくIPアドレス(アクセス元IPアドレス)
・そのURLに紐づくアクセス日時
といった要素の関連を書き表すとか。
学校の宿題なのか、新入社員さんの研修課題なのかわからないけど、まぁがんばって。
- 165 ：NAME IS NULL：2009/05/01(金) 07:02:14 ID:???.net
- 課題だとしても実用的じゃなさすぎる。
出したやつは馬鹿だなｗ
- 166 ：NAME IS NULL：2009/05/02(土) 16:13:53 ID:???.net
- そうか？
結構こういう汎用ログからのデータ収集って実社会で役に立つと思うが。
注目してる香具師が極端に少ないだけで。
普通にアクセスログ表示ソフトがどんな項目で分析してるか調べるといいと思う。
http://pc11.2ch.net/test/read.cgi/db/1232457109/
「ビジネス」BIツール「インテリジェンス」
http://pc11.2ch.net/test/read.cgi/hp/1218494105/
【アクセス解析】Google Analytics 5
http://pc11.2ch.net/test/read.cgi/hp/1098282501/
詳細なアクセス解析をしたい！！！
http://pc11.2ch.net/test/read.cgi/php/996937818/
Analogスレ
http://pc12.2ch.net/test/read.cgi/unix/1014402672/
統合監視ツールどうよ?
http://pc11.2ch.net/test/read.cgi/linux/1150732249/
GNU/Linux とネットワーク/セキュリティ
あと、IT監査とかで結構需要は多い。一般ソフト並みとはいかないけど。
- 167 ：NAME IS NULL：2009/05/02(土) 17:29:02 ID:???.net
- >>166
よく読め。ログをERで表せって話だ。
- 168 ：素人：2009/05/11(月) 00:45:40 ID:???.net
- すみません。オッケーウェブで質問して、回答ももらったのですが、回答が１件だけだったので
もう少し他の意見も参考にしたいと思ってこっちに来ました。オッケーウェブの方はもう締め切って
あるので、マルチだと言わずに聞いて欲しいです
僕が質問したトピックはこちら
ttp://okwave.jp/qa4946216.html
ＥＲ図が削除されていたのでもう一度アップしました
ttp://kansai2channeler.hp.infoseek.co.jp/cgi-bin/joyful/img/9156.zip
確かに回答の通りこの場合はok_ngで検索すればいいだけなので冗長だと思いました。
そうすると、この１対１の関係が成り立つのはどのような場合でしょうか？
使い分け方とメリットデメリットあたりが聞きたいです。
それと、１対１のテーブルは、たまたまマイレージプログラムと乗客のテーブルで見たのですが、
それは「特殊」なパターンなのでしょうか？それとも一般的なものでしょうか？
そのあたりも教えて下さい。
- 169 ：NAME IS NULL：2009/05/11(月) 05:28:05 ID:???.net
-
｢こういう理由でこの１対１の関係を作ったのだけど、どういった問題があるか指摘して欲しい｣
のような話でないと、なんともいえないです。
｢合格者テーブル｣を作った理由ですね。その理由からメリットデメリットが導かれてくるんじゃないかなぁと。
訳もわからず、理由も無く、なんとなく作ったのなら、それは意味が無いし先の回答者の様な返事になるだけですよ。
※自身で「冗長だ」と思うならそういう設計をしなければ良いわけで....何故悩むのかと。
もし本を読んで見つけたのならそのデータ構造を作る理由を読み直して理解した方が良いです。
※あと、「そうすると、この１対１の関係が成り立つのはどのような場合でしょうか？」も
ちょっと意味が判りかねます
- 170 ：NAME IS NULL：2009/05/11(月) 08:54:15 ID:???.net
- なんでマルチが嫌われるのかと言えばだな、回答した香具師に失礼だからさ。
okで回答した香具師に失礼と思わない訳？
にちゃんで回答した香具師にも失礼な行動は予想出来るよな。
にちゃんで回答してもらったが、納得出来ないので教えて欲しいと他所でまた訊くのだろ？
- 171 ：素人：2009/05/11(月) 09:31:11 ID:???.net
- 大変失礼しました。
- 172 ：NAME IS NULL：2009/05/25(月) 05:26:51 ID:???.net
- 結局、 >>161 も>>168 も音沙汰無しなんだな。
後日談とかちょっとだけ楽しみにしてた私はマヌケだった。ﾊｽﾞｶｼ.....
- 173 ：NAME IS NULL：2009/05/26(火) 07:16:07 ID:???.net
- 今にちゃんでの回答に納得出来なくて、他所で訊いてる所だろ。
- 174 ：NAME IS NULL：2009/06/18(木) 01:33:24 ID:???.net
- えーと、初めてのオラクル案件でマスタテーブルを
UNIONで結合したような統合テーブルが設計されていたのだが
オラクルが特別なのか、案件が特別なのかどっちらでしょうか。
- 175 ：NAME IS NULL：2009/06/18(木) 21:46:40 ID:???.net
- 統合テーブルってなに？
viewのこと？
- 176 ：174：2009/06/18(木) 23:37:09 ID:???.net
- すまん、それは漏れが感じたテーブルのイメージ名。
view ではなく Table です。項目を大雑把に書くと
テーブル名,詳細キー,値1,値2,テキスト1,テキスト2,日付1,日付2,備考,etc…
値の例）
部門,1,null,null,営業,null,null,null,テキスト1:部門名,etc･･･
消費税,1,5,null,null,null,null,null,値1:消費税率×100,etc･･･
- 177 ：NAME IS NULL：2009/06/19(金) 00:47:06 ID:???.net
- 特別だからってどうなるの？ 指定なら対応するしか選択肢無いと思うが。
- 178 ：NAME IS NULL：2009/06/19(金) 01:05:15 ID:???.net
- >>174
オラクルに限ったやり方ではないし
特別ってほど奇異でもない
ただ例としている部門と消費税を一緒にするのはエスカレートしすぎって感じ
- 179 ：NAME IS NULL：2009/06/19(金) 03:25:51 ID:???.net
- 単にテーブルだけ出してきて、それが特別かどうか聞かれてもな
もしかしたらものすごく特別な使い方してる可能性もあるし、
結構見られるようなものかもしれない
汎用的なマスタとして使ってるのかもしれない、リポジトリのような使い方かもしれない
が、使ってるDBMSだ何だろうと、そのテーブルがそのままの形なら
設計やり直してくれとお願いするな、俺ならｗ
- 180 ：NAME IS NULL：2009/06/19(金) 06:01:10 ID:???.net
- 消費税なんて変わりそうなものは別に分けたいね。
まあその時の担当じゃなければどうでもｗｗｗ
コボルベースの設計とかを引き継ぐ理由とか有るのでは？
- 181 ：174：2009/06/19(金) 21:37:46 ID:???.net
- >>178
オラクルだからって事ではないんですね。
>>179
リポジトリではないですね。
汎用的なマスタなんだろうけど汎用性が高すぎる。
次のプロジェクトから設計やり直しをお願いしてみるよw
>>180
なるほどコボルベースの設計か、
設計者が実績あると言っていたから伝統なんだろうな
ASP.net2008で開発してDBが伝統か
- 182 ：NAME IS NULL：2009/06/19(金) 22:07:28 ID:???.net
- 中身のない実績なんだろうな。
- 183 ：NAME IS NULL：2009/06/20(土) 08:47:31 ID:???.net
- 昔コボルでの実績だろう。
- 184 ：NAME IS NULL：2009/06/20(土) 10:17:54 ID:???.net
- しかしその何がどう問題なのか、正しく指摘できる者はいないのであった。
- 185 ：NAME IS NULL：2009/06/21(日) 08:51:28 ID:???.net
- コボルにも対応出来るのが普通だしな。
ちゃんとコストとか実行速度のデータ示せないと検討も出来ない。
- 186 ：NAME IS NULL：2009/06/22(月) 21:30:17 ID:???.net
- >>184-185
釣れますか？
- 187 ：NAME IS NULL：2009/06/22(月) 23:32:51 ID:???.net
- 3日粘ってようやく一匹。
- 188 ：NAME IS NULL：2009/06/24(水) 00:24:45 ID:???.net
- すいません、正規化を俺が望まなければちょっとの修正ですんだものを、
DB構造もプログラムも大改修して多大なコストがかかりました
技術屋として間違ってはないと信じてる
でも経営としては間違ってるんだろうな、きっと
- 189 ：NAME IS NULL：2009/06/24(水) 06:53:19 ID:???.net
- >>188
将来のデータ不整合、障害発生のリスクと
目先のコスト、どっちが大事かな。
まぁ、派遣切りのご時世だもんな。
- 190 ：NAME IS NULL：2009/06/24(水) 09:00:48 ID:???.net
- 金がかかったそもそもの原因は正規化のせいじゃなくて
元々の設計がダメだったせいってなんで気がつかないの
- 191 ：NAME IS NULL：2009/06/24(水) 16:12:25 ID:???.net
- 表層に現れるのは「修正にコストかかった」ってことだけだからな
お偉いさんには「こんな簡単なことに時間かけて何やってんだアイツは」としか映らない
技術者をないがしろにしてきた代償だよ
- 192 ：NAME IS NULL：2009/06/24(水) 19:12:46 ID:???.net
- >>188
もともと正規化してなかったので、そのちょっとの修正の「ついでに」
正規化した、というのであれば、そのコストは、ついでの作業に伴い発生したコスト
技術屋って言い方すればコスト意識を無視できるわけではないと思うがな
ｘｘ屋さんってのは、ｘｘを売るから屋なわけで
コスト関係なく技術的に最善最上な状態でないと気に食わないというのであれば
それは技術原理主義者とｗ
コストとのバランスをとれるから技術者じゃなくて技術屋なんだと
- 193 ：NAME IS NULL：2009/06/24(水) 19:32:12 ID:???.net
- しかし、コスト至上を理由に次々とパッチワークしていったシステムはひじょうに脆く、改定に対する耐性が格段に低くなる。
全てを「自分の好みに修正」したいってんなら、お前なにやってるんだの世界だけど。
後まで見据えての決断であれば技術者の良心だろ。
姉歯はいかんよ、姉歯は。
- 194 ：NAME IS NULL：2009/06/25(木) 00:20:29 ID:???.net
- 元々の設計のままでのコストの発生具合による。
好みや良心の技術第一主義で通しても、理解してくれる客は少ない。
でも自分のアピールや努力が足りずに、姉派みたいな弱い立場に陥るのは技術第一主義者には多いと思うよ。
漏れは設計しか遣らないとか逝っても、設計外の人間に理解してもらえる事は少ない。その積み重ねがどんどん立場を弱くして、設計だけしか頼まれない弱い立場で責任だけ押し付けられる事に成る。
設計に金を出してくれる客と良い関係を築けての商売。
- 195 ：NAME IS NULL：2009/06/25(木) 04:53:37 ID:???.net
- >>193
その、しかしってのは>>192を受けていってるのか？
技術屋ならバランスとれっていってるのに
コストのために犯罪犯すような話といっしょにするなよ
>>194
すくなくとも今のソフトウェア産業において、設計だけでは
ビジネスとして成り立たないと思うがな
本来客は、設計に金をだすんじゃなくて、プログラムやシステム全体に金をだすわけで
その中の設計に配分される割合が低すぎる＝設計が軽視されている
それは客の理解の問題じゃなくて、売り側が過当競争によって
目に見えにくいコストから削ってるからじゃないかと思うが
- 196 ：NAME IS NULL：2009/06/25(木) 06:13:48 ID:???.net
- だから設計でちゃんとコストが変わる事を設計担当がアピールするのが大事。
何もしないから、配分の割合減らされて、コスト削られてるのだよ。
- 197 ：NAME IS NULL：2009/06/27(土) 01:37:32 ID:???.net
- >>196
これって客先に説明しておしまい。ってならいいけど
無知な上級SEが良いところ見せようとして・・・説得したあとから
平気で台無しになるようなことをしてきて、あとよろしくって♪って感じの多いわな
- 198 ：NAME IS NULL：2009/06/27(土) 07:52:04 ID:???.net
- 上級SEぐらいおさえられないでどうする
身内の敵はもっと上だぞ
マネージャーやら社長やら・・・
- 199 ：NAME IS NULL：2009/06/27(土) 08:56:32 ID:???.net
- 常に人減らせないか、安い人材に出来ないか考えてるからね。
そういう人たちにも、ちゃんとした設計がコストに影響する事を示せないと負け。
- 200 ：NAME IS NULL：2009/06/27(土) 21:04:36 ID:???.net
- 逆に考えて、
設計がコストに影響することを理解できないような人たちが、
マネージャやら、〇〇長やらを
やってることが問題なんじゃない？
で、この問題をどう解決するか、なんだか。
- 201 ：NAME IS NULL：2009/06/28(日) 00:47:26 ID:???.net
- 日本で仕事をしない。
これ最強。
- 202 ：NAME IS NULL：2009/06/28(日) 02:52:03 ID:???.net
- 理解しなくても、会社の資本金を出してたり、出資者から任命されてたりするから権限持ってる。
文句有るなら自分の資金で設計遣ってれば良い。
- 203 ：NAME IS NULL：2009/07/27(月) 20:54:41 ID:???.net
- どんなまずい設計のシステムでも、
実際に運用されていて問題のないものはあまりいじらないものだよ。
- 204 ：NAME IS NULL：2009/07/28(火) 06:21:49 ID:???.net
- まずさ加減に寄るな。
致命的なのや、将来的に問題になりそうなのは苦労してでも弄らないと後で困るよ。
弄らないまでも、報告だけはしてシステム関係者の中で共通認識は築いておくべき。
後で、問題が起きてからDB担当の個人の責任にされたほうが割喰うよ。
- 205 ：NAME IS NULL：2009/07/28(火) 21:02:53 ID:???.net
- もちろん問題点の把握はしておかなければいけない。
あと、問題が発生して誤動作したときのリカバリーの手順とかもマニュアル化しておく。
- 206 ：NAME IS NULL：2009/07/29(水) 03:38:45 ID:???.net
- 誤動作する時点て致命的じゃないのかなあ。
データ失うよね？
- 207 ：NAME IS NULL：2009/07/29(水) 14:16:26 ID:???.net
- >>203=205は
もっともらしい事言いたいだけの
他の板に居場所がない老害コボラー
- 208 ：NAME IS NULL：2009/08/10(月) 19:46:20 ID:fUpv0ZNe.net
- >>206 完璧主義者の集まりが作ったシステムなら あっさりデータなくなるだろうけど
多少の開発経験がある人が居れば DB経験がなくても バックアップや履歴、ログは残るはずだよ
スムーズに復旧できるかどうかは別の問題だが…
- 209 ：NAME IS NULL：2009/08/22(土) 00:12:51 ID:/H1vAtQw.net
- むやみに正規化できないケースはいくつもあるぞ。
顧客コードとそれに対応する顧客名称などがテーブルにあっても、
実はマスタ化するまでもない一見の顧客の場合、特定のコードを使って、
顧客名称のみ画面から入力したいという与件があったりするケース。
ＥＤＩで顧客からマスタと依頼データをもらっていて、
依頼データをもらった時点のマスタの値を依頼データに付加して保持しないと
いけないケース。
複雑な料金計算の設定マスタなど、既存のデータと処理をそのまま移行する
必要があって、下手にデータの持ち方を変えてしまうと、
明確に仕様化されていない部分の動作が保障できなくなってしまうケースなど。
- 210 ：NAME IS NULL：2009/08/22(土) 02:06:14 ID:???.net
- >>209
>顧客コードとそれに対応する顧客名称などがテーブルにあっても、
>実はマスタ化するまでもない一見の顧客の場合、特定のコードを使って、
>顧客名称のみ画面から入力したいという与件があったりするケース。
>ＥＤＩで顧客からマスタと依頼データをもらっていて、
>依頼データをもらった時点のマスタの値を依頼データに付加して保持しないと
>いけないケース。
これは別に全然問題ない
「顧客名称のみの登録もできる」
「依頼データをもらった時点の値を保持する」
という仕様のもとに設計して正規化すればいいだけの話
>複雑な料金計算の設定マスタなど、既存のデータと処理をそのまま移行する
>必要があって、下手にデータの持ち方を変えてしまうと、
>明確に仕様化されていない部分の動作が保障できなくなってしまうケースなど。
これはありがちな話で、実際妥協してしまうことも多いんだけど
そもそも「明確に仕様化されていない部分」があることが問題なわけで
正規化できない理由にはしてほしくない
- 211 ：NAME IS NULL：2009/08/22(土) 03:20:06 ID:???.net
- その辺は正規化してちゃんと効果有るの？
正規化したいだけの自己満足程度？
- 212 ：NAME IS NULL：2009/08/22(土) 04:39:23 ID:???.net
- >>211
正規化することに理由を求められてもな・・
逆に「正規化しないこと」にこそ理由が必要だと思うんだが
逆に質問していい？
「君の会社の開発標準において、論理データモデルを
作成するという工程はないの？」
- 213 ：NAME IS NULL：2009/08/22(土) 06:57:35 ID:???.net
- あるわけがない。
- 214 ：NAME IS NULL：2009/08/22(土) 15:07:29 ID:???.net
- 最近、クラウド絡みで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なんて見たくもない。バグの原因＆パフォーマンス劣化の原因になりやすい。
もちろん、全てのケースでこの形でうまくいくとは思えないが多くの部分はこの型におさめられるのではなかろうか。そうすれば余計な頭を使わなくて済む箇所が一つ減る。
今でも一部はそういう作りはあるけど（汎用マスタ等）、それを可能な限り全てのテーブルでやる。（究極的にはテーブルは一つで全レコードがそのテーブルの中。レコードを区別する為のコードがさらに必要にはなるけど）
- 215 ：NAME IS NULL：2009/08/22(土) 15:16:00 ID:???.net
- RDBすてろよｗ
- 216 ：NAME IS NULL：2009/08/22(土) 18:01:32 ID:???.net
- >>214
>・SQLがきわめて単純になる。
>・DB構造に頭を悩ませる必要がなくなる。
ちゃんとしたDB設計もできない設計者、SQLもかけないようなプログラマにとってはメリットかもしれんがな
>・スケールアウトしやすい。
クラウドに適した形式だから、莫大なデータ量で通常ではハンドリングできなくて
クラウドにするってならわかるが、クラウド考慮しないなら関係ないんじゃない？
>複雑なSQLなんて見たくもない。バグの原因＆パフォーマンス劣化の原因になりやすい。
すくなくとも複雑なSQLがパフォーマンス劣化の原因ではなく、（SQLにより実行される）複雑な処理が原因なわけで
>・今まで1つのSQLで取得できてたものが複数回のSQLになる。
>・今まで1行で帰ってきたものが複数行になるのでコードでループでまわしてレコードを組み立てる必要がある。
ような状況で、パフォーマンス劣化は避けられるどころか余計悪くなると思うがな
>多くの部分はこの型におさめられるのではなかろうか。そうすれば余計な頭を使わなくて済む箇所が一つ減る。
頭使わなくて済む個所が減ったらダメだろｗ
いままでSQL書いただけでやってくれてたことを、全部自前で実装するんだぞ？
プログラムしないといけないことも増えるし、頭使うとこも増えると思うがな
>今でも一部はそういう作りはあるけど（汎用マスタ等）、それを可能な限り全てのテーブルでやる。（
いまのRDBMSでも、やろうと思えばそういう風にできるわけだ
でも普通はみんなそんなことはやらない。それが答えだと思うがな
メリットデメリットってのは、何に対してなのかはっきりさせてから評価してくれないか
このままだと頭使わない奴にとってメリットがあるって結論になるなｗ
- 217 ：NAME IS NULL：2009/08/22(土) 18:50:31 ID:???.net
- >>216
>クラウドに適した形式だから、莫大なデータ量で通常ではハンドリングできなくて
>クラウドにするってならわかるが、クラウド考慮しないなら関係ないんじゃない？
最初は考慮してなかったが後からやっぱ必要だった！（見積もりが甘い？）って時にはメリットになると思います。
>ような状況で、パフォーマンス劣化は避けられるどころか余計悪くなると思うがな
SQLだとちょっと書き方変えるだけで10倍、100倍もパフォーマンスが違う事ってありますよね。みんながみんなSQLのエキスパートであれば問題ないのですが。それに比べればましかなと思ってます。もちろん処理内容によりますが。
>頭使わなくて済む個所が減ったらダメだろｗ
”余計な頭を使う箇所が減る”の間違いでした。
>メリットデメリットってのは、何に対してなのかはっきりさせてから評価してくれないか
メリット、デメリットは一般的なテーブル構造（先の例での前者）に対する、KVS的なテーブル構造のメリット、デメリットです。
>このままだと頭使わない奴にとってメリットがあるって結論になるなｗ
おっしゃるとおりで、このスレッドの趣旨には反しますがこれが一番のメリットと思います。頭を使う必要が少なければ、設計する人によって品質がバラバラという可能性が減るのではないのでしょうか（こういう構造で業務を満たせるのであれば）。
職人頼りなシステム開発が工業製品へと一歩前に進めるような気がします。
- 218 ：NAME IS NULL：2009/08/22(土) 19:11:02 ID:???.net
- >>214
こんなことしなくても
みんなお前ほど頭悪くないから大丈夫だよ
- 219 ：NAME IS NULL：2009/08/22(土) 21:45:36 ID:QZMSHBrB.net
- 開発効率が３０年前に逆戻りすることだけは確実だな…
- 220 ：NAME IS NULL：2009/08/22(土) 22:12:18 ID:???.net
- 馬鹿でも扱えるようにしたら色んなところで問題が出るってなぜわからんのだ。
カスレベルの人材でも働けるのは業界にとって大きなマイナスだ。
- 221 ：NAME IS NULL：2009/08/22(土) 22:19:41 ID:???.net
- >>217
>職人頼りなシステム開発が工業製品へと一歩前に進めるような気がします。
逆だ。DBでやらない分アプリでやることが増えて、
プログラマの腕頼みになるだけだ
みんなが言ってるとおり、時代に逆行しているよ
- 222 ：NAME IS NULL：2009/08/23(日) 00:47:33 ID:???.net
- カスは時給安くても働くから、時給高い熟練は不要になるしな。熟練にしか出来ない正規化とかの無駄な仕事が必要ｗｗｗ
単にDB使いこなせないからアプリでがんばるよ的発想だよな。
SQLを使ってたほうが遥かにパフォーマンスが良い現実。
これまでの歴史で今の状況に成ってるのを理解しないと。
オブジェクト廚が、オブジェクトDBなら便利になるぜとかのたまってたけど遅くて結局は消えてるし。
また馬鹿が湧いて、無駄な事を繰り返すのかな。
- 223 ：216：2009/08/23(日) 01:05:42 ID:???.net
- >>217
>最初は考慮してなかったが後からやっぱ必要だった！（見積もりが甘い？）って時にはメリット
クラウドにしやすい、ゆえにスケールアウトしやすいメリットがあるっていうならわかるが
クラウド云々関係なしに ってのはお前の出した前提条件だが？
クラウドにしないでスケールアウトってんならデータ形式はあんまり関係ないだろ
あくまでクラウドに適してるのがメリットであって、スケールアウトは副次的な話だ
>SQLだとちょっと書き方変えるだけで10倍、100倍もパフォーマンスが違う事ってありますよね。
オプティマイザが入るSQL処理でさえ簡単にそれだけの差がでる。
自前アプリでその処理をやるわけだ
みんながみんなSQLのオプティマイザより賢くプログラム組めるのか？
>みんながみんなSQLのエキスパートであれば問題ないのですが。それに比べればましかなと思ってます。
みんながみんなプログラムのエキスパートであれば問題ないのですが。
それに比べれば(SQLの方がオプティマイザある分)ましかなと思ってます
>メリット、デメリットは一般的なテーブル構造（先の例での前者）に対する、KVS的なテーブル構造のメリット、デメリットです。
いやだからその２者をくらべたときに、誰にとってメリットデメリットだと？
ほんとに頭使わないシステム開発者にとってのメリットでいいのかよ
>品質がバラバラという可能性が減るのではないのでしょうか
減るかもしれんな。頭使わない安価粗悪な物によってまともな物が駆逐されてな
全体のレベルを下げるだけだ。品質低い方に統一してどうする
>職人頼りなシステム開発が工業製品へと
工芸品が工業製品になるためには、その職人の技が一般化されてることが必要なわけで
一部の人しかできないことを、だれにでもできる事だけで作ったとしてもそれは単なる粗悪品
一部の人しかできなかったことを、誰にでもできるようにしないと意味がない
そのために論理や技法があり、それを学んだり論議したりしてるんだよ
お前の主張は、
工業製品ならだれでも作れないとダメでしょ。
馬鹿にはシステム開発できないんで、システム開発は工業製品じゃないよね
ってことだ
- 224 ：NAME IS NULL：2009/08/23(日) 01:25:59 ID:???.net
- >>214袋叩きワロタw
- 225 ：NAME IS NULL：2009/08/23(日) 02:35:18 ID:???.net
- >>217
> みんながみんなSQLのエキスパートであれば問題ないのですが。
SQLのエキスパートはそんなにいらない。
もちろん、一見優秀そうなゴミでは何の役にも立たないが…。
- 226 ：NAME IS NULL：2009/08/23(日) 03:11:11 ID:???.net
- おっ！最近レス多いですねぇ。いいじゃないですか。
スレの趣旨に合っていれば、DB技術者の意見を気軽に言い合ってもいいんじゃない。
レスが一つ入ると反応する方が結構居そうなので。
それぞれ扱ってるシステムの規模や影響、会社の風土とが違うでしょうから、
一概に良いか悪いかは言えませんが。
- 227 ：NAME IS NULL：2009/08/23(日) 04:28:10 ID:???.net
- >>214
とりあえず、「KVS的な構造」といって後者はないだろう。
- 228 ：NAME IS NULL：2009/08/23(日) 07:11:42 ID:???.net
- >>214
COBOLやRPGの時代にそういうテーブル設計しているのありました。
今SQLで実装している業務を試しにCOBOLで実装してみたほうがいい。
まあ、あの時代はある種夢の時代だったな。
「おれ５０００ステップのプログラム作っちゃったぜ！」と
無駄に長いプログラムを作れば儲かった頃だし。
ちなみにSQLより速い処理が組めるRPGやCOBOLのプログラマなんて
ツチノコ並みの珍獣だと思うが。
- 229 ：NAME IS NULL：2009/08/23(日) 10:56:13 ID:???.net
- >>228
COBOLやRPGは知らないけど、「処理の速さ」という点では
プログラムでゴリゴリ書いたほうが良いこともある
DB側（リレーション、制約、ストアド、SQL）に機能を持たせる
一番のメリットはやはり保守性だろう
- 230 ：NAME IS NULL：2009/08/23(日) 13:45:30 ID:???.net
- サーバーでやるかクライアントでやるかの違いだろうね。>>214
メリット・デメリットは>>214の他に
メリット
自分で最適化できる。
デメリット
サーバー/クライアント間のデータ転送量が多くなる。（高速LANなら無視できる）
かな？
- 231 ：NAME IS NULL：2009/08/23(日) 14:32:06 ID:???.net
- >>229
ストアドの速さに勝てるの？ありえなくないか？
DBに機能をもたせると保守性は落ちるとおもうが。
- 232 ：NAME IS NULL：2009/08/23(日) 15:05:03 ID:???.net
- ストアドにしたからといっては飛躍的に高速になるわけではない。
- 233 ：NAME IS NULL：2009/08/23(日) 16:21:00 ID:???.net
- 処理の種類によるけど遅くなることはないだろｗ
- 234 ：NAME IS NULL：2009/08/23(日) 21:31:35 ID:???.net
- データをどこに持っているかにもよる
DBMSに格納されているなら、そのDBMSに特化したストアドより早く外部プログラムが
実行できるとは思えない。
ストアドでも外部プログラムでも、ロジックは同じように作れるわけだからな
保守性については、システムの保全とか改修のしやすさとか、
何を主眼として保守性とするかによって変わると思うが
- 235 ：NAME IS NULL：2009/08/23(日) 21:33:12 ID:???.net
- 遅いクエリーはストアドであっても遅い
- 236 ：229：2009/08/23(日) 21:54:10 ID:???.net
- >>234
「保守性」っていうのは、改修の効率の良さ、再利用性の高さ、
論理的整合性の保ちやすさなどをひっくるめた意味で書いた
曖昧な定義でごめんね
- 237 ：NAME IS NULL：2009/08/24(月) 00:12:00 ID:???.net
- >>235
だったら外部プログラムならなお一層遅いだろ？
論理性がまったくないようだけど本業のほうは大丈夫？
- 238 ：NAME IS NULL：2009/08/24(月) 04:53:27 ID:???.net
- 他のクラウドで処理したデータも拾ってこなきゃならんから遅いだろうね。
全クラウドが、光ファイバーで繋がってて、膨大なクエリ処理しても、遅延は最大でも数百ナノ秒だぜってわけじゃないだろうし。
- 239 ：NAME IS NULL：2009/08/24(月) 06:28:52 ID:???.net
- サーバーサイドの処理と限定して話をするけど
>COBOLやRPGは知らないけど、「処理の速さ」という点では
>プログラムでゴリゴリ書いたほうが良いこともある
SQLの実行エンジンの最適化処理でブロックI/Oやらをやられると
プログラムで１行FETCHや1行WRITEしている
これらの言語は太刀打ちできないワケだが。
そりゃ、OSのAPIを直打ちするレベルになれば別だけどな…。
今時のRDBMSは統計情報を元にSQLの実行プランを最適化するが、
一般プログラマにコレを越えるプログラム組めって言っても
かなり辛い。
むろんプログラマが書いた方が良いこともあるだろう。
どんな例か知らんけど。
- 240 ：NAME IS NULL：2009/08/24(月) 17:29:10 ID:???.net
- なんかストアドよりインデックスが速いよスレの二番煎じな流れだな。
詭弁のガイドライン
2.ごくまれな反例をとりあげる
「だが、RDBよりプログラマが書いた方が良いこともある」
15.新しい概念が全て正しいのだとミスリードする
「クラウドで使われているKVSを使わぬ限りシステム構築に明日はない」
- 241 ：NAME IS NULL：2009/08/24(月) 21:15:01 ID:???.net
- >>239
> 今時のRDBMSは統計情報を元にSQLの実行プランを最適化するが、
> 一般プログラマにコレを越えるプログラム組めって言っても
> かなり辛い。
腐るほどあるよ。
- 242 ：NAME IS NULL：2009/08/24(月) 22:02:49 ID:???.net
- >>241
腐ったSQLを平気で書くプログラマのプログラムを想像した。
北へと旅に出たくなった・・・
- 243 ：NAME IS NULL：2009/08/24(月) 22:27:07 ID:???.net
- >>241
腐るほどある。と言われても、AS/400みたいなマシンで無い限りSQLと他の言語の
速度比較とかは出来んはずだが、AS/400なんざ普及していないだろ。
RDBMSでSQL使うよりもC++でコレクションクラスを使った方が速いよ、なんて
議論無意味だしな。
- 244 ：NAME IS NULL：2009/08/24(月) 23:03:22 ID:???.net
- ちょっと議論の的がズレていってない？
>>214は、処理の速さについては
メリットとしてもデメリットとしても挙げてないんだし
問題の本質はそこじゃなくない？
- 245 ：NAME IS NULL：2009/08/25(火) 00:03:36 ID:???.net
- 単に屑PGが適当に組んでも速度が出ないと困るってか？
SQL覚えるのが一番の近道。
- 246 ：NAME IS NULL：2009/08/25(火) 02:06:15 ID:???.net
- >>244
問題の本質とは?
確かに、214さんが処理の速さについては
言及しておられないようです。
ただ、私見ですが214さんがSQLを良く
理解しておられないのは感じます。
開発側とすれば画面に表示する情報を
1SQLで取得できるように設計するべきで、
その方が楽だと思いますがね。
遅かったら運用のせいにも出来るしね。
>>242
まぁ、そんなこと言わないで、がんばって行きましょ。
分かるけどね…
- 247 ：NAME IS NULL：2009/08/25(火) 02:50:49 ID:???.net
- >>246
クエリの知識しかないアプリ屋のくせに
えらく上から目線だなオイ
- 248 ：NAME IS NULL：2009/08/25(火) 03:07:51 ID:???.net
- >>247
いえいえ、とんでもない。
そんなお褒めの言葉、
こちらこそありがとうございます。
- 249 ：NAME IS NULL：2009/08/25(火) 04:14:41 ID:???.net
- 単に複雑なSQL組めない屑PGだろ。
select *だけで全部済む様にしたいとか言いそうだし。
まるでオープン系コボラｗｗｗ
- 250 ：NAME IS NULL：2009/08/25(火) 07:07:25 ID:???.net
- >>246
情報を1SQLでとれないってのは、どっちが？
- 251 ：NAME IS NULL：2009/08/25(火) 09:54:39 ID:/mfME5w3.net
- まだまだＤＢのオプティマイザはアホだから、実行プランやトータルコスト考えながらクエリやＰＧ書けない奴はダメだな。
下請けソフトハウスのアプリ屋なんてそんな奴ばっか…
何のためにキーやインデックスがあるのかちょっとは考えてくれよ
- 252 ：NAME IS NULL：2009/08/25(火) 10:08:13 ID:???.net
- >>249
複雑なSQLはそれ自体のメンテが大変かもね。アクセスパスは不変じゃないし
無理矢理SQLに詰め込まれても、常に効率が良いとは限らない。
要はバランスだと思う。ちょっと頑張ればSQLのみで済むからSQLに詰め込もうとか、
どうせUAPで処理必要なんだから、SQLでは無理せずにUAP側にロジック入れようとか
いろいろ状況もあるだろうし、適材適所で臨機応変に使って行きゃ良い。
まぁ同一システム内でばらばらだと困るので、ある程度の取り決めは必須だが。
ところで、組み込みSQLで select * 使う人はいないはずだけど…。
さすがにそんな人にはコード書かせないでしょ。
- 253 ：NAME IS NULL：2009/08/25(火) 14:02:27 ID:???.net
- >>252
>ところで、組み込みSQLで select * 使う人はいないはずだけど…。
>適材適所で臨機応変に使って行きゃ良い。
- 254 ：NAME IS NULL：2009/08/26(水) 02:19:56 ID:???.net
- >>250
こんばんは。246で発言した者です。
どちらかとの御質問ですが、どれとどれのことか分かりませんでした。
私が不出来なもので申し訳ございません。
先に私が発言した主旨としては以下の様になります。
開発側の人としては画面に表示するデータが1SQLで(select * は論外ですが)、
もちろんジョイン、必要であればサブクエリーを使用し取得したデータ群を、
使用する言語によったデータセットで使った方が楽なのではないかと思った次第です。
(それぞれの環境次第なので一概に言えないのは分かっております。)
214さんはそれぞれ必要な都度SQLを発行し、表示するデータを構築される
ように思われたので上記の様な発言を致しました。
ただ、214さんがデメリットでそのことを挙げておられることを見過ごしておりました。
申し訳ございません。
先に私が発言しました「214さんがSQLを～]の発言は撤回させてください。
その後の「遅かったら運用の～」は私の過去に受けた経験から発言したものです。
開発より、運用に従事している期間が長いものですから。
>>247
お気を悪くされましたらお詫びいたします。
- 255 ：NAME IS NULL：2009/08/26(水) 07:13:53 ID:???.net
- 遅いのは開発側、というよりDB設計者のせいだよ。
- 256 ：NAME IS NULL：2009/08/26(水) 15:34:09 ID:???.net
- >>254
そもそもの発端はKVS的な設計はどうだろうって論題で、
KVS的な設計では１SQLでデータ取るのは不可能だって話だ
それを前提にしてるから
>214さんはそれぞれ必要な都度SQLを発行し、表示するデータを構築される
ようになってるわけで
１SQLでデータ取れるような設計しろってのは、議論の前提がおかしいだろうが
>>255
その言い方だとDB設計者は開発側の人間じゃないように聞こえるが
- 257 ：NAME IS NULL：2009/08/26(水) 16:03:01 ID:???.net
- >>214は、この設計を既存のRDBに割り当てて使うって言ってんのかな。
それなら駄目すぎて話しにならんと思うが。
- 258 ：NAME IS NULL：2009/08/27(木) 00:00:34 ID:???.net
- そもそも「KVS的」といって>>214みたいなのが出てくるのがおかしいし、
あれが1SQLでデータが取得できないというのも変。
いったいオマエラ何の議論をしているの？
- 259 ：NAME IS NULL：2009/08/27(木) 00:27:25 ID:???.net
- もう>>252がベストアンサーって事で良くね？
- 260 ：NAME IS NULL：2009/08/27(木) 07:01:17 ID:???.net
- >>259
自演乙
- 261 ：NAME IS NULL：2009/08/29(土) 00:37:35 ID:???.net
- 具体的に1sqlってどこまで許すのか示されてないしな。
まあdb知らない人みたいだから無茶言いそうだが。
- 262 ：NAME IS NULL：2009/09/10(木) 16:45:52 ID:???.net
- こちらの方がおっしゃっている設計指針についてどう思われるでしょうか。
http://masuda220.jugem.jp/?cid=11
・テーブルの役割・用途は一つ
・（極力？）データに対する更新・削除は行わない
など
なるほどとも思うのですが、役割に応じて分割すると
あまりに細かく分割しすぎて見通しが悪くなりそうな気もしますし、
データの更新・削除を認めないのは冗長かつ非効率な気もします。
実務による、というお答えが返ってきそうですが、一般的な設計指針として
ご意見をお聞かせいただければ幸いです。
- 263 ：NAME IS NULL：2009/09/10(木) 23:30:01 ID:???.net
- >>262
モデリングの手法としては合ってると思う
ただこの後の工程で、パフォーマンスや効率性を考慮して
冗長化、非正規化することは必要だけど
>あまりに細かく分割しすぎて見通しが悪くなりそうな気もしますし、
モデル上は、細かくテーブル分割してあるほうが分かりやすいよ
テーブル名とリレーション見るだけで何を表しているか分かるからね
>データの更新・削除を認めないのは冗長かつ非効率な気もします。
「データの更新・削除を認めない」って書いてあるところが見つけられなかったんだけど、
どこから引用したの？
- 264 ：262：2009/09/11(金) 06:59:45 ID:???.net
- >>263
レスありがとうございます。
書籍などではここまで言及してあるものを読んだことがなかったので、
どうなんだろうと思っていたのですが、正しい手法なのですね。
（「正しい」という表現が適切かわかりませんが）
> 「データの更新・削除を認めない」って書いてあるところが見つけられなかったんだけど、
> どこから引用したの？
これは少しコメントを端折り過ぎました。
「テーブル設計 データモデリングのエッセンス（２）」などに書かれているのですが
> ビジネスイベントは一度作成（インサート）したら、後から、更新や削除はしない。
> このテーブルに許される操作は、インサートと参照のみにする。
とあります。
また、ビジネスリソース系のテーブルについても同様の方法を取ることもあると書かれています。
ここに書かれている業務システムの例に合わせて言えば、
受注テーブルは最新の状態にしておき、更新や削除の記録が必要ならば別テーブルにログとして保持する。
受注テーブルにはキャンセルされた受注や変更前の受注は保持しない。
というのが主流だと自分は思っていました。
また、導出テーブルをトリガで作成するという手法も初めて知りました。
- 265 ：NAME IS NULL：2009/09/12(土) 11:16:27 ID:???.net
- >>1
1. Excelのワークシートと勘違いしてるから。
2. 設計＆指揮者がコードに関心があるのにデータに関心がないから。
レベル低すぎ？
- 266 ：NAME IS NULL：2009/09/12(土) 11:25:44 ID:???.net
- むしろコボラ上がりが、繰り返し項目を使いたくって、
正規化なんか理想論だ、実際は性能が落ちる原因だとか
トンデモ説を信仰している（ふりをする）からじゃん
- 267 ：NAME IS NULL：2009/09/12(土) 11:35:27 ID:???.net
- コボラ上がり(かつRDBを知らん)奴なんて数えるほどだろ。
それよりも、RDBしか使ったことがなくても実はわかってない、ってのが
圧倒的じゃないか？>>265の言うexcelと勘違いしてるようなのとか。
- 268 ：NAME IS NULL：2009/09/12(土) 12:27:58 ID:???.net
- ファイル設計の延長くらいにしか考えてない奴は多いな
- 269 ：NAME IS NULL：2009/09/13(日) 03:40:03 ID:???.net
- コボルの本読むとそんな感じだしな。
正規化なんて全く記述無し。
- 270 ：NAME IS NULL：2009/09/13(日) 11:52:21 ID:???.net
- そりゃ正規化はRDBでしか必要ないからな！固定長レコードで正規化
してもテーブルの連結がめんどくさかったら意味ねえ！
- 271 ：NAME IS NULL：2009/09/13(日) 12:47:27 ID:???.net
- そういえば昔、上から全項目を固定長にしろとお達しがあって、嫌々やったら速度が上がった
（つーか、負荷テスト後もあんまり性能が落ちない）DBがあったなｗ
- 272 ：NAME IS NULL：2009/09/13(日) 13:25:37 ID:???.net
- その昔の経験って、今も成り立っているのかな？
そこが曖昧なまま薦められても困るのよね。
- 273 ：NAME IS NULL：2009/09/13(日) 16:04:54 ID:???.net
- 今は一般的にはtext型みたいなのが一番速い
長さチェックも空白詰めもしないから
ただしOracleだけは固定長が速い
- 274 ：NAME IS NULL：2009/09/13(日) 18:09:22 ID:???.net
- >>273
逆だろ。
Oracleには固定長の文字列型なんてないはず。
最小長と最大長が等しい可変長文字列を、便宜上固定長文字列型って騙ってるだけ。
まぁほとんどのDBMSで、列サイズが固定であるが故の速度的メリットは大きいから、
Oracleでも可変長文字列を入れていた項目を擬似固定長に変更した時の速度向上は
見込めるかもしれないって程度。
- 275 ：NAME IS NULL：2009/09/13(日) 18:15:13 ID:???.net
- > 固定長の文字列型なんてない
> 列サイズが固定であるが故の速度的メリットは大きい
矛盾してないか？ 最初の文は、内部的には可変長文字列の特殊設定だと
言っているような気がするんだが。
- 276 ：NAME IS NULL：2009/09/14(月) 04:23:37 ID:???.net
- CHAR型って固定長じゃないのか
- 277 ：NAME IS NULL：2009/09/14(月) 13:32:43 ID:???.net
- DB2も固定長の方が速いけど。
text型みたいなのはある程度まではそこそこ速いけど、
ある閾値を越えると急に遅くなったりするので
処理系しだいだろうとは思う。
つか、Oracleとかの「こうすると速い」系のネタは都市伝説が多いよなー。
商品コードとかの長さが決まっている項目なら固定長で、
備考の様な長さが不確定な部分は可変長と素直に設計していけばいいのでは？
「速いから固定長」とかはなんか違うだろ。
「考えるのが嫌だから全て可変長」の方がまだスジが通っている。ｗ
- 278 ：NAME IS NULL：2009/09/14(月) 14:32:30 ID:???.net
- >>275
Oracleは内部的には全部可変長扱いだって聞いたことがあるからそのことじゃね？
DB2とかだと内部的にCHAR型とVARCHAR型は別扱いなので、きちんと使い分けた
方が望ましいけど、Oracleはちょっと変態なのでムリにCHAR型にする必要はないと。
(全ての？)列サイズが固定で速くなるってのはまた別の話で、データの格納と言うか、
表領域の使われ方のことではないかと。まぁどっちかって言うと行サイズだが…。
HiRDBだとFIX表ってわざわざ宣言したりするね。
- 279 ：NAME IS NULL：2009/09/14(月) 17:34:21 ID:???.net
- オラクルは昔と今では、だいぶ違うけどな。昔の経験なんて引きずってたらそれこそコボラ状態。
- 280 ：NAME IS NULL：2009/09/14(月) 18:09:35 ID:???.net
- DB2とかは固定長・可変長は分けて処理するしNOT NULLな制約も考慮して
適切な設計にあわせて実スピードは上がっていく。
逆に設計がアレだとあんまし速度はでないRDBMSだな。
Oracleも昔の都市伝説と言うか、昔のヘンテコ小技を今のVerに持ち込むのは
ヤめてくれって感じるな。
普通に設計して普通にSQL書いてください。
- 281 ：NAME IS NULL：2009/09/15(火) 21:32:23 ID:???.net
- Oracleの仕様がヘンテコだからな
- 282 ：NAME IS NULL：2009/09/16(水) 10:24:42 ID:???.net
- 何でOracleはヘンテコな仕様なのに普及したんだろうね？
M$やらIBMやらが注力しなかったからかな？
- 283 ：NAME IS NULL：2009/09/16(水) 13:25:20 ID:???.net
- 当時は癖のある DB しかなかったよ
- 284 ：NAME IS NULL：2009/09/16(水) 17:52:21 ID:???.net
- おかげさまで今でもうっかり(+)とかやっちゃうぜ
- 285 ：NAME IS NULL：2009/09/16(水) 20:18:06 ID:???.net
- >>282
ごめんね、キミの大好きなOracleを馬鹿にしちゃってｗｗｗ
- 286 ：NAME IS NULL：2009/09/19(土) 02:03:14 ID:???.net
- 今日もアホなテーブルとクエリを見てゲンナリした
○○○○○は遅いねってお前の設計が（ry
- 287 ：NAME IS NULL：2009/09/19(土) 18:16:28 ID:???.net
- >>282
性能がいいものが売れるとは限らない。
大人の事情というのがあるんだよｗ
- 288 ：NAME IS NULL：2009/09/20(日) 07:47:11 ID:???.net
- まあそれほどまでに当時のSQL鯖/サイベースとDB2が糞だった訳で。
オラクルの出現で競争が生まれ、それらも今やかなりマシになった功績は大きい。
周りのヘンテコDB仕様に合わせて客取り込んでいって成長したから、今でも名残が残るのはしょうがない。だんだん洗練してヘンテコ仕様もろとも下位互換は切ってくだろうけど。
- 289 ：NAME IS NULL：2009/09/20(日) 08:40:22 ID:???.net
- そもそもまともに使えるRDBMSを最初に売り出したのがOracle。市場での競争が始まるのが
後発のInformix、Sybase、Ingres等が現れてから。DB2もあったけど、当時のIBMはIMSの
商売の方が重要でDB2はほとんど力を入れておらず、顧客がRDBMSを必要とする場合に
程度でSymfowareやHiRDBのような扱い。
MSのSQL Serverや、他社OSでも使えるDB2 UDB(の原型)が現れて現在のような競争状態に
なるのはそれよりもさらに後。
- 290 ：NAME IS NULL：2009/09/20(日) 11:46:31 ID:???.net
- 過去のことはいいから現在一番ましなRDBはなんなのさ。
- 291 ：NAME IS NULL：2009/09/20(日) 12:10:29 ID:???.net
- 今の製品はだいたいみんなまともだろ？あとはどのポイントを重視するか。
総合1位なんて点数のつけ方で変わるよ。
- 292 ：NAME IS NULL：2009/09/20(日) 12:13:25 ID:???.net
- 君の重視するポイントでよろしく頼むよ。
- 293 ：NAME IS NULL：2009/09/20(日) 12:17:20 ID:???.net
- 製品比較は別スレでやれ。
- 294 ：NAME IS NULL：2009/09/20(日) 12:23:38 ID:???.net
- >>292
じゃあSQLiteが一番だな。これで満足か？
- 295 ：NAME IS NULL：2009/09/20(日) 12:31:17 ID:???.net
- どのポイントを重要視したの？
- 296 ：NAME IS NULL：2009/09/20(日) 13:31:27 ID:???.net
- サポート契約してるとOracleって結構不具合とかあるんだなぁ、
って感じますが、他のRDBMSでもあるんですかね？
- 297 ：NAME IS NULL：2009/09/20(日) 21:30:20 ID:???.net
- DB2も不具合はある。
Oracleよりは少ないが、それだけDB2普及していない証明でもあるような希ガス。
別に不具合あってもいいんだけどさ、それの対応がタマに「我慢汁」とか「それはOSの不具合です」
とか解決に繋がらない回答を貰うと、「あー、Postgresでいいじゃん」とか思うな。
- 298 ：NAME IS NULL：2009/09/20(日) 23:21:46 ID:???.net
- DB2は、「なんでいまだにこんなバグが？」と思うようなのがけっこうあるね。
インスタンスダウン→「次のFPで修正されます」のコンボに何回遭遇したか。
- 299 ：NAME IS NULL：2009/09/21(月) 00:11:44 ID:???.net
- DB2ってiSeriesは鉄なみの硬さがあると思うが、それ以外のプラットフォームは・・・。
Oracleもよくインスタンス落ちるがiのDB2は落ちた事がない。
これもIBMの中の人とガチで仲良し(?)レベルで会話できる人が少ない性もあるんだろうな。
- 300 ：NAME IS NULL：2009/09/21(月) 12:39:41 ID:???.net
- 単にasはろくな処理してなくて使い込んでないから固く見えてるだけじゃ。
全部as内完結で、不安定になる様な秘穴を突けなくしてあるとも言うが。
オラは、いろいろ弄れる割に秘穴を突いてしまう確率が高くなるだけ。
ちゃんと組めばド安定で運用出来るよ。RACも組めるし。
ポスグレはサポート無いから、業務では選択肢に無いな。
マイエスはオラクルがサポートしてくれるなら、これから使う鴨田が。
- 301 ：NAME IS NULL：2009/09/21(月) 15:08:44 ID:???.net
- 結局なんだかんだ言いつつサポートの有無でプロダクトを選ぶという矛盾が
別にサポートあったって落ちたときに損害補償してくれるわけでもないんだし
金払うだけ無駄なのがサポートだぜ
パッチの提供なんて逆にPostgreSQLなんか速攻で修正されて出てくる
オープンソースだから原因も即バレで、仕様ですと隠される事もないしな
- 302 ：NAME IS NULL：2009/09/21(月) 15:42:44 ID:???.net
- 矛盾つーか、セルフサポートできるんならOSSも選べるってだけだろ。
一応サポート契約していれば、どんな障害/質問に対しても「マニュアル
読め」以上の何らかの回答を一定期間内にしてくれるし。
- 303 ：NAME IS NULL：2009/09/21(月) 16:42:14 ID:???.net
- んでその回答って役に立つのか？
PostgreSQLの構築/運用実績あるSIにやって貰った方が
Oracleに無駄に500万払い続けるよりマシな気がする
- 304 ：NAME IS NULL：2009/09/21(月) 17:14:32 ID:???.net
- おめーら別スレでやれよ
- 305 ：NAME IS NULL：2009/09/21(月) 17:54:54 ID:???.net
- >>303
サポート契約してれば何か起きたときの事故対策会議で「サポートに問い合わせ中です」
って言える。もちろんその後は「原因不明なので再現待ちです」って逃げる。
DBMSに限らず、商用OS等でも良くあるが…運用担当者が泣く黄金パターンだよな。
まぁ実際問題として、サポートにまともな回答もらえるとはだれも思ってないんだよ。
ただ、実質使えないサポートであっても、それを望んでいる客がいるのもまた事実だから、
そういう提案してしまうのはしょうがないと思う。
- 306 ：NAME IS NULL：2009/09/21(月) 18:55:49 ID:???.net
- >>303
そりゃ役に立つ人はいるだろうさ。
当然、Postgresでシステム構築したとしても、Postgresのサポートを
必要とする場合だってあるだろうし。
- 307 ：NAME IS NULL：2009/09/21(月) 23:09:15 ID:???.net
- ＞PostgreSQLの構築/運用実績あるSIにやって貰った方が
＞Oracleに無駄に500万払い続けるよりマシな気がする
ぶっちゃけその通りだけどな。
漏れの中ではOracleは言うほどマシなRDBMSじゃないと認識している。
Oracleが必要な業務があるのは事実だろうが、多くの導入例では
「Oracleはいらんだろ」的な納品されている現場は多い。
- 308 ：NAME IS NULL：2009/09/22(火) 09:05:44 ID:???.net
- しかしPostgresのシステム構築やサポートできるSIなんて
付き合いある範囲じゃ見当たらないな。
- 309 ：NAME IS NULL：2009/09/22(火) 11:04:07 ID:???.net
- オープンソースのDBすら自分で構築しようとしないエンジニアって・・
- 310 ：NAME IS NULL：2009/09/22(火) 11:39:52 ID:???.net
- それは「システムを自分で開発しないエンジニアって」と言っているに等しいぞ。
内製するかどうかとオープンソースかどうかなんてあんま関係ない。ただ、開発を
SIに任せる場合にOSSで受けてくれる業者がほとんどないというだけ。
- 311 ：NAME IS NULL：2009/09/22(火) 12:29:28 ID:???.net
- >>308
知り合いかどうか知らんがPostgresはNTTやらNEC系はやってるな。
別に漏れもヤれと言われれば並みのOracle程度には出来る。
つか漏れも社内のなんちゃってテスト環境用にはDreby使っている。
- 312 ：NAME IS NULL：2009/09/22(火) 12:56:37 ID:???.net
- まぁ会社としてサポートするとなると、スキルのある要員の継続確保が問題になるな。
俺的には別に特殊なスキルが必要とは思えないのだが、商用/フリーに関わらず
調査すら出来ない人間ってのが意外といるわけで。
- 313 ：NAME IS NULL：2009/09/22(火) 14:38:29 ID:???.net
- OSSは裾野の部分がまだ弱いからねぇ。研修制度とか、サードパーティの層の厚さとか。
Linuxは大メーカー自身が手がけるようになって大分よくなったけど。
- 314 ：NAME IS NULL：2009/09/22(火) 15:22:04 ID:???.net
- オープンソースのサポートなんて遣るくらいならオラクル保守入って丸投げのほうが楽だな。
オープンソースで手厚いサポートできるようなスキルある香具師雇うなら、オラクル以上に金かかりそうだw
オラクルに損害賠償請求する馬鹿企業は居ないが、個人に損害賠償してくる馬鹿企業は山ほど居るだろうし。
- 315 ：NAME IS NULL：2009/09/22(火) 20:15:18 ID:???.net
- >>314
凄い妄想だな。
底辺のオマエには知らん世界だろうが、Oracle使った案件でも契約書に
損害賠償跳ね除ける文面が契約事項としてあげてあるベンダーがほとんどだが。
- 316 ：NAME IS NULL：2009/09/23(水) 06:02:53 ID:???.net
- Postgresにサポートが無いとか、お前らシロート？
- 317 ：NAME IS NULL：2009/09/23(水) 09:08:19 ID:???.net
- 比率で言うならOracle信者ほど素人が多いのは不思議な現実。
サポートが心の拠り所らしい。
- 318 ：NAME IS NULL：2009/09/23(水) 11:28:58 ID:???.net
- ポスグレで自分で面倒見るのは自殺行為なんだよ。
- 319 ：NAME IS NULL：2009/09/23(水) 15:25:24 ID:???.net
- 別に「Oracleはインタンスが絶対に落ちなくてサポートが満足な製品で漏れは一度も苦労した事ない」
と言える製品ならそれはそれで構わんよ。
漏れはそんなOracle見た事ないが。年に１・２回はｲﾐﾌﾒｲに落ちる。
ただまあ、漏れの経験でｲﾐﾌﾒｲに落ちた場合サポートに問い合わせても「原因不明です。OSかハードに問題があると思われます」
の逃げ口上が出て終わりなんで、PostgresだろうとOracleだろうと能力のない人間が構築したシステムは
どれも自殺したくなる。
むしろ、上の発言で出てきた問題を全てIBMに投げられるiSeries、もしくはOSSだからと言う理由でPostgresを
選んだほうがラクになれる。
- 320 ：NAME IS NULL：2009/09/24(木) 07:36:57 ID:???.net
- データやSRAは独自パッケージまで出してるのに
- 321 ：NAME IS NULL：2009/09/25(金) 13:21:23 ID:???.net
- 設計
- 322 ：NAME IS NULL：2009/09/25(金) 16:04:56 ID:???.net
- 今までで一番酷かったのがLinuxの8iだな
2000万払った挙げ句、使用は自己責任でとか言われたｗ
- 323 ：NAME IS NULL：2009/09/26(土) 15:26:21 ID:???.net
- Linuxの8iって人柱Verだった頃のじゃね？
まあ、未だにそれで動いているトコはあるんだろうけど。
- 324 ：NAME IS NULL：2009/09/26(土) 20:34:26 ID:???.net
- 要するに人柱バージョンを2000万でうりつけてるのかｗ
- 325 ：NAME IS NULL：2009/09/26(土) 21:00:40 ID:???.net
- 値段は規模にもよるから、Linuxで8iで2000万が高いか安いか判断が難しいが。
HP-UXの8でもそれくらい取るベンダー見た事あるし。ただイニシャルはともかくランニングコストは
あんまし安くなかったが。年600万くらい。
Linuxの8iは自己責任と言うからにはランニングコストは０なんだろ。w
DB2(iSeries)だとイニシャルは下は300万で上は２億くらいの幅でランニングは100～600万くらい飛んでいく。
- 326 ：NAME IS NULL：2009/09/27(日) 03:34:04 ID:???.net
- 8iの頃はソラリスが鉄板だったので、リナックスなんて選んだほうが自殺行為なだけ。
東証がポスグレ採用なんて無謀な事はしないのと同じ。
IBMに丸投げ出来るぐらいの資金が有るなら、日電や不実に丸投げしてオラクルの面倒見てもらえるけどな。
うちはRACだけど意味不明に落ちてもリカバリは出来る仕組みにしてるよ。
そもそも絶対に落ちないなんてあり得ないし、ソフトのバグが無いのも信用してない。PGなんてバグ入りの欠陥品しか作れないし。製造業の品質管理に比べたら認識が甘過ぎるよ。
逆に、ポスグレは絶対落ちなくてサポートも満足と保証されてるの？
２億の案件でポスグレで組んで、損害賠償なんて喰らったら人生終わるなw
- 327 ：NAME IS NULL：2009/09/27(日) 04:40:49 ID:???.net
- oracleは絶対落ちないなんてありえない前提なのにpostgreには要求するのかｗ
どんなdbを使おうがフェイルセーフな構成にすればいいって自分で答えだしてるじゃん
- 328 ：NAME IS NULL：2009/09/27(日) 19:50:33 ID:???.net
- >>326
なんかあんまし大型案件やった事ないみたいなのでコメントだが。
規模と傾向もあるが基幹系ならIBM(i)とその他のベンダー＋Oracleの組み合わせだとIBMの方が半額くらいのコストで開発・運用が可能だ。
無論、Oracleの方がコスト安いケースもあるが、「IBM＝高い」と言うのは思い込みだ。
ある程度以上の資金がいるのは事実だが、>>326の意見は「安物買いの銭失い」な思考だ。
そして東証もけっこう落ちてるじゃねーかｗ
- 329 ：NAME IS NULL：2009/09/27(日) 20:40:49 ID:???.net
- いいよな。天下りで仕事もらえるようなところは。
東証を落としてもお咎めなしだぜきっと。
- 330 ：NAME IS NULL：2009/09/29(火) 01:30:04 ID:???.net
- 逆にIで落ちてたら大変なんじゃねw
- 331 ：NAME IS NULL：2009/09/30(水) 01:32:27 ID:???.net
- 何故データベース設計は軽視されるのか？
- 332 ：NAME IS NULL：2009/09/30(水) 05:39:47 ID:???.net
- 痛い目に会うような複雑なシステムじゃないから or ( 痛い目は末端がくらって表に出ない and それが痛い目だと気が付いていない )
- 333 ：NAME IS NULL：2009/09/30(水) 16:53:59 ID:???.net
- ちゃんとコスト計算が出来るまともなエンジニアが皆無。
- 334 ：NAME IS NULL：2009/10/09(金) 23:00:06 ID:???.net
- アプローチ使ってるけど、アプリの使い方じゃなくて、データベース設計の初心者本てなんかないかな
- 335 ：NAME IS NULL：2009/10/10(土) 17:22:36 ID:???.net
- >>334
デマルコ読め
- 336 ：NAME IS NULL：2009/10/11(日) 17:53:45 ID:???.net
- http://www.amazon.co.jp/dp/4822281116
これ読めばいいの？
- 337 ：NAME IS NULL：2009/11/24(火) 00:12:10 ID:???.net
- 賢者に聞いていいですか？
たとえば、２ｃｈとか「PC等」→「プログラム」→「【PHP】CakePHP」→「レス」って構成ですよね。
これってどういうDB設計になってるんですか？
実務経験がないのでわかりません。
「PC等（カテゴリID）」→「プログラム（カテゴリID＋サブカテゴリID）」→「【PHP】CakePHP（サブカテゴリID＋スレID）」→「レス（スレID＋レスID）」
→「デスクトップ（カテゴリID＋サブカテゴリID）」→「cpuをとっかえたい（サブカテゴリID＋スレID）」→「レス（スレID＋レスID）」
って感じですか？
１つのデータベースに、テーブルを1000個とか作ることとかあるんですか？
その場合、テーブルの名前を特定して探しにいく方法でしょうか？
- 338 ：NAME IS NULL：2009/11/25(水) 01:58:52 ID:???.net
- 2chはdbじゃないので(ry
http://pc11.2ch.net/test/read.cgi/db/1056967775/
SQL総合案内スレッド
http://pc11.2ch.net/test/read.cgi/db/1133798099/
姉歯DB設計
- 339 ：NAME IS NULL：2009/11/25(水) 20:11:39 ID:???.net
- マジ？2chはファイル記憶なの？
- 340 ：NAME IS NULL：2009/11/25(水) 20:47:50 ID:???.net
- 普通に考えれば2chはファイルだし、事実そう。
RDBで実装する意味が解らん。
- 341 ：NAME IS NULL：2009/11/25(水) 23:19:21 ID:wSmHcJvY.net
- 2ｃｈの量でもファイル入出力に耐えれるものなのか。
人間のイメージなんてちっぽけなものなんだな。
- 342 ：NAME IS NULL：2009/11/25(水) 23:34:29 ID:???.net
- >>341
実務経験がないから仕方ないのかもしれんが、
RDBに不思議な幻想を持つのはヤめた方がいい。
2chの場合は要求される仕様が「追記オンリー、更新は基本なし、当然削除もなし
発言は1000もしくは512KB(板によるが)で、ブラウザを使うユーザーにはhtml変換し
専用ブラウザはdat直読み。
そして圧倒的な書き込み&ＰＶときたら並のRDBMSでは即死する。
- 343 ：NAME IS NULL：2009/11/25(水) 23:42:32 ID:wSmHcJvY.net
- ありがとう。ファイル入出力の方がいいんだね。
たしかに、DBは偉大ってイメージがあるかも。組み込みエンジニアだからDBに縁がなくて。
twitterと2chは同じようなものかと思ったの。twitterはDBだよね。メンバーの紐付けあるし。
無数にレコードが追加されるからどういう設計なのかなーって。
- 344 ：NAME IS NULL：2009/11/26(木) 00:17:44 ID:???.net
- twitterは細かい事は知らんが、最初Rubyとデータベース使って結構落ちてなかったか？
そりゃ2chだってタマに落ちるけどな。
- 345 ：NAME IS NULL：2009/11/27(金) 00:30:39 ID:???.net
- ファイル入出力のほうがいいというのは間違い。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、ありませんか?
- 346 ：NAME IS NULL：2009/11/27(金) 00:59:55 ID:kLScCozf.net
- twitterの設計の想像がつかない。
- 347 ：NAME IS NULL：2009/11/27(金) 02:15:50 ID:???.net
- ＞ファイル入出力のほうがいいというのは間違い。ISAMファイル直弄りのコボラーに成りたいならともかくw
（略
＞潤沢な資金力さえ有ればdbでも捌けると思うけどね。
金かければなんでも出来るだろ。
コストパフォーマンス無視して「ＤＢの方が向いている」なんて・・・。
2chのサーバーと同じ導入コストでRDBMSを用いて実装し、
2ch以上のパフォーマンス出してから語ってくれ。
そして東証も派手に落ちてニュースになったんだが。
あれを「ちゃんとdbで注文捌いて約定処理が出来てるし。」とコメントできる神経が凄いな。
- 348 ：NAME IS NULL：2009/11/27(金) 02:49:00 ID:???.net
- お前らDBDB言ってるけどRDBMSのことだろ
テキストファイルだってなんだってDBはDBだ
- 349 ：NAME IS NULL：2009/11/27(金) 14:26:38 ID:???.net
- twitter は、元は Ruby on Rails じゃなかったっけ。今は知らないけど。
RoR は O/Rマッパーに ActiveRecord 使ってるから、多分バックエンドの DB は
RDBMS だとは思うけど、何を使ってるかまでは調べてない。
そういえば、ニコニコ動画のコメントサーバはバックエンドに MySQL 使ってるね。
更新頻度の高いテーブルと低いテーブルに選別して、InnoDBとMyISAMを
使い分けてると、どこかに書いてあった。あと memcached だったかの
キーバリューストアも併用して、パフォーマンス稼いでたはず。
ってか、この辺の話はDB設計と言うより、アーキテクチャ設計の話だね……
- 350 ：NAME IS NULL：2009/11/27(金) 14:40:31 ID:???.net
- むしろバックエンドにDB使ってないシステムなどまずない
- 351 ：NAME IS NULL：2009/11/27(金) 20:55:10 ID:???.net
- とりあえず、>>350が利用している2chはRDBは使っていない
- 352 ：NAME IS NULL：2009/11/28(土) 03:36:12 ID:???.net
- いやだからRDBMSじゃなくてDBは使ってるだろ
テキストファイルに書き出すのだって独自DBなわけで
- 353 ：NAME IS NULL：2009/11/28(土) 07:31:54 ID:???.net
- 逆に東京証券取引所の規模でテキストファイルのほうが無茶だろ。
銀行の取り付け騒ぎで人が大量に押し寄せてATM操作するとISAMでがんばってるホストが堕ちるのと同じ。
テキストファイル自体はdbじゃないだろ。
- 354 ：NAME IS NULL：2009/11/28(土) 09:10:00 ID:???.net
- ＞ATM操作するとISAMでがんばってるホストが堕ちるのと同じ。
ナニ言ってんだ？コレ？
タイムアウトやら領域が足りなくてトランザクションがコケた事とISAMの関連が意味不明。
ISAMでなく、普通のRDBでも帯域＆領域足りなきゃ落ちるのは一緒なんだが。
テキストを独自ＤＢと言うのは痛いが、引き合いにホストを持ち出してトンデモ理論展開スナ。
- 355 ：NAME IS NULL：2009/11/28(土) 12:06:43 ID:???.net
- >353-354
データベースの定義 ＠ Wikipedia
> 特定のテーマに沿ったデータを集めて管理し、容易に検索・抽出などの
> 再利用をできるようにしたもの。
> 狭義には、コンピュータによって実現されたものを言う。
広義には記録メディアが紙だろうが石版だろうがDBはDBなんだぜ。
テキストファイルは言わずもがな。
- 356 ：NAME IS NULL：2009/11/28(土) 14:30:13 ID:???.net
- 小学生は2chなんかせずに外で遊んでこいよ。
- 357 ：NAME IS NULL：2009/11/28(土) 15:04:45 ID:???.net
- とりあえずテキストファイルがＤＢと言うヤツは
ニコ動とか東京証券取引所のシステムを「石版」で構築してから語ってくれ。
- 358 ：NAME IS NULL：2009/11/28(土) 15:22:55 ID:WYkIZs31.net
- MySQL CSVストレージエンジン・・・
- 359 ：NAME IS NULL：2009/11/28(土) 15:52:18 ID:???.net
- テキストファイルだけならDBじゃないけどプログラムとしてテキストファイルを使うなら
それを読み出してデータストアとして利用するロジックがあるんだからDBと言えるだろうに
ただ石板は情報システム的にDBにはなり得ないから例えが悪い
- 360 ：NAME IS NULL：2009/11/28(土) 15:54:11 ID:???.net
- テキストファイルはDBにならないって言ってる奴は、
ミドルエアとしてのDBMSと勝手に解釈して限定してるんだろ。
- 361 ：NAME IS NULL：2009/11/28(土) 16:25:41 ID:WYkIZs31.net
- >>359
追記専用で基本屋外設置かつメンテ頻度も大変低いという条件下では
中の人の名前が順に彫り込まれる墓石というデータメディアは大変に
優れたものだと思う。
何より墓石メディアを用いた墓場というDBは古くは古代メソポタミア
に始まる何千年もの利用実績があるわけで、侮れん。
- 362 ：NAME IS NULL：2009/11/28(土) 18:50:14 ID:???.net
- 必死に話をそらそうとしているのを見ると頭が可哀想な人なんだろうな。
常識でモノを考えて喋ってくれ。
会社でよく「コミュニケーション力が低い」と怒られている人だろうけど。
- 363 ：NAME IS NULL：2009/11/28(土) 18:57:49 ID:???.net
- >357
指摘が全く意味不明だ。
石版メディアを使ったDBは読み書きが遅く電子処理に向かないので、
東京証券取引所では使えない。それだけの話がなんで理解できない？
おそらく君が「DB」と呼んでいるものは、正式には「RDBMS」だ。
- 364 ：NAME IS NULL：2009/11/28(土) 19:02:55 ID:???.net
- いやだから現実的に情報システムで利用できる媒体のみで語れよ
テキストファイル、パンチカード、印刷物あたりまでは理解できるが
石板をシステムで読み書きするシステムなんて現実的に存在しないだろ
- 365 ：NAME IS NULL：2009/11/28(土) 19:09:00 ID:???.net
- >>364
今は純粋に「データベース」という言葉の定義についての話をしてるんだろ？
情報システムで容易に媒体以外はデータベースにあらず、というのは単に君個人の
思い込みであって常識じゃない。
電話帳は電話番号のデータベース。これが常識レベルの解釈。
- 366 ：NAME IS NULL：2009/11/28(土) 19:10:15 ID:???.net
- × 容易に媒体 ⇒ ○ 容易に扱える
そういう意味じゃ、石版がNGなら紙もNGだろ。
- 367 ：NAME IS NULL：2009/11/28(土) 19:30:53 ID:???.net
- 現実問題として紙に印刷しておいてあとでドキュメントスキャナで取り込むというデータの保存の仕方はあるけれど
石板に掘っておいてあとで読み込むなんて使い方をしている奴は誰もいないわけで
- 368 ：NAME IS NULL：2009/11/28(土) 19:36:05 ID:???.net
- だから、昔は住所データベースが手書きだったりしたんだってば。
電子的に扱えるかどうかなんて問題じゃないんだって。
- 369 ：NAME IS NULL：2009/11/28(土) 19:43:07 ID:???.net
- しかし、「データベース」の定義に照らしてもやっぱり2chはデータベースじゃないわな。
- 370 ：NAME IS NULL：2009/11/28(土) 19:56:06 ID:???.net
- >>368
印刷物はDBとして使えるって言ってるじゃんみんな
否定されてるのは石版なんてとんでもない例でしょ？
- 371 ：NAME IS NULL：2009/11/28(土) 19:56:53 ID:???.net
- >>369
- 372 ：NAME IS NULL：2009/11/28(土) 20:53:21 ID:???.net
- >370
手書き文書は印刷物じゃないし、情報システムと親和性が無いのは石版と同じ。
石版の話は極端な例だけど間違いや嘘じゃない。
「データベースと呼べるかどうか」は、使いやすい／使いにくい、早い／遅いなんて
話とは別次元の問題だよ。
- 373 ：NAME IS NULL：2009/11/28(土) 20:57:48 ID:???.net
- >言ってるじゃんみんな
「みんな」が誰を指してるのか知らんが、世の中の常識とは言葉の認識が乖離してるな。
- 374 ：NAME IS NULL：2009/11/28(土) 21:02:17 ID:???.net
- 紙も石板も単にメディアの一種にすぎない
データベースってのは、メディアは関係ない
ハンドリングの容易さとか管理のしやすさとかは別の話
ＤＢとＤＢＭＳの区別ついてない奴が多すぎるな
俺も普段はＤＢ＝（Ｒ）ＤＢＭＳの意味で使ってる場合が多いが
こういった議論のときはきっちり区別しろよ
- 375 ：NAME IS NULL：2009/11/28(土) 21:15:58 ID:???.net
- テキスト/バイナリ、電子メディア/紙/石版wなんてのは単に実装方法の違いだけの
話なんだよね。DBかどうか、ってのは記録された情報の性質で決まる事なんだから、
「テキスト形式で保存したから」「記録媒体がアナログだから」なんて理由で
DBじゃなくなるという理屈は根本的におかしい。
- 376 ：NAME IS NULL：2009/11/28(土) 22:21:58 ID:???.net
- うちの墓石にも幕末から死んだ先祖の名前と日付が掘ってあるけど、あれもDBだったんだな
- 377 ：NAME IS NULL：2009/11/28(土) 22:49:14 ID:???.net
- 「データの再利用を目的として、特定のテーマに沿ったデータを集めて管理したもの」では
ないので、墓石はDBとは呼びにくいな。
上記の目的で墓石にデータを記録したなら、それはDBと呼んで差し支えない。
- 378 ：NAME IS NULL：2009/11/28(土) 22:54:56 ID:???.net
- >>377
>特定のテーマに沿ったデータを集めて
お墓の中に入っている人の名前しか入っていないけど。
>データの再利用を目的として
毎年お墓参りしないの?
- 379 ：NAME IS NULL：2009/11/28(土) 23:12:30 ID:???.net
- >378
一般的には、墓石は単に故人の名前を残すこと自体が目的だと思うけど。
例えば「大量の先祖の中から特定の故人の名前を探す事を容易にする」のを目的に
墓石に名前を彫ったんだとしたらDBと呼べるんだろうけど。
目的がデータの再利用ならデータの構造も探索に適した構造になってる筈だけど、
故人の名前に見出しが付いてたりはしないだろ？
>毎年お墓参りしないの?
俺はしないw
つか、お墓参りはデータの再利用なのか？
- 380 ：NAME IS NULL：2009/11/28(土) 23:18:18 ID:???.net
- 没年でインデクシングされた故人データベースとして使う事は可能だなw
- 381 ：NAME IS NULL：2009/11/28(土) 23:27:29 ID:???.net
- 所詮墓石はデータメディアにしか過ぎない。
墓地の管理人さんも含めて初めてデータベース管理「システム」
と呼べる。
- 382 ：NAME IS NULL：2009/11/28(土) 23:36:57 ID:???.net
- 過去帳ならともかく、墓石そのものは集積されていないからなぁ。
- 383 ：NAME IS NULL：2009/11/28(土) 23:52:27 ID:???.net
- 墓石とか石版とかどうでもいいよｗｗｗ
- 384 ：NAME IS NULL：2009/11/29(日) 00:06:05 ID:???.net
- >>383
しょうもない話だけど、本質を捉えていて面白いじゃないか。
こういう話を見てると、普段「データベース」という物がいかに
表面的かつ一面的にしか捉えられていないかが解るな。
- 385 ：NAME IS NULL：2009/11/29(日) 05:16:11 ID:???.net
- しかし「データベース」の定義という知識が必要となることはまずないからなぁ。
今では博物学的意味しかないかもしれん。
- 386 ：NAME IS NULL：2009/11/29(日) 05:22:49 ID:???.net
- テキストファイルや紙までなら理解できるけど
石版とかになるともうデータを取り出す目的で作ってるわけじゃないし
データベースじゃなくてストレージなんじゃないかと
- 387 ：NAME IS NULL：2009/11/29(日) 06:09:08 ID:???.net
- ストレージがなければデータベースも実装できないのだが。
- 388 ：NAME IS NULL：2009/11/29(日) 06:31:32 ID:???.net
- 自動車にはタイヤが必要だがタイヤは自動車ではない
- 389 ：NAME IS NULL：2009/11/29(日) 07:40:55 ID:???.net
- データベースは物質ではなくて概念の名前。
石版の例で言えば、厳密には石版そのものがデータベースなのでなく、石版に記録された情報が
データベースなの。
> 石版とかになるともうデータを取り出す目的で作ってるわけじゃないし
この話は「仮にデータの集積方法が石版への記述であったとしてもDBはDB」という例え話だろ。
データを取り出す目的で石版を作る事だって当然できる。
ほかのデバイスより読み書きの効率が悪いとか集積率が悪いとか、そんな事はここでは全く
問題ではない。
> しかし「データベース」の定義という知識が必要となることはまずないからなぁ。
知識以前に常識の問題だと思う。
データベースという言葉が何を指すのか知らないで日々その言葉を使うのか？
狭義のDB＝DBMSの中にもDBって言葉は入ってるんだぜ。
- 390 ：NAME IS NULL：2009/11/29(日) 08:23:41 ID:???.net
- 「DBMS」と「データベース」は異なる概念だというのは常識レベルの話だとしても、
あるAが「データベース」の定義にはてはまるかどうかという判断が求められることって
こんな議論の場でもなきゃまずないだろ。だいたい、「データベース」という言葉は
そもそもDBMSと比較して定義があいまいだし。
掲示板/BBSという用語を正確に定義付けられなくても2chやるのに何の支障も
ないってことよ。
- 391 ：NAME IS NULL：2009/11/29(日) 09:06:02 ID:???.net
- なんでこんな現実性のない言葉遊びで熱くなれるんだ？
職場で「空気読めないヤツ」とか言われないか？＞石版データベース君
- 392 ：NAME IS NULL：2009/11/29(日) 09:06:16 ID:???.net
- > あるAが「データベース」の定義にはてはまるかどうかという判断が求められる
日常的に行われている事だけど、当たり前過ぎて普通は意識しないだけだろ。
というか、そんな高尚な話か？
一から十まで常識レベルの話をとくとくと聞かせてるのに、まるで理解してるように
見受けられないから話が長引いてるだけだと思うんだけど。
> 掲示板/BBSという用語を正確に定義付けられなくても2chやるのに何の支障も
> ないってことよ。
エンジニアが仕事で使うならそんな訳にいかんだろ。ちゃんとしろよ。
- 393 ：NAME IS NULL：2009/11/29(日) 09:14:55 ID:???.net
- >391
石版の話は単なる例え話だ。言葉の定義は単なる遊びでなく現実の問題だ。
散々感覚のズレを指摘されてるのに反省が見られんな。
こういういい加減な奴が技術者ってのが信じられん。
- 394 ：NAME IS NULL：2009/11/29(日) 09:20:20 ID:???.net
- 言葉遊び云々を言うなら、「テキストで保存したらもうDBじゃない」という
主張の方がよっぽど屁理屈だと思うんだ。
- 395 ：NAME IS NULL：2009/11/29(日) 09:44:03 ID:???.net
- >>392
別に判断が必要じゃなきゃ仕事でもしないだろ。そもそも、データベースに該当するか
どうかという判断なんて、たとえばどういうケースで何のために行うの？
- 396 ：NAME IS NULL：2009/11/29(日) 09:58:23 ID:???.net
- 判断するというより、言葉の指す意味の範囲を知っておく事が重要だよ。
仕様書に「ログインユーザのデータベースを作成する」と書いてあったとして、
書いた側と受け手に共通認識が無いとおかしな事になる。
ぶっちゃけこういう時、勝手にRDBMSの準備をする奴は無能なエンジニアだと思う。
- 397 ：NAME IS NULL：2009/11/29(日) 10:17:09 ID:???.net
- ＞仕様書に「ログインユーザのデータベースを作成する」と書いてあったとして、
この場合は普通にDBMSを用いてログイン情報を管理する事を想定すると思うが。
要件に「ログインユーザの履歴を記録する」ならテキストに順次書き出しを想定する。
＞書いた側と受け手に共通認識が無いとおかしな事になる。
＞ぶっちゃけこういう時、勝手にRDBMSの準備をする奴は無能なエンジニアだと思う。
現実の仕事だとすり合わせとか会議があるからありえないケースだが、
そういう発想できる人の方がコミュニケーション能力と実務経験が欠如したエンジニアだと感じる。
- 398 ：NAME IS NULL：2009/11/29(日) 10:30:07 ID:???.net
- DBを作成するけど、所謂DBMSを使わない案件だっていくらでもある。
DBが概念に過ぎない事を知っているエンジニアは、実装はどうするか？という発想になる。
そうでない人はDBMSを使う（仕様作成元は使いたがっている）と信じて疑わない。
> 現実の仕事だとすり合わせとか会議があるからありえないケースだが
勘違いしたまま実装まで行かないのは当然。
だだし、すり合わせの場でその話が出るまではずっと勘違いしてるわけだ。
仕事の仕方は全然違うと思うがね。
- 399 ：NAME IS NULL：2009/11/29(日) 10:31:32 ID:???.net
- >>396
コミュニケーションミスの話はまた別のような。
「AはXである」
「『Iさんの言うA』はXである」
この2つの命題はは異なるからね。
データベースとDBMSは概念が異なるという常識があって、その上でその仕様書に
書かれた「データベース」がどちらを指しているのか明確でなく、さらにその違いが
実装する上で重要な違いなのであれば、普通は確認するよね。
そういう状況で、「『データベース』は必ずしもDBMSを必要としない」といって
勝手にテキストファイルで作ってしまうのも同様に困ったチャンだろうね。
後で客と「データベースを作れと言ったじゃん」「テキストファイルでもデータベースです」
みたいな押し問答になったりして。
- 400 ：NAME IS NULL：2009/11/29(日) 10:42:43 ID:???.net
- 石板DB否定派＝DBとは実装のこと。テキストがDBの実現手段に含まれる事を想像もしない。
石板DB肯定派＝DBとは概念のこと。DBの実装形態が様々あることを理解し、色々な可能性を想定している。
DBを概念として捉えている人は、実装について勝手な思い込みはしない。
> 勝手にテキストファイルで作ってしまうのも同様に困ったチャンだろうね。
その人はポジション的に石板DB否定派だと思う。
- 401 ：NAME IS NULL：2009/11/29(日) 10:46:30 ID:???.net
- >>397
>この場合は普通にDBMSを用いてログイン情報を管理する事を想定すると思うが。
スタンドアロンや組み込みのシステムでもかい？
- 402 ：NAME IS NULL：2009/11/29(日) 10:55:39 ID:???.net
- >>400
アンタさぁ、自分ひとりが後者、他の全員が前者だと思ってるだろw
- 403 ：NAME IS NULL：2009/11/29(日) 10:58:48 ID:a+E7ORTb.net
- 既婚女性板はカルト団体の糖一教回や、そよ風などが支配し世論工作をしています。
既婚女性に成り済ましレスを繰り返してます。
残念だが既婚板の政治スレは全部カルトの工作スレです。
例えばこのスレ
↓
【民主党の政策に不安を感じる奥様の雑談室】その80
http://hideyoshi.2ch.net/test/read.cgi/ms/1259420965/
web魚拓
http://s03.megalodon.jp/2009-1129-0505-19/hideyoshi.2ch.net/test/read.cgi/ms/1259420965/
- 404 ：400：2009/11/29(日) 11:01:08 ID:???.net
- >402
いや、常識的な大半のエンジニアが後者、このスレにいる数名が前者だと思ってるが？
なんでそう思う？
- 405 ：NAME IS NULL：2009/11/29(日) 11:21:32 ID:???.net
- その「数名」ってどこにいるの？
その話題でループしてんのアンタ一人じゃない？
- 406 ：400：2009/11/29(日) 11:28:21 ID:???.net
- >405
そもそも石版の話を出したのは俺じゃないんだけどな。
テキストファイルはNGだ、紙ならセーフだ、墓石はどうだ、なんて話をしてた人は
明らかに前者だろ。石版DBの話にチャチャ入れてた奴も前者だと思ってるけど。
あ、君がどっちかは知らんよ。
- 407 ：NAME IS NULL：2009/11/29(日) 11:41:05 ID:???.net
- どうせもう「前者」は居ないんだろうし、
>337以前の流れに戻そうや。面白かったけど、ちょっと引っ張りすぎ。
- 408 ：NAME IS NULL：2009/11/29(日) 11:43:41 ID:???.net
- 墓石のチャチャいれ？>>382なら俺だ。
つかその時点で既にデータベース≠DBMSが前提の議論じゃん。
- 409 ：NAME IS NULL：2009/11/29(日) 11:52:49 ID:???.net
- >>408
>383 とか >391 のつもりだったんだが。
>382はそれもそうだなあ、と思いながら読んだよ。
> その時点で既にデータベース≠DBMSが前提の議論じゃん
君はそうかも知れんけども。
>386 とか >397 は理解してるようには見えん。
- 410 ：NAME IS NULL：2009/11/29(日) 12:45:50 ID:???.net
- なんか休日に寂しい暇人が勝手に敵を作って「俺Sugeee」って言ってるスレだな。
定義厨は他人の意見を絶対に聞き入れないからカキコするだけ無駄だな。
- 411 ：NAME IS NULL：2009/11/29(日) 16:25:18 ID:???.net
- 馬鹿は反省しないから馬鹿なんだよね
- 412 ：NAME IS NULL：2009/11/29(日) 17:19:39 ID:???.net
- DBとDBMSの区別もつかないレベルの人に仕事が回ってきちゃうぐらい
データベース設計が軽視されているという流れでOK？
- 413 ：NAME IS NULL：2009/11/29(日) 18:15:34 ID:???.net
- DBってドラゴンボールですか？
- 414 ：NAME IS NULL：2009/11/29(日) 23:57:19 ID:???.net
- 墓石をデータの永続化対象として何がいけないのか、さっぱりわからん
- 415 ：NAME IS NULL：2009/11/30(月) 00:10:22 ID:???.net
- 曰く「実際にそういう実施例が存在するかどうか」が重要なんだそうだ。
頭が固いを通り越してアホとしか思えん。
- 416 ：NAME IS NULL：2009/11/30(月) 00:15:09 ID:???.net
- DBってドラゴンボールではないんですね
- 417 ：NAME IS NULL：2009/11/30(月) 05:27:07 ID:???.net
- ログイン認証の情報はテキストに保存しないって言ってる奴正気か？
htpasswd知らないとかないよな
- 418 ：NAME IS NULL：2009/11/30(月) 06:56:41 ID:???.net
- このスレの本題はRDBMSのスキーマ設計の軽視だが、
実は軽視されてるのはデータ設計全般なんだろうか。
と、ここ数日のやりとりを見ていて思った。
2chのレベルが平均的とは思わないけれども。
- 419 ：NAME IS NULL：2009/11/30(月) 07:22:36 ID:???.net
- 一部のアフォが喚いているだけだろ
- 420 ：NAME IS NULL：2009/11/30(月) 22:20:31 ID:???.net
- マジレスすると軽視されてるのは設計屋だお
- 421 ：NAME IS NULL：2009/11/30(月) 22:27:14 ID:???.net
- マジレスすると開発＆運用屋は軽視されている
- 422 ：NAME IS NULL：2009/12/01(火) 00:41:31 ID:???.net
- マジレスするとDBはデータベースだお
- 423 ：NAME IS NULL：2009/12/01(火) 01:33:05 ID:???.net
- マジレスするとこの板が出来たときは8割のスレがドラゴンボール関連だった
- 424 ：NAME IS NULL：2009/12/01(火) 01:41:26 ID:???.net
- 過去レスみたら、>>19にワロタｗ
ひどいね
- 425 ：NAME IS NULL：2009/12/01(火) 02:04:03 ID:???.net
- タイムスタンプにINT型でUNIX時間入れてるのが酷いと思ったけど超えたな
- 426 ：NAME IS NULL：2009/12/01(火) 10:05:12 ID:???.net
- 正しい知識を持った人間以外がプロになっているのがおかしい
一級建築士と同じように、充分な知識を学習した人間のみが、
システム設計に参画出来るようにするのが本来の正しい姿。
もう、遅いけどね。
- 427 ：NAME IS NULL：2009/12/01(火) 15:06:04 ID:???.net
- 機械設計だって回路設計だって人生設計だって資格はないけどな
- 428 ：NAME IS NULL：2009/12/01(火) 20:06:48 ID:???.net
- 十分な知識を学習とかって、実務経験に勝るモノはないんだが。
正確には「各行程を経験し死ぬまで学習意欲があり常に成長し続ける
コミュニケーション能力の高い人間」でないと設計はやるべきではない、
が正しいな。
知識なんてあって当たり前でなんの自慢にもならん。
まあ、免許制にして欲しいと思う事は多々あるがｗ
- 429 ：NAME IS NULL：2009/12/01(火) 21:25:31 ID:???.net
- ペーパーでOracleのプラチナやPostgreSQLのゴールド持ってる奴より
無資格で現場で痛い目に遭ってる奴の方がまだいいだろうな
- 430 ：NAME IS NULL：2009/12/01(火) 21:55:33 ID:???.net
- どっちが重要なんて比べるもんじゃないだろ。
知識も経験もどっちかが欠けてたらダメじゃん。
知識なんてあって当たり前。経験なんて勝手に積み上がる。
- 431 ：NAME IS NULL：2009/12/01(火) 22:20:12 ID:???.net
- 知識は幅広い視野を持つのに必要、経験はその上で必要。
スレチだが、ちまちま何かを作ったのに、それをカバーした上品なライブラリ見つけたらマジへこむ。
- 432 ：NAME IS NULL：2009/12/01(火) 22:32:55 ID:???.net
- 「知識より経験」って言う奴って、自慢できるのが本当に経験だけだったりするからな。
そういう奴は得てして怪しげなノウハウを振りかざしたり、理論的な話をするとなぜか怒ったり。
- 433 ：NAME IS NULL：2009/12/01(火) 22:48:16 ID:???.net
- >>429
Platinumはペーパーでは取れんだろう。
- 434 ：NAME IS NULL：2009/12/01(火) 23:24:20 ID:???.net
- >>432
資格もっててスマソｗ
つかDB関連の資格はペーパーはなくなないがある程度以上は実際に使った人間でないと
受かるのは辛いだろ。
現実には資格持ちは「古くて使えなくて胡散臭い都市伝説」を信じてるヤツ多いけどな。
「SQLはこう書くと・・・」とか「サロゲートキーが・・・」とか「こういう場合はストアドが・・・」とか、
「こうやって教えられた」とか、応用を知らんのかと小一時間(ry
実際やらしてみるとパフォーマンスでなかったり、JOBの再投入が不可能な論理設計したりとか。
資格取った後も最新動向やら勉強会やらニュースとか読め。
- 435 ：NAME IS NULL：2009/12/02(水) 00:43:57 ID:???.net
- なんだその痛すぎる自己紹介はw
- 436 ：NAME IS NULL：2009/12/02(水) 01:12:12 ID:???.net
- ペーパーでplatinum結構いるよ
goldだとやたらいる
- 437 ：NIN：2009/12/02(水) 01:52:02 ID:???.net
- その先生方に確認したんだが、
テーブルの主キーの空きを管理するテーブルを作って、
主キーの空きを管理するっていうことを聞いたんだけど、ほんとかぬ？
- 438 ：NAME IS NULL：2009/12/02(水) 03:45:08 ID:???.net
- OracleのGoldやPlatinumは講習会受けて取る資格だからな
難しいのは確かだけど時間と金がものを言う資格でもある
- 439 ：NAME IS NULL：2009/12/02(水) 04:26:21 ID:???.net
- 国家資格の情報処理試験が評価されてない現実。
- 440 ：NAME IS NULL：2009/12/03(木) 20:45:05 ID:???.net
- >>425
1970年1月1日0時0分0秒からの経過秒数をDBに整数型で入れてるってこと？
…それはナイスな方法だな。今度使わせてもらうわ。
- 441 ：NAME IS NULL：2009/12/03(木) 21:21:06 ID:???.net
- データ的には軽いけどトラブル対応時に人間が見て全く意味がわからないから死ねる
というか死んだ
- 442 ：NAME IS NULL：2009/12/04(金) 00:27:24 ID:???.net
- その手の変換ツールぐらい準備しておくものだ。プログラマなら簡単にツールぐらい作れるだろ。
- 443 ：NAME IS NULL：2009/12/04(金) 01:15:07 ID:???.net
- いやだから普通にtimestampでいいじゃんて話じゃないのか
プログラム上でだっていちいち変換して使わなきゃならんのだし
- 444 ：NAME IS NULL：2009/12/04(金) 07:26:50 ID:???.net
- RDBMSによって実装が違うが、このケースでは普通にtimestampを使えばいいのでは？
そういう型がないRDBMSなら仕方ないと思うけど。
- 445 ：NAME IS NULL：2009/12/04(金) 08:09:50 ID:???.net
- Unix系のアプリなら、time_t型を入れると出し入れが便利じゃん。
変換するコストもいらないし。
- 446 ：NAME IS NULL：2009/12/04(金) 09:21:40 ID:???.net
- 画面にそのまま出すのか
入力は？
- 447 ：NAME IS NULL：2009/12/04(金) 22:45:54 ID:???.net
- まあUnix系なら「出し入れ」だけは便利な面はあると思う。
日付や時刻関連でGROUP BYするときにちょっと殺意が沸くくらいだな。
- 448 ：NAME IS NULL：2010/03/21(日) 14:22:04 ID:7Pz5sOZx.net
- age
- 449 ：NAME IS NULL：2010/04/11(日) 16:39:24 ID:???.net
- ahe
- 450 ：NAME IS NULL：2010/05/16(日) 01:23:57 ID:LQJdvEO0.net
- 有効期間のあるマスタテーブルの主キーってサロゲートキーにできるのかな？
- 451 ：NAME IS NULL：2010/05/16(日) 02:11:03 ID:???.net
- できるよ
- 452 ：NAME IS NULL：2010/07/31(土) 21:47:51 ID:IkDl9wDS.net
- age
- 453 ：NAME IS NULL：2010/10/30(土) 13:29:21 ID:???.net
- インデックス10個のテーブルに100万件のデータってやばいですか？
- 454 ：NAME IS NULL：2010/10/30(土) 14:23:02 ID:???.net
- >>453
全然普通
- 455 ：NAME IS NULL：2010/11/02(火) 22:37:47 ID:???.net
- それ殿くらいの鯖スペックでの話？
- 456 ：NAME IS NULL：2010/11/03(水) 08:21:23 ID:???.net
- その辺の安鯖でも楽勝なレベル
要求性能にもよるが、10年前のハイエンドクラスだときついだろうね
- 457 ：NAME IS NULL：2010/11/16(火) 17:14:04 ID:???.net
- atom 1.6GHz 2GBメモリで１００人ぐらいの共有鯖でもおk？
- 458 ：NAME IS NULL：2010/11/23(火) 16:06:12 ID:lzgg56a3.net
- 余裕のヨーコゼッターランド
- 459 ：NAME IS NULL：2010/11/24(水) 16:00:20 ID:???.net
- じゃあ問題出たら損害賠償請求するのでヨロw
- 460 ：NAME IS NULL：2010/11/24(水) 21:25:35 ID:???.net
- じゃあ性能要件を満たす設計をしてあげたからその分の費用請求ヨロｗ
0.25人月で60万円でおｋ
- 461 ：NAME IS NULL：2010/11/24(水) 21:32:17 ID:???.net
- 単価安いなｗ
- 462 ：NAME IS NULL：2010/11/26(金) 21:57:49 ID:???.net
- 1人月240万だろ？充分高いだろ
俺のとこなんて1人月120万だよ基本orz
- 463 ：NAME IS NULL：2010/11/27(土) 02:10:26 ID:???.net
- そんなボッタクリな所には仕事頼まないしw
- 464 ：NAME IS NULL：2011/01/18(火) 19:33:09 ID:???.net
- プラズマクラスター効果なし
http://twitter.com/ozawa_yuuki/status/6549767047872513
- 465 ：NAME IS NULL：2011/10/29(土) 19:01:44.37 ID:???.net
- 大手ベンダーの標準的な人月って150万くらい？
- 466 ：NAME IS NULL：2011/11/27(日) 14:59:22.75 ID:???.net
- >>439
国家資格（笑）の情報処理試験受けたことあんのかと
あんなもん実務に役立つのはどのポジションだろうが2割程度だろ
「プラズマテレビがガス放電で発光してます」とか知ってる必要あんの？
IPAは今年度になってようやく業界のゼネコン型に言及するレベル
お勉強しか出来ない無能集団の天下り先
国家自体が無能で仕事遅いしなｗ
ロジックとデータ（論理・物理）見てテストして
壁にぶち当たってマニュアルやら仕様書見て
ソースとデータ（論理・物理）見てｒｙ・・・・ループ
この作業以外で技術力を上げる方法なんか存在しない
- 467 ：NAME IS NULL：2011/12/02(金) 21:33:33.05 ID:kohrfEHA.net
- 派遣で天才プログラマーが消えた
- 468 ：NAME IS NULL：2011/12/03(土) 00:57:01.54 ID:???.net
- >>466
糞ﾜﾛﾀお前の情試の例はよりによってITパス/FEの午前かよｗ
高度のスペシャリスト系は良く出来てる
所詮知識なので合格即実務で出来る、ではないが
「この程度も知らずに実務やってないよね？」感はある
- 469 ：NAME IS NULL：2011/12/03(土) 12:43:57.30 ID:???.net
- >>468
高度がよく出来てる？
アホか？回答速報当日出ないような奇問も混じってるわけだが？
- 470 ：NAME IS NULL：2011/12/03(土) 13:50:27.97 ID:???.net
- >>469
お前はずっとFE午前レベルの「プラズマテレビの～」だけやってろｗ
お前みたいに高度もとれない程度の知識レベルの奴が設計してるシステムとか・・・
関わってる連中が可愛そうだわ。まさにスレタイにピッタリな人間ｗｗｗ
- 471 ：NAME IS NULL：2011/12/04(日) 00:16:08.13 ID:???.net
- >>470
難易度低い時に受けてたまたま取れたヤツが偉そうにしてるの見ると痛々しくなるよな。
基本はわかってるが応用効かないし、製品個別の仕様部分を考慮できなかったりロクなヤツがいない。
- 472 ：NAME IS NULL：2012/04/23(月) 13:48:49.67 ID:???.net
- 専板のDB設計スレが保守の末落ちる程だから軽視も致し方ない
- 473 ：NAME IS NULL：2012/07/15(日) 16:24:28.05 ID:???.net
- 大本の設計程制約少ないから楽に作れるもんなんだが、
逆に末端がどんどん依存してくれるから後で変更するのがた～いへん。
わかってるとこだとDB設計にコストかけてくれる。
わかってないとこだと作る側の営業と使う側の購買が交渉にコストかけてくれる。
後者、会社関係単位で迷惑。
詳細テーブル全てに予めtempカラム群持たせるのって、
個人的にはかなりの糞だと思うんだが・・・
- 474 ：NAME IS NULL：2012/07/22(日) 12:59:18.94 ID:???.net
- 予備カラム…COBOL脳全開の設計ですな。
- 475 ：NAME IS NULL：2012/07/22(日) 14:06:03.40 ID:C+pjCT8o.net
- そこで列指向データーベースですよ
- 476 ：NAME IS NULL ：2012/07/23(月) 19:43:57.61 ID:???.net
- そうそう
ところで激安中古CAD専門店っていいの見つけた。
かなり安いし使える
- 477 ：NAME IS NULL：2012/07/24(火) 22:41:20.78 ID:???.net
- >>474
何百万レコード級のテーブルを
使ったことはある？
ALTER TABLEだけで何十分とか
当たり前にかかったりするぞ。
それを思えば、ハナからバカにした
ものでもない。
- 478 ：NAME IS NULL：2012/07/24(火) 22:49:28.17 ID:???.net
- >>477
レコード数が多いからこそ、カラム数を減らすべきだってことが分からないのか？
- 479 ：NAME IS NULL：2012/07/24(火) 22:55:57.42 ID:???.net
- COBOL脳だとRDBにおいてはテーブルサイズが大きくなるとパフォーマンスが加速度的に劣化する場合があることを理解できない。
あいつらなんでもかんでも一行づつ処理しようとする。
処理時間=一行の処理時間(一定)×行数
はRDBじゃ通用しないんだよ
- 480 ：NAME IS NULL：2012/07/24(火) 23:29:57.10 ID:qDs+O0CQ.net
- 某H関連会社に訪れた際、若手ＳＥが仕様レビューを受けていた
「ここでSQLのSUM関数で合計を取得します」
「それ信用できるの？ちゃんと一つずつ足さないとダメだよ」
２１世紀でこれかと驚いた
- 481 ：477：2012/07/26(木) 22:49:50.88 ID:???.net
- >>478
ケースバイケースだと言ってるんだよ。
絶対どっちか、というものではない。
予備カラムがあっても、理由が充分なら、
それでよいではないか。
- 482 ：NAME IS NULL：2012/07/26(木) 23:25:44.93 ID:???.net
- 予備カラムなんて持たせたら、いざ使う時、意味合いとカラム名が乖離するよね。
検索パフォーマンスが必要無いならxml型にするって手もあるけど
- 483 ：NAME IS NULL：2012/07/26(木) 23:36:01.31 ID:D083zD7I.net
- DB変更は仕様変更になるから別契約だけど
予備項目を活用する分には保守の範囲内で出来るから
予備を多めに作っとくっていうのがあったな
クソだと言われてる設計でも事情でそうなってるのも結構あるよね
- 484 ：NAME IS NULL：2012/07/27(金) 00:24:21.29 ID:???.net
- 予備カラム多用すると、後々どの予備カラムが何の目的で使われてるか分からなくなるw
画面から予備カラムにセットする値にも制限掛からないから、変な値入ってバグってみたり。
- 485 ：NAME IS NULL：2012/07/27(金) 20:28:23.51 ID:???.net
- そもそも可変長ランダム入出力が基本なRDBのレコードにおいて
予備カラムをあらかじめ作る必要性はうすい
COBOLだから予備カラムつくるんじゃなくて、それが動いているプラットフォームが
固定長バッファのシーケンシャル入出力を基本としてたから必要なだけ
- 486 ：NAME IS NULL：2012/07/28(土) 01:31:34.34 ID:+zDhKkY8.net
- >>439
あんな天下り先確保のための試験を
ボッタクリ価格で受けるとか、
怒りが湧いてくる。
- 487 ：NAME IS NULL：2012/07/28(土) 02:12:21.50 ID:???.net
- まるで意味のない資格では無いだろ。
とはいえ午後1は酷い問題混じってることあるから、選択運の要素が強いけど。
- 488 ：NAME IS NULL：2012/07/28(土) 10:54:33.10 ID:???.net
- >>486
安いので許せや
- 489 ：NAME IS NULL：2012/07/28(土) 10:55:35.76 ID:???.net
- >>487
酷い問題のってどれですか
- 490 ：NAME IS NULL：2012/08/04(土) 09:12:32.99 ID:???.net
- >>487-488
>>486 は取れなかった奴の言い訳じゃね (w
- 491 ：NAME IS NULL：2013/10/13(日) 20:53:47.26 ID:4bhXtCWz.net
- 保守age
- 492 ：ＮＰＣさん：2014/01/15(水) 06:23:23.94 ID:8z9mQXwT.net
- 66427727358778987766457232625+40=66427727358778987766457232665
www.2ch.net
toro.2ch.net/db/
toro.2ch.net/test/read.cgi/db/1228061247/
- 493 ：NAME IS NULL：2014/01/29(水) 00:39:34.78 ID:???.net
- >>1
せっかく合意のとれた業務フローとテーブル設計を
180度ひっくり返しに来る奴（客・身内問わず）がいるから
それが最初からわかってるから軽視される
- 494 ：NAME IS NULL：2014/01/29(水) 01:16:58.43 ID:???.net
- この前某中古ショップですごく安いパソコンを発見しました。
ちょうど私はその時新しいパソコンがほしいと思っていて本当に買おうかと悩みました。
というのも２０１１年製でCPUがCorei5、メモリも４ＧＢあるしHDDが１ＴＢもあってお値段がなんと３８０００円でした。
まだ発売日からあまり期間も経っていないしこのスペックでこの値段ならかなりお買い得かなと思ったのですが、問題は少スペース型というか拡張性がないタイプのものだったんです。
それにグラフィックボードもついておらず後々の事を考えるとやめといたほうがいいかなという結論に達しました。
結局ネットでBTOのパソコンを後で注文しました。
いやぁしかしまさか周りにあるパソコンの中で一番スペックが高いのに一番安い値段になってるとは思いませんでした。
http://toro.2ch.net/test/read.cgi/hp/1382021349/
http://toro.2ch.net/test/read.cgi/hp/1352858999/
- 495 ：NAME IS NULL：2014/02/02(日) 00:06:45.66 ID:LwhyxpFz.net
- 自分で競馬データベースや競馬新聞を作りたいんだが
どんなプログラミング言語を学習すればいいですか？
競馬を通してプログラミングを勉強すれば楽しいと思うし、
仕事にも役立つとなれば一石二鳥。
データーソースは外部の物を利用。
- 496 ：NAME IS NULL：2014/02/14(金) 21:34:14.86 ID:???.net
- ↓こういう提供されたexcelデータがあるとします
日本小学校
１年 |２年
1組 ２組 | 1組 ２組
座席番号１安藤 伊藤|五十嵐 飯田
座席番号２臼井 榎本|上田 岡田
座席番号３０（全クラス３０で統一）
↑をデータベースに格納しようとすると
こういう風な感じになると思いますが
日本小学校 一年 1組 座席番号1 安藤
日本小学校 一年 1組 座席番号2 山田
日本小学校 ２年 1組 座席番号1 伊藤
視覚的に編集するには前者の方がやりやすいですよね
こういう前者のデータ構造は何か名称があったりしますでしょうか
また前者のテーブルの横にアメリカ小学校を追加する場合もあります
こういうデータを管理するために何かいいツールとかないでしょうか？
データベースに格納できるよう変換してくれたり
１年 |２年
1組 ２組 | 1組 ２組
日 座席番号１安藤 伊藤|五十嵐 飯田
本 座席番号２臼井 榎本|上田 岡田
小
ア 座席番号１ボブ トム
メ 座席番号２マリー
リ
カ
小
こんな風にしたり
- 497 ：NAME IS NULL：2014/02/15(土) 11:02:45.63 ID:???.net
- >>496
そもそもそれはデータ構造と呼べる代物かが疑問なんだが
表現方法としては「マトリクス表」とか呼べばいいんじゃね？
ツール？excel使えばいいじゃん
excel VBAでcsvを出力するマクロを作れば終いだ
- 498 ：NAME IS NULL：2014/02/15(土) 20:26:44.89 ID:???.net
- やっぱ自作ですかね
どうもです！
- 499 ：NAME IS NULL：2014/07/22(火) 14:35:32.25 ID:AM7LzXqx.net
- ★2ch勢いランキングサイトリスト★
◎ +ニュース板
・ 2NN
・ 2chTimes
◎ +ニュース板新着
・ 2NN新着
・ Headline BBY
・ unker Headline
◎ +ニュース板他
・ Desktop2ch
・ 記者別一覧
◎ 全板
・ 全板縦断勢いランキング
・ スレッドランキング総合ランキング
・ ログ速
◎ 全板実況込み
・ 2勢
・ READ2CH
・ i-ikioi
※ 要サイト名検索
- 500 ：NAME IS NULL：2014/07/23(水) 19:35:38.12 ID:???.net
- 埼玉県警川口署は２０日、小学生の女児の下半身を触ったとして強制わいせつの疑いで、
同県蕨市南町、東大大学院博士課程の内藤慶一容疑者（２６）を逮捕した。
川口署によると、内藤容疑者は「研究が忙しく、ストレスがたまっていた。少女に興味があった」と供述している。
逮捕容疑は１月４日午後５時半ごろ、埼玉県川口市並木２丁目の書店１階の階段近くで、
当時９歳で小学４年だった女児の下半身を触った疑い。
書店の防犯カメラ画像を解析するなどして内藤容疑者が浮上した。
３月上旬に近くのスーパーで別の女児が下半身を触られる被害があり、関連を調べる。
http://www.47news.jp/CN/201407/CN2014072001001585.html
- 501 ：NAME IS NULL：2015/02/08(日) 18:11:12.29 ID:???.net
- 色々あるけど結論として
役に立たないんだよ。
まじで。
- 502 ：NAME IS NULL：2015/08/22(土) 10:22:18.62 ID:???.net
- テーブル設計がきちんとしてるだけで
オプティマイザがいい仕事するんやで
- 503 ：NAME IS NULL：2015/10/22(木) 23:00:56.18 ID:72sKbAfY.net
- ☆ 日本の核武装は早急に必須ですわ。☆
総務省の『憲法改正国民投票法』、でググってみてください。
日本国民の皆様方、2016年7月の『第24回 参議院選挙』で、日本人の悲願である
改憲の成就が決まります。皆様方、必ず投票に自ら足を運んでください。お願い致します。
- 504 ：NAME IS NULL：2015/11/22(日) 12:48:10.28 ID:7pwbZA71.net
- インターフェイスが決まってからデータベースを設計するのに今更気づいた。
- 505 ：NAME IS NULL：2015/11/24(火) 20:00:17.75 ID:dq6F7Xc9.net
- >>504
インターフェイスって何？
- 506 ：NAME IS NULL：2015/11/24(火) 21:21:06.03 ID:bTXxqVP9.net
- > 748 名前：名無しピーポ君 ：2015/11/24(火) 12:28:48.30
> 噂の日教組保育士がまた報復やったってさ
>
> 749 名前：名無しピーポ君 ：2015/11/24(火) 12:41:16.38
> あーーーー在日居住地にある能満幼稚園の
- 507 ：NAME IS NULL：2015/12/10(木) 17:38:16.52 ID:9MpJNZja.net
- >>504
システム間インターフェイスだとしても、ユーザーインターフェイスだとしても間違っているか？
- 508 ：NAME IS NULL：2015/12/10(木) 17:40:03.26 ID:9MpJNZja.net
- データをどう持つのかを初めから考えていないとUIもデータモデルも失敗する。
- 509 ：NAME IS NULL：2016/01/21(木) 04:46:50.28 ID:???.net
- 途中で持ち方換える事もあるけどな
- 510 ：NAME IS NULL：2016/12/16(金) 06:28:37.13 ID:???.net
- 柔軟に設計しろよ。ただしスタンダードはある。
- 511 ：NAME IS NULL：2017/08/18(金) 10:52:33.77 ID:???.net
- >>216
Googleの検索システムがKVSの御時世に何言ってっだこいつ？
- 512 ：NAME IS NULL：2017/08/18(金) 13:05:23.32 ID:???.net
- >>511
8年前の書き込みに何言ってっだこいつ？
- 513 ：NAME IS NULL：2017/08/18(金) 22:51:50.80 ID:41NDIrx4.net
- >>511
>>512
自演なのかも知れんがクッソワロタ
- 514 ：NAME IS NULL：2017/08/22(火) 21:43:07.29 ID:???.net
- スレタイが気になっから来てみたが
データベース設計を「テーブルレイアウトを決める」という作業と捉えてる時点でDB設計を軽視してるんだよね
テーブル設計はDB設計の中でも末端作業だから、そういう認識から変えたほうがいい気がする
経験上、DB設計出来ますってやつのうち概念設計や論理設計がまともにできるやつは20人に1人いればいいほう
- 515 ：NAME IS NULL：2017/08/23(水) 00:07:55.54 ID:xUh+Pb4A.net
- 論理設計とかについて偉そうに語れるほど
論理設計が出来るとは思ってないが
テーブルを正規化したり
適切なデータ型を決定したり
制約を定義するといったことを
末端作業と言って軽視すのは
どうかと思うよ
- 516 ：NAME IS NULL：2017/08/23(水) 01:15:21.19 ID:???.net
- 軽視してるってわけでもないんだがテーブルレイアウトを決めるのはDB設計全体の一部でしかなく
それも最後のほうにやる作業だって意味
ある業務に関わるデータをどういうデータ構造で管理するのが適切かを考えようとしてる時に
「Excelのフォーマットを決める」ような作業が、RDBなら「テーブルレイアウトを決める」という作業
「どういうExcelフォーマットにしようか」ってのと同じ観点から始めて
テーブル定義書と申し訳程度のER図を書くことがDB設計だと思ってる人がすごく多い
DB設計はテーブルレイアウトを決める作業じゃなくて、DB設計の結果としてテーブルレイアウトが決まる
- 517 ：NAME IS NULL：2017/08/23(水) 02:10:01.71 ID:???.net
- システム設計を「クラスの定義を決める」作業として捉えてるのと同じって言ったほうがわかりやすいか
クラス図とクラス定義書を書くのが設計だと思ってる人はほとんどいないけど
DB設計においてはそのレベルの人がたくさんいるよね
- 518 ：NAME IS NULL：2017/08/23(水) 08:18:56.25 ID:ZPvWL1rI.net
- テーブルを正規化したり
適切なデータ型を決定したり
制約を定義するといったことが
最も大切だよ
それだけの話
それらを必要に応じて
敢えて崩すのはアリだけど
正規化をやらないとかはありえない
- 519 ：NAME IS NULL：2017/08/23(水) 22:05:49.25 ID:???.net
- >>518
それって結局、DB設計をテーブルレイアウトを決める作業と捉えてて
テーブルレイアウトを決めるのにはそれらが最も大切だって言ってるんじゃねーの？
例えば正規化ってOOにおけるSRPやOCPみたいな設計原則に相当するものだよ
SRPに従ってクラスを分けることがシステムやプログラム全体の設計の中で最も大切だったりする？
クラス定義においてならまだ理解できるけどさ
それと同じで正規化の知識は必須だし、業務アプリなら当然その設計原則に従ったモデルを作るんだけど
DB設計において正規化することが最も大切なわけではないよ
- 520 ：NAME IS NULL：2017/08/23(水) 22:20:54.73 ID:HAUVK0b0.net
- >>519
テーブルを正規化したり
適切なデータ型を決定したり
制約を定義するといったことが
最も大切だよ
それより大切なことって何かな？
- 521 ：NAME IS NULL：2017/08/23(水) 22:52:53.62 ID:???.net
- >>1
>何故データベース設計は軽視されるのか？
理由を考えてみたが、教育不足と経験不足が大きな原因だと思う
まず一般的なプログラムの設計に比べてDB設計はその機会自体が圧倒的に少ない
それはプログラムに比べてDBは数も少なくライフライクルも長いし、プログラム設計に比べればDB設計は一人で担当できる規模が大きいから
機会自体が少ないから、業務アプリに関わるエンジニアの中で繰り返し何度もDB設計の経験が積めるような人も当然少ないし
その中でも優れたDB設計者となるともっと少ない
だから一部のDB設計に特化した会社や部門を除くと、かなり大手でもDB設計に関してまともに後進の教育や育成ができるような人はすごく稀
そうでない人たちに教育・育成されたエンジニアが大多数を占めるからDB設計が軽視されることが自然と多くなる
DB設計能力の低いと、どうしてもプログラムの処理に重きを置きがちで
プログラムからデータをどう使いたいかという観点でDBを設計しちゃう人が多い(=DB設計の軽視)
そういうやり方を見てきた人たちはそれが当たり前だと考えるからDB設計軽視が再生産される
個人レベルでは優れた教育を受けたり、数多くの経験を積むことで負の連鎖からは抜け出せそう
会社レベルではDB設計の機会の少なさと重要性を認識して、優れた育成者を多く育てる努力が必須かな
- 522 ：NAME IS NULL：2017/08/23(水) 22:56:37.93 ID:???.net
- >>520
DB設計において最も重要なことは
ビジネスドメインと要求を深く理解して適切なデータモデルを作ること
- 523 ：NAME IS NULL：2017/08/23(水) 23:33:45.34 ID:HAUVK0b0.net
- >>522
ビジネスドメインと要求を深く理解するというのは
そもそもデータベース設計レベルの話かい？
- 524 ：NAME IS NULL：2017/08/24(木) 00:54:44.89 ID:???.net
- >>523
そうだよ
ちゃんとしたデータベース設計には必須だよ
対象のドメインと要求を深く理解しないと適切なデータモデルは作れないから
だからプログラムの実装に近い人がDB設計するよりも
要求分析をする人で技術力もある人がDB設計をしたほうがまともな設計ができることが多いよ
後者の場合は組織や責任者がDB設計にとって何が重要か理解しててDB設計を軽視してないっていう理由も大きいけどね。
- 525 ：NAME IS NULL：2017/08/24(木) 01:09:48.34 ID:3UP+EtyQ.net
- >>524
ふむ
要求分析をする人で技術力もある人が
ビジネスドメインと要求を深く理解して適切なデータモデルを作れば
テーブルを正規化したり
適切なデータ型を決定したり
制約を定義するのは
やらなくて良いと仰りたいなかな？
- 526 ：NAME IS NULL：2017/08/24(木) 01:22:40.19 ID:???.net
- >>523
大局的には「計算機で効率的に処理可能な形式で対象を表現したモデル」――「対象領域の計算機向けモデル」（数理モデルとか、あっちの意味でのモデル）の構築こそが根本であるので、
それを重要視する、ということ？
でも個人的には正規化などのtuple（型）の設計しながらフィードバックしていって上記の概念を理解・把握・構築している感じがある
具象から始まり抽象化する、というか、つまり何なのか、を追求していくとそこに至るというか
なので個人的には>>522 兼 >>520 ww
データベースに長けた人からみるとまた違うのかな？
- 527 ：NAME IS NULL：2017/08/24(木) 01:41:42.12 ID:3UP+EtyQ.net
- >>526
ビジネスドメインと要求を深く理解して適切なデータモデルを作る
という作業の中に
テーブルを正規化したり
適切なデータ型を決定したり
制約を定義する
という作業が内包されてるなら
そもそも比較することが間違い
- 528 ：NAME IS NULL：2017/08/27(日) 03:26:41.28 ID:???.net
- 正規化も、データ型の決定も、それより上位の工程がちゃんとできてれば
ほぼ機械的に決定して薦めれるからなぁ
- 529 ：NAME IS NULL：2017/08/27(日) 11:26:11.65 ID:???.net
- DB設計と、要件定義やモデリングとかとを同一視しすぎてるような気もするな。
本質的に不可分なのだという主張なら、それはそれというか、方向性としてはわかる。
もっとも、そうなるとその線引きは難しいだろうけど。
- 530 ：NAME IS NULL：2017/08/27(日) 13:03:07.94 ID:???.net
- >>528
機械的にやれるからと言って軽視するのが
そもそも間違い
- 531 ：NAME IS NULL：2017/08/27(日) 16:06:51.20 ID:???.net
- >>529
DB設計の一部である概念設計は要件定義の一部
という考え方なので不可分といえば不可分
フェーズの呼び方は会社によって違うだろうけど
要件定義時に概念設計,
基本設計時に論理設計,
詳細設計時に物理設計が基本
DB設計の質を一番大きく左右するのが概念設計
エンティティの漏れやリレーションの間違いがあると
制約の定義漏れやデータ型の選択ミスとは比べられないレベルの悪影響が出る
(正規化の多くは概念設計で行われる)
もっと狭義のDB設計フェーズという考え方があるのかもしれないけど
そういう考え方自体がデータベース設計軽視につながっている可能性があるのかも
- 532 ：NAME IS NULL：2017/08/27(日) 19:45:14.75 ID:???.net
- >>531
その考え方を徹底すると、DB設計はなくなりそう。ｗ
- 533 ：NAME IS NULL：2017/08/28(月) 10:28:40.21 ID:???.net
- >>530
機械的にやれるということと、軽視するということには関連性がない
君はいったい何と戦ってるんだ？
- 534 ：NAME IS NULL：2017/08/28(月) 19:01:17.75 ID:???.net
- >>531
概念設計、論理設計、物理設計のどの段階で正規化するの？
- 535 ：NAME IS NULL：2017/08/28(月) 19:05:55.75 ID:pMau8GL2.net
- >>534
普通は初めから正規化したようなまとまりで考える。
- 536 ：NAME IS NULL：2017/08/28(月) 22:24:53.78 ID:???.net
- 概念モデルに正規化もなにも無いと思うけど
概念を正しく論理モデルにする作業が正規化だろ
- 537 ：NAME IS NULL：2017/08/28(月) 22:34:45.38 ID:???.net
- >>534
>>535の言うとおり、どこかで正規化の工程があるというよりは
最初からほぼ正規化されたモデルで考えて
モデルを改善するたびに正規化違反をチェックしながら都度対応する
なので概念設計が終わったらその段階まででの正規化も終わってる
論理設計時にはサロゲートキーや削除フラグみたいなのが追加されて
正規化が崩れる場合があるからその場合も都度判断して対応する
物理設計では正規化に関わるようなところは基本的にいじらない
DB概念設計のインプットになるようなドメインモデリングをする時は
概念間の関係とわかりやすさを重視するので正規化されてるかどうかは気にしない
- 538 ：NAME IS NULL：2017/12/29(金) 11:16:22.87 ID:dtNZwIie.net
- 誰でも簡単にパソコン1台で稼げる方法など
参考までに、
⇒ 『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。
グーグル検索⇒『宮本のゴウリエセレレ』
DX2Z9GYZ7S
- 539 ：NAME IS NULL：2018/10/13(土) 19:50:55.09 ID:???.net
- https://imgur.com/FAF05na.jpg
- 540 ：NAME IS NULL：2020/03/17(火) 17:13:56.31 ID:???.net
- そういえば、昔、DB仕様が悪くて、日次夜間バッチ処理が2日かかるシステムがあったな。
- 541 ：NAME IS NULL：2020/03/30(月) 23:47:53.57 ID:???.net
- 今の現場にも「正規化！正規化！」キチがおる、確かに少し歪んだところもあるが、締めのバッチなどでやむを得ず放置されている
で、「じゃ、キッチリ正規化してみてよ」ってお願いしたら「影響範囲がー」とか
お前はアホか？お前はそれを改善するために「正規化！」言うてたんやろ
もう。口出しすんなってＰＭに怒られてたわ
- 542 ：NAME IS NULL：2020/03/31(火) 19:03:26.69 ID:Kc++IpJB.net
- わかってないやつほど正規化と言ってしまう。用語で知ったかぶりをする典型例。
- 543 ：NAME IS NULL：2020/03/31(火) 19:48:49.04 ID:???.net
- 「良い設計」を専門用語で言うと「正規化」だと思ってるような奴がこの板にも多いよね
- 544 ：NAME IS NULL：2020/11/27(金) 18:40:16.40 ID:Ej4Euwca.net
- いまどきまったく正規化されていない表を思いつく方が難しい。
- 545 ：NAME IS NULL：2020/11/28(土) 00:34:19.70 ID:???.net
- それが難しいようじゃあデータベース設計に向いてないんじゃないかねぇ。
- 546 ：NAME IS NULL：2020/11/28(土) 00:44:18.27 ID:???.net
- >>545
データベース設計よりも、日本語が向いてなさそう。ｗ
- 547 ：NAME IS NULL：2020/11/28(土) 00:56:27.32 ID:???.net
- 本人は本気で「難しい」と思ってるのかもしれんよ
- 548 ：NAME IS NULL：2020/11/29(日) 21:29:54.99 ID:ytxd6aPT.net
- すべてを2次元の表であらわしているデータなんて、Excelでも見たことない。
- 549 ：NAME IS NULL：2020/11/29(日) 22:03:27.79 ID:???.net
- つか、RDBの表は2次元じゃないがな。
- 550 ：NAME IS NULL：2020/11/30(月) 01:35:47.36 ID:???.net
- テーブルのことを表、インデックスを索引と呼ぶのはいまだに違和感がある
- 551 ：NAME IS NULL：2020/12/02(水) 22:02:19.48 ID:VAfE8mAC9
- 副業、大手も制度着々…コロナ禍、働き手は空き時間活用
https://www.itmedia.co.jp/business/articles/2009/07/news111.html
富士通「年収3500万円」の衝撃 ソニー、NECも戦々恐々の「グローバル採用競争」
https://www.itmedia.co.jp/business/articles/2008/21/news031.html
東大の起業ラッシュは本物か、大学発ベンチャー数日本一の実力
https://business.nikkei.com/atcl/NBD/19/special/00448/
AI研究の第一人者、東大・松尾研でも起業ラッシュ
https://business.nikkei.com/atcl/gen/19/00158/051900002/?i_cid=nbpnb_arc
失敗は認める、多数決はダメ。拡大する「社会起業家集団」の作り方
https://newswitch.jp/p/23033
新卒“即”起業せよ。社会起業家への最短距離に挑む若者たち
https://newswitch.jp/p/23020
人々の共感を得られないと潰される時代。
https://news.yahoo.co.jp/articles/37aef71415e8181ce8451e27feb3983bf1f6f9cd
ゼロから起業するよりも事業承継（小さな会社の買収）が圧倒的に有利である3つの理由
https://honsuki.jp/pickup/17323.html
「エース人材だって起業OK」、NECは挑戦者が集う場をつくる
https://business.nikkei.com/atcl/gen/19/00106/012900003/
NECなど「出向起業」 大企業人材、起業しやすく
https://www.nikkei.com/article/DGXMZO61733720Q0A720C2TJ1000/
- 552 ：NAME IS NULL：2020/12/04(金) 10:47:51.96 ID:RVC9j45Y.net
- 軽視していないけど、人間の脳には難しいからだよ。
人件費がいくらあっても足りない。
ディープラーニングに任せたほうがいい分野だよ。
- 553 ：NAME IS NULL：2020/12/04(金) 21:54:56.41 ID:???.net
- 設計のどの部分をディープラーニングに任せるって話なんだろうか
- 554 ：NAME IS NULL：2020/12/08(火) 01:32:48.66 ID:TMPxYOvH.net
- >>549
あなた職場では嫌われているよね
- 555 ：NAME IS NULL：2020/12/08(火) 01:33:42.67 ID:TMPxYOvH.net
- >>550
製品マニュアルを呼んだことがありますか？
- 556 ：NAME IS NULL：2020/12/08(火) 01:34:02.37 ID:TMPxYOvH.net
- >>550
製品マニュアルを読んだことがありますか？
- 557 ：NAME IS NULL：2020/12/08(火) 02:01:56.21 ID:???.net
- >>554
おまえもそうやと思うで？
- 558 ：NAME IS NULL：2020/12/28(月) 18:37:06.97 ID:???.net
- 軽視したくないけどさ、設計が良いかどうかってどうやって見分けるの？
正規化をバカにする人が多いけど、あれ以外に人に教えられる観点ってあるのか？
- 559 ：NAME IS NULL：2020/12/28(月) 21:49:44.98 ID:???.net
- RDBに関して言えば正規化ほど体系化されててわかりやすい観点は他にはないね
良い設計かどうかは求められた状況に対してどれだけ高い品質特性を備えているかで
観点としては機能性以外に使いやすさ、わかりやすさ、堅牢性、運用性、耐障害性、
保守性(柔軟性/拡張性/変更容易性)、効率性(時間/資源)、移植性なんかがある
正規化はデータ整合性、使いやすさ、保守性あたりを高めようとするもの
- 560 ：NAME IS NULL：2020/12/28(月) 22:15:27.79 ID:???.net
- 正規化は非正規形で起きる問題(更新異常等)を防ぐものであってそれ以上ではない。
実際、更新異常を考慮する必要のないDWHなどでは不要。
- 561 ：NAME IS NULL：2020/12/28(月) 22:49:55.68 ID:???.net
- >>560
DWHでも更新異常は考慮する必要あるよ
更新異常ってCRUDのUだけのことじゃないから
DWHは正規化が不要なんじゃなく
ソースデータの正規形をベースに特定の分析用途に特化させて非正規化してるだけ
スタースキーマもスノーフレークもDWHに特化した非正規化パターン
非正規形のデメリットはDWHだろうがOLTPだろうが同じ
- 562 ：NAME IS NULL：2020/12/28(月) 23:05:07.35 ID:???.net
- >ソースデータの正規形をベースに特定の分析用途に特化させて非正規化してるだけ
正規形非正規形というのはあくまでもリレーションの表現であって抽象的なデータモデルには
そんな区別はないんだが。
だからDWHにおいて
>ソースデータの正規形
通常これは実在しない。
- 563 ：NAME IS NULL：2020/12/28(月) 23:56:41.44 ID:???.net
- >>562
ごめん、何言ってるかわからない
抽象的なデータモデルって何のこと？ どっから出てきたの？
- 564 ：NAME IS NULL：2020/12/29(火) 03:14:05.40 ID:???.net
- 更新異常が発生しにくいだけで
考慮する必要がないわけないわな
>>562はエアプが即バレして煙に巻きたいのだろう
- 565 ：NAME IS NULL：2020/12/29(火) 09:14:29.22 ID:???.net
- >ソースデータの正規形
これが抽象的なデータモデルを指しているのかと思ったんだが、そうでないなら話は簡単。
DWHは「ソースデータの正規形」が存在することを要求しないんで>>561は正しくない。
データソースが正規化された他のDBであることはあるが、それはそのシステム自身の
要求によって正規化されているだけ。
- 566 ：NAME IS NULL：2020/12/29(火) 12:56:45.72 ID:???.net
- >>558
正規化がバカにされてるんじゃなく
正規化を理解してなかったり正規化されてるかどうか以外にDB設計を見る目がないのに
ドヤ顔でDB設計を語ろうとしてる人間がバカにされてるんだと思うぞ
- 567 ：NAME IS NULL：2020/12/29(火) 14:29:23.16 ID:???.net
- それな
ちょうど当てはまるやつがいるな
- 568 ：NAME IS NULL：2020/12/29(火) 14:46:08.18 ID:???.net
- 頭おかしいやつには下手に触らず黙ってスルー推奨
- 569 ：NAME IS NULL：2020/12/30(水) 00:27:51.52 ID:???.net
- RDBと関係ないRやPython使った統計処理の分野でも
分析をやりやすくするために下準備としてDBで言うところの正規化をしてる
更新異常を考慮する必要は全くないけど
- 570 ：NAME IS NULL：2020/12/30(水) 09:11:39.06 ID:???.net
- そういうのごっちゃにすると話が発散するからやめて。
そもそもその「正規化」って、リレーションの正規化と違ってなにをどうするかきちんと定義されたものじゃないでしょ。
- 571 ：NAME IS NULL：2020/12/30(水) 09:15:25.16 ID:???.net
- それに統計解析向けの加工って、クレンジングは最初に必要かもしれないけどあとは解析しやすいようにJOINしまくるのがふつう。
DWHのスタースキーマから任意に抽出した1つの表の形のデータセット、あれがまさに統計解析向けのもの。
- 572 ：NAME IS NULL：2020/12/30(水) 18:11:29.74 ID:???.net
- エアプDWHの次はエアプ統計解析かよw
なんでろくにやったこともない事を語りたがるのかね
- 573 ：NAME IS NULL：2020/12/30(水) 18:23:27.87 ID:???.net
- データベース設計は軽視されるの原因と
エアプ野郎が語りたがる原因の一つに
素人に毛が生えたような人間には難しさが分からず
自分でもできそうに思えてしまうところにある
- 574 ：NAME IS NULL：2020/12/30(水) 22:22:42.93 ID:???.net
- >>572
誰のどのレスに対して言っているのか曖昧でよくわからんが、とりあえずどのレスの
どこがどう違っているのかはっきり書いたら？
反論は受けたくないけどマウントだけ取った気分になりたい中学生じゃなけりゃ。
- 575 ：NAME IS NULL：2020/12/31(木) 00:08:25.03 ID:???.net
- エアプ素人さんはスタースキーマのファクトとディメンションがそれぞれ第何正規形か考えると良いと思うよ
>>566の言葉を借りれば正規化すら理解してないのにドヤ顔で語ろうとしてるのが丸わかりだから
- 576 ：NAME IS NULL：2021/01/02(土) 16:36:20.20 ID:2lMlvbHe.net
- ど底辺の土方グラマーだけどDB設計させられて「なんでちゃんとしたDB屋に頼まないんだよ、DBって根幹部分で大切だろ！」って疑問だったけどここ見て納得。
日本の企業が作る(使う）システムがクソな理由も・・・
- 577 ：NAME IS NULL：2021/01/02(土) 18:35:41.55 ID:???.net
- ある意味当たってる。
そうやってしばらくして、曲がりなりにもER図書いたり正規化ができるようになって
いっぱしのDB屋を気取れるようになったら彼等の仲間入り。
- 578 ：NAME IS NULL：2021/01/03(日) 14:52:40.06 ID:???.net
- >>576
根幹部分だからこそDB中心のシステムを作る開発者なら誰もが身につけておくべきスキルだぞ
要件定義や基本設計を含めて依頼するならともかく
DB設計だけを外部に依頼するのは今の時代にはそぐわないので設計専業のDB屋は絶滅危惧種
- 579 ：NAME IS NULL：2021/01/04(月) 05:23:06.48 ID:THUOMM/C.net
- ホンマにうわさ以上に凄いのが金さんの億様株レシピて投資ブログ。
ここまじで神すぎる！
めちゃ当てまくる。
おすすめなのは危険な銘柄と宝石の銘柄て記事に出てくる銘柄。
- 580 ：NAME IS NULL：2021/01/11(月) 02:01:22.68 ID:FK6r9Thn9
- プログラミングにはやってはいけない勉強法がある！？爆速で成長する王道のプログラミング学習法を紹介！
https://www.youtube.com/watch?v=ZJqVQJwvwNI
慶應主席レベルの秀才がプログラミングの独学に失敗した理由
https://www.youtube.com/watch?v=F2m1bsqaAHg
知らずに転職したら失敗する！ブラックIT企業を見分ける11のポイントを徹底解説
https://www.youtube.com/watch?v=a8qDFMsYAqM
営業マンが独学のみでプログラマーに転職して1年で月収80万超えた話
https://www.youtube.com/watch?v=94YQSckQGCs
未経験から2年でフリーランスエンジニアに！安定的に稼げるようになるための5ステップ
https://www.youtube.com/watch?v=oGNpEmFOEcU
フリーランスエンジニアになるなら大規模ベンチャー or 小規模ベンチャー どっち？
https://www.youtube.com/watch?v=-39tg9icRlU
生産性10倍！知らないと損する3つの最強デザインツール
https://www.youtube.com/watch?v=z6x1R1455Kc
- 581 ：NAME IS NULL：2021/01/12(火) 12:19:00.49 ID:???.net
- プログラム組まないやつが設計すると保守性重視になるよな…
人間がパッと見て理解しやすい設計にしがち
ナチュラルキー多用したり
- 582 ：NAME IS NULL：2021/01/12(火) 15:18:33.28 ID:???.net
- >>581
ナチュラルキーを多用してるにもかかわらず保守性が高いならいいんじゃね
- 583 ：NAME IS NULL：2021/01/12(火) 16:22:51.65 ID:???.net
- >>582
>>581は「保守性」と言っちゃってるが、実はたぶん保守性の話やないな。
初見のわかりやすさしか見えてないような、困ったちゃんの話なんやろな。
- 584 ：NAME IS NULL：2021/01/12(火) 17:06:29.79 ID:???.net
- そうすると保守性を理解してない>>581が困ったちゃんってことになる
- 585 ：NAME IS NULL：2021/01/12(火) 17:48:57.44 ID:???.net
- すまん、保守性って言葉が悪かったな
プログラムの保守性ではなくて
ユーザーからの問い合わせ時にデータ見てパッとわかるテーブル構造を好む
- 586 ：NAME IS NULL：2021/01/12(火) 20:38:59.75 ID:???.net
- 人間にとっての見やすさというかわかりやすさも重要な品質要素だからね
それを犠牲にして得られるメリットとのバランス次第
何と何をトレードオフしようとしてるのか理解してないうちはまともな設計は期待できない
- 587 ：NAME IS NULL：2021/01/12(火) 21:08:10.26 ID:???.net
- パッと見理解しやすくて保守性も高いならいいことずくめに読めるが。
たぶん言いたいことは逆になにか問題があるということなんだろうけど
結論書いてないから何を言いたいのかわからない。
- 588 ：NAME IS NULL：2021/01/12(火) 21:28:46.10 ID:???.net
- >>587
理解力なさすぎ。
人工キー+JOIN前提みたいな、不慣れだとややこしげに見えるテーブルを組みたがらない素人の話なだけやろ。
- 589 ：NAME IS NULL：2021/01/12(火) 21:37:08.48 ID:???.net
- だから、そこで自然キーの欠点や人工キーの利点を説明しなきゃ何を言いたいのかわからんだろ。
人工キーが自然キーより優れているのは自明だと思ってるとかそんなとこかね。
- 590 ：NAME IS NULL：2021/01/12(火) 21:45:26.42 ID:???.net
- >>589
SQL書くときに条件や結合は少ないほうがバグが発生しにくい
プログラマにとってはサロゲートキーの方がわかりやすい
しかしサロゲートキーだと生データを見たときにわかりにくいことがある
ナチュラルキーとサロゲートキーの代表的なメリットデメリットだと思うけど…
その辺天秤にかけてこのテーブルはサロゲートキー、このテーブルはナチュラルキーと決定できるのは
設計もプログラムも保守もやる人。
どれか一つしかやらない人はこのへんのさじ加減わからないのでは。
- 591 ：NAME IS NULL：2021/01/12(火) 21:57:42.32 ID:???.net
- こうやってブレイクダウンするとどこに誤解があるか見えてくる。
複合キーは扱いづらいのでかわりにサロゲートキーを使うことはあるが
自然キーだと一律にサロゲートキーより扱いづらいなんて理由はないだろう。
- 592 ：NAME IS NULL：2021/01/12(火) 22:30:44.50 ID:???.net
- >>591
おっしゃる通り複合キーの場合だな
大変失礼しました
設計と保守しかしない年配のSEさんはサロゲートキーを知らずに複合キーを使いまくる傾向にある
プログラマは若かったり雇われだったりなので口出しできずにクソシステムの出来上がり
- 593 ：NAME IS NULL：2021/01/12(火) 22:34:47.77 ID:???.net
- >>591
めんどくさ。
そんな話じゃなかったやろ。。。
おまえは、自分が理解できない話を、自分が理解できるようにしたいだけ。ｗ
何が「ブレイクダウン」や。ｗ
- 594 ：NAME IS NULL：2021/01/12(火) 22:41:52.84 ID:???.net
- >そんな話じゃなかったやろ。。。
どういう話なのか、お前はまず言いたいことを結論からハッキリ書くようにしろ。
- 595 ：NAME IS NULL：2021/01/13(水) 00:21:46.78 ID:???.net
- 呼び名はともかく人工キーは80~90年代でも普通に使われてただろうから年配だろうが知らないわけない
複合キーは見てわかりやすいわけじゃないが
人工キーに比べると整合性を維持する設計が簡単なんだよ
SQL書く時は面倒くさいから嫌がられるけど不整合が発生するのに比べればマシだから
- 596 ：NAME IS NULL：2021/01/13(水) 00:38:42.76 ID:???.net
- >>594
自分の理解力を棚に上げんなよ。
- 597 ：NAME IS NULL：2021/01/13(水) 00:53:04.45 ID:???.net
- >>595
不整合はユニーク制約つければいいんでないの
- 598 ：NAME IS NULL：2021/01/13(水) 08:06:07.69 ID:???.net
- 同じ型の単純キー同士なら、それが自然キーか人工キーかで扱いやすさが変わることはないやね。
- 599 ：NAME IS NULL：2021/01/13(水) 08:13:51.20 ID:???.net
- >>598
変わらない
複合キーが問題
- 600 ：NAME IS NULL：2021/01/14(木) 02:05:44.63 ID:???.net
- >>595
ちょっと、「整合性を維持する設計」について詳しく説明してくれ
- 601 ：NAME IS NULL：2021/01/20(水) 22:55:59.22 ID:LfU5rlWt.net
- >>558
仕様変更に強いかどうか。それと人間にとってわかりやすいかどうか。正規化の話はもっともらしいが、ちゃんとしたテストと運用・保守をやっていれば、ただの非現実的な理屈だとわかる。
- 602 ：NAME IS NULL：2021/01/20(水) 23:01:10.32 ID:LfU5rlWt.net
- >>595
論理的な整合性をアプリケーションで担保する。そうでないとアプリケーションのテストも難しい。
- 603 ：NAME IS NULL：2021/01/20(水) 23:02:58.59 ID:LfU5rlWt.net
- >>600
彼はアプリ屋と壁を作るタイプだから、かかわらない方がいいよ。
- 604 ：NAME IS NULL：2021/01/20(水) 23:16:12.27 ID:???.net
- >>601
アホなの？
- 605 ：NAME IS NULL：2021/01/22(金) 08:45:35.16 ID:???.net
- >>601
このちゃんとした
ってのがどれだけ難しいか
- 606 ：NAME IS NULL：2021/01/25(月) 05:16:41.94 ID:cGhuaVFN.net
- よく読め
- 607 ：NAME IS NULL：2021/03/07(日) 00:02:21.33 ID:MYaT20ZKW
- 26歳で独立して月収150万になった 元引きこもりエンジニアの物語
https://agroro.com/2020/05/06/prof/
【こんな僕が】フリーランスエンジニアで月収100万円を達成した5つの方法
https://takablog358.org/freelance-programmer-income/
ITフリーランスエンジニアの年収｜会社員との違いや独立後の案件の取り方
https://boxil.jp/mag/a6287/
月収90万のITフリーランスプログラマー・SEが選んでる在宅案件はこんな案件です
https://arma-search.jp/article/homework
フリーランスの年収は平均いくら？年収1000万円以上の割合とは
https://freelance.levtech.jp/guide/detail/1242/
フリーランスの仕事や職業の種類って何があるの？独立5年目で月収200万の僕が詳しく解説
https://www.buntadayo.com/entry/job-change-freelance
ブラック企業から退職し、独立後11ヶ月で“月収300万円超え”になるまでの軌跡を
デザイナー社長船越良太に聞いてみた！
https://tokyofreelance.jp/interview-funakoshi/
- 608 ：575：2021/06/22(火) 17:07:34.18 ID:???.net
- ははは・・・
晴れて？「DB屋（）」の仲間入りしそうだ・・・
PostgreSQL9.3とSQLServer2005を、プライベートで、弄ったことあるだけなのに（実務ではOracle11の炎上案件の燃料として放り込まれたぐらい）
7月からPostgreSQL12がフロントエンドで、Oracle（ナンバリングは効いてない）がバックエンドで動いてる「工場のFAのすごいやつと思えば間違いじゃない（スマートファクトリー）」とかいう謎の説明されたシステムのDBチームに配属になったわ・・・
メカ系や移動体通信系のファームしか経験ないつにいきなり・・・
ズブの素人よりはマシかもしれないけどDBそのもののスキルだったらそこらの学生以下だよ俺・・・orz.
- 609 ：NAME IS NULL：2021/06/22(火) 18:09:02.74 ID:???.net
- いまどきDBでチームがあるのか
ある意味すごいな
- 610 ：NAME IS NULL：2021/06/22(火) 18:59:21.66 ID:wVCfrFWc.net
- >>609
開発対象が、工場の機械からデータ受け取る中継ボックスみたいなところから、工場の中間サーバから複数の工場の情報をまとめるサーバまで一貫してるんだそうな。
そして中継ボックス、中間サーバ、全体の情報あつめるサーバってのを全部面倒見てる１０人ほどのチームとのこと。
まだ現場に入ってないから実態判らんけど、門外漢な俺を採用しちゃうところだし、上下どころか横の連携もまともにとれないようなカオスなところでもおかしくないって個人的な経験則が言ってる。
他に仕事ないから受けたけど、今から「どんなとこかなー？ 抜けるとしたらどうやって抜けようかなー？」って考えてるｗ
- 611 ：NAME IS NULL：2021/06/22(火) 21:26:23.41 ID:???.net
- もし関係者が見たら、特定できそうやな。ｗ
ほどほどにしとけよ。
- 612 ：NAME IS NULL：2021/06/26(土) 18:20:28.11 ID:???.net
- データベースのテーブル設計書ってどうしてる?
エクセル方眼紙にしてかいてるんだけど、なんかいいのないのかな
- 613 ：NAME IS NULL：2021/06/26(土) 23:14:34.00 ID:???.net
- >>612
MySQL Workbenchはどや？
最近は使ってないから知らんが。
- 614 ：NAME IS NULL：2021/07/03(土) 17:38:43.26 ID:R35jReGz.net
- >>612
A5Mk-Ⅱがよく使われている。
- 615 ：NAME IS NULL：2021/10/13(水) 12:36:34.50 ID:???.net
- データベーススペシャリストでよく問われるページサイズとか空き容量率とかどのメーカーのDBをターゲットにしてるんや？
教えてくれ
- 616 ：NAME IS NULL：2021/10/13(水) 13:54:50.17 ID:???.net
- 特にどのDBMSをターゲットにしてるとかないぞ
一般的なBTreeを前提にしてるだけ
- 617 ：ド底辺PG：2021/11/10(水) 22:00:45.28 ID:KaB0M86I.net
- プロジェクトが燃え尽きたから別の案件に燃料しに行ったんだが、TEXT（可変長文字列）をPKにしてINDEX張ってて「パフォーマンス出ねぇ！」ってやってんですけど・・・
ちょう乱暴に描くと
CREATE TABLE T_TAGS(
JPN AS TEXT NOT NULL,
ENG AS TEXT,
・・・品詞とか同義語とかの定義いろいろ・・・
PRIMARY KEY(JPN)
)
て感じの定義で、SELECTのサブクエリとかでも ON TBL1.JPN = ・・・ みたいにテキストのカラムをJOINしてるんすよ？
ドテ・イ・ヘーンな俺でも「なんで数値でIDのカラムを作らないの？」ぐらいの疑問はあるんだけど、
これって「データベースあるある」だったりするの？
- 618 ：NAME IS NULL：2021/11/10(水) 22:40:02.10 ID:???.net
- 遅いのがTEXTのせいだってどうやって判断したの？
- 619 ：NAME IS NULL：2021/11/11(木) 00:02:07.19 ID:???.net
- >>617
>これって「データベースあるある」だったりするの？
文字列をPKに使うかどうかは状況による
絶対避けるというほどのものでもない
個人的には可変長は極力避けるけどパフォーマンスクリティカルなシステムじゃなければ
全部可変長で揃えてても特に問題なかったりする
PKを数値にしたバージョン作ってさくっと比較すればいいんじゃん？
- 620 ：NAME IS NULL：2021/11/11(木) 19:06:31.16 ID:NSxyRLjO.net
- >>617
あなたの言っていることは頭がおかしいくらい変なことを言っている。
たまたまいままで見てきたテーブルの主キー項目が数値型だっただけで、根拠のない思い込みをしてないか？
念を押すと、頭のおかしい発言だぞ。
- 621 ：NAME IS NULL：2021/11/11(木) 19:36:50.37 ID:NSxyRLjO.net
- >>617
そのTEXT型がラージオブジェクト型というオチのネタ書き込みじゃないだろうな？
- 622 ：NAME IS NULL：2021/11/11(木) 20:16:55.16 ID:???.net
- >>620
そこまでやないやろ。ｗ
テキストはCOLLATEの懸念があるし、 数値のが望ましいのはたしかやし。
まあ、遅いのはテキストキーやからと決めつけてかかってるところはアタマ弱そうやが。
EXPLAINしろっつーの。
- 623 ：ドテ・イ・ヘーン：2021/11/11(木) 21:02:49.02 ID:xQZydvmR.net
- 俺の思い込みが解消されないレベルの現場という前提を認識ください m(_ _)m
マジ学生以下よ、俺のスキル・・・・
EXCELを読んでDBに追記して、DBを参照してEXCELに吐き出すっていう単機能のモジュール２つを並行して「これ、改良して」ってソースだけ渡されたんすよ！
周りが「おそいおそい！」って騒いでて「どんなもんじゃらほい？」って見たらJOINが５～６個あってTEXTのカラムでつないでたんよ。
さすがにSELECTのWHERE句でIN使うほどじゃなかったけど、そういうSQLあっても不思議じゃないレベルのある意味読みやすいSQLでしたｗ
あと、遅いの根拠が「本番で使ってる高負荷に耐える超高性能マシン」で動かした旧バージョンと「テスト用のレンタル屋から借りてるそこそこの性能のマシン」で動かした新バージョンというね・・・
何の比較にもなってねぇじゃん！
という新事実が発覚して、馬鹿らしくなったので今日は仕事放り出して酒飲んできましたｗ
- 624 ：NAME IS NULL：2021/11/11(木) 21:39:46.36 ID:6iIlck1C.net
- 説明の仕方でもうダメ
- 625 ：NAME IS NULL：2021/11/11(木) 21:41:27.49 ID:6iIlck1C.net
- Excelは何と関係があるのか？
- 626 ：NAME IS NULL：2021/11/11(木) 21:41:54.34 ID:6iIlck1C.net
- 何が遅いのかまったくわかってねえな
- 627 ：NAME IS NULL：2021/11/11(木) 23:17:34.86 ID:???.net
- charやvarcharの文字列って意味でtextって言ってるんじゃなくtext型って話だったのか・・
sqliteならともかくそれ以外のメジャーなサーバー系DBMSでtext型をPKにすることはまずないぞ
- 628 ：NAME IS NULL：2021/11/12(金) 00:22:09.87 ID:???.net
- >>623
まとめたら、スペックの違いやろ。
一言ですむわ。ｗ
- 629 ：NAME IS NULL：2021/11/27(土) 20:05:57.75 ID:l5sFA9ZC.net
- よくわかってないクライアントがよくわかってないSEに文句言って
よくわかってないフィルターで「お前らの作ったシステム遅いぞゴラァ！」ってなって現場に届くあるある案件ですな。
- 630 ：NAME IS NULL：2022/02/12(土) 03:16:43.64 ID:Nh8yTOt3.net
- >>629
性能要件があって、データが増えてもパフォーマンスに問題がないと一言、入っているだけで違うのにな。
- 631 ：NAME IS NULL：2022/02/17(木) 18:59:32.20 ID:???.net
- まあ、最近はフルSSDのストレージで構築したからsqlがとても早いです。statpack見るととんでもなくディスクREADしてるアホsqlあるけど、システム影響なし、いいんだか悪いんだかですねー
- 632 ：NAME IS NULL：2022/02/22(火) 20:09:39.42 ID:P63gZsOo.net
- >>631
それで解決したことにするとSSDでもどうにもならないSQLが増産されることになる。
- 633 ：NAME IS NULL：2022/03/24(木) 22:48:04.07 ID:blhKkXUv.net
- お前ら和歌山県出身の下村拓郎様（35歳独身、元自衛隊）をご存知か、この方は将来素晴しい人物になるから覚えておいて損はないぞ
- 634 ：NAME IS NULL：2022/06/01(水) 14:23:26.36 ID:???.net
- スキーマの意味よくわかってないけどスキーマ設計書にテーブル構成書いてるよ
- 635 ：NAME IS NULL：2022/06/01(水) 17:38:04.59 ID:???.net
- それっぽく聞こえるもんねw
- 636 ：NAME IS NULL：2022/06/01(水) 20:43:48.71 ID:1CNMa44D.net
- スキーマの概念が後付けの製品しか知らないんだろうな
- 637 ：NAME IS NULL：2022/06/01(水) 20:44:36.18 ID:1CNMa44D.net
- 論理的な意味でも括りというのは必要
- 638 ：NAME IS NULL：2023/04/11(火) 20:09:59.45 ID:+S9P9M6L.net
- ER図を見てもよくわからない設計は典型的なダメパターン
だか大手SIerの人間はテストも運用も保守もしたことがないので、理解不能な理屈で設計したがる。
- 639 ：NAME IS NULL：2023/07/08(土) 11:55:41.75 ID:Dzd22CIu.net
- 今月から、某メーカー系の現場入り。
50万件ぐらいしか入っていない商品マスターを検索するサイトが激重。
DB設計がもろこぼらーの発想。苦言をやんわり現場に伝えたつもりだが、超絶俺様気質の担当者で、聞き入れる気配なし。
逃げたい。
ちなみに、私はデータベーススペシャリスト餅。
- 640 ：NAME IS NULL：2023/07/08(土) 12:27:10.70 ID:???.net
- よくある話。
「こぼらーの発想」とか言ってもどこがどう悪いのか他人には伝わらんだろうし。
- 641 ：NAME IS NULL：2023/07/08(土) 14:07:15.72 ID:???.net
- 正規化って概念がないんだろうな
エクセル感覚であるだけ用意する設計なんだろ
- 642 ：NAME IS NULL：2023/07/08(土) 14:41:30.21 ID:???.net
- 検索が重いとしか書かれていないのに正規化が出てくる人もどっこいどっこい。
- 643 ：NAME IS NULL：2023/07/08(土) 17:41:12.84 ID:???.net
- >ちなみに、私はデータベーススペシャリスト餅。
オレはお前から逃げたいｗ
- 644 ：NAME IS NULL：2023/07/09(日) 05:25:53.28 ID:Yld3I0en.net
- こぼらーがなぜ嫌われるかをこぼらー自身は検証もしないし、俺流正義マンで権力まで持ってたら。。。。
出くわしたら逃げるしかないんだろうか？
- 645 ：NAME IS NULL：2023/07/09(日) 09:49:24.47 ID:???.net
- いまどきCOBOL知ってる人も少ないだろうしどこがどのように問題かという具体的な指摘もないから
傍で見ていてよくわからんのよね。検証のしようもないだろう。
- 646 ：NAME IS NULL：2023/07/09(日) 15:34:31.38 ID:???.net
- RDBをよく知らない構造化ファイル時代のコボラーはJOINを嫌い
COBOLプログラムから一番扱いやすい形の構造化ファイル風にテーブルを作る
でもそんな時代は30年近く前に終わってる上に定形検索だけなら遅くはならないので
データベーススペシャリスト餅ｗが表面しか見ていないだけだろう
- 647 ：NAME IS NULL：2023/07/09(日) 22:27:42.41 ID:???.net
- 「コボラー」と言っとけば多分反論は来ないしお手軽にマウントとった気分になれる便利なワード。
- 648 ：NAME IS NULL：2023/07/10(月) 06:12:24.27 ID:???.net
- このスレなんてそれが生き甲斐のやつばかりじゃん
初心者の質問にはまともに答えず、馬鹿にして溜飲を下げるだけ
- 649 ：NAME IS NULL：2023/07/10(月) 22:30:41.83 ID:???.net
- ところで構造化ファイルってどんなん？
- 650 ：NAME IS NULL：2023/08/18(金) 08:33:02.53 ID:???.net
- ﾎﾎﾎ!(^O^)
- 651 ：NAME IS NULL：2023/09/30(土) 00:06:07.97 ID:???.net
- まじかよ、それはありえんわ
- 652 ：NAME IS NULL：2023/10/03(火) 22:53:58.05 ID:puC6ODCi.net
- VSAMとか悪名高いよな
- 653 ：NAME IS NULL：2023/12/03(日) 23:59:55.07 ID:???.net
- VSAM
- 654 ：NAME IS NULL：2024/03/07(木) 18:22:53.35 ID:4BnqPTKi.net
- 処理速度の遅さが頻繁に問題になっていても、めちゃくちゃな設計とめちゃくちゃなSQLを使うのが優秀な開発者なのがITの世界ではエリートだったりするからなあ
目に見えない部分は評価されにくい
- 655 ：NAME IS NULL：2024/03/09(土) 19:05:23.11 ID:???.net
- 推敲してレスしなおしてくれないか
- 656 ：NAME IS NULL：2024/03/09(土) 21:29:57.56 ID:sC2bZ4HS.net
- 有名製品でもデータモデルはひどかったりする
- 657 ：NAME IS NULL：2024/04/19(金) 07:20:06.15 ID:0Ztguvb/.net
- アプリ開発者がただの入れ物として設計してしまうからなあ
189 KB
新着レスの表示
掲示板に戻る
全部
前100
次100
最新50
read.cgi ver 2014.07.20.01.SC 2014/07/20 D ★