レス数が1000を超えているけど、まだ書けるかも知れないよ。
MySQL 総合 Part24
- 1 :NAME IS NULL:2013/08/14(水) NY:AN:NY.AN ID:???.net
- オラクル社によるオープンソースのRDBMS、MySQLの総合スレです。
MySQL 総合 Part23
http://toro.2ch.net/test/read.cgi/db/1343294198/
MySQL Developer Zone http://dev.mysql.com/
MySQL 5.5 マニュアル (E) http://dev.mysql.com/doc/refman/5.5/en/index.html
MySQL 5.1 マニュアル (J) http://dev.mysql.com/doc/refman/5.1/ja/index.html
日本MySQLユーザ会(MyNA) http://www.mysql.gr.jp/
ML過去ログ http://www.mysql.gr.jp/mysqlml/mysql/
ここで質問をする前に、MyNAでのFAQと心得の条を最初に確認しましょう。
http://www.mysql.gr.jp/frame/modules/bwiki/?FAQ
http://www.mysql.gr.jp/frame/modules/bwiki/index.php?%BB%A8%B3%D8%2F%BF%B4%C6%C0
- 961 :NAME IS NULL:2015/01/04(日) 15:18:45.52 ID:???.net
- DBに持たせているとBLOG記事と一緒にバックアップを取ることもできて
便利のような気がするけど。
後はloginid,name,valueとしてユーザー毎に設定を保持できるように
するのも楽だし(もちろん静的ファイルでも可能だけど)。
>設定を参照する度にnameを検索することが少々無駄に感じてしまいます。
静的ファイルから読みだすのと対して変わらないような。
- 962 :NAME IS NULL:2015/01/04(日) 15:36:05.90 ID:???.net
- >>958
ユニークIDを付けて、運用時はそれをキーに検索したらどうかな。
- 963 :945:2015/01/04(日) 17:33:53.17 ID:???.net
- 皆様有難うございます。
15年来設定をテキストファイルで保存していたため、どうもRDBをRDBとして使う以外のことに抵抗があるだけなのかも知れません。
現在はテキストファイルに固定長で保存しているためにポインタをシークするだけで検索などは不要のため、どうも一々RDBに問合せを出すということが無駄に感じていました。
いくつかのWebシステムを読んでみたのですが、MovableTypeは少し特殊な方法かも知れませんが、多くの場合>>957さんの方法で行っているようです。
私もバックアップの事を考えている中でMySQLに入れることを考えたのですが、OpenPNEは画像ファイルもアクセス制限のためにDBに入れるなど、システム毎にいろいろな方法があるんですね。
ありがとうございました。
- 964 :NAME IS NULL:2015/01/04(日) 18:50:40.78 ID:???.net
- >>963
俺も>>957のような持たせ方は気持ち悪くてしょうがないけどねぇ。
- 965 :945:2015/01/04(日) 22:38:47.41 ID:???.net
- 気持ち悪いというか、valueフィールドはchar型にしなければならないので、ブール値や数値を一々変換するのが少々手間がかかる上に無駄に感じていますね。
そのために設定テーブルを作ると考えたのですが、それであれば設定を追加する度にテーブルを変更する必要が有り、1レコードしか無いテーブルを持つことになるのでそれも無駄に感じてしまいます。
私のシステムを変更してみたので、しばらく使ってみようと思います。
- 966 :NAME IS NULL:2015/01/04(日) 23:35:20.24 ID:???.net
- 何故世界中の多くのシステムでDBが使われているのか
それを考えたら答えは出るよな
無駄だと思うのは設計が間違っているか、DBを必要としないか
今作っているシステムがテキストファイル保存で事足りるならそれでええと思うよ
- 967 :NAME IS NULL:2015/01/05(月) 19:39:05.10 ID:ECYaSO8s.net
- テキストファイルだとブール値や数値は
いちいち変換しないのかな
- 968 :NAME IS NULL:2015/01/15(木) 13:51:06.34 ID:GI4jYeFb.net
- tinyintやsmallintについて質問です
予め最大値が決まっている小さな数を扱う場合、
現在はすべてint(1)で取り扱っていますが、
tinyint(tinyint(1)はBool型なので、それ以外)やsmaillintを使うべきなのでしょうか?
例えば0〜100までの数しか入らないデータを扱う場合は
int(1)ではなくtinyint(4)にした方がいいのでしょうか?
大は小を兼ねるともいいますが、tinyintにすることによって処理速度が上がったりしますか?
- 969 :NAME IS NULL:2015/01/15(木) 18:30:28.61 ID:???.net
- 【質問】
double型の項目に、「71.4」という値をセットして、レコードを新規登録
登録データを読み出して、更新しようとすると、エラーが発生する
原因や解決策が分かる方がいたら教えていただけると嬉しいです。
【問題の詳細】
VB6.0 SP5で作ったアプリケーションからMySQLのDBに対して更新を実行すると、下記のエラーが発生。
err=-2147217864
行が見つからなかったため、更新できません。
列の値は最後に読み込まれた後で変更された可能性があります。
【エラーが発生する条件】
1.レコードの登録でdouble型の項目に「71.4」という値を登録
2.登録したレコードを読み出し、更新をすると上記のエラー発生
***注意点***
「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
※「*」は半角アルファベtット
- 970 :NAME IS NULL:2015/01/15(木) 18:39:16.95 ID:???.net
- >>968
tinyintにすれば処理速度はあがります
個人的には、tinyintが好きではないのでsmallintを使います
データの大きさにもの凄くシビアであれば、tinyintを使った方がいいのだと思います。
mysqlのバージョンが変われば、データ型の取り扱いが変わる。(MySQL3.23の頃とchar型が違う)
こんなこともあるので、あまり多くのデータ型を使いたくないのが本音ではあります。
ただ、smallintとintegerでは、違いがかなりあるので、ある程度の使い分けは仕方なし。と考えています。
- 971 :NAME IS NULL:2015/01/15(木) 20:19:02.05 ID:???.net
- >>970
処理速度は上がるんですね!
解説も参考になります
ありがとうございました
- 972 :NAME IS NULL:2015/01/15(木) 23:08:24.17 ID:???.net
- intやtinyintの()の中の数字は、表示幅だからあんまり関係ない
- 973 :NAME IS NULL:2015/01/16(金) 03:44:11.94 ID:???.net
- 速度が上がるということについて信頼の置けるソースがなかな見つからず。
- 974 :958:2015/01/16(金) 09:02:38.93 ID:???.net
- カーソルロケーションを見失っている感じではあるんですよね。
INSERT INTOでExcuteしてレコードを追加するのをやめてみました。
VB6なので、カーソルロケーションをadUseClientに指定した上で、レコードをオープン
addNewでレコードを追加して、Updateすると
double型項目に71.4をセットしても、更新可能になりました。
SQL文で、Excuteするときに、カーソルロケーションを指定することって可能ですか?
- 975 :NAME IS NULL:2015/01/16(金) 13:34:34.83 ID:???.net
- >>974
MySQLの話だと思ってる?
- 976 :958:2015/01/16(金) 14:02:53.59 ID:???.net
- >>975
思っています。
あと、わざわざこういう言い方するのは悪意を感じて好きではないです。
指摘したいことがあるなら、指摘してください。
- 977 :NAME IS NULL:2015/01/16(金) 14:17:51.50 ID:???.net
- >>976
MySQL以外のDBだと発生しないという事を確認すること
その上で、他の人が再現する上で必要な情報を書くこと
例えばテーブルの定義、インサートするサンプルデータ
VBでやらないといけないなら、その部分のソースも
最低限、ここまでは書かないと誰もコメントくれないと思う。
- 978 :958:2015/01/16(金) 14:19:03.87 ID:???.net
- ついでなので。
サーバのコマンドラインから、MySQLに入り
INSERT INTOで、double型に71.4という値をセットしてレコード登録
INSERT INTO ***_*** set seqno = 1, **** = 71.4;
端末(Win 2K)からAccess2000で、該当のテーブルのリンクを表示(ODBC5.1)
ACCESS上から登録した71.4の値を変更しようとすると、「このレコードは他のユーザーによって変更されています」
カーソルロケーションを見失った時のような動きになります。
- 979 :958:2015/01/16(金) 14:44:35.77 ID:???.net
- >>977
サンプルですか。
では、現象が発生するデータを作ります。
環境は>>969の前提で。
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で起こった現象が再現できます
- 980 :NAME IS NULL:2015/01/16(金) 16:52:24.90 ID:???.net
- 「err=-2147217864」でググってみた?
- 981 :958:2015/01/16(金) 17:24:07.00 ID:???.net
- >>980
調べてはみました。
INSERT INTO で、double型に「71.4」をセットしてレコードを登録したときのみ発生するのかは分かりませんでした。
自分には見つけられそうに無いので、申し訳ないですが原因を教えてください。
- 982 :NAME IS NULL:2015/01/16(金) 20:10:24.21 ID:???.net
- >>981
なんでも人に頼るのはよくないよ。googleったら俺もすぐ見つけられたし。
http://bugs.mysql.com/bug.php?id=38147
これに載ってるところだとODBCドライバを更新するといいんじゃないのかな。
- 983 :958:2015/01/19(月) 08:28:20.33 ID:???.net
- >>982
>なんでも人に頼るのはよくないよ。googleったら俺もすぐ見つけられたし。
調べた上で、分からなかったので質問しています。
ありがとう御座いました。
- 984 :958:2015/01/19(月) 09:43:24.47 ID:???.net
- >>982
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
教えていただきありがとう御座いました。
- 985 :NAME IS NULL:2015/01/20(火) 04:40:23.64 ID:???.net
- ODBC最近使ってないけど、そんな頻繁にまともに接続できない事態に陥るかね。
>>984が事実なら相当ひどいが。
- 986 :NAME IS NULL:2015/01/21(水) 19:26:12.66 ID:???.net
- Win2kとか化石使ってることのほうがひどい。
- 987 :NAME IS NULL:2015/01/26(月) 13:21:58.44 ID:???.net
- MySQL+PHPのPDOで内部結合した後のfetchなんですが
表に内容が違うカラムがあった場合に、変数的に同じ名前になってしまいます。
テーブルA、テーブルBに果物というカラムがあって
それぞれ、りんご、みかんだった場合
$result = $stmt->fetch(PDO::FETCH_ASSOC);
$result["果物"]はみかんになってしまいます。
foreachで回してみても、りんごはどこにも居ないわけですが
これはテーブル設計が駄目で
対応はテーブルAにテーブルBを内部結合、またはテーブルBにテーブルAを内部結合といった
対策をとるしかないのでしょうか。
- 988 :NAME IS NULL:2015/01/26(月) 14:10:59.34 ID:???.net
- AS で名前つけるとかViewを作るとか
- 989 :NAME IS NULL:2015/01/26(月) 14:12:00.55 ID:???.net
- select A.果物 as A_果物, B.果物as B_果物 from 〜
- 990 :976:2015/01/26(月) 14:20:07.04 ID:???.net
- >>988,978
なるほどこういう機能があったんですね
素早いご回答ありがとうございます。
- 991 :NAME IS NULL:2015/02/05(木) 01:49:01.97 ID:???.net
- 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 は使用していません。
もっとこうした方がいいとか、助言があればよろしくお願いします。
- 992 :NAME IS NULL:2015/02/05(木) 06:46:52.04 ID:???.net
- >>991
どんなパッケージでもいえることだけど、こういうのを順に追っかけるのが一番の近道だと思う。
互換性のない変更もあるから、アップグレードするたびにチェックすること。
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なんてすっかりサポート対象外だろうから、いろいろ覚悟したほうがいいかと。
- 993 :NAME IS NULL:2015/02/05(木) 10:54:14.89 ID:???.net
- >>991
> 文字コードがまちまちで
> sjis を無理矢理バイナリとして格納している
4.1以上へのアップグレードはこういうの直さないとうまくいかないから
アプリ修正も視野に入れた方がいいです
- 994 :NAME IS NULL:2015/02/05(木) 12:47:30.50 ID:???.net
- >>986
そう?
Win2kは、まだ10台くらいある
Xpは30台くらい
うちは全部で200台くらいだけど、そのくらいの規模で一々MSのご都合に合わせてPC全部買い換えるとこがどれくらいあるんだろ。
- 995 :NAME IS NULL:2015/02/05(木) 12:52:30.24 ID:???.net
- 200台ってクライアントじゃないの?MySQL入れるの?
まあそれでもクライアントならパフォーマンスやハードのサポート切れたりするから
Win2kはないなあさすがに
- 996 :NAME IS NULL:2015/02/05(木) 12:58:34.59 ID:???.net
- >>995
975の話しの流れは、クライアントの話しだよ
クライアントがWin2kで、ODBC接続する話しの流れからだから。
- 997 :NAME IS NULL:2015/02/05(木) 15:27:18.93 ID:???.net
- >>994
いろいろ言いたいけど、ピンポイントでいうなら、なぜ買い換えるという発想になるの?
- 998 :NAME IS NULL:2015/02/05(木) 17:12:45.31 ID:???.net
- >>997
なんでこんな関係ない話しを広げようとするのか分からないけど・・・
買い換えるという発想にならないから、Win2kやXPも残っているという話しなんですが。
どうして、これに食いつくのか理解出来ない。
- 999 :NAME IS NULL:2015/02/05(木) 18:32:48.73 ID:???.net
- >>998
食いついたとか、広げようとか、そんな豪勢なもんじゃないよ。
何でPCを買い換えるんだろうなって思っただけで。
管理者じゃないんだろうし、どうでもいい話でした。
- 1000 :NAME IS NULL:2015/02/06(金) 00:14:36.22 ID:???.net
- 普通OS入れ替えだよね
- 1001 :980:2015/02/06(金) 01:55:35.44 ID:???.net
- >>992 >>993
どうもありがとうございます。
今日確認したところ、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 しか使ってないので、こういう不自然な処理を
普通にしてたのを久しぶりに思い出しました。
まあ、とりあえず叩けば映るので、必要に迫られるかさくっと挿入できる
いい案が浮かぶまで温存させておくことにします。
- 1002 :958:2015/02/06(金) 08:25:23.01 ID:???.net
- >>1001
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
- 1003 :958:2015/02/06(金) 18:15:22.05 ID:???.net
- ごめんなさい。
手持ちのソースからコード抜粋したので余計な部分も載ってます。
SQL文だけ参考にしてみてください
- 1004 :NAME IS NULL:2015/02/07(土) 04:42:09.46 ID:???.net
- 日本語の表示で、枠線の位置がずれるのは何が原因かな?
文字コードはmysqlもphpもsshも全部utf8なんだけど。。。
http://i.imgur.com/DEvIins.jpg
- 1005 :NAME IS NULL:2015/02/07(土) 04:57:35.88 ID:???.net
- ターミナルの設定の問題。CJKの文字幅設定がどっかにあるじゃろ。
- 1006 :NAME IS NULL:2015/02/07(土) 22:44:08.84 ID:???.net
- Cjkにチェックを入れても変わらないですね。。
- 1007 :NAME IS NULL:2015/02/07(土) 22:46:56.41 ID:???.net
- あ、ぱっと見でCJKの問題だろうとは思ったんだけど、それってmysqlが作ってる表自体がずれてるって話かな。
ならmysqlの出力設定になんかあるんでないの
- 1008 :NAME IS NULL:2015/02/08(日) 01:21:41.58 ID:???.net
- >>1007
そうなんですよ。mysqlの出力の表が日本語が含まれてるとずれるんです
この設定であってますよね?
http://i.imgur.com/SzMcSA5.jpg
- 1009 :NAME IS NULL:2015/02/09(月) 00:41:09.64 ID:???.net
- >>1008
確かMySQL 5.6で直った気がする
- 1010 :NAME IS NULL:2015/02/10(火) 00:14:24.43 ID:???.net
- http://jbbs.shitaraba.net/sports/42269/
285 KB
新着レスの表示
掲示板に戻る
全部
前100
次100
最新50
read.cgi ver 2014.07.20.01.SC 2014/07/20 D ★