>>50
月ごとだよね？
SELECT YEAR(access_datetime), MONTH(access_datetime), COUNT(*)
FROM access_log
GROUP BY YEAR(access_datetime), MONTH(access_datetime);

>>51
サンキュー！！！！！

カテゴリごとのリストページをページングしたいです。

SELECT c_id, c_name, c_spec FROM t_item WHERE c_category = '日本製' ORDER BY c_id DESC LIMIT 61, 60;

offsetを使うと余計なレコードまで取得するので遅くなるとの事です。どのように書けばoffsetを使わずに同じ結果を取得出来るでしょうか？

c_categoryで抽出してc_idで降順に並べ替えた後に新しく連番を振り直す事が出来れば比較演算子(？)を使って解決出来そうな気がするのですがその手段がわかりません。

よろしくお願いします。

こんばんは。
>>5
の質問について教えていただけると嬉しいです。
よろしくお願いします。

>>53
c_id がユニークなら
並び替えだけじゃなく読み飛ばしたい行の切り捨てにも使えるよね

>>55
c_idはユニークな連番の数字です。
それだと方法があるのですか？

INSERT　～　ON DUPLICATE KEY UPDATE や、REPLACEを使って、
・無ければINSERT
・有れば「とある条件の場合」「まるごと」UPDATE
について考えています
以下、「無ければINSERT」「datetimeが更新されていたらUPDATE」とする例ですが、

INSERT INTO test_table
( unique_key, column_a, column_b, datetime )
VALUES
( 1, 100, 200, '2015-04-01 00:00:00' )
ON DUPLICATE KEY UPDATE
column_a = (
CASE WHEN datetime < VALUES(datetime) THEN VALUES(column_a)
ELSE column_a END),
column_b = (
CASE WHEN datetime < VALUES(datetime) THEN VALUES(column_b)
ELSE column_b END),
datetime = (
CASE WHEN datetime < VALUES(datetime) THEN VALUES(datetime)
ELSE datetime END)

これでも動くのですが、「CASEの判定条件が同じ」「全部VALUESの値で更新」と
なってるのでもっと綺麗なSQLはないかなーと思ってるんですがありませんかね？
（実際はもっとカラムや条件が多くさらに長ったらしくなるので・・・）

>>56
SELECT * FROM t ORDER BY id LIMIT 20 OFFSET 60
↓
SELECT * FROM t WHERE id > 60 ORDER BY id LIMIT 20

任意のページには直接飛べない(Nページ目の1番目に来るidが判らない)から
事前にキャッシュを作るなりしてね

>>57
INSERT INTO ...
SELECT (ここを考えて)
ON DUPLICATE KEY UPDATE ...

で条件は一か所にまとめられるけど、あまり見やすくはないかな

>>58
遅くなりましたがありがとうございます
まだイマイチ理解できていないので色々試してみます

>>59
>>58の読み飛ばしは、
1ページあたり60件表示でかつ、order by c_id ASCである場合は、
c_idの小さいほうから 60*(ページ番号 - 1) 件は、間違いなく不要となるため
切り捨てることができるという考えかなと。

ただ、c_id DESC だし、データ内容や抽出条件次第で、
たとえば21ページ目を表示するにあたって1200件はじいたところで
焼け石に水になるのは目に見えてるので採用しなくていいと思う。

まずは適切なインデックスを作成することからはじめてみては。

PHP5.4+MySQL5.5を使ってます
ユーザーの入力した個人情報を暗号化して保存しようと思うのですが、
どのようなデータ型にすればいいでしょうか？

例えば住所なんかは文字数が長くなることが容易に想定できるので、
それを暗号化して更に文字数が増え、DBに設定したカラムの長さを超えてしまい復号化できなくなる心配があります
可変的な文字列を保存するカラムにしたいのですが、皆様はどういう風に作られていますでしょうか？

別に住所が暗号化されてる必要もないとは思うけど
長さはTEXT型にしとけば問題ないじゃない。
検索とか困らない？

個人情報って特定の個人に結びついてる情報が問題なんだから
個人が特定されなけりゃいいんでないの？

>>63
ありがとうございます、検索する予定は今のところないのでTEXT型にしてみます


＞個人情報って特定の個人に結びついてる情報が問題なんだから
＞個人が特定されなけりゃいいんでないの？
住所はそこに住んでる人がわかってしまうので個人情報だと思ったのですが、違うんですか？
そうであれば電話番号とかも暗号化して保存する必要はないんですかね？

誰にでも見える場所に置くの？
それなら暗号化は必要かな。

いえ、万が一の話ですがハッキング等によってDBが流出した場合を想定してのリスクヘッジです
みなさんがどのようにされてるか気になったのでそこも合わせて質問させていただきました

プロはどうしてるんだろうね？
自分も同じく初心者だから、エンコードして格納しておけばいいのかな？程度だよね。
たしかに検索するとき不便になっちゃうね。

報道されるような流出事件の場合、氏名や住所とかまで流出してるよね。
つまり、それらは暗号化してないことが多いのでは。
もちろん、パスワードは暗号化するのが一般的だろうけど。

暗号化にも復号可能な暗号化と復号不可能な暗号化があるのは理解してるの？
パスワードは暗号化してもパスワードとして成立するけど
氏名住所暗号化しちゃダメでしょ

やはりそういうものなんすね

＞氏名住所暗号化しちゃダメでしょ

いやこれ復号可能な暗号化前提でしょ
じゃないと保存する意味がない。それくらい読み取ろう

で、暗号化はMySQL側でやる手もある
AES_ENCRYPTならBlob型にすればおｋ
更にHEXを使えば文字で扱えるがVARBINARYもアリ
その場合は元の2倍くらいの長さを確保しておけば良い

>>69
分かって書いてると思うけど、複合不可のものは暗号とは言わないよ。MD5とか

>>71
復号可能な暗号化前提だとパスワードの暗号化って部分でおかしくなるんだよな

>>68
暗号化と言っても、ディスク、通信レイヤー、データベースファイル、アプリケーション‥‥どこに適用するかによって、守れるもの、守れないものがあるやね。

>>72
こいつバカだろ
勉強しなおして来い

59はパスワードなんて一言も言ってないのに、突然パスワードがーって言い出す低脳な奴がいるなｗ

>>72
？？？？

結局、どれが一番プロの方からすると正しいんでしょうか？

ハッシュ化だね

この場合なら暗号化で意味通るけど

>>79
ハッシュ化で調べたたら有用な情報がぞろぞろ出てきたっす。
ありがとうございます。

不可逆な暗号ってなんだよと数年前にも話題になってたな

個人情報など後で利用するものをハッシュ化するって・・・無知も程ほどにしておけ

パスワードはハッシュ化して入力値と照らし合わせることができるが、
>>76も言ってるがパスワードの話なんてしてないだろ

>>72の流れで>>79書いたんだけど
ややこしかったかな

一つの質問から話が派生していくことなんてよくあると思うけど、頑なに>>62がそんな話してない！って言うのはどうして？

>>69 があいまいな文章を書いたのがきっかけじゃないのかな

ver 5.6.20です

初歩的なんでしょうがちょっと教えて下さい。DBに誰が何時ログインし、どのデータベースにアクセスしたとかの追跡はバイナリログを設定し、
そこから…になるんですか？
別に深い意味は（今んところは）無いのですが

>>86
バイナリログではできない。
一般クエリログならできるけどログが多すぎて現実的ではない。
お金を払ってMySQLの商用版を買えばできる。
http://www-jp.mysql.com/products/enterprise/audit.html

>>87
ありがとうございます。ログの種類について確認しなおさんといかんですね
それにしても商用はやはりそれなりの価値があるんですねw

5.6がなんもしなくてもメモリを300M使ってるんですが
そういうもんですか？

googleのmysql魔改造に関する論文ありますか？

>>89
5.6で機能強化されたPerformance Schemaがメモリをバカ食いするので、
VPSなどメモリが少ない環境ではOFFにしてもよいかと。
[mysqld]
performance_schema = OFF

ありがとうございます
なんか気持ち悪かったんで

>>93
bind_address
ただデフォルトでネットワーク待ち受けしてるはずだけど

>>94
ありがとう
デフォルトで待ち受けしてたわ
ファイアウォールで閉じてた

外部キー みたいに連携しているキーで、でも制約は無い状態のキーのことを
なんと呼べばいいの？ 外部キーでいい？

制約のない外部キーってのがよくわからん

制約があるから連携していると言えるんであってそれが無いんだったら単にカラムが一致してるってだけなんでは？

workbenchの6.3.3、ファイルパスに日本語があると保存できなくない？
6.2.4で修正済みになってるのに直ってないわこれ

>>98
連携はしてるけど制約はしてない状態。