元スレMySQL 総合 Part15
mysql覧 / PC版 / みんなの評価 : ☆
前へ
102 = :
timestamp型のカラムの内容を元に、毎日一定の時刻にデータの削除をしたいんですが
このような事は可能でしょうか？
また、可能な場合はどのように設定すれば？
OSはFC6、mysqlは5.1.6です。
107 = :
新機能を除けば、5.0より5.1の方が品質は良い
5.1を使いつつ新機能は当面使わないのが勝ち組
108 = :
すみません、色々調査しましたがどうしてもうまく行かないので
質問させてください。
下記の様な掲示板データをテーブルに格納しております。
idは自動的に付与され、resはidの記事に対する返答が
あった場合、id(親記事)の番号は入ります。
この構成で、2008-12-18の記事だけ取得するが、
それに関連する返答も取得したい場合のクエリを
教えていただきたいと思います。
下記の構成だと、idの1とidの2が取得できれば良いのですが。。。
┌───┬──┬──────┬────────┐
│id │res │ comment │time │
├───┼──┼──────┼────────┤
│1 │0 │ あいう │2008-12-18 00:0 │
├───┼──┼──────┼────────┤
│2 │1 │ かきく │2008-12-19 00:10│
├───┼──┼──────┼────────┤
│3 │0 │ さしす │2008-12-19 01:20│
├───┼──┼──────┼────────┤
│4 │3 │ たちつ │2008-12-19 09:30│
├───┼──┼──────┼────────┤
│5 │3 │ なにぬ │2008-12-20 10:00 │
└───┴──┴──────┴────────┘
109 = :
>>107
ふーん、montyは全く逆のこと言ってるね
110 = :
>>108
select * from tbl_test where DATE(time) ='2008-12-18' or res in(select id from tbl_test where DATE(time)='2008-12-18');
これで出ることは出る
111 = :
>>118
108です。
ありがとうございます。
とりあえず抜き出せたことだけでも良かったです。
本来ならばデータは大量にあるのでスレッドのように抽出出来れば
いいのですが、こちらはまた考えて見ます。
既にご存知であればお教えください。
112 = :
失礼
108です
>>111は
>>110さんへの返答です。
113 = :
日本語を入力して、
データーを取り出してみたら、
？？？？？
になってるんだけど、何が悪かったかな？
116 = :
>>115
起動直後の一発目は速くなるかもしらんけど、
あとはOSのディスクキャッシュが効くだろうから
変わらん気がする。
期待すべきはデータを取り出すほうじゃないかな。
117 = :
シフトJISにするとSQLインジェクションに対応できないという
記事を読んだのですが、UTF-8でデーターベースを設定していても
シフトJISの文字が入ってきた場合、強制的にシフトJISとして
流通してしまうのでしょうか？
118 = :
http://blog.ohgaki.net/set_namesa_mcb_asc
SET NAMESは禁止
MySQLには文字エンコーディングを変更する「SET
NAMES」SQL文が用意されています。（PostgreSQL
も同様のSQL文、SET CLIENT_ENCODINGがありま
す）この機能はSQLコンソールからは使ってよい機能
ですが、アプリケーションからは使ってはならない機
能です。 SQLインジェクションに脆弱になる場合があ
ります。
119 = :
>>117
文字化けしたデータとして流通するでしょ
知識の問題じゃなく単に分析力の問題じゃん、それ
UTF-8のところにSJIS無理やり流し込むとか文字化けして当然なんだから
気にせずサニタイズしたらいい
ある文章が文字化けしてるのか自然な文章なのかを判別するのは割りと凝った事が必要そう
120 = :
つまりデーターベースで使われる文字コード自体を
utf-8としておけば、シフトJISの文字コードの文字が
入ってきても、普通にサニタイズすれば問題ないという
ことですね。
強制的にセキュリティを破られるのかと思った。
123 = :
MySQL 4.1以降での文字の扱い
MySQLはバージョン4.1以降で文字の扱いが大きく変わりました。
それまでのMySQLは、クライアント側で使っている文字(バイトの並び)
がそのままDBに格納され、取得するとそのまま返ってくるという非常
に単純な挙動でした。従って、クライアント側で使用している文字エ
ンコーディング(符号化方式)がDBで使用する文字エンコーディングと
異なる場合は、クライアント側でDBに合わせて変換を行う必要があり
ました。
しかし、MySQL 4.1以降ではサーバ側とクライアント側にそれぞれ文字
エンコーディングが指定できるようになり、ちゃんと設定すればサーバ
が透過的に変換してくれるので、クライアント側で事前に変換をする必
要が無くなったのです。
ここまでなら便利な機能が増えて良かった良かったとなるのですが、現
実はそうも行かないのでした。
MySQLはサーバもクライアントもデフォルトでlatin1という文字コード(?)を
使用します。latin1というのは名前の通りの文字コードで、漢字とかはか
らっきしダメです。MySQLサーバで何も指定せずにDBを作るとその中の
テーブルでは基本的にlatin1を使う事になりますので、日本向けのサー
ビスでMySQLを使用するなら、大抵はujis(EUC-JP),sjis(Shift_JIS),utf8(U
TF-8)のどれかを指定してDBを作ります。
DBの文字エンコーディングをUTF-8にして、DBサーバに対してクライアン
トとなるアプリケーションからUTF-8のINSERT SQLを発行した場合、問
題なく動きそうですが、MySQLのクライアントは何も設定していなければ
SQLの文字エンコーディングがlatin1だとサーバに通知するので、サーバ
ではlatin1からDBの文字エンコーディングであるUTF-8へ変換するルー
ルを送られてきたUTF-8に適用してしまい、大抵の場合文字化けしてグ
チャグチャになります。
4.1より前のバージョンではこういう変換は行われなかったため、その時
代に書かれたアプリケーションの中には動かなくなるものもあり対策が
必要になりました。
125 = :
「SQLインジェクション対策でプリペアドステートメントを使おう」
って記事をよく見かけるのですが、
プリペアドステートメントの使いかたが
わかりません
126 = :
http://jp.php.net/manual/ja/pdo.prepared-statements.php
ここのページに
「アプリケーションで明示的にプリペアドステート
メントを使用するように すれば、SQL インジェク
ションは決して発生しません」
って書いてあるのだが、文字コードに
シフトJISを使っている場合は、
プリペアドステートメントでも通過されて
しまうよね？
127 = :
SQLインジェクション対策で、
mysql_real_escape_string を使ってエスケープするのと、
preparedstatement と使う方法と、
2種類あるようですが、
どっちを使うべきなのですか？
129 = :
>>126
>文字コードにシフトJISを使っている場合は、
何コード使ってようが、関係ないと思う。
>プリペアドステートメントでも通過されてしまうよね？
「通過されてしまう」とは?
>>127
一般論としては、prepared statement なんだろうけど、
クエリーキャッシュが効かなくなるとかの難点もある。
133 = :
CREATE/DROP TEMPORARY TABLE と、TEMPORARY TABLE への INSERT/UPDATE/DELETE/SELECT
だけができるようなアクセス権限設定は可能でしょうか？
CREATE TEMPOARY TABLE テーブル名を決め打ちするくらいしか思いつきませんでした。
136 = :
show create database example1;
137 = :
>>136
ちょーさんくすです。
139 = :
インストール直後の設定がうまくいかない・・・。
141 = :
質問です。
PHPから操作するときなんだけど，hoge1ていうテーブルをuseするとき，
mysql_selectdb("hoge1");
と
mysql_query("use hoge1");
って何か違うの？
142 = :
最終的にそのPHPスクリプトが掴んでいるMySQLサーバーとのセッション上で
use hoge1 と同等の処理を実行するという点では同等だと思います >>141
個人的には MySQL と PHP のどちらに処理を寄せるかの趣味の問題かな、という気が
しますけれども、どちら派が多いのですかね。SQL文レベルでの紛れを嫌うのであれば
PHP上で mysql_selectdb を使う方が無難ですかねえ。
php5-5.2.4 のソースコードを眺めてみましたが、mysql_selectdb の方は最終的に
MySQL C API の mysql_select_db() を呼び出しているようです。
mysql_query の方は(当然ながら)引数として何でもありなので最終的には MySQL C API
の mysql_real_query() を呼び出しているようです。
mysql-5.0-5.0.51 のソースコードを眺めたところでは mysql_select_db() の
mysql_real_query() どちらも実質的には(マクロですが) simple_command()
を発行しているだけかな…最終的にサーバーと通信する際に流れる(MySQLプロ
トコルの)パケットは同じになるような気がします(けど調べ方がわからない)。
143 = :
>>140
違うよ
データーベース側の文字コードと、
クライアント側の文字コードを、同じとみなす、、
って設定をどうやるのか、って聞いてるの。
明示的に指定しないと、MySQLは、デフォルトで
lation-1を勝手にあてはめやがるから。
144 = :
WinXPproSP3でMySQL5.0を使用しております
小一時間ほど前からMySQLを始めたのですがバックアップの項目でつまっています
何が間違っているか教えていただけないでしょうか？
mysqldump -uroot -pxxxxxx -hlocalhost test > c:\Documents and Settings\xxxxxx\test.sql
と入力すると
ERROR:
Unknown command '\D'.
Outfile disabled.
Outfile disabled.
と表示されてしまいます
\Dがひっかかってるのは一目瞭然なのですが、教本ではこれでバックアップが出来てるようです
ためしに/Dや\d、/dなどに変えてみても（他の\も/に変えてます）同じようにOutfile Disabledと出てしまいます
何が問題なのでしょうか？
145 = :
すみません、自己解決しました
MySQLのコマンドラインからじゃなくて、Winにくっついてるほうからなんですね
146 = :
http://www.google.co.jp/trends?q=MySQL
MySQL
じわじわ低下しとる
147 = :
3000レコードほどのデータベースを更新する処理を考えています。
UPDATE hoge SET key = val, key = val, WHERE id = 1
UPDATE hoge SET key = val, key = val, WHERE id = 2
…
と3000個クエリを発行するのと、
REPLACE hoge (key,key) VALUES (val,val), (val,val)...
としてひとつのクエリで済ませるのではどちらが早いものなのでしょうか。
148 = :
Syntax Errorですね。上のWHEREの前のコンマは不要です。
みんなの評価 : ☆
mysql一覧へ類似してるかもしれないスレッド
- MySQL 総合 Part12 (1001) - [94%] - 2008/1/30 17:34 ○
- MySQL 総合 Part25 (947) - [94%] - 2017/6/18 6:30
- MySQL 総合 Part13 (996) - [94%] - 2008/6/10 21:02 ☆
- MySQL 総合 Part14 (1001) - [94%] - 2008/11/23 10:17 ☆
- MySQL 総合 Part17 (1001) - [94%] - 2010/6/10 20:47 ○
- MySQL 総合 Part18 (986) - [94%] - 2011/1/17 15:46
- 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 vs PostgreSQL Part2 (941) - [31%] - 2022/5/26 1:30 ○
トップメニューへ / →のくす牧場書庫について