元スレ【PHP】Laravel【フレームワーク】 Part.2

php覧

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで

101 = 39 :

>>89
>表示のための分岐はいくらでも書いて問題ないよ。

それもやめろっって何回言わせんだ。
デザイナが触れなくなるだろーが。

102 = :

>>95
ん？おまえは還元率の計算をViewでやってるの？
ECサイトでポイントを表示するケースって、カートとか確認画面とかメルマガでDM送るときにこの商品を買ったら50ポイントです！とかあるけど、全部のビューに書いてる？変更するときどうすんの。

104 = :

>>98
経験上大量レコードからJOINで大幅にレコード件数減らせるんなら減らした方が低負荷になるはずだけどなぁ
間違ってたらスマン

105 = :

>>101
いやデザイナーに実コード触らせるとかやめろよ。そんなやり方
デザイナーから上がってきたhtmlはコーダーが実環境にマージ・適用した方が全体でみて低リスクだし低コストになる

106 = :

>>98
なんで世の中JOINが遅いことになってるんだろうな。最近のARしか知らないプログラマはほんと軟弱だわ。
JOINが遅いのは設定と設計とクエリが悪いの。その対策チームはJOINを無くすために存在してるんじゃなくて、設計とクエリを見直してパラメータを調整して速いJOINにするために存在してるの。対策した後もJOINを使うの。

107 = 39 :

>>102

>87
>>85
>フォーマッタはあったら便利だろ。

>88
>先のことをさぁ、考えて、作るんだよ。
>>85くん。

加えて、Twigには、FilterとFunctionという便利なものもある。
おまえは、石器時代の人間か？

108 = 39 :

>>105

おまえのアプリは作ったら作ったまんまか？
おまえ、サーバ側の改修やってるときに、
デザイナが書いたHTMLやCSSの面倒見たいか？
物好きだなぁ…。

110 = :

>>106
いや違う。複数からアクセスされたときに単純なクエリにかかわらず
JOINが高負荷になってしまう問題が存在していて
それを解決するために各チームが存在している。
解決したソースコードを提供した人には賞金が授与されるけど
未だ誰もこれを解決できるソースを提供できた人はいない

111 = :

>>107
でも>>82読んだ限りだとARにフォーマッタ仕込みたいんだろ？
Twigはテンプレートエンジンの方じゃんなんでごっちゃになってるの？

112 = 39 :

>>106

それは、下手くそなバカがJOINするからだ。
アホが書いたくそぐっちゃぐちゃのSQLを1/3に減らしたら
実行速度が1/10になりましたとか、普通にあるだろ。
あいつらは実行計画の見方もしらない。
JOIN前にSELECTで絞りまくったほうが速いとすら思っている。

113 = :

>>108
変に分からんヤツに荒らされて狂うくらいなら自分でやった方がいいに決まってるだろ

114 = :

>>109
Oracleの中の人が言ってるんだから混同してないでしょ。
もしくは今後実装予定の機能をポロっと言ってしまった可能性もあるけど

116 = 39 :

>>111

「たい」んじゃなくて、仕込「める」と言っているんだ。
OOPというのはそういうものだ。

118 = 39 :

>>115

寝ぼけ過ぎだ。
お前が言っていた
>表示のための分岐はいくらでも書いて問題ない
場所、
それが、その場所だ。いい加減に気づけ。

119 = :

>>110
うーん皆の話に齟齬があるみたいだからその複数アクセスの規模を明示して？
多分秒間10や20くらいじゃそうならないよね？

120 = :

>>112
それはJOINじゃなくてクエリの書き方の問題でしょ。
ここで言われてる複数アクセス時のJOIN高負荷は賞金がかけられてるやつだから
DB本体のコーディングの問題。

121 = 39 :

>>113

まったく、だからお前のやっている仕事はスケールしないんだよ。

連投禁止かかりはじめたから、しばらくポイント貯めるぞ。

123 = :

>>120
何言ってんのか意味不明。JOINのアルゴリズムはほぼ確立されていて、データ量が膨大であれインデックスがメモリに乗ってCPUに余裕があればどんなに大量のアクセスがあっても理論上は遅くならない。Btreeの仕組みとインデックスの用途、実行計画について調べてこい。

125 = :

>>120
言いたいことは大体分かったけど
なんかソースみたいな記事持ってこないと噛み付いてる人は納得しないと思うよ

126 = :

>>123
遅くなる問題があるからわざわざ専門チームがいて
賞金もかけられれるんでしょ。
PostgreSQLやMySQLの開発チームの中に
JOIN問題を解決する対策チームがいるからそいつらに言って
間違い正して来いよ。

128 = :

JOINの高負荷問題で通常の開発者にはあまり関係ないはず。
あれはGoogleとかAmazonクラスのWEBサービスじゃないと
発生しないんじゃないっけ

129 = 39 :

おまえらは、LaravelのスレッドでなぜJOINの話題を始めるのだ。
バカなのか？

130 = :

同時アクセスでJOIN高負荷ってなんだよ…。JOIN 高負荷 賞金でググってもなんも出てこないぞ。

132 = :

>>130
よく知らんけど多分日本語じゃ無理だろうな

133 = :

それもそうだな。終わりにしよう。いいネタは出たな。

134 = 39 :

まったく、俺様のように、Laravelの欠点や、対抗馬となるべき未来のフレームワークについて語れ。

135 = :

話を戻すけど>>73については何がいいたいの？

136 = :

>>132
けっきょく知らねーのかよw
お前は日本語で誰も話題にしてないRDBのJOIN問題に辿り着いてここで披露してるわけか。すごいな。

137 = :

未来のフレームワークについては別スレのほうがいいのでは

138 = :

>>136
俺は120じゃないけど日本語での検索ワードじゃ無理だろうなって思ったから言っただけだよ

142 = :

>>139
動くよ
もし数値であることも判定したいならinteger付けたりとかだね

143 = 39 :

なるほど。一応、型は意識していると。
では、Aの商品の時は最大50個までで、Bの商品の時は100個までだけど、
クーポンを使ったときにはBの商品は20個限定、

みたいな処理は、どこにどうやって書くの？

145 = :

>>143
それもバリデーションに書くね。その場合条件付きバリデーションって
方法になる

147 = :

それはバリデーションじゃなくて制約、仕様なんだからバリデーションに書くなよ。
単体でテストできるようにクラスでも関数でもいいから分離しとけ。　

148 = :

まさか学校の課題をここで聞いているんじゃなかろうな

149 = 39 :

ほーら、なんかいろいろ言い出した。
つまり、作ってるやつで書き方違うって事だ。

150 = :

>>149
そりゃ違うでしょ。各会社でコーディング規約が違うんだから。
同じ会社なのに書き方違ったら馬鹿だけど

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / php一覧へ

類似してるかもしれないスレッド

• 【PHP】Laravel【フレームワーク】 Part.3 (983) - [98%] - 2021/2/12 4:00
• 【PHP】Laravel【フレームワーク】 Part.4 (460) - [98%] - 2021/4/4 4:00
• 【PHP】Laravel【フレームワーク】 Part.12 (314) - [96%] - 2023/1/30 18:45
• 【PHP】Laravel【フレームワーク】 Part.9 (884) - [96%] - 2022/3/13 12:00
• 【PHP】Laravel【フレームワーク】 Part.8 (148) - [96%] - 2021/8/8 21:30
• 【PHP】Laravel【フレームワーク】 Part.7 (779) - [96%] - 2021/7/9 16:18
• 【PHP】Laravel【フレームワーク】 Part.6 (745) - [96%] - 2021/6/21 6:30
• 【PHP】Laravel【フレームワーク】 Part.5 (568) - [96%] - 2021/5/1 22:00
• 【PHP】Laravel【フレームワーク】 Part.10 (446) - [94%] - 2022/6/6 19:30
• 【PHP】Laravel【フレームワーク】 Part.11 (870) - [94%] - 2022/8/28 15:45
• 【PHP】Laravel【フレームワーク】 (887) - [82%] - 2019/4/23 21:00
• 【PHP】フレームワーク Akelos (129) - [54%] - 2019/5/9 7:46