元スレMySQL 総合 Part20
mysql覧 / PC版 / みんなの評価 :
前へ
352 :
またセキュリティホール増やすのか
353 = :
moongiftってRubyスレで暴れてた基地外じゃないか
354 :
>>353
ｋｗｓｋ
355 = :
このMySQL-MHAってツールはどのくらい凄い事なんでしょうか？
「DeNAが社内利用しているMySQLの自動フェイルオーバーツール、オープンソースで公開開始」
http://www.publickey1.jp/blog/11/denamysql_1.html
356 = :
知らん
357 = :
>>355
・Active-Stanby構成のHAクラスタがいらないところ。
・つまりサーバーリソースが無駄にならない。
・寝覚めが良くなる。
問題はR/W Splittingしている場合のフェイルオーバー時の挙動。
358 = :
>>355
・健康で文化的な最低限度の生活を営む権利を有する。
・納税の義務を負う。
・その能力に応じて、ひとしく教育を受ける権利を有する。
問題は施行後に獲得された領土についての場所的適用範囲。
360 = :
メガネを換えるんだ
361 = :
メガネは顔の一部です
362 = :
遠近両用
364 = :
クソも食えば栄養になる
365 = :
その栄養がまたクソになる
366 = :
そのクソは、やがてinnoDBとなる
368 = :
クソも食えば栄養になる
369 = :
http://www.youtube.com/watch?v=hj1B8OGgwYc
検証番組とかいらないと思うよ。
とりあえず謝らないと、それはそれで問題だから、まあ、謝ったの？は正しいと思うけど。
これってさ、間違えを犯してさ、今度から気をつけようってレベル？のことじゃあないから。
風評被害で自殺してる農家だっているんだぜ？
震災の時って、日テレとかフジでも中継の時に不謹慎なことを
やってる人がいたけど、その程度のメディアリテラシーの人間が番？組作ってるから、
その程度の人間しか見なくなって、見ると人がどんどん減ってるっ？てことに、
そろそろ気がついたほうがいいよ。
まあ、オレは見ないから関係ないけどね。？
MYSQL5 <-注目
370 = :
質問
検証できる環境が手元に無いので聞きたいんだけど
mysqldumpでスキーマ別でダンプデータとって、
それをそのまま同じスキーマにリストアしてしまった場合って
データは二重に登録されてしまう？
それともその後差分があったとしたらその差分が消されるとかでしょうか
371 = :
試してから質問しろ
372 = :
>>370
ヒント。プライマリーキー。
373 = :
>>371
試したいんだけど、数日検証できない状況にいるからすぐ知りたくて
>>372
ありがとう
てことは、データが二重に登録されることはないんだね
376 = :
テーブルは簡単で、less_no int, msg textです。
たとえば、書き込みが９００件だと 801～900番までを順に取得したいです。descだと逆転して900番から上に取得になります。
レスのサイズを先に取得して、limitで開始位置を指定すればできますが、もう少しスマートで簡単に取得できる方法があれば教えていただきたいですm(_ _)m
377 = :
>レスのサイズを先に取得して
レスのサイズって何？
378 = :
>>377
テーブルの行数、掲示板のレスの数です。レスの数がわかれば -100でlimitの開始位置がわかります。
380 = :
>>379
トリガを使うケースに見える。
ただ、DELETEしたら番号崩れるじゃないかとか
他に心配することがたくさんありそう
381 = 379 :
>>380
トリガていうんですか、、調べてみます
取得したい値はオートインクリメントの主キーなんですが、deleteしたら崩れるんでしょうか？
不安になってきた、今のやり方のままで良いのかなぁ…
382 = :
番号崩したくないならDELETEしなきゃいいじゃない
383 = :
それだとDELETEの存在意義が無いように思えるのですが
384 = :
>>381
取得する値(キー)じゃなくて設定したい値(「このデータは101行目だよ」)のことだろ。
なにをどうしたいのか、もうちょっとわかるように説明すれ。
385 = :
初心者なので何をどう説明すればちゃんと理解してもらえるのかわかりません
386 = :
オートインクリメントの主キーがDeleteしたら崩れるとか
何言いたいのかわからない
387 = :
わからないのは私の説明不足ではなく、あなたの理解力が足りないせい？
388 = :
連番にしたいのか？やめとけ
389 = :
AがBです。
でも、AがBっておかしくない？
日本語以前の問題かもしれない。。
390 = :
>>384
なるほど！そういうことですか！勘違いしてました、納得出来ました
a-1）既存データが100件ある。最新データの主キーのidは100で一致してる
a-2）次にinsert予定のデータが何件目になるか判定する ＞101である
a-3）「101件目だよ」としてinsertする（id=0 でinsert、auto_incrementのため）
b-1）既存データが70件ある。最新データの主キーのidは100。（30件削除したのでデータ数とは一致しない）
b-2）次にinsert予定のデータが何件目になるか判定する ＞101である
b-3）「101件目だよ」としてinsertする（id=0 でinsert、auto_incrementのため）
これが両方成立するような、スマートなやり方を知りたいんです
最初に書いたような、とりあえずinsertしてlastinsetIdとって対象カラムをupdateすれば確実なんですが
何か他にやり方あるかなって。。
実際の計画としては「101件目だよ」の部分には別のデータが入ります
idをパラメータにした http://hoge.com/id/101 てページがあって、
それをgoo.glのshortURLに変換して 101件目だよ のカラムに入れてInsertしたいんです
なので、自己のIDの値がinsertの時点で必要なんです
最初からこう書いた方がわかりやすかったかもですね、すみません
391 = :
1) IDを決める
2) IDをもとにしたショートURLを求める
これって2)を1)と同時にやる必要なくない？
ショートURLあらかじめ10万個ぐらい作っておいて
SHORT_URL(ID, URL)テーブルに入れておけばいいんじゃ
392 = :
>>391
何の話？
393 = :
>>390
理解したと思ったら、他の奴のレスをもう一回読んで、
本当に必要な設計を再検討してみると良いよ。
単に auto increment 使うのが最適解に100万円。
394 = :
mysqlにSEQUENCEはないからスマートな手段もないんじゃね。
goo.glのAPIのリターンを待つ必要があるのが最大のポイントじゃね。
395 = :
>>391
確かにそうなんですけどね、apiがエラーした時が恐いし
>>393
もう一回読んでみます
>>394
goo.gl、恐くなってきたな～
皆さん意見ありがとうございました
396 = :
IDテーブルに1レコード作って自分で管理すれば？
398 = :
>>396
自前でショートURL機能実装した方が良い気もするんですが。。どうなんですかねぇ
399 = :
ハード更改したんだけど、あまりパフォーマンスが変わらないから、
topで見たらシングルのまま動いてるみたい。
まんべんなくCPUを使うための設定って何か必要なのですか？
centos5でmysqlのバージョンは
Ver 14.12 Distrib 5.0.77, for redhat-linux-gnu (i686) using readline 5.1
DBはMyISAM型です。
みんなの評価 :
mysql一覧へ類似してるかもしれないスレッド
- MySQL 総合 Part22 (1001) - [94%] - 2012/7/10 16:45
- MySQL 総合 Part21 (1001) - [94%] - 2011/12/25 22:16
- MySQL 総合 Part25 (947) - [94%] - 2017/6/18 6:30
- MySQL 総合 Part24 (1010) - [94%] - 2015/2/14 4:46
- MySQL 総合 Part23 (992) - [94%] - 2013/8/11 17:00
- MySQL 総合 Part26 (860) - [94%] - 2023/2/2 9:30
- MySQL 総合 Part13 (996) - [89%] - 2008/6/10 21:02 ☆
- MySQL 総合 Part14 (1001) - [89%] - 2008/11/23 10:17 ☆
- MySQL 総合 Part15 (1001) - [89%] - 2009/4/20 12:15 ☆
- MySQL 総合 Part17 (1001) - [89%] - 2010/6/10 20:47 ○
- MySQL 総合 Part18 (986) - [89%] - 2011/1/17 15:46
- MySQL 総合 Part19 (982) - [89%] - 2011/6/9 2:33
- MySQL 総合 Part12 (1001) - [89%] - 2008/1/30 17:34 ○
- MySQL vs PostgreSQL Part2 (941) - [36%] - 2022/5/26 1:30 ○
トップメニューへ / →のくす牧場書庫について