私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレMySQL 総合 Part18
mysql スレッド一覧へ / mysql とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 :
レスフィルター : (試験中)
質問があります。
ぜひアドバイスをお願いします。
point テーブル
+-------+------------+
| point | expire |
+-------+------------+
| 10000 | 2010-08-10 |
+-------+------------+
| 10000 | 2010-08-11 |
+-------+------------+
| 10000 | 2010-08-12 |
+-------+------------+
point テーブルには、
ユーザの所持ポイント数 point (unsigned) と、
そのポイントの有効期限 expire が格納されています。
「有効期限が近いものから合計○ポイントマイナスする」
というような命令を単一のクエリで実現することは可能でしょうか?
たとえば、
「上記テーブルから合計15000マイナスする」とすると
以下の状態になってほしいわけです。
point テーブル
+-------+------------+
| point | expire |
+-------+------------+
| 0 | 2010-08-10 |
+-------+------------+
| 5000 | 2010-08-11 |
+-------+------------+
| 10000 | 2010-08-12 |
+-------+------------+
お詳しい方、どうぞよろしくお願いします。
ぜひアドバイスをお願いします。
point テーブル
+-------+------------+
| point | expire |
+-------+------------+
| 10000 | 2010-08-10 |
+-------+------------+
| 10000 | 2010-08-11 |
+-------+------------+
| 10000 | 2010-08-12 |
+-------+------------+
point テーブルには、
ユーザの所持ポイント数 point (unsigned) と、
そのポイントの有効期限 expire が格納されています。
「有効期限が近いものから合計○ポイントマイナスする」
というような命令を単一のクエリで実現することは可能でしょうか?
たとえば、
「上記テーブルから合計15000マイナスする」とすると
以下の状態になってほしいわけです。
point テーブル
+-------+------------+
| point | expire |
+-------+------------+
| 0 | 2010-08-10 |
+-------+------------+
| 5000 | 2010-08-11 |
+-------+------------+
| 10000 | 2010-08-12 |
+-------+------------+
お詳しい方、どうぞよろしくお願いします。
>>204
そういう用件のためのプロシージャ
そういう用件のためのプロシージャ
>>205,206
教えていただきありがとうございます!
調べたのですがいまいち確証が得られていないことがあるのですが、
プロシージャ内の処理はトランザクションのような保証はないのでしょうか。
もしないとすれば、おとなしくInnoDBにして
アプリケーション側でルーチンを組むのがよいのでしょうか。
教えていただきありがとうございます!
調べたのですがいまいち確証が得られていないことがあるのですが、
プロシージャ内の処理はトランザクションのような保証はないのでしょうか。
もしないとすれば、おとなしくInnoDBにして
アプリケーション側でルーチンを組むのがよいのでしょうか。
InnoDBにしてストアドプロシージャを使えばいいと思うけど。
複数レコードをアトミックに更新しないといけないから、
MyISAMの場合はプロシージャだろうがアプリで手組みだろうが
最初にLOCK TABLESしないとだめだね。
複数レコードをアトミックに更新しないといけないから、
MyISAMの場合はプロシージャだろうがアプリで手組みだろうが
最初にLOCK TABLESしないとだめだね。
プロシージャについて、もう一点教えていただけないでしょうか。
一連の処理内でテーブルから値を取得するときは
DECLARE v_pts INT UNSIGNED;
SELECT p.point INTO v_pts FROM point_table p LIMIT 1;
このようにすると理解していますが、
取得したい型がENUMやSETの場合はどのようにすればよいのでしょうか。
DECLARE v_pts SET;
DECLARE v_pts VARCHAR(50);
としても取得することはできませんでした。
一連の処理内でテーブルから値を取得するときは
DECLARE v_pts INT UNSIGNED;
SELECT p.point INTO v_pts FROM point_table p LIMIT 1;
このようにすると理解していますが、
取得したい型がENUMやSETの場合はどのようにすればよいのでしょうか。
DECLARE v_pts SET;
DECLARE v_pts VARCHAR(50);
としても取得することはできませんでした。
今MySQLの勉強をしています。
で思ったのですが、どうしてINSERT文とUPDATE文では、これほどまで書式が違うんでしょう?
正直INSERT文の書式に統一して、複数のレコードを一気に更新できるようにしてほしいと思います。
で思ったのですが、どうしてINSERT文とUPDATE文では、これほどまで書式が違うんでしょう?
正直INSERT文の書式に統一して、複数のレコードを一気に更新できるようにしてほしいと思います。
>>217
ありがとございました。
勘違いでして、普通にVARCHARに入れることができました。
また、カーソルなのですが、ドキュメントとを読むと「読み取り専用」とありますが、
宣言後に内容を書き換えたり、
もしくは変数名とCURSORという型だけ宣言しておいて、
中のSELECT文はあとから代入する、というようなことはできないのでしょうか?
ありがとございました。
勘違いでして、普通にVARCHARに入れることができました。
また、カーソルなのですが、ドキュメントとを読むと「読み取り専用」とありますが、
宣言後に内容を書き換えたり、
もしくは変数名とCURSORという型だけ宣言しておいて、
中のSELECT文はあとから代入する、というようなことはできないのでしょうか?
つか、例えば小数点以下3桁までしか要らなかったら、1000倍して整数にすれば楽だろ。
user_table
--------------------------------
id | name | dated
--------------------------------
1 | hoge | 2010-08-21
--------------------------------
2 | hoge | 2010-08-23
--------------------------------
2 | hoge | 2010-08-22
....
thread_table
--------------------------------
id |uid |thread| text | dated
--------------------------------
1 | 1 | 1 | aaa.. | 2010-08-21
--------------------------------
2 | 2 | 1 | ccc.. | 2010-08-23
--------------------------------
2 | 1 | 2 | aaa.. | 2010-08-22
....
select
`b`.`id`,`thread`,`name`,`text`,`b``dated`
from
`user_table` `a`,`thread_table` `b`
where
`a`.`id`=`b`.`uid`
order by `dated` desc limit 5;
thread_tableのthreadの値がユニークで一番更新日が新しいもの順(order by `thread_table`.dated desc)に取り出したいのですがどうすればいいでしょうか?
distinctやgroup by `thread`を追加しても期待した値が取れませんでした。
thread_table をあらかじめソートしたものを
from user_table a, (select * from thread_table order by dated desc ) b
結合。group byすればよい。
group by thread;
from user_table a, (select * from thread_table order by dated desc ) b
結合。group byすればよい。
group by thread;
質問です。
いろんなテーブルを結合したSQLで、
その一部にだけFOR UPDATEをかけることってできませんよね?
そういう場合はクエリを分けるしかないんでしょうか。
単純な例として、
ユーザー情報と、それに関連するマスタデータを取りたくて、
ユーザ情報はロックしたいけどマスタデータはロックしたくないとき、
1.ユーザー情報だけをSELECT FOR UPDATE
2.ユーザー情報とマスタデータを結合してSELECT(ロックしない)
とするのが普通?
いろんなテーブルを結合したSQLで、
その一部にだけFOR UPDATEをかけることってできませんよね?
そういう場合はクエリを分けるしかないんでしょうか。
単純な例として、
ユーザー情報と、それに関連するマスタデータを取りたくて、
ユーザ情報はロックしたいけどマスタデータはロックしたくないとき、
1.ユーザー情報だけをSELECT FOR UPDATE
2.ユーザー情報とマスタデータを結合してSELECT(ロックしない)
とするのが普通?
トランザクションの使用について質問があります。
これまで、
SELECT文を実行する場合には、
トランザクションを入れていなかったのですがこの方針は正しいですか?
DELETE / INSERT / UPDATE の場合には入れてます。
これまで、
SELECT文を実行する場合には、
トランザクションを入れていなかったのですがこの方針は正しいですか?
DELETE / INSERT / UPDATE の場合には入れてます。
いや、それを言うと全トランザクションをSERIALIZABLEにしないといけない
よその更新をどこまで見せるかはあくまで要件次第
よその更新をどこまで見せるかはあくまで要件次第
1レコードのサイズについてお聞きしたいのですが
レコードのサイズによってSQLのスピードが変わってきたりするのでしょうか?
テキストを保存しようとしているカラムがあるのですが、
varchar(255)とlongtextで迷っています
longtextにすればサイズの問題はないのですが、スピードや負荷に影響があるのかどうかが知りたいです
ご教授よろしくお願いします
レコードのサイズによってSQLのスピードが変わってきたりするのでしょうか?
テキストを保存しようとしているカラムがあるのですが、
varchar(255)とlongtextで迷っています
longtextにすればサイズの問題はないのですが、スピードや負荷に影響があるのかどうかが知りたいです
ご教授よろしくお願いします
http://dev.mysql.com/doc/refman/4.1/ja/select.html
>LIMIT 節を使用すると、SELECT ステートメントで返されるレコード数を制限することができる。LIMIT は 1 つまたは 2 つの数値引数を取る。
中略
>引数が 2 つの場合、最初の引数は戻り値として返す最初のレコードまでのオフセットを表し、2 つ目の引数は戻り値として返す最大レコード数を表す。
最高で40個まで獲ってこいって言ってんだから、32でも不思議は無いわな。
>LIMIT 節を使用すると、SELECT ステートメントで返されるレコード数を制限することができる。LIMIT は 1 つまたは 2 つの数値引数を取る。
中略
>引数が 2 つの場合、最初の引数は戻り値として返す最初のレコードまでのオフセットを表し、2 つ目の引数は戻り値として返す最大レコード数を表す。
最高で40個まで獲ってこいって言ってんだから、32でも不思議は無いわな。
初心者ですみません。
2万件毎に区切られたCSVファイルを10万件分登録するとして、データの追加はどのようにすれば良いのでしょうか?
サーバーの仕様なのか、INSERTできる件数の上限があるみたいで相当な時間が掛かってしまいそうなので…。
2万件毎に区切られたCSVファイルを10万件分登録するとして、データの追加はどのようにすれば良いのでしょうか?
サーバーの仕様なのか、INSERTできる件数の上限があるみたいで相当な時間が掛かってしまいそうなので…。
前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / mysql スレッド一覧へ
みんなの評価 : 類似してるかもしれないスレッド
- MySQL 総合 Part12 (1001) - [94%] - 2008/1/30 17:34 ○
- MySQL 総合 Part13 (996) - [94%] - 2008/6/10 21:02 ☆
- MySQL 総合 Part14 (1001) - [94%] - 2008/11/23 10:17 ☆
- MySQL 総合 Part15 (1001) - [94%] - 2009/4/20 12:15 ☆
- MySQL 総合 Part17 (1001) - [94%] - 2010/6/10 20:47 ○
- MySQL 総合 Part19 (982) - [94%] - 2011/6/9 2:33
- MySQL 総合 Part26 (860) - [89%] - 2023/2/2 9:30
- MySQL 総合 Part20 (995) - [89%] - 2011/10/17 4:48
- MySQL 総合 Part21 (1001) - [89%] - 2011/12/25 22:16
- MySQL 総合 Part22 (1001) - [89%] - 2012/7/10 16:45
- MySQL 総合 Part23 (992) - [89%] - 2013/8/11 17:00
- MySQL 総合 Part24 (1010) - [89%] - 2015/2/14 4:46
- MySQL 総合 Part25 (947) - [89%] - 2017/6/18 6:30
- MySQL vs PostgreSQL Part2 (941) - [31%] - 2022/5/26 1:30 ○
トップメニューへ / →のくす牧場書庫について