X



何故データベース設計は軽視されるのか?
0538NAME IS NULL2017/12/29(金) 11:16:22.87ID:dtNZwIie
誰でも簡単にパソコン1台で稼げる方法など
参考までに、
⇒ 『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。

グーグル検索⇒『宮本のゴウリエセレレ』

DX2Z9GYZ7S
0540NAME IS NULL2020/03/17(火) 17:13:56.31ID:???
そういえば、昔、DB仕様が悪くて、日次夜間バッチ処理が2日かかるシステムがあったな。
0541NAME IS NULL2020/03/30(月) 23:47:53.57ID:???
今の現場にも「正規化!正規化!」キチがおる、確かに少し歪んだところもあるが、締めのバッチなどでやむを得ず放置されている
で、「じゃ、キッチリ正規化してみてよ」ってお願いしたら「影響範囲がー」とか
お前はアホか?お前はそれを改善するために「正規化!」言うてたんやろ
もう。口出しすんなってPMに怒られてたわ
0542NAME IS NULL2020/03/31(火) 19:03:26.69ID:Kc++IpJB
わかってないやつほど正規化と言ってしまう。用語で知ったかぶりをする典型例。
0543NAME IS NULL2020/03/31(火) 19:48:49.04ID:???
「良い設計」を専門用語で言うと「正規化」だと思ってるような奴がこの板にも多いよね
0544NAME IS NULL2020/11/27(金) 18:40:16.40ID:Ej4Euwca
いまどきまったく正規化されていない表を思いつく方が難しい。
0545NAME IS NULL2020/11/28(土) 00:34:19.70ID:???
それが難しいようじゃあデータベース設計に向いてないんじゃないかねぇ。
0546NAME IS NULL2020/11/28(土) 00:44:18.27ID:???
>>545
データベース設計よりも、日本語が向いてなさそう。w
0547NAME IS NULL2020/11/28(土) 00:56:27.32ID:???
本人は本気で「難しい」と思ってるのかもしれんよ
0548NAME IS NULL2020/11/29(日) 21:29:54.99ID:ytxd6aPT
すべてを2次元の表であらわしているデータなんて、Excelでも見たことない。
0549NAME IS NULL2020/11/29(日) 22:03:27.79ID:???
つか、RDBの表は2次元じゃないがな。
0550NAME IS NULL2020/11/30(月) 01:35:47.36ID:???
テーブルのことを表、インデックスを索引と呼ぶのはいまだに違和感がある
0551NAME IS NULL2020/12/04(金) 10:47:51.96ID:RVC9j45Y
軽視していないけど、人間の脳には難しいからだよ。
人件費がいくらあっても足りない。
ディープラーニングに任せたほうがいい分野だよ。
0552NAME IS NULL2020/12/04(金) 21:54:56.41ID:???
設計のどの部分をディープラーニングに任せるって話なんだろうか
0553NAME IS NULL2020/12/08(火) 01:32:48.66ID:TMPxYOvH
>>549
あなた職場では嫌われているよね
0554NAME IS NULL2020/12/08(火) 01:33:42.67ID:TMPxYOvH
>>550
製品マニュアルを呼んだことがありますか?
0555NAME IS NULL2020/12/08(火) 01:34:02.37ID:TMPxYOvH
>>550
製品マニュアルを読んだことがありますか?
0556NAME IS NULL2020/12/08(火) 02:01:56.21ID:???
>>553
おまえもそうやと思うで?
0557NAME IS NULL2020/12/28(月) 18:37:06.97ID:???
軽視したくないけどさ、設計が良いかどうかってどうやって見分けるの?
正規化をバカにする人が多いけど、あれ以外に人に教えられる観点ってあるのか?
0558NAME IS NULL2020/12/28(月) 21:49:44.98ID:???
RDBに関して言えば正規化ほど体系化されててわかりやすい観点は他にはないね

良い設計かどうかは求められた状況に対してどれだけ高い品質特性を備えているかで
観点としては機能性以外に使いやすさ、わかりやすさ、堅牢性、運用性、耐障害性、
保守性(柔軟性/拡張性/変更容易性)、効率性(時間/資源)、移植性なんかがある

正規化はデータ整合性、使いやすさ、保守性あたりを高めようとするもの
0559NAME IS NULL2020/12/28(月) 22:15:27.79ID:???
正規化は非正規形で起きる問題(更新異常等)を防ぐものであってそれ以上ではない。
実際、更新異常を考慮する必要のないDWHなどでは不要。
0560NAME IS NULL2020/12/28(月) 22:49:55.68ID:???
>>559
DWHでも更新異常は考慮する必要あるよ
更新異常ってCRUDのUだけのことじゃないから

DWHは正規化が不要なんじゃなく
ソースデータの正規形をベースに特定の分析用途に特化させて非正規化してるだけ

スタースキーマもスノーフレークもDWHに特化した非正規化パターン
非正規形のデメリットはDWHだろうがOLTPだろうが同じ
0561NAME IS NULL2020/12/28(月) 23:05:07.35ID:???
>ソースデータの正規形をベースに特定の分析用途に特化させて非正規化してるだけ

正規形非正規形というのはあくまでもリレーションの表現であって抽象的なデータモデルには
そんな区別はないんだが。
だからDWHにおいて

>ソースデータの正規形

通常これは実在しない。
0562NAME IS NULL2020/12/28(月) 23:56:41.44ID:???
>>561
ごめん、何言ってるかわからない
抽象的なデータモデルって何のこと? どっから出てきたの?
0563NAME IS NULL2020/12/29(火) 03:14:05.40ID:???
更新異常が発生しにくいだけで
考慮する必要がないわけないわな
>>561はエアプが即バレして煙に巻きたいのだろう
0564NAME IS NULL2020/12/29(火) 09:14:29.22ID:???
>ソースデータの正規形

これが抽象的なデータモデルを指しているのかと思ったんだが、そうでないなら話は簡単。
DWHは「ソースデータの正規形」が存在することを要求しないんで>>560は正しくない。
データソースが正規化された他のDBであることはあるが、それはそのシステム自身の
要求によって正規化されているだけ。
0565NAME IS NULL2020/12/29(火) 12:56:45.72ID:???
>>557
正規化がバカにされてるんじゃなく
正規化を理解してなかったり正規化されてるかどうか以外にDB設計を見る目がないのに
ドヤ顔でDB設計を語ろうとしてる人間がバカにされてるんだと思うぞ
0566NAME IS NULL2020/12/29(火) 14:29:23.16ID:???
それな
ちょうど当てはまるやつがいるな
0567NAME IS NULL2020/12/29(火) 14:46:08.18ID:???
頭おかしいやつには下手に触らず黙ってスルー推奨
0568NAME IS NULL2020/12/30(水) 00:27:51.52ID:???
RDBと関係ないRやPython使った統計処理の分野でも
分析をやりやすくするために下準備としてDBで言うところの正規化をしてる
更新異常を考慮する必要は全くないけど
0569NAME IS NULL2020/12/30(水) 09:11:39.06ID:???
そういうのごっちゃにすると話が発散するからやめて。
そもそもその「正規化」って、リレーションの正規化と違ってなにをどうするかきちんと定義されたものじゃないでしょ。
0570NAME IS NULL2020/12/30(水) 09:15:25.16ID:???
それに統計解析向けの加工って、クレンジングは最初に必要かもしれないけどあとは解析しやすいようにJOINしまくるのがふつう。
DWHのスタースキーマから任意に抽出した1つの表の形のデータセット、あれがまさに統計解析向けのもの。
0571NAME IS NULL2020/12/30(水) 18:11:29.74ID:???
エアプDWHの次はエアプ統計解析かよw
なんでろくにやったこともない事を語りたがるのかね
0572NAME IS NULL2020/12/30(水) 18:23:27.87ID:???
データベース設計は軽視されるの原因と
エアプ野郎が語りたがる原因の一つに
素人に毛が生えたような人間には難しさが分からず
自分でもできそうに思えてしまうところにある
0573NAME IS NULL2020/12/30(水) 22:22:42.93ID:???
>>571
誰のどのレスに対して言っているのか曖昧でよくわからんが、とりあえずどのレスの
どこがどう違っているのかはっきり書いたら?
反論は受けたくないけどマウントだけ取った気分になりたい中学生じゃなけりゃ。
0574NAME IS NULL2020/12/31(木) 00:08:25.03ID:???
エアプ素人さんはスタースキーマのファクトとディメンションがそれぞれ第何正規形か考えると良いと思うよ

>>565の言葉を借りれば正規化すら理解してないのにドヤ顔で語ろうとしてるのが丸わかりだから
0575NAME IS NULL2021/01/02(土) 16:36:20.20ID:2lMlvbHe
ど底辺の土方グラマーだけどDB設計させられて「なんでちゃんとしたDB屋に頼まないんだよ、DBって根幹部分で大切だろ!」って疑問だったけどここ見て納得。
日本の企業が作る(使う)システムがクソな理由も・・・
0576NAME IS NULL2021/01/02(土) 18:35:41.55ID:???
ある意味当たってる。
そうやってしばらくして、曲がりなりにもER図書いたり正規化ができるようになって
いっぱしのDB屋を気取れるようになったら彼等の仲間入り。
0577NAME IS NULL2021/01/03(日) 14:52:40.06ID:???
>>575
根幹部分だからこそDB中心のシステムを作る開発者なら誰もが身につけておくべきスキルだぞ

要件定義や基本設計を含めて依頼するならともかく
DB設計だけを外部に依頼するのは今の時代にはそぐわないので設計専業のDB屋は絶滅危惧種
0578NAME IS NULL2021/01/04(月) 05:23:06.48ID:THUOMM/C
ホンマにうわさ以上に凄いのが金さんの億様株レシピて投資ブログ。
ここまじで神すぎる!
めちゃ当てまくる。
おすすめなのは危険な銘柄と宝石の銘柄て記事に出てくる銘柄。
0579NAME IS NULL2021/01/12(火) 12:19:00.49ID:???
プログラム組まないやつが設計すると保守性重視になるよな…
人間がパッと見て理解しやすい設計にしがち 
ナチュラルキー多用したり
0580NAME IS NULL2021/01/12(火) 15:18:33.28ID:???
>>579
ナチュラルキーを多用してるにもかかわらず保守性が高いならいいんじゃね
0581NAME IS NULL2021/01/12(火) 16:22:51.65ID:???
>>580
>>579は「保守性」と言っちゃってるが、実はたぶん保守性の話やないな。
初見のわかりやすさしか見えてないような、困ったちゃんの話なんやろな。
0582NAME IS NULL2021/01/12(火) 17:06:29.79ID:???
そうすると保守性を理解してない>>579が困ったちゃんってことになる
0583NAME IS NULL2021/01/12(火) 17:48:57.44ID:???
すまん、保守性って言葉が悪かったな
プログラムの保守性ではなくて
ユーザーからの問い合わせ時にデータ見てパッとわかるテーブル構造を好む
0584NAME IS NULL2021/01/12(火) 20:38:59.75ID:???
人間にとっての見やすさというかわかりやすさも重要な品質要素だからね
それを犠牲にして得られるメリットとのバランス次第
何と何をトレードオフしようとしてるのか理解してないうちはまともな設計は期待できない
0585NAME IS NULL2021/01/12(火) 21:08:10.26ID:???
パッと見理解しやすくて保守性も高いならいいことずくめに読めるが。

たぶん言いたいことは逆になにか問題があるということなんだろうけど
結論書いてないから何を言いたいのかわからない。
0586NAME IS NULL2021/01/12(火) 21:28:46.10ID:???
>>585
理解力なさすぎ。
人工キー+JOIN前提みたいな、不慣れだとややこしげに見えるテーブルを組みたがらない素人の話なだけやろ。
0587NAME IS NULL2021/01/12(火) 21:37:08.48ID:???
だから、そこで自然キーの欠点や人工キーの利点を説明しなきゃ何を言いたいのかわからんだろ。
人工キーが自然キーより優れているのは自明だと思ってるとかそんなとこかね。
0588NAME IS NULL2021/01/12(火) 21:45:26.42ID:???
>>587
SQL書くときに条件や結合は少ないほうがバグが発生しにくい
プログラマにとってはサロゲートキーの方がわかりやすい

しかしサロゲートキーだと生データを見たときにわかりにくいことがある

ナチュラルキーとサロゲートキーの代表的なメリットデメリットだと思うけど…

その辺天秤にかけてこのテーブルはサロゲートキー、このテーブルはナチュラルキーと決定できるのは
設計もプログラムも保守もやる人。
どれか一つしかやらない人はこのへんのさじ加減わからないのでは。
0589NAME IS NULL2021/01/12(火) 21:57:42.32ID:???
こうやってブレイクダウンするとどこに誤解があるか見えてくる。

複合キーは扱いづらいのでかわりにサロゲートキーを使うことはあるが
自然キーだと一律にサロゲートキーより扱いづらいなんて理由はないだろう。
0590NAME IS NULL2021/01/12(火) 22:30:44.50ID:???
>>589
おっしゃる通り複合キーの場合だな
大変失礼しました

設計と保守しかしない年配のSEさんはサロゲートキーを知らずに複合キーを使いまくる傾向にある
プログラマは若かったり雇われだったりなので口出しできずにクソシステムの出来上がり
0591NAME IS NULL2021/01/12(火) 22:34:47.77ID:???
>>589
めんどくさ。
そんな話じゃなかったやろ。。。

おまえは、自分が理解できない話を、自分が理解できるようにしたいだけ。w
何が「ブレイクダウン」や。w
0592NAME IS NULL2021/01/12(火) 22:41:52.84ID:???
>そんな話じゃなかったやろ。。。

どういう話なのか、お前はまず言いたいことを結論からハッキリ書くようにしろ。
0593NAME IS NULL2021/01/13(水) 00:21:46.78ID:???
呼び名はともかく人工キーは80~90年代でも普通に使われてただろうから年配だろうが知らないわけない

複合キーは見てわかりやすいわけじゃないが
人工キーに比べると整合性を維持する設計が簡単なんだよ
SQL書く時は面倒くさいから嫌がられるけど不整合が発生するのに比べればマシだから
0594NAME IS NULL2021/01/13(水) 00:38:42.76ID:???
>>592
自分の理解力を棚に上げんなよ。
0595NAME IS NULL2021/01/13(水) 00:53:04.45ID:???
>>593
不整合はユニーク制約つければいいんでないの
0596NAME IS NULL2021/01/13(水) 08:06:07.69ID:???
同じ型の単純キー同士なら、それが自然キーか人工キーかで扱いやすさが変わることはないやね。
0597NAME IS NULL2021/01/13(水) 08:13:51.20ID:???
>>596
変わらない
複合キーが問題
0598NAME IS NULL2021/01/14(木) 02:05:44.63ID:???
>>593
ちょっと、「整合性を維持する設計」について詳しく説明してくれ
0599NAME IS NULL2021/01/20(水) 22:55:59.22ID:LfU5rlWt
>>557
仕様変更に強いかどうか。それと人間にとってわかりやすいかどうか。正規化の話はもっともらしいが、ちゃんとしたテストと運用・保守をやっていれば、ただの非現実的な理屈だとわかる。
0600NAME IS NULL2021/01/20(水) 23:01:10.32ID:LfU5rlWt
>>593
論理的な整合性をアプリケーションで担保する。そうでないとアプリケーションのテストも難しい。
0601NAME IS NULL2021/01/20(水) 23:02:58.59ID:LfU5rlWt
>>598
彼はアプリ屋と壁を作るタイプだから、かかわらない方がいいよ。
0603NAME IS NULL2021/01/22(金) 08:45:35.16ID:???
>>599
このちゃんとした
ってのがどれだけ難しいか
0604NAME IS NULL2021/01/25(月) 05:16:41.94ID:cGhuaVFN
よく読め
06055752021/06/22(火) 17:07:34.18ID:???
ははは・・・
晴れて?「DB屋()」の仲間入りしそうだ・・・
PostgreSQL9.3とSQLServer2005を、プライベートで、弄ったことあるだけなのに(実務ではOracle11の炎上案件の燃料として放り込まれたぐらい)
7月からPostgreSQL12がフロントエンドで、Oracle(ナンバリングは効いてない)がバックエンドで動いてる「工場のFAのすごいやつと思えば間違いじゃない(スマートファクトリー)」とかいう謎の説明されたシステムのDBチームに配属になったわ・・・
メカ系や移動体通信系のファームしか経験ないつにいきなり・・・
ズブの素人よりはマシかもしれないけどDBそのもののスキルだったらそこらの学生以下だよ俺・・・orz.
0606NAME IS NULL2021/06/22(火) 18:09:02.74ID:???
いまどきDBでチームがあるのか
ある意味すごいな
0607NAME IS NULL2021/06/22(火) 18:59:21.66ID:wVCfrFWc
>>606
開発対象が、工場の機械からデータ受け取る中継ボックスみたいなところから、工場の中間サーバから複数の工場の情報をまとめるサーバまで一貫してるんだそうな。
そして中継ボックス、中間サーバ、全体の情報あつめるサーバってのを全部面倒見てる10人ほどのチームとのこと。
まだ現場に入ってないから実態判らんけど、門外漢な俺を採用しちゃうところだし、上下どころか横の連携もまともにとれないようなカオスなところでもおかしくないって個人的な経験則が言ってる。

他に仕事ないから受けたけど、今から「どんなとこかなー? 抜けるとしたらどうやって抜けようかなー?」って考えてるw
0608NAME IS NULL2021/06/22(火) 21:26:23.41ID:???
もし関係者が見たら、特定できそうやな。w
ほどほどにしとけよ。
0609NAME IS NULL2021/06/26(土) 18:20:28.11ID:???
データベースのテーブル設計書ってどうしてる?
エクセル方眼紙にしてかいてるんだけど、なんかいいのないのかな
0610NAME IS NULL2021/06/26(土) 23:14:34.00ID:???
>>609
MySQL Workbenchはどや?
最近は使ってないから知らんが。
0611NAME IS NULL2021/07/03(土) 17:38:43.26ID:R35jReGz
>>609
A5Mk-Uがよく使われている。
0612NAME IS NULL2021/10/13(水) 12:36:34.50ID:???
データベーススペシャリストでよく問われるページサイズとか空き容量率とかどのメーカーのDBをターゲットにしてるんや?
教えてくれ
0613NAME IS NULL2021/10/13(水) 13:54:50.17ID:???
特にどのDBMSをターゲットにしてるとかないぞ
一般的なBTreeを前提にしてるだけ
0614ド底辺PG2021/11/10(水) 22:00:45.28ID:KaB0M86I
プロジェクトが燃え尽きたから別の案件に燃料しに行ったんだが、TEXT(可変長文字列)をPKにしてINDEX張ってて「パフォーマンス出ねぇ!」ってやってんですけど・・・
ちょう乱暴に描くと
CREATE TABLE T_TAGS(
 JPN AS TEXT NOT NULL,
 ENG AS TEXT,
 ・・・品詞とか同義語とかの定義いろいろ・・・
 PRIMARY KEY(JPN)
)
て感じの定義で、SELECTのサブクエリとかでも ON TBL1.JPN = ・・・ みたいにテキストのカラムをJOINしてるんすよ?

ドテ・イ・ヘーンな俺でも「なんで数値でIDのカラムを作らないの?」ぐらいの疑問はあるんだけど、
これって「データベースあるある」だったりするの?
0615NAME IS NULL2021/11/10(水) 22:40:02.10ID:???
遅いのがTEXTのせいだってどうやって判断したの?
0616NAME IS NULL2021/11/11(木) 00:02:07.19ID:???
>>614
>これって「データベースあるある」だったりするの?
文字列をPKに使うかどうかは状況による
絶対避けるというほどのものでもない
個人的には可変長は極力避けるけどパフォーマンスクリティカルなシステムじゃなければ
全部可変長で揃えてても特に問題なかったりする

PKを数値にしたバージョン作ってさくっと比較すればいいんじゃん?
0617NAME IS NULL2021/11/11(木) 19:06:31.16ID:NSxyRLjO
>>614
あなたの言っていることは頭がおかしいくらい変なことを言っている。

たまたまいままで見てきたテーブルの主キー項目が数値型だっただけで、根拠のない思い込みをしてないか?

念を押すと、頭のおかしい発言だぞ。
0618NAME IS NULL2021/11/11(木) 19:36:50.37ID:NSxyRLjO
>>614
そのTEXT型がラージオブジェクト型というオチのネタ書き込みじゃないだろうな?
0619NAME IS NULL2021/11/11(木) 20:16:55.16ID:???
>>617
そこまでやないやろ。w
テキストはCOLLATEの懸念があるし、 数値のが望ましいのはたしかやし。

まあ、遅いのはテキストキーやからと決めつけてかかってるところはアタマ弱そうやが。
EXPLAINしろっつーの。
0620ドテ・イ・ヘーン2021/11/11(木) 21:02:49.02ID:xQZydvmR
俺の思い込みが解消されないレベルの現場という前提を認識ください m(_ _)m
マジ学生以下よ、俺のスキル・・・・

EXCELを読んでDBに追記して、DBを参照してEXCELに吐き出すっていう単機能のモジュール2つを並行して「これ、改良して」ってソースだけ渡されたんすよ!
周りが「おそいおそい!」って騒いでて「どんなもんじゃらほい?」って見たらJOINが5〜6個あってTEXTのカラムでつないでたんよ。
さすがにSELECTのWHERE句でIN使うほどじゃなかったけど、そういうSQLあっても不思議じゃないレベルのある意味読みやすいSQLでしたw

あと、遅いの根拠が「本番で使ってる高負荷に耐える超高性能マシン」で動かした旧バージョンと「テスト用のレンタル屋から借りてるそこそこの性能のマシン」で動かした新バージョンというね・・・

何の比較にもなってねぇじゃん!

という新事実が発覚して、馬鹿らしくなったので今日は仕事放り出して酒飲んできましたw
0621NAME IS NULL2021/11/11(木) 21:39:46.36ID:6iIlck1C
説明の仕方でもうダメ
0622NAME IS NULL2021/11/11(木) 21:41:27.49ID:6iIlck1C
Excelは何と関係があるのか?
0623NAME IS NULL2021/11/11(木) 21:41:54.34ID:6iIlck1C
何が遅いのかまったくわかってねえな
0624NAME IS NULL2021/11/11(木) 23:17:34.86ID:???
charやvarcharの文字列って意味でtextって言ってるんじゃなくtext型って話だったのか・・
sqliteならともかくそれ以外のメジャーなサーバー系DBMSでtext型をPKにすることはまずないぞ
0625NAME IS NULL2021/11/12(金) 00:22:09.87ID:???
>>620
まとめたら、スペックの違いやろ。
一言ですむわ。w
0626NAME IS NULL2021/11/27(土) 20:05:57.75ID:l5sFA9ZC
よくわかってないクライアントがよくわかってないSEに文句言って
よくわかってないフィルターで「お前らの作ったシステム遅いぞゴラァ!」ってなって現場に届くあるある案件ですな。
0627NAME IS NULL2022/02/12(土) 03:16:43.64ID:Nh8yTOt3
>>626
性能要件があって、データが増えてもパフォーマンスに問題がないと一言、入っているだけで違うのにな。
0628NAME IS NULL2022/02/17(木) 18:59:32.20ID:???
まあ、最近はフルSSDのストレージで構築したからsqlがとても早いです。statpack見るととんでもなくディスクREADしてるアホsqlあるけど、システム影響なし、いいんだか悪いんだかですねー
0629NAME IS NULL2022/02/22(火) 20:09:39.42ID:P63gZsOo
>>628
それで解決したことにするとSSDでもどうにもならないSQLが増産されることになる。
0630NAME IS NULL2022/03/24(木) 22:48:04.07ID:blhKkXUv
お前ら和歌山県出身の下村拓郎様(35歳独身、元自衛隊)をご存知か、この方は将来素晴しい人物になるから覚えておいて損はないぞ
0631NAME IS NULL2022/06/01(水) 14:23:26.36ID:???
スキーマの意味よくわかってないけどスキーマ設計書にテーブル構成書いてるよ
0632NAME IS NULL2022/06/01(水) 17:38:04.59ID:???
それっぽく聞こえるもんねw
0633NAME IS NULL2022/06/01(水) 20:43:48.71ID:1CNMa44D
スキーマの概念が後付けの製品しか知らないんだろうな
0634NAME IS NULL2022/06/01(水) 20:44:36.18ID:1CNMa44D
論理的な意味でも括りというのは必要
0635NAME IS NULL2023/04/11(火) 20:09:59.45ID:+S9P9M6L
ER図を見てもよくわからない設計は典型的なダメパターン

だか大手SIerの人間はテストも運用も保守もしたことがないので、理解不能な理屈で設計したがる。
0636NAME IS NULL2023/07/08(土) 11:55:41.75ID:Dzd22CIu
今月から、某メーカー系の現場入り。
50万件ぐらいしか入っていない商品マスターを検索するサイトが激重。
DB設計がもろこぼらーの発想。苦言をやんわり現場に伝えたつもりだが、超絶俺様気質の担当者で、聞き入れる気配なし。
逃げたい。
ちなみに、私はデータベーススペシャリスト餅。
0637NAME IS NULL2023/07/08(土) 12:27:10.70ID:???
よくある話。
「こぼらーの発想」とか言ってもどこがどう悪いのか他人には伝わらんだろうし。
0638NAME IS NULL2023/07/08(土) 14:07:15.72ID:???
正規化って概念がないんだろうな
エクセル感覚であるだけ用意する設計なんだろ
0639NAME IS NULL2023/07/08(土) 14:41:30.21ID:???
検索が重いとしか書かれていないのに正規化が出てくる人もどっこいどっこい。
0640NAME IS NULL2023/07/08(土) 17:41:12.84ID:???
>ちなみに、私はデータベーススペシャリスト餅。
オレはお前から逃げたいw
0641NAME IS NULL2023/07/09(日) 05:25:53.28ID:Yld3I0en
こぼらーがなぜ嫌われるかをこぼらー自身は検証もしないし、俺流正義マンで権力まで持ってたら。。。。
出くわしたら逃げるしかないんだろうか?
0642NAME IS NULL2023/07/09(日) 09:49:24.47ID:???
いまどきCOBOL知ってる人も少ないだろうしどこがどのように問題かという具体的な指摘もないから
傍で見ていてよくわからんのよね。検証のしようもないだろう。
0643NAME IS NULL2023/07/09(日) 15:34:31.38ID:???
RDBをよく知らない構造化ファイル時代のコボラーはJOINを嫌い
COBOLプログラムから一番扱いやすい形の構造化ファイル風にテーブルを作る
でもそんな時代は30年近く前に終わってる上に定形検索だけなら遅くはならないので
データベーススペシャリスト餅wが表面しか見ていないだけだろう
0644NAME IS NULL2023/07/09(日) 22:27:42.41ID:???
「コボラー」と言っとけば多分反論は来ないしお手軽にマウントとった気分になれる便利なワード。
0645NAME IS NULL2023/07/10(月) 06:12:24.27ID:???
このスレなんてそれが生き甲斐のやつばかりじゃん
初心者の質問にはまともに答えず、馬鹿にして溜飲を下げるだけ
0646NAME IS NULL2023/07/10(月) 22:30:41.83ID:???
ところで構造化ファイルってどんなん?
0647NAME IS NULL2023/08/18(金) 08:33:02.53ID:???
ホホホ!(^O^)
0648NAME IS NULL2023/09/30(土) 00:06:07.97ID:???
まじかよ、それはありえんわ
0649NAME IS NULL2023/10/03(火) 22:53:58.05ID:puC6ODCi
VSAMとか悪名高いよな
0651NAME IS NULL2024/03/07(木) 18:22:53.35ID:4BnqPTKi
処理速度の遅さが頻繁に問題になっていても、めちゃくちゃな設計とめちゃくちゃなSQLを使うのが優秀な開発者なのがITの世界ではエリートだったりするからなあ

目に見えない部分は評価されにくい
0652NAME IS NULL2024/03/09(土) 19:05:23.11ID:???
推敲してレスしなおしてくれないか
0653NAME IS NULL2024/03/09(土) 21:29:57.56ID:sC2bZ4HS
有名製品でもデータモデルはひどかったりする
レスを投稿する


ニューススポーツなんでも実況