元スレMySQL 総合 Part23

mysql覧

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

752 = :

>>751
どれを使うのがよいかを別として、これじゃわかんなかったってことかな
http://dev.mysql.com/doc/refman/5.1/ja/c.html

756 = :

>>755
それは効率いい方法無い

757 = :

会社の案件管理にデータベース使いたいとおもてます
mySQLとPHPもしくはperlCGIで構築したいです。
けどぜろから作るより既存のフリーテンプレが何かあるんじゃないかと。
定番のなにかオススメありませんけ

758 = :

やりたいことは
・折衝案件登録
・受注済か折衝中か
・作業の進捗
・担当者ひもづけ
・受注額と外注費、粗利
これらを月ごとに〆て会議資料にしたい

760 = :

RDBの勉強を始めたところなのですが、トランザクションのロック単位が分かりません。
トランザクションの中で異なる複数のテーブルを順番に読み書きしている場合、
START TRANSACTIONを実行した瞬間から、これらの複数テーブルあるいは対象レコードに
一斉にロックがかかるのでしょうか。
そうならないと矛盾が起きると思うのですが。

761 = :

>>760
「読み取り一貫性」「トランザクションレベル」とかでググれ

763 = :

>>760
お前みたいな素人の考える範囲で収まってると思うか？
その道のプロがいるんだから大体進んでいるのだよ、世の中は。

764 = :

トランザクションは難しいよねぇ。
ISAMをイサムと読んでる俺には無理だったよｗｗｗ

765 = :

>>760
START TRANSACTION を送信した瞬間にDBMSが
「お、このアプリはテーブルAとテーブルBを使いそうな予感がしたのでロックしておこう」
という処理をするのは矛盾以前に不可能と存じます。

766 = :

>>765
全テーブルロックしろよ

767 = :

いやあ＾＾；
俺もさっき、ド下手なコード書いたらロックが掛かって困ったｗ
頑張って競合しないようにコード修正しよ。

769 = :

やっとロックを回避するコードにでけたｗ疲れたぁ～

774 :

相談があります。

ゲーム情報サイトを作っていまして
ページの右上に、次のように登録情報数を表示させたいです。

　登録ゲーム数（国内）：XXXXX本
　登録ゲーム数（海外）：XXXXX本

このとき、データ件数を高速で取得するため
トリガを使う方法を考えました。
参考：ttp://developer.cybozu.co.jp/archives/kazuho/2009/06/mysql-innodb-se.html

ですが、これだと「国内」と「国外」でテーブルを分けないといけません。
英語版サイトも作る予定ですので、
日本のゲームと世界各国のゲーム情報は等価で扱いたい、
つまり同じテーブルで管理したいです。

データ総数は10万件ほどになる見込みで、
トリガを使わないインデックス全スキャンも避けたいのですが、

上記の件数表示を高速で行う何か良い方法はありませんでしょうか？

775 = :

DBに持たせない

776 = :

10万件なら全スキャンしても大して時間かからんろ

778 = :

毎回スキャンっていうのがどうもな
INSERTした時にどっかに数保存しとけばいいやん

779 = 777 :

そうですね。
削除や発売国を更新した時も数を更新して。

ただ荒らし対策で（Wikiのように誰でもデータを更新できる）
特定ユーザーが登録したデータの一括削除機能もあるのです。
ちゃんと何件削除したかを制御して数を更新しないと・・・
バグの素ですね・・・。

そして2行目に書いた「削除や発売国を更新した時も数を更新して」についても
複数ユーザーがほぼ同時に同じゲームデータの発売国を更新したときとかに
きちんと制御しきれるか・・・頭が痛い・・・。

780 = :

>>779
微妙な処理をするときは、あらためて件数を数えたらどうだろう。

782 = 777 :

正確な数字を取ろうとすると
テーブルの全レコードをロックして数えることになるので
正確な数字は諦めるか・・・。

正確な数字は諦めて>>780さん案になりそうです。
トリガ案も大量INSERTとDELETの負荷が恐いし。

皆さんありがとうございました。

783 = :

なんでお前は名前欄に他人の番号入れるんだよ？

784 = :

>>779
だからDBにもたせなきゃいいってのに。常に厳密な数字が必要とは思えんし

785 = :

あ、リロードできてなかった。
いい方向に倒れてよかったよかった。

786 = :

寝ぼけてんのか

787 = :

どのくらいのアクセス数を見込んでるのかわからんが、
この程度の話を聞いてるような奴が作ってるページは毎回count(*)やっても
DBに負荷かからないから安心していいよｗ

790 = :

>>789
チェックポイントファイルは作れません。
普通に全バックアップしてください。

792 = :

>>791
ほかのDBにはあるの？ 便利そうだなそれ

795 = :

>>794
ほほー
そろそろMySQL卒業しよっかな
オラクルだからいつかは卒業しなきゃと思ってたんだけど

799 = :

ポスグレに移籍することはあってもマリアちゃんだけは無いわ

800 = :

そんなこと言ってもこれから先はマリアが主流になってくるよ

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

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

• MySQL 総合 Part25 (947) - [94%] - 2017/6/18 6:30
• MySQL 総合 Part24 (1010) - [94%] - 2015/2/14 4:46
• MySQL 総合 Part13 (996) - [94%] - 2008/6/10 21:02 ☆
• MySQL 総合 Part22 (1001) - [94%] - 2012/7/10 16:45
• MySQL 総合 Part26 (860) - [94%] - 2023/2/2 9:30
• MySQL 総合 Part21 (1001) - [94%] - 2011/12/25 22:16
• MySQL 総合 Part20 (995) - [94%] - 2011/10/17 4:48
• MySQL 総合 Part12 (1001) - [89%] - 2008/1/30 17:34 ○
• MySQL 総合 Part18 (986) - [89%] - 2011/1/17 15:46
• 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 総合 Part19 (982) - [89%] - 2011/6/9 2:33
• MySQL vs PostgreSQL Part2 (941) - [36%] - 2022/5/26 1:30 ○