MySQL 総合 Part24

まあ何回かやってみれば
テキスト使うのが馬鹿らしくなるのでわかると思う
使い方慣れるまでは面倒かもしれないけど

>>947
製作者がそういう風にしたほうが便利だと思ったからやってるだけ。
あなたは静的ファイルのほうが無駄がないと思っているからそうしているだけ。
よそはよそ、うちはうち。
だから別に気にしなくていいよ。

DBに持たせているとBLOG記事と一緒にバックアップを取ることもできて
便利のような気がするけど。
後はloginid,name,valueとしてユーザー毎に設定を保持できるように
するのも楽だし（もちろん静的ファイルでも可能だけど）。

>設定を参照する度にnameを検索することが少々無駄に感じてしまいます。
静的ファイルから読みだすのと対して変わらないような。

>>947
ユニークIDを付けて、運用時はそれをキーに検索したらどうかな。

皆様有難うございます。

15年来設定をテキストファイルで保存していたため、どうもRDBをRDBとして使う以外のことに抵抗があるだけなのかも知れません。
現在はテキストファイルに固定長で保存しているためにポインタをシークするだけで検索などは不要のため、どうも一々RDBに問合せを出すということが無駄に感じていました。

いくつかのWebシステムを読んでみたのですが、MovableTypeは少し特殊な方法かも知れませんが、多くの場合>>946さんの方法で行っているようです。

私もバックアップの事を考えている中でMySQLに入れることを考えたのですが、OpenPNEは画像ファイルもアクセス制限のためにDBに入れるなど、システム毎にいろいろな方法があるんですね。

ありがとうございました。

>>952
俺も>>946のような持たせ方は気持ち悪くてしょうがないけどねぇ。

気持ち悪いというか、valueフィールドはchar型にしなければならないので、ブール値や数値を一々変換するのが少々手間がかかる上に無駄に感じていますね。

そのために設定テーブルを作ると考えたのですが、それであれば設定を追加する度にテーブルを変更する必要が有り、1レコードしか無いテーブルを持つことになるのでそれも無駄に感じてしまいます。

私のシステムを変更してみたので、しばらく使ってみようと思います。

何故世界中の多くのシステムでDBが使われているのか
それを考えたら答えは出るよな
無駄だと思うのは設計が間違っているか、DBを必要としないか
今作っているシステムがテキストファイル保存で事足りるならそれでええと思うよ

テキストファイルだとブール値や数値は
いちいち変換しないのかな

tinyintやsmallintについて質問です
予め最大値が決まっている小さな数を扱う場合、
現在はすべてint(1)で取り扱っていますが、
tinyint（tinyint(1)はBool型なので、それ以外）やsmaillintを使うべきなのでしょうか？

例えば0〜100までの数しか入らないデータを扱う場合は
int(1)ではなくtinyint(4)にした方がいいのでしょうか？
大は小を兼ねるともいいますが、tinyintにすることによって処理速度が上がったりしますか？

【質問】
double型の項目に、「71.4」という値をセットして、レコードを新規登録
登録データを読み出して、更新しようとすると、エラーが発生する
原因や解決策が分かる方がいたら教えていただけると嬉しいです。

【問題の詳細】
VB6.0 SP5で作ったアプリケーションからMySQLのDBに対して更新を実行すると、下記のエラーが発生。
err=-2147217864
行が見つからなかったため、更新できません。
列の値は最後に読み込まれた後で変更された可能性があります。

【エラーが発生する条件】
１．レコードの登録でdouble型の項目に「71.4」という値を登録
２．登録したレコードを読み出し、更新をすると上記のエラー発生
＊＊＊注意点＊＊＊
「71.4」という値以外を新規で登録した場合は、登録したレコードを読み出して更新しても、エラーは発生しない。
その際に、「71.4」という値で更新も可能
更新で「71.4」になったレコードを読み出して、再度更新しても上記のエラーは発生しない。

【環境】
○サーバ側
OS：Linux RedHat Enterprise 6.5
DBサーバ：MySQL 5.1.71(x86_64)

○クライアント側
OS：
　Windows 7(32bit)
　Windows 2k Pro
ODBC：（それぞれのOSで共にエラーを確認）
　odbc3.51.04
　odbc5.01.08

【DBの構成】
DB名：「＊＊＊＊＊」
テーブル名：「＊＊＊_＊＊＊」
問題の項目：
　項目名「＊＊＊＊＊＊」
　データ型　double　※デフォルト（桁指定無し）
　Null：Yes
※「＊」は半角アルファベｔット

>>957
tinyintにすれば処理速度はあがります

個人的には、tinyintが好きではないのでsmallintを使います
データの大きさにもの凄くシビアであれば、tinyintを使った方がいいのだと思います。

mysqlのバージョンが変われば、データ型の取り扱いが変わる。（MySQL3.23の頃とchar型が違う）
こんなこともあるので、あまり多くのデータ型を使いたくないのが本音ではあります。
ただ、smallintとintegerでは、違いがかなりあるので、ある程度の使い分けは仕方なし。と考えています。

>>959
処理速度は上がるんですね！
解説も参考になります
ありがとうございました

intやtinyintの()の中の数字は、表示幅だからあんまり関係ない

速度が上がるということについて信頼の置けるソースがなかな見つからず。

カーソルロケーションを見失っている感じではあるんですよね。

INSERT INTOでExcuteしてレコードを追加するのをやめてみました。
VB6なので、カーソルロケーションをadUseClientに指定した上で、レコードをオープン
addNewでレコードを追加して、Updateすると
double型項目に71.4をセットしても、更新可能になりました。

SQL文で、Excuteするときに、カーソルロケーションを指定することって可能ですか？

>>963
MySQLの話だと思ってる？

>>964
思っています。

あと、わざわざこういう言い方するのは悪意を感じて好きではないです。
指摘したいことがあるなら、指摘してください。

>>965
MySQL以外のDBだと発生しないという事を確認すること
その上で、他の人が再現する上で必要な情報を書くこと
例えばテーブルの定義、インサートするサンプルデータ
VBでやらないといけないなら、その部分のソースも

最低限、ここまでは書かないと誰もコメントくれないと思う。

ついでなので。

サーバのコマンドラインから、MySQLに入り
INSERT　INTOで、double型に71.4という値をセットしてレコード登録
INSERT INTO ***_*** set seqno = 1, **** = 71.4;

端末（Win 2K）からAccess2000で、該当のテーブルのリンクを表示（ODBC5.1）
ACCESS上から登録した71.4の値を変更しようとすると、「このレコードは他のユーザーによって変更されています」
カーソルロケーションを見失った時のような動きになります。

>>966

サンプルですか。
では、現象が発生するデータを作ります。

環境は>>958の前提で。
DB作成
create database bcd;
テーブル作成
create table xyz_table (seqno integer not null default 0, gaikei double default null, PRIMARY KEY (seqno) );
レコード登録
insert into xyz_table set seqno = 1 , gaikei = 71.4;

このデータを、PC側の端末（Win2k Pro）からAccess2000でリンク（ODBC5.1）
ACCESS上からgaikei項目の71.4を変更しようとすると、
「このレコードは他のユーザーによって変更されています」
となり、自分の環境では958で起こった現象が再現できます

「err=-2147217864」でググってみた？

>>969
調べてはみました。

INSERT INTO　で、double型に「71.4」をセットしてレコードを登録したときのみ発生するのかは分かりませんでした。
自分には見つけられそうに無いので、申し訳ないですが原因を教えてください。

>>970
なんでも人に頼るのはよくないよ。googleったら俺もすぐ見つけられたし。

http://bugs.mysql.com/bug.php?id=38147
これに載ってるところだとODBCドライバを更新するといいんじゃないのかな。

>>971
＞なんでも人に頼るのはよくないよ。googleったら俺もすぐ見つけられたし。
調べた上で、分からなかったので質問しています。

ありがとう御座いました。

>>971
ODBCを更新してみました。

紹介していただいたサイトでは ODBC 5.1.9で正常動作すると書かれています。
ODBC5.1.9、5.1.12、51.1.13ドライバにアップグレードしたところ、
新規にDSNを作成しようとするとサーバのDBを取得できなかったため、接続はやめました。
最新のODBC 5.3.4では、DSNの作成に失敗するため、接続はやめました。
ODBC5.1.8に戻しています。
端末環境 Win2k Pro

教えていただきありがとう御座いました。

ODBC最近使ってないけど、そんな頻繁にまともに接続できない事態に陥るかね。
>>973が事実なら相当ひどいが。

Win2kとか化石使ってることのほうがひどい。

MySQL+PHPのPDOで内部結合した後のfetchなんですが
表に内容が違うカラムがあった場合に、変数的に同じ名前になってしまいます。

テーブルA、テーブルBに果物というカラムがあって
それぞれ、りんご、みかんだった場合
$result = $stmt->fetch(PDO::FETCH_ASSOC);
$result["果物"]はみかんになってしまいます。

foreachで回してみても、りんごはどこにも居ないわけですが
これはテーブル設計が駄目で
対応はテーブルAにテーブルBを内部結合、またはテーブルBにテーブルAを内部結合といった
対策をとるしかないのでしょうか。

AS で名前つけるとかViewを作るとか

select A.果物 as A_果物, B.果物as B_果物 from 〜

>>977,978
なるほどこういう機能があったんですね
素早いご回答ありがとうございます。

MySQL 3.23.58 を使用しているのですが、そろそろヤバいので
5.5 にアップデートしようと思っています。

1つのメジャーバージョンの間であれば、データベースファイルが
自動的にアップグレードできるようですが、そのバージョンは
4.0.30、4.1.25、5.0.96、5.1.73、5.5.42
で最適ですか? 間に挟むべきバージョンはありますか?

mysqldump を使う方法も検討していますが、文字コードがまちまちで
sjis を無理矢理バイナリとして格納している古いデータベースとかが
あるので、できれば避けたいです。

環境は Windows 2000 SP4 で、サーバー、クライアントは同じマシン、
主に使用しているクライアントは PHP 5.3.29、Perl 5.12.5 です。
用途は Web の開発用で、ODBC は使用していません。

もっとこうした方がいいとか、助言があればよろしくお願いします。

>>980
どんなパッケージでもいえることだけど、こういうのを順に追っかけるのが一番の近道だと思う。
互換性のない変更もあるから、アップグレードするたびにチェックすること。
http://dev.mysql.com/doc/refman/5.5/en/upgrading-from-previous-series.html

windowsならこれも。
やったことはないけど細かく手順を書いてくれててやさしさを感じた。
http://dev.mysql.com/doc/refman/5.5/en/windows-upgrading.html

あとWindows2000なんてすっかりサポート対象外だろうから、いろいろ覚悟したほうがいいかと。

>>980
> 文字コードがまちまちで
> sjis を無理矢理バイナリとして格納している

4.1以上へのアップグレードはこういうの直さないとうまくいかないから
アプリ修正も視野に入れた方がいいです

>>975
そう？
Win2kは、まだ10台くらいある
Xpは30台くらい
うちは全部で200台くらいだけど、そのくらいの規模で一々MSのご都合に合わせてPC全部買い換えるとこがどれくらいあるんだろ。

200台ってクライアントじゃないの？MySQL入れるの？
まあそれでもクライアントならパフォーマンスやハードのサポート切れたりするから
Win2kはないなあさすがに

>>984
975の話しの流れは、クライアントの話しだよ
クライアントがWin2ｋで、ODBC接続する話しの流れからだから。

>>983
いろいろ言いたいけど、ピンポイントでいうなら、なぜ買い換えるという発想になるの？

>>986
なんでこんな関係ない話しを広げようとするのか分からないけど･･･
買い換えるという発想にならないから、Win2kやXPも残っているという話しなんですが。
どうして、これに食いつくのか理解出来ない。

>>987
食いついたとか、広げようとか、そんな豪勢なもんじゃないよ。
何でPCを買い換えるんだろうなって思っただけで。
管理者じゃないんだろうし、どうでもいい話でした。

普通OS入れ替えだよね

>>981 >>982
どうもありがとうございます。

今日確認したところ、Windows 2000 は安定してますが CRT がそろそろ
逝ってしまいそうな感じでしたので、当初予定していたアップデートを
あきらめて、現行のサイトを保管しているマシンにデータベース単位で
同居させることにしました。

移転先は Windows 7 に MySQL 4.1.25 がインストール済みです。

ここは慎重に data ディレクトリ丸ごとのコピーはせずに mysqldump を
使うやり方を採用することにしました。

いざダンプした取り込もうとしたところ sjis のテーブルの取り込みで
いきなりエラーが出てうまくいきませんでした。

エラーが出る箇所を見ると '十' とか2バイト目が 0x5C になる文字の
後ろに \ が入って '十\' になってるんですよね。

確か 3.23.58 のころは INSERT INTO t VALUES ('十\') にするのが
正解だった気がするので、これが入らないとなるとコードの方もかなり
直す必要が出てきそうです。

最近は 4.1.25 で utf8 しか使ってないので、こういう不自然な処理を
普通にしてたのを久しぶりに思い出しました。

まあ、とりあえず叩けば映るので、必要に迫られるかさくっと挿入できる
いい案が浮かぶまで温存させておくことにします。

>>990
CSVに落して、CSVファイルをインポートするっていう形はどうですか？
テーブル名が日本語の場合、エンコードが違うことでSQL文の実行で失敗することもありますが、半角英数のテーブル名であれば、これで移行できるかもしれません。

CSVにエクスポート
str = "select * from " & TableName(cnt) & " "
str = str & "into outfile 'C:\" & TableName(icnt) & ".csv' "
str = str & "fields terminated by '\,' "
str = str & "enclosed by '\'' ;"
''SQL実行
ado.Execute str, result

CSVからインポート
str = "load data "
str = str & "infile 'C:\" & TableName(cnt) & ".csv' "
str = str & "into table " & TableName(cnt) & " "
str = str & "fields terminated by '\,' "
str = str & "enclosed by '\'' ;"
''SQL実行
v_ado_conn.Execute str, result

ごめんなさい。
手持ちのソースからコード抜粋したので余計な部分も載ってます。
SQL文だけ参考にしてみてください

日本語の表示で、枠線の位置がずれるのは何が原因かな？
文字コードはmysqlもphpもsshも全部utf8なんだけど。。。
http://i.imgur.com/DEvIins.jpg

ターミナルの設定の問題。CJKの文字幅設定がどっかにあるじゃろ。

Cjkにチェックを入れても変わらないですね。。

あ、ぱっと見でCJKの問題だろうとは思ったんだけど、それってmysqlが作ってる表自体がずれてるって話かな。
ならmysqlの出力設定になんかあるんでないの

>>996
そうなんですよ。mysqlの出力の表が日本語が含まれてるとずれるんです
この設定であってますよね?
http://i.imgur.com/SzMcSA5.jpg