スレ立てるまでもない質問はここで 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
今稼働中のシステムの改善てことならスロークエリログをとったりデータの分布を調べたり、
やりようはあると思うが。