私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレMySQL 総合 Part17
mysql スレッド一覧へ / mysql とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 : ○
レスフィルター : (試験中)
ローカルのphpMyAdminでテーブルを作成する時にテーブル名を
大文字で入力し作成しているのですが、
テーブルを作成し終わるとなぜか小文字になってしまってます。
何が原因でしょうか？
※Windows Vista
大文字で入力し作成しているのですが、
テーブルを作成し終わるとなぜか小文字になってしまってます。
何が原因でしょうか？
※Windows Vista
質問させてください
SQL文の文末についてですが ～';で終わらなければいけないところを
～':"; こんな感じで書いていたところがありエラーログが出ていました
・・・・が、正常にSQL文が実行されているようなのですが、これはMySQLの親切機能みたいなものなのでしょうか？
適当なSelect文の文末を↑みたいにわざと間違えて実行したところエラーのウィンドウは表示されますが
その後正常にSqL文が実行されるのを確認しました。
SQL文の文末についてですが ～';で終わらなければいけないところを
～':"; こんな感じで書いていたところがありエラーログが出ていました
・・・・が、正常にSQL文が実行されているようなのですが、これはMySQLの親切機能みたいなものなのでしょうか？
適当なSelect文の文末を↑みたいにわざと間違えて実行したところエラーのウィンドウは表示されますが
その後正常にSqL文が実行されるのを確認しました。
phpMyAdminの話で申し訳ないがちょと質問
フィールドの順番を変えたいのですが
どうやるんでしょうか？
フィールドを追加していったらよく見る必要なフィールドが画面外に orz
フィールドの後に追加というのはわかりましたが
「構造」やら「操作」を見てもそれらしいものが見あたらず…
フィールドの順番を変えたいのですが
どうやるんでしょうか？
フィールドを追加していったらよく見る必要なフィールドが画面外に orz
フィールドの後に追加というのはわかりましたが
「構造」やら「操作」を見てもそれらしいものが見あたらず…
小手先でやるなら、新しいフィールドを作ってから、
update table set newfield=oldfield
してから、古いフィールド削除して、フィールドのリネームなのかな？
※バックアップは忘れずに。
update table set newfield=oldfield
してから、古いフィールド削除して、フィールドのリネームなのかな？
※バックアップは忘れずに。
ああ、そっか、そういう手があるか、頭良いな～。
エクスポートしてコピペしようかと思ってたｗ
エクスポートしてコピペしようかと思ってたｗ
SQL文のUPDATEで「飲食店 あいうえお」となっているレコードを
「あいうえお」だけに更新したいのですが、SQL文だけで出来ますでしょうか？
出来る場合は、SQL文のアドバイスをお願いします。
「あいうえお」だけに更新したいのですが、SQL文だけで出来ますでしょうか？
出来る場合は、SQL文のアドバイスをお願いします。
ご返答有難うございます。
20個くらいnow()で指定されているプログラムがあり、日付を
好きなように遡って検証したいといわれたのですが、
これらを変更しないでどうにかできないかと思い質問させて
いただいた次第です。
よろしくお願いいたします。
20個くらいnow()で指定されているプログラムがあり、日付を
好きなように遡って検証したいといわれたのですが、
これらを変更しないでどうにかできないかと思い質問させて
いただいた次第です。
よろしくお願いいたします。
変更しない、というのはプログラムに埋め込んだSQLのこと？
データ変更していいなら直接SQL叩くとか
時刻はOSで1つのグローバルな場所から都度持ってくるから
プロセス内だけというのは難しいかも、OS次第かもしれないけど。
データ変更していいなら直接SQL叩くとか
時刻はOSで1つのグローバルな場所から都度持ってくるから
プロセス内だけというのは難しいかも、OS次第かもしれないけど。
それはperlの範疇だなぁ
sub now {return time; }
*main::now = sub( reutrn 1; );
もしくは
*CORE::GLOBAL::time = sub { return 1; };
もしくは
use subs qw( time );
sub time { return 1; };
で関数を上書きすれ
テストの基本だべ
sub now {return time; }
*main::now = sub( reutrn 1; );
もしくは
*CORE::GLOBAL::time = sub { return 1; };
もしくは
use subs qw( time );
sub time { return 1; };
で関数を上書きすれ
テストの基本だべ
delete from data id NOT IN (select id from data where shouhin_id=1 order by update desc limit 10);
これは動かないでしょうか、検証してないけど。
これは動かないでしょうか、検証してないけど。
delete from data where id NOT IN (select id from data where shouhin_id=1 order by update desc limit 10);
whereが抜けてた。
whereが抜けてた。
バイナリログって全部保存しておくものですか？
尋常じゃない量になりそうなんですが
尋常じゃない量になりそうなんですが
バイナリログの定番の運用法ってよく分からないよね。
バックアップ取ったら定期的に purge するもんだと思ってるけど。
バックアップ取ったら定期的に purge するもんだと思ってるけど。
レプリケーションなしの場合は、バイナリログというのは
フルバックアップを取った時点から現在までロールフォワードするためのもの。
フルバックアップを3世代取るとして
4/04 フルバックアップA取得
4/11 フルバックアップB取得
4/18 フルバックアップC取得、4/03までのバイナリログを削除
4/25 フルバックアップA取得、4/11までのバイナリログを削除
...
って運用する。
Oracleなら普通だけど、まあMySQLでここまでやってるのは見たことないな。
フルバックアップを取った時点から現在までロールフォワードするためのもの。
フルバックアップを3世代取るとして
4/04 フルバックアップA取得
4/11 フルバックアップB取得
4/18 フルバックアップC取得、4/03までのバイナリログを削除
4/25 フルバックアップA取得、4/11までのバイナリログを削除
...
って運用する。
Oracleなら普通だけど、まあMySQLでここまでやってるのは見たことないな。
フォームからチェックボックスで趣味を複数選択した時の事で質問なんですが
ID 名前 性別 趣味
001 aさん 男 音楽、ドライブ、映画
005 bさん 女 料理、読書、音楽
こういった場合下のように趣味のテーブルを分けて
foreachでデータを入れるのが一般的なんでしょうか？
ID 名前 性別
001 aさん 男
005 bさん 女
ID 趣味
001 音楽
001 ドライブ
001 映画
005 料理
005 読書
005 音楽
なんだか冗長に見えるけどあってます？
ID 名前 性別 趣味
001 aさん 男 音楽、ドライブ、映画
005 bさん 女 料理、読書、音楽
こういった場合下のように趣味のテーブルを分けて
foreachでデータを入れるのが一般的なんでしょうか？
ID 名前 性別
001 aさん 男
005 bさん 女
ID 趣味
001 音楽
001 ドライブ
001 映画
005 料理
005 読書
005 音楽
なんだか冗長に見えるけどあってます？
大体あってる。
が、一時的に最初の形のテーブルに入れといて、
後でバッチ処理で正規化する場合もある。
が、一時的に最初の形のテーブルに入れといて、
後でバッチ処理で正規化する場合もある。
foreachするならデリミタが指定できるんで最初の形のテーブルでもいいんじゃないのかな。
趣味マスタとか作らないんなら、使うときにexplodeするとかのがコードが簡単かもしれんね。
ただ、ボリュームや優先順位、用途を知らんから何とも言えんけど
趣味マスタとか作らないんなら、使うときにexplodeするとかのがコードが簡単かもしれんね。
ただ、ボリュームや優先順位、用途を知らんから何とも言えんけど
mysql+php(Vertrigo)で蔵書のデータベース作ろうと思ってるんだけど
小説とか雑誌とか単行本とか参考書とかで必要な列が違うんだけどこういう場合それぞれテーブル分けるべき？
それとも被ってるところもあるしnull値OKにしてひとまとめにした方がいいですかね？
後者の場合は必要なデータだけPHP側で表示させる感じで
データは多分1万レコードくらいで検索とかも出来るようにしたいんだけど
小説とか雑誌とか単行本とか参考書とかで必要な列が違うんだけどこういう場合それぞれテーブル分けるべき？
それとも被ってるところもあるしnull値OKにしてひとまとめにした方がいいですかね？
後者の場合は必要なデータだけPHP側で表示させる感じで
データは多分1万レコードくらいで検索とかも出来るようにしたいんだけど
プライベート用と考えて、俺なら分けないけど人それぞれだからなぁ。
分けない場合も後で本の種類が増えて行く時が不便だから、極力被らない列を減らす努力がいるな。
何入れてもいい列をつくって共通化を図るとか。
テーブルを分けると後で本の種類が増える度にテーブルの追加＋PHPのコードまで書き換えになるからなぁ。
どっちでもいいっちゃどっちでもよさそうだけどね。
分けない場合も後で本の種類が増えて行く時が不便だから、極力被らない列を減らす努力がいるな。
何入れてもいい列をつくって共通化を図るとか。
テーブルを分けると後で本の種類が増える度にテーブルの追加＋PHPのコードまで書き換えになるからなぁ。
どっちでもいいっちゃどっちでもよさそうだけどね。
AUTO_INCREMENTなカラムを主キーにせずに作る方法って無いかな。
REPLACE INTO ～ を使うときに、別のユニークキーを使ってるんだけど
念のため飾りで通し番号もほしいときにどうしたらいいかわからんです。
REPLACE INTO ～ を使うときに、別のユニークキーを使ってるんだけど
念のため飾りで通し番号もほしいときにどうしたらいいかわからんです。
>>797
そんなことできるんだ！ ありがとう
そんなことできるんだ！ ありがとう
おかしな質問かもしれませんが、
テーブルＡを参照している他のテーブルを知ることはできますか？
次のような状態に陥っています。
1.テーブルAを作成
2.外部キー制約によりAを参照するテーブルBを作成
3.テーブルBを削除(DROP TABLE)
4.テーブルAを削除しようとするとエラー
ERROR 1217 (23000): Cannot delete or update a parent row: a foreign key constraint fails
説明のためAとBを連続して作成していますが、実際には別々に作成しており、
どこか別のテーブルから参照されているのではないかと考えてるのですが・・・
よろしくお願いします。
テーブルＡを参照している他のテーブルを知ることはできますか？
次のような状態に陥っています。
1.テーブルAを作成
2.外部キー制約によりAを参照するテーブルBを作成
3.テーブルBを削除(DROP TABLE)
4.テーブルAを削除しようとするとエラー
ERROR 1217 (23000): Cannot delete or update a parent row: a foreign key constraint fails
説明のためAとBを連続して作成していますが、実際には別々に作成しており、
どこか別のテーブルから参照されているのではないかと考えてるのですが・・・
よろしくお願いします。
>>794
もしかして、レコードがあったらアップデート、無ければインサートをやりたいのかな？
直接的な回答じゃないが、自分はカラムにUnique制約付けて、
insert～
on DUPLICATE KEY UPDATE～
ってやってる。パフォーマンスはこの方が良さそうなもので。
期待値が違ってたらごめん、無視してくだされ。
もしかして、レコードがあったらアップデート、無ければインサートをやりたいのかな？
直接的な回答じゃないが、自分はカラムにUnique制約付けて、
insert～
on DUPLICATE KEY UPDATE～
ってやってる。パフォーマンスはこの方が良さそうなもので。
期待値が違ってたらごめん、無視してくだされ。
前へ 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 総合 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 総合 Part25 (947) - [89%] - 2017/6/18 6:30
- MySQL vs PostgreSQL Part2 (941) - [31%] - 2022/5/26 1:30 ○
トップメニューへ / →のくす牧場書庫について