>>299
>>291ですでに答えてるように、質問の回答だけならすでにしてる

>>300
逆にどうやって現在の連番を取得するの？
連番の計算→それを暗号化
こっちのほうが無駄なコードな気がするけど

md5の負荷を気にするような、かなり大規模なシステムなら設計段階でしっかりやるべき
パスワードをmd5なら分かるけど、連番をmd5なんて主義とか以前の問題だと思うけどな

インストの段階で困ってるんだけど、どなたか相談に…。
サーバを一から環境設定していくのは初めての人間です。
Cent OSで、Tritonn(Senna) x MySQL x php を使いたい。

http://doruby.kbmj.com/fuj_on_rails/20100107/tritonn_

を参考にして
MySQL-server-5.0.87までのインストールは完了。
コンソール上でのmysql、senna動作確認は問題なし。

で、phpをyumでインストしていったのだけれど、
yum install php-mysql で失敗する。
エラーメッセージ：mysql conflicts with MySQL-server　など

どうやら MySQL-server-5.0.87 と php のバージョンが合っていないみたいで、どうすれば MySQL-server-5.0.87 と競合のない php-mysql がインストールできるでしょうか。

>>301
質問と関係なくコーディングに行き詰まったので出てきました、元の質問した者です。
レスくれた人たちありがとう。

作ってるのはぶっちゃけmixiアプリのゲームのようなものだと思ってください。
idの連番はこちらが作るのではなく、mixiのユーザーIDです。
それを引数に使ってDBアクセスだと、気を付けないと適当にID入れてごにょごにょ…
とかできると想定外のアクセスをされる可能性があるので
ユーザーIDを暗号化したものを引数にすればよくね？
ユーザーIDはユニークだから暗号化してもほぼ確実にユニーク→じゃあキーにすればよくね？
と思った次第です。
とりあえず速度に影響はなさそうなので、今回はこれで行く予定です。
もちろんこれ以外でのセキュリティ対策もしっかりやる予定。

>>303
「も」？

>>302
PHPを自前でビルド
いやまじで

AUTO_INCREMENTのIDとは別にユーザーID用Columnを用意すれば
解決できるよね？

>>305
なるほど、yumは楽だけど、あんまり更新されてないし、
融通が利かないのですよね。

とりあえずMySQL-server-5.0.87と合うPHPのバージョンを探してみます。
それからビルドしてmake installかな。
ありがとう。

>>306
うん、ってかどう考えても普通はそうすると思うんだがなぁ

select distinct a from table1 where b=c
select distinct a from table1 where b=d

以上の、２つの文で、（aの値が）重複したものだけを、
結合して抽出したいのですが、どのように書けばよいでしょうか？
できれば結合結果に、ORDER BY 'e' と LIMITも加えたいです。

大規模サイト向けのテーブル構造を勉強して実験したいのですが、
参考となる解説サイトってありませんかね？

ちなみに大規模サイトというのは、
mixiのような不特定多数のユーザが利用するSNSのようなサイトです。

大規模SNSのテーブル設計は企業秘密じゃないかなあ
OpenPNEでもダウンロードして覗いてみたらどう

昔、mixiサーバー不具合でソースが丸見えになってた時があったよね
まあ今は全然変わってるかもしれんが

なんかの不具合でソース丸見えになる可能性ってあるの？
Apacheでスクリプトがスクリプトとして認識されてないようなコンフィグのミスとか？

>>312
OpenPNEのテーブル設計はとても大規模向けとは思えないんですよ。
せいぜい100～200ユーザーが毎日アクセスしていたら
レコードが肥大化してパフォーマンスが悪くなると思います。

データベースの分割やパーティショニングを効果的に使って
万単位の利用を捌いているような設計の情報って、ネットで探せなくて・・・

>>315

>万単位の利用を捌いているような設計の情報って、ネットで探せなくて・・・
探しかたが悪い。要素技術ならいくらでもある。

だが、要素技術だけマスターしてもどうしようもない。
レーシングカーでも飛行機でもロケットでもなんでもいいが多くの構成要素をもつ工学製品がどうやって作られているか、回り道のようでもいろいろ勉強してみろ。
要素技術ひとつひとつ完全にマスターするだけでなく、なにを選びなにを捨てるか、取捨選択＝トレードオフ、全体のバランスをとるセンスを研くことがいかに大事か掴みとらないかぎり、大規模システムには手を出さないほうがいい。


ところで万単位って大規模か？

その勉強方法がわからないから、訪ねてるんじゃないの？

大規模サイトの開発・運用はいくつか本がでてるけど、
時期によって実際は最適解は変わってくるだろうから
システム全体を疎なつくりにしとくくらいじゃないかな。
事前にやれることといったら。

>>314
見た目はそんな感じだった
mixi.jp/aaaaaa.plにアクセスするとPerlのソースがそのまま出てた

>>315
そういうのは企業秘密なのかなかなか情報ないね
技術セミナーとか出てみても質問してみてもうまいことぼかしてあって、具体的なことは教えてくれない
やはり中で働いてみるしかないんだろうな

そのくせ、求人は「大規模サイト構築経験」とかいうの多いんだよな。

どこも試行錯誤なんじゃないのかなあ。

Webサービスをやってる企業も手探りなのかな？
pixivはオープン後、数日でアクセスが増えてデータが肥大化したから
サーバ増強した？かなにか対策したという話を聞いたことある。

でも、こういう状態って運営経験無いとわからないよな。
自分達が作ったサービスが予想以上にヒットした時、
経験無いから対策できませんってなったら、せっかくの商機も失ってしまう。

商機を失ってしまう会社はやっぱりあるよ。
そのへんは大規模経験があるベンダと付き合いがあるかどうかじゃないかなあ。
別に大きなベンダでなくともそれなりの経験があるだろうし。

ホスティングサービスに相談して解決できてしまうレベルだったりもするかもしれない。

slideshareにアップされた大手サイトのドキュメント見てるけど、
それぞれ工夫していると言うのはわかるが、
具体的なテーブル構成や設計に関する事は書いてないな（当たり前かw

俺の中で意外だったのは、データベースを分けるのではなく、
テーブルを分けてレプリケーションする方法をしている方法が割と多かった

>>317
だから
マニュアル坊やは何やってもダメなんで大規模に首つっこむなっての

試行錯誤できないやつはなにやってもダメだが
きまった手順のな分野にはそういう奴はいらんわけよ。

つまり、自分で乗り越えられることが先端にかかわるための必要条件。
十分条件でないぞ。

第三者だけど、

A：マニュアルを見てきっかけを掴む
B：自分で試行錯誤してきっかけを掴む

では、明らかにBの方が効率が悪いぞ？
君は受験勉強で赤本買ったり、受験対策の過去問やったりしない？

マニュアルに載っているようなことはマニュアルを見なくても
脳内の引き出しから出てくるのは前提条件だろ。
その上で、ネット上に散在している要素技術を蓄積し、かつ
それを必要な時に組み合わせて問題解決できることが求められてるんだよ。

自らの成功体験を語っているはずなんで全部正解だと思う。
ただ、命題からちょっとずつズレているだけ。

大規模だと普通は、Oracleとか使うだろ。ｌ
で、マニュアルに載ってない情報を教えてもらう流れ。

あ、そうなんだ。俺、引退して３年くらいたつからな。

引退ってお前何歳だよw

>>325
> 第三者だけど、
>
> A：マニュアルを見てきっかけを掴む
> B：自分で試行錯誤してきっかけを掴む
>
> では、明らかにBの方が効率が悪いぞ？

ゆとり乙

> 君は受験勉強で赤本買ったり、受験対策の過去問やったりしない？

教科書なんてない未開の分野に乗り出す人間と後からついてくる人間の違いがわからん奴になにいっても無駄だな。

大規模システムにきまり切った定石なんてない。みな一品もの。
スケールアップしか手がないシステムならそれでいくしかないし、スケールアウトできる切口があればスケールアウトすればいい。
トレードオフのポイントみつけるのは技術センスが必要。ダメな奴はダメ。ほんとうにセンスのアリ無し。

ただし大規模の設計センスがないからといって技術レベルが低いってことじゃない。
向き不向き。全体のトレードオフを見つけるのがうまい奴は得てして細かい実装には拘らないことがおおいから
実装者としては中級の場合もある。
質問者はとっかかりが掴めないといってるが、それは向いてないんだから別の方向を探したほうがいい。
別の道を歩きながら経験積んで大規模に立ち向かうセンスが身につくかもしれないし、
細部に拘った実装で名をあげるかもしれないし

Web前提で書いてるだろ。

>>331
お前みたいな古い根性論の奴多いな。
「俺の背中を見て仕事を覚えろ」ってやつ？www

チームにとけ込めない人間ならそれで良いだろうな。
何が「一品もの(ｷﾘｯ」だw

現実には定石はあるし、マニュアルも作ってる。
ただお前は知らないだけ。違うか？人に教えられる能力がないだけなんだよ。

>>323
PARTITION BY じゃね？

>>331
140字に収めて下さい

>>334
>現実には定石はあるし、マニュアルも作ってる。

じゃあ、出してあげればw

根性論なんて、って言っているやつも分かって言ってると思う。字面みて、ちょっとカチンと来ているだけだろ。

枯れた技術は、抑えるのは当然として、新しいことやろうとすると、やっぱ工夫しないとダメだし。

すごく端的かもしれんけど、戦闘機を国産で作ろうとなったとき、既にアメリカにある技術だから、教えてもらえばいいってことにはならない。
同じように大規模でもサクサク動く何かを作ろうとしたときに、別の会社にノウハウあっても意味はない。

みんな正解を言いあって、ケンカしているのがホント解せないわ。
おまえは偉そうだから腹が立つ、って言わないと。そこは。

>>338
> 根性論なんて、って言っているやつも分かって言ってると思う。字面みて、ちょっとカチンと来ているだけだろ。

「現実には定石はあるし、マニュアルも作ってる。」なんて書いてる >>334
が分かってやってるはずない。

>現実には定石はあるし、マニュアルも作ってる。

そのマニュアル出してみろよ。
そのマニュアル読めば素人でもDB100台規模のシステム組んで運用出来るんだろうな？
その定石ってのは、DB100台から1000台に拡張するときもなんの問題もなく適用できる定石なんだろうな？

そんなもんあるわけねえだろ。
多少失敗しながら自分で考えて技術身につけないと、100台規模から1000台規模になんて拡張できねえんだよ。
10倍のシステム拡張成功させた人間が、エッセンスを言葉でマニュアルに書いても、
それを本当に理解できるのは同等レベルのエンジニアだけ。そういうエンジニアは間違いなく膨大な時間を使って実験して
膨大な失敗をしている。失敗を話さないからスゲーって思うだけ。ものすごい時間を投資して勉強してんだよ。

マニュアル読めばできるなんて考えてる馬鹿が多いから、システム開発は上流から下流まで全部ボロボロになるんだよ。

おちつけよ、まぁもっとやれ。

>>339
そんなマニュアル会社の大事な財産なんだからこんなところで出すかよ　アホか
おまえみたいに自宅鯖の前で唸ってるだけじゃないんだよ

>>341
> そんなマニュアル会社の大事な財産なんだからこんなところで出すかよ　アホか


>>338
>根性論なんて、って言っているやつも分かって言ってると思う。

な、
こいつ　341=334 分かってないだろ

ちょっと煽ると本気になるってガキかよ >>341,334

釣りや皮肉に
まともに反応されると
スレがつまらなくなるよ >>341

数値型

初歩的な質問過ぎて逆にググってもでてこないから教えてください
数値型っていろいろあるけど、整数ならINT使うべきなんでしょうか？
　INT
　TINIINT
　SMALLINT
　MEDIUMINT
　BIGINT

もちろん、INT型の範囲を超える値を使うなら
BIGINTにするけど、TINYINTやSMALLINTはいらないコですか？

それとも、テーブル設計時にサイズが例えば128桁未満で確定してるなら
TINYINTのカラムにすべきですか？

話それるけど、Javaの場合、JVMが最適化してくれるから
short型とか使わずに、int型で宣言した方が性能でるってのがあって
MySQLとか各種データベースもそういうのあったりすんのかなーっていう質問です。