>>637
同意。
バイナリをDBに格納するなんて基地外。
コネクション長時間握られてあっという間に飽和するぞ。
転送時間を考えるべし。

ごめん リストアって書いてあったね
リストアはどうやったの？

Bug #25162: Backing up DB from 5.1 adds 'USING BTREE' to KEYs on table creates
http://bugs.mysql.com/bug.php?id=25162
ということらしい
バージョンを合わせるか、「mysqldump --compatible=mysql40 ．．．」という手もあるようだ

>>651他
みなさんありがとうございましたm(_ _)m
素人なんで勉強になりました。
C案で決定でやることにします。

質問です。
NOW()やUNIX_TIMESTAMP()は、
FOR UPDATE等のロックで待たされた場合、
SELECTを仕掛けた瞬間と、待ちが終わってSELECTが実行できたときと
どちらの時間を返しますか？

どっちか知りたいなら試してみりゃいい。
ただし、決まっているとは限らんけどな。

>>662
おっしゃるとおり。時間ができたら試してみます。
べ、別に誰か既に試したなら教えてくれてもいいんだからねっ！

試してみた。結果、待ちが終わった時間を取得。

まぁ、ロックされてる情報にしたって最新のを取得してくれるんだから
時間もそうなるよなぁ。

phpを用いて、 mysqlで構築したDBからデータを取得し、ページ上に表示させようと考えています。
しかし、同じようにDBに接続し、クエリを発行しているのに取得結果が異なります。
対象のデータはchar型の文字列で、一方のページでは「TEST」となるのに対し、もう一方のページでは「"TEST"」となってしまいます。
接続には後述のような記述を用いていますが、SELECT文のみ異なります。
前者はSELECT * FROM test WHERE以下略
後者はSELECT aaa,bbb FROM test WHERE以下略
何故このような違いが出るのでしょうか？自分としてはクォーテーションが含まれない方が好ましいのですが、どうすれば良いでしょうか？
上記に関し、mysqlスレならわかるかもとphpスレより誘導されてきました。
何かわかる方が居られましたらご教示頂ければと思います。
参考までに、phpでDB接続・クエリ発行のソースを記しておきます。


$db = mysql_connect("localhost", "アカウント", "パスワード") or die("接続できませんでした\n");
mysql_query("SET NAMES utf8") or die("SET NAMES utf8 の設定ができません");
mysql_select_db("データベース名", $db) or die("該当するデータベースがないようです\n");
$query = "SELECT カラム FROM テーブル名 WHERE no = '$no'";
$result = mysql_query($query, $db);
$row = mysql_fetch_row($result);

肝心の出力処理の部分を書きなさい

>666
失礼しました。
両者とも$row[0]や$row[1]です。
前者は
echo $row[0];
後者は
print <<< HTML
<h2>$row[0]</h2>
HTML;
このあたりの違いはありますが・・・

データベースの容量が大きくなってしまったので、
ローカルで1行ずつ容量の削減をする作業をしています。
容量は700MB、レコード数は約20万です。

$i = file_get_contents('count.php');
$j = 0;
while(1){
$r = db_query('SELECT id,description FROM entry ORDER BY id LIMIT '.$j.',1'); //mysqli関数を使った独自関数です
if($r === FALSE){ die(); }
db_query('INSERT INTO entry SET decription = "'.mb_substr($r[0]['description'],0,200,'UTF-8').'" WHERE id = "'.$r[0]['id'].'"');
$i++;
file_put_contents('count.php',$i);
$j++;
if($j==1000){break;} //ここの数字を変えて1度に処理する量を変える
}
db_query('OPTIMIZE TABLE entry');

テーブルの容量が減れば減るほど、UPDATEやOPTIMIZEは早く終わるのではと思い、
1000行ずつやってみているのですが、1回に数分かかり、200回もやらなくてはいけません。
10000行やると1回に十数分かかり、だいたい15MBくらいの削減になるようです。

そこで質問なのですが、どれくらいずつやるのが良いと思いますか？
よろしくお願い致します。

あとプログラムで1行ずつやるよりは、こうしたほうが速いと思う。

CREATE TABLE temp AS SELECT id, SUBSTR(description, 0, 200) FROM entry;
DROP TABLE entry;
RENAME TABLE temp TO entry;

>>676
クエリはすべて成功したと考えてよい。

ちなみにこれも老婆心だとは思うけど
UPDATEは更新対象が０行でも正常終了するから気をつけて。

>>647
どなたか教えていただけると嬉しいです＞＜

>>647
難しいなぁ。
サブクエリ側で同じkey内のランダムな行をなんとかして
EXISTSでなんとかしてできそうな気がしたけどやっぱわからん。

>>647,6
ORDER BY rand()を利用すればできるかもしれないけど、全件走査になるだろうしな。
件数が少ないならプログラム側でなんとかなるだろうし、件数が極端に多くなったらIDを
乱数で発生させて適度に抜き出したほうがいいだろうし。

乱数ソートはインデックスが効かないんだから、SQLでなんとかするよりもプログラム側で
なんとかするほうがいいでないかの。

>>647
解決法は分からないんだけど・・・
差し支えなければ、どういう用途で使用するのか教えてくれる？

>665,>667です。
どなたかわかりませんでしょうか？(´・ω・｀)

>>682
とりあえず両者とも、クエリ発行直後の時点でechoなりログ吐くなりしてみたら？
そこの時点で同じなら、その後の処理になにかあるんだろう。

最近データベースに画像を保存できると知りました。それで、テーブルの扱いについて質問です。

例えば同じサービスに日記と料理レシピの紹介機能があってそれぞれ写真をUPできるとき、
1）写真データは専用の写真テーブルに入れるべきでしょうか？
2）それとも日記テーブルとレシピテーブルに写真用カラムを作って入れるべきですか？

1）の場合、登録時も引き出し時にトランザクションの負荷が発生するし、
2）の場合、ユーザごとの合計アップロード容量を算出する時手間です

どうしたら良いでしょうか
合計容量の算出なんて各ユーザの管理画面でしか不要だから2）が正解でしょうか
それとも第3・第4のテーブルを使って効率的に実装する方法があるんでしょうか

どういう風に作るとどんな面で利点がある、という形で意見貰えると嬉しいです
初心者過ぎてDB設計の留意点などわからないので漠然とした質問になってすみません
よろしくお願いします

ユーザの立場を想像して言うと、一枚の写真を日記とレシピの両方に
使いたい場合もあるだろうなぁ、とか思うんだな。

>>685
>1）の場合、登録時も引き出し時にトランザクションの負荷が発生するし、
ここがわからん
別テーブルにすると更新も読み出しも負荷が高くなるって意味？

個人的には画像は無理にDBに入れんでも
ファイルでいいんｼﾞｬﾏｲｶと思うが

>>686
ありがとうございます。確かにそうですね～！
「日記の記入と一緒に画像UP」の他に「既存の画像アーカイブから選んで日記に貼りつけ」の
機能も必要ですね

>>687
あ、引き出し時はトランザクションいらないですね
でもjoinが発生するんでしょうか
＞別テーブルにすると更新も読み出しも負荷が高くなるって意味？
はい、トランザクションとかjoinとか、そういうものが少しでも発生しないように
作った方が良いのかなと思いまして…

画像を普通にファイルとして保存する場合、利用ファイル容量の計算難しくないですか？
（PHP使ってるんですが…　任意のディレクトリ以下のファイル容量を
再帰的に取得できる関数があるのかな～）
DBに画像登録なら、ファイルサイズも保存出来るからSUMで一発解決かなーと思いました

画像自体はファイルで、そのデータだけDBいれときゃいいようなー

>トランザクションとかjoinとか、そういうものが少しでも発生しないように


なんで瑣末な事をやたらと気にするのかね

>>687
少しでも負荷を軽くしたいのならファイルで扱ったほうがいいと思うけどな。そもそも画像データ
そのものは検索対象にならないんだし。

>画像を普通にファイルとして保存する場合、利用ファイル容量の計算難しくないですか？
ファイル名と一緒にサイズも登録しておけばいいだけじゃないの。

>>689
なんか初耳です。データだけってのはどういうことですか？
ファイル容量のデータ（100kbとか）のこと？

>>690
大した負荷じゃないんですかね？
トランザクションもjoinも最近おぼえたので「なんか大層なことをしてしまってる」ような
気がしてるんですが。

>>691
＞ファイル名と一緒にサイズも登録
これは689さんの言ってることと一緒でしょうか？　そういうことですよね？
容量計算用のテーブルにファイルサイズを入れる、と。なるほど…

>>692
>トランザクションもjoinも最近おぼえたので「なんか大層なことをしてしまってる」ような
>気がしてるんですが。

そりゃやらない場合よりはオーバーヘッドはあるよ。
ただ、それらをなるべく使わないようになんてのは、RDBを使う旨みをなるべく捨てようと
してるようなもんだわな。
まあとことん高負荷なサービス運営しようと言うところなら、一部その旨みを捨ててでも
システムへの負荷を下げるという技を使ってるかもしれないけど、こんなとこでこんなの
聞いてる人が作るものなら、先々は分らんが当面はそういう話は関係無いでしょ。
まずは実装の細かいとこでの効率なんかより、素直な設計のちゃんと動くものを作り
上げることを考えた方がよろし。

>データだけってのはどういうことですか？

画像データは普通のバラのファイルとして格納しといて、
そのファイルの情報(パス名とか)だけDBに入れておくってことだと思う。

>>693
あーなるほど、わかりました！　ありがとうございました

画像はシステム的に破綻をきたしやすいよ。
DBにいれると例えばWeb側から画像表示となった場合、
（ローカルサーバにDBない前提だが）
ネットワーク越しにMySQLのポートを長時間つかむことになる。
ローカルでも同じことだけどね。
データ量がテキストの比じゃないからね。
俺も昔管理のしやすさを期待してそうしたけど大変なことになった。

DBに入れて初回アクセス時に適当なディレクトリにコピーを作っておいて、二回目以降はそちらを参照。
一定時間が過ぎたらディレクトリから削除。
毎回DBから取得はキツいでしょ

デカいデータを取り出すのが遅いとかそういう話してるんじゃないのか
データURIスキーム使ってもそこは一緒じゃん

2つの開発環境でdescのdiffを取っていて気づいたのですが、
片方ではあるビューのDEFAULT欄に元テーブルのカラムのDEFAULT値が
表示されるのですが、もう片方ではNULLとなります。
他にも片方で0000-00-00 00:00:00、もう一方でNULLになる箇所などがあります。

ビューのDEFAULTの欄なので、実質的な違いはないのですが、
これって仕様なんでしょうか？
それともバージョン違いのせい？（5.0.22と5.0.45）

できれば両方とも同じ表示になるようにしたいのですが、
ビュー再作成ではダメでした…