13/10/06 10:56:45.93 +EhvAfJr0
RoRはもうその役目を終えたなあ
後続のフレームワークを生み出すための原動力になったというだけでも
一応意味は有った
少なくともStruts1系よりは良かった。
281: 河津掛け(神奈川県)
13/10/06 11:07:32.10 Hb/pL+pj0
>>280
せっかく今勉強してるのにそんなこと言われても困るんだが
282: 毒霧(大阪府)
13/10/06 11:16:18.73 K5Oy6sHe0
>>279
フロントの商品検索だから、INSERTは別に遅くても構わないんだよ。
商品データだけなら良いけど、そこにカラー、サイズ、在庫が絡んできてきつい。
商品データの検索条件も揺れるし。
283: ナガタロックII(神奈川県)
13/10/06 11:27:40.44 1ZONMQES0
C++の漏れには関係ないな
284: シューティングスタープレス(東京都)
13/10/06 11:31:58.61 ovr0Yn4B0
>>282
検索も高速化できたよ。
諸事情により正規化と言っても一番重要なリレーションは弄れなかったんでInsertほど劇的変化はなかったが・・・
それでもIndex見直しとデータ型の変更で五分の一程度に短縮できた。
一番大きかったのはバックグラウンドプロセスが動く部分を徹底チューニングしたとこかな。
検索だけ、InsertやUpdateだけって絞り方のチューニングだとそこまで行かないことが多い。
よほどシビアな運用を既にやっちゃってるDBじゃない限り、「そこはあんまり重要じゃないんだけどなー」と思っても弄ってみると波及効果で改善してくことはあり得る。
285: 毒霧(大阪府)
13/10/06 11:33:59.03 K5Oy6sHe0
>>284
＞バックグラウンドプロセスが動く部分
実行計画を主に見てたんだけど
設定パラメータとかも注意してみたほうがいいのかな？
286: レッドインク(東京都)
13/10/06 11:39:17.80 eR5Hv55v0
Rubyは趣味で作った言語っぽくてイマイチだな。
JAVAもなんか肌に合わない。
という事でやっぱC#か、ううむ。
287: シューティングスタープレス(東京都)
13/10/06 11:43:40.06 ovr0Yn4B0
>>285
うん。
Oracleなら起動パラメータのチューニング。SGAとかPGA周り、後はI/Oだね。
I/Oっていうと更新系の処理以外はあまり弄らない人多いけど、読み出し速度がかなり変わる。
実ファイル→メモリキャッシュの流れを早くしてあげると検索も相当早くなるよ。
あと、無駄なjobの停止。
実行計画は大事だけど、その実行計画が採用されるまでにオプティマイザやらが動くとこに集中してリソース配分してやればさらに早くできる。
288: 16文キック(富山県)
13/10/06 11:44:05.64 Diw3teu90
お前らRuby書き直せばいいやん、優秀なんだからできるさ
289: 毒霧(大阪府)
13/10/06 11:47:00.43 K5Oy6sHe0
>>287
MySQL5.1なんだよな
MySQL(Linux)のキャッシュ機構はLinuxのファイルキャッシュに相乗りしていて
ファイルキャッシュがメモリに乗ってる限りは大丈夫らしい。
まあでも設定回りをもう一度確認してみます。
290: シューティングスタープレス(東京都)
13/10/06 11:47:48.46 ovr0Yn4B0
>>286
Javaが肌に合わないのにC#とかあり得ないぞ。
Javaに余計なお荷物を使いもしないのに持たせてるのがC#と考えていいと思う。
291: 毒霧(大阪府)
13/10/06 11:49:37.40 K5Oy6sHe0
Javaはムカつくよ。
クラスひとつにつき１ファイル作らせるところが。
292: ヒップアタック(新疆ウイグル自治区)
13/10/06 12:09:40.00 EhYKnir20
オススメはしないけどファイル名のクラス以外に別のクラス書けるよ
293: 栓抜き攻撃(東京都)
13/10/06 12:10:23.46 TGTrrV+h0
>>215
自然キーだと必然的に複合キーになるだろ
代理キーvs自然キーは一言で結論の出るテーマではない
お前はニワカ
294: 栓抜き攻撃(東京都)
13/10/06 12:12:01.80 TGTrrV+h0
>>209
同じだろ
295: 男色ドライバー(新疆ウイグル自治区)
13/10/06 12:43:41.61 F304ukC90
JavaとC#は似てるがC#の方がC++に近いから好きだな
業務で大容量のDBを使用するならORACLEかDB2にならざるを得ない
ただし可用性、パフォーマンス、信頼性をそれほど求めないオープンソースで十分だけどね
RoRの登場はStrutsで苦労していた俺には衝撃的だった
要件が単純だと問題ないが複雑だと結構面倒だけどね
新しいフレームワークを考えるきっかけになった意義は大きい
296: 男色ドライバー(新疆ウイグル自治区)
13/10/06 12:44:56.55 F304ukC90
↑（訂正）
ただし可用性、パフォーマンス、信頼性をそれほど求めないオープンソースで十分だけどね
→ただし可用性、パフォーマンス、信頼性をそれほど求めないならオープンソースで十分だけどね
297: 中年'sリフト(東日本)
13/10/06 14:38:35.67 AHJzISJd0
オープンソーでやるのって自分で全部引き受ける覚悟が必要だよね。
SIerってそれをやらないんだよね。リスク回避リスク回避っていって
自分自身でやりきらない。
だから高いOracleとかすすめるんだよなー。
もっともそれはいわゆる大企業のお客さんも同じで、どーせローテの
都合でいるだけの情シスでそんな覚悟はしょいたくないから全部丸投げ。
こんなことしてると高くつくのはしょうがないよな。
SIerに保険屋もやらせてるようなもんだから。
298: ストマッククロー(東京都)
13/10/06 15:29:17.12 c9tSAxur0
>>297
他の機能なら不具合あっても回避しつつ改修とかできるけど、データベースの不具合はデータ壊すこともあるから、そのリスクは負いたくないわな。
299: シューティングスタープレス(東京都)
13/10/06 15:38:34.06 ovr0Yn4B0
>>297
わかりすぎるわ。
会社に一匹はいるんだよね。システムの大先生（）でいち早くOSSだのクラウドだのを導入したがる馬鹿。
OSS使ってもベンダに面倒見させりゃ中間マージンは削れないし、新規バグ踏んだ時の対応はメンテナが対応してくれるまではどうしょもない。
クラウド使ってもDevOpsもわかってないから密林だのGoogleが何とかしてくれる→保守ベンダが何とかしてくれる→いや、仕様だし。で詰む。
結局自分の手を動かさない口先番長なんだよね。
英語の資料読み込めるほどの英語力もないし、Google先生に手伝ってもらって解読するような根性もない。
ちっちゃいプロトタイプ作って動かせば十分発見できるレベルの不整合を数百万の金かけてベンダにテストさせて確認するの。
本人はシステムの大先生（）だから他の奴らにはバレてないって思ってるらしいけど、上役でちょっと目端の利く人は見抜いてるんだよな。
300: ストマッククロー(東京都)
13/10/06 15:48:52.65 c9tSAxur0
>>299
> ちっちゃいプロトタイプ作って動かせば十分発見できるレベルの不整合を数百万の金かけてベンダにテストさせて確認するの。
> 上役でちょっと目端の利く人は見抜いてるんだよな。
要するに、その上役は数百万の損失を見過ごしてるボンクラと言うことか。
どうせ作り話するなら、もう少し頑張りや (w