スレ立てるまでもない質問はここで 162匹目

2022/10/21(金) 16:38:02.86

この板はプログラムを作る人のための板です。
あらゆる質問はまず
スレ立てるまでもない質問はここで
スレにしてください。

次スレは>>980が立てること

【前スレ】
スレ立てるまでもない質問はここで 161匹目
https://mevius.5ch.net/test/read.cgi/tech/1661583836/

VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured

2022/10/21(金) 17:08:16.85

Rubyはもう終わりつつあります
そのためしつこくRubyを薦めてくる輩がいますが、そいつの言葉は無視しましょう

2022/10/21(金) 19:57:35.30

つまりこれからの時代はシェルスクリプトだ

2022/10/22(土) 00:40:30.19

前スレで近寄ってはいけないプログラミング言語の結論が出ていて笑った

Ruby www

**前スレ962** (ｱｳｱｳｳｰ Sa45-S9Fx) · 2022/10/22(土) 01:22:49.49

散々な言われようだけどRubyはそんなまずいの？
質問乗ってくれてる人がいる訳だけど
C#勧める人もいたけどどうすべきかね
自分は目的のものが作れたらそれでいいんだけどね

2022/10/22(土) 01:37:05.70

>>5
作るものによる
WEB系の新プロジェクトにRubyを使うのは止めといた方がいい
WEB系以外はRubyの出る幕はない

2022/10/22(土) 02:20:58.42

railsでどうしても作りたいとかじゃない限りはRubyはオススメ出来ないかな
似たような仕組みは他のフレームワークで体験出来るしね
それに処理速度が有名所では一番遅いんじゃないかな？
コンピュータの性能が上がっているしそこまでネックになる事は無いにしても
早いに越したことはない

2022/10/22(土) 09:21:26.50

カラムが100個ぐらいあるテーブルを検索する画面を作るのですが、レコード数が膨大で1億件ぐらいあり、
各カラム一つ一つにインデックスを貼れば、そのカラムだけで検索した時は速いのですが、
複数カラムで検索すると、データの偏りにもよると思うのですが、遅い時も多くなってしまいます。
全てのカラムの組み合わせに対してインデックスを貼るのも、その後のメンテナンスを考えるとあまり現実的でなく、
何かうまいやり方はないかと模索しているのですが、似たようなことやったことある人いませんか？

2022/10/22(土) 09:28:44.61

100列もあるようなクソ設計してる時点で無理
サーバーのSSD化とか物理的手段で頑張れ

2022/10/22(土) 09:37:44.22

>>9
元々は別々のサーバに分散しているテーブルをその都度結合していたんですが、
必ずしも単純なキーの突合だけでは済まないこともあり、性能に難があるということで、
一つにまとめたんですよね・・・。

2022/10/22(土) 10:29:12.54

全部の組み合わせの複合インデックスなんて必ずしも使われないだろ。
単一カラムインデックスだけだと選択性が悪い使用頻度が高い組み合わせに複合インデックスを追加していけばいいんでは。
あと、もしDWHみたいに各部分キーのカラムのカーディナリティが低いならビットマップインデックスを検討してみるとか。

2022/10/22(土) 10:32:28.85

>>11
ビットマップインデックスも検討したんですが、エディションの関係で使えないんです・・・。
確かに使用頻度の高いものだけインデックス貼るのが現実できなんでしょうけど、
実際にユーザーがどれをどの頻度で使うかっていう客観的な統計データが無いので、
ヒアリングするとかで絞り込むしかなさそうです・・・。

2022/10/22(土) 11:49:46.44

まさにその検索性能と整合性を両立するために正規化するものだが

2022/10/22(土) 13:23:14.68

>>12
今稼働中のシステムの改善てことならスロークエリログをとったりデータの分布を調べたり、
やりようはあると思うが。

2022/10/22(土) 13:54:08.44

Ruby on Rails では、1対1 で表を分割したり、
単一テーブル継承を使ったりする

例えば単一テーブル継承では、
自宅住所・会社住所がある場合、住所から継承させる

そしてO/R マッパーが自動的に、型を切り替える。
自宅住所なら住所表のtype=1、会社住所ならtype=2 など

だからプログラマーは、住所表を意識しなくてよい。
自宅住所・会社住所だけを扱うだけでよい

こうやって、似たような項目を裏側で、1つの表にまとめてしまう

2022/10/22(土) 13:57:04.35

RoRは原始的なんだな

15 (ﾜｯﾁｮｲ e94f-9Hqw) · 2022/10/22(土) 14:21:12.97

Ruby on Rails 6 実践ガイド［機能拡張編］、黒田努の本では、

顧客の生年月日X・姓Y・名Z の時、
複合インデックスXYZで、X, XY, XYZが速くなる

だから更に、複合インデックスYZで、Y, YZが速くなる。
複合インデックスXZで、X, XZが速くなる。
インデックスZで、Zが速くなる

組合せ爆発を防ぐには、何かを省くか、
別表に移して、リアルタイム更新を避けるとか

他にも、ミックの本では、副問い合わせを避けて、case 式に置き換えるとか、
実行計画を見たり、Railsでは、N+1 問題を避けるとか

100列なんかのレベルでは、Database Specialist みたいな上位資格が必要。
資格の問題集・過去問をやってみるとか