私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレMySQL 総合 Part24
mysql スレッド一覧へ / mysql とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 :
レスフィルター : (試験中)
>>945
エスケープして格納したいのなら、検索キーワードもエスケープすりゃええ。
エスケープして格納したいのなら、検索キーワードもエスケープすりゃええ。
ブログの様なシステムを制作しており、そのブログの設定はMySQLではなく静的ファイルに保存するようにしています。
他のシステムを見ると設定自体もMySQLに保存しているようなのですが、設定は1レコードのみのテーブルを用意して保存しているのでしょうか?
設定をRDBに保存するとどうしても無駄が多いように感じてしまうのですが、何か特殊な設定があるのでしょうか?
よろしくお願いします。
他のシステムを見ると設定自体もMySQLに保存しているようなのですが、設定は1レコードのみのテーブルを用意して保存しているのでしょうか?
設定をRDBに保存するとどうしても無駄が多いように感じてしまうのですが、何か特殊な設定があるのでしょうか?
よろしくお願いします。
なんで1レコード？
nameとvalueのテーブル作って
(1ページあたりの記事数,5),
(背景の色,#f00),
(タイトル,mYbloG),
って放り込めばいいんじゃないの？
nameとvalueのテーブル作って
(1ページあたりの記事数,5),
(背景の色,#f00),
(タイトル,mYbloG),
って放り込めばいいんじゃないの？
ありがとうございます。
たしかにそうですね。設定毎のフィールドを用意することを勝手にイメージしてました。
その方法でも設定が少量であればRDBとして無駄に思えるのですが、その方法が一般的になるでしょうか?
設定を参照する度にnameを検索することが少々無駄に感じてしまいます。
たしかにそうですね。設定毎のフィールドを用意することを勝手にイメージしてました。
その方法でも設定が少量であればRDBとして無駄に思えるのですが、その方法が一般的になるでしょうか?
設定を参照する度にnameを検索することが少々無駄に感じてしまいます。
まあ何回かやってみれば
テキスト使うのが馬鹿らしくなるのでわかると思う
使い方慣れるまでは面倒かもしれないけど
テキスト使うのが馬鹿らしくなるのでわかると思う
使い方慣れるまでは面倒かもしれないけど
>>958
製作者がそういう風にしたほうが便利だと思ったからやってるだけ。
あなたは静的ファイルのほうが無駄がないと思っているからそうしているだけ。
よそはよそ、うちはうち。
だから別に気にしなくていいよ。
製作者がそういう風にしたほうが便利だと思ったからやってるだけ。
あなたは静的ファイルのほうが無駄がないと思っているからそうしているだけ。
よそはよそ、うちはうち。
だから別に気にしなくていいよ。
DBに持たせているとBLOG記事と一緒にバックアップを取ることもできて
便利のような気がするけど。
後はloginid,name,valueとしてユーザー毎に設定を保持できるように
するのも楽だし（もちろん静的ファイルでも可能だけど）。
>設定を参照する度にnameを検索することが少々無駄に感じてしまいます。
静的ファイルから読みだすのと対して変わらないような。
便利のような気がするけど。
後はloginid,name,valueとしてユーザー毎に設定を保持できるように
するのも楽だし（もちろん静的ファイルでも可能だけど）。
>設定を参照する度にnameを検索することが少々無駄に感じてしまいます。
静的ファイルから読みだすのと対して変わらないような。
>>958
ユニークIDを付けて、運用時はそれをキーに検索したらどうかな。
ユニークIDを付けて、運用時はそれをキーに検索したらどうかな。
皆様有難うございます。
15年来設定をテキストファイルで保存していたため、どうもRDBをRDBとして使う以外のことに抵抗があるだけなのかも知れません。
現在はテキストファイルに固定長で保存しているためにポインタをシークするだけで検索などは不要のため、どうも一々RDBに問合せを出すということが無駄に感じていました。
いくつかのWebシステムを読んでみたのですが、MovableTypeは少し特殊な方法かも知れませんが、多くの場合>>957さんの方法で行っているようです。
私もバックアップの事を考えている中でMySQLに入れることを考えたのですが、OpenPNEは画像ファイルもアクセス制限のためにDBに入れるなど、システム毎にいろいろな方法があるんですね。
ありがとうございました。
15年来設定をテキストファイルで保存していたため、どうもRDBをRDBとして使う以外のことに抵抗があるだけなのかも知れません。
現在はテキストファイルに固定長で保存しているためにポインタをシークするだけで検索などは不要のため、どうも一々RDBに問合せを出すということが無駄に感じていました。
いくつかのWebシステムを読んでみたのですが、MovableTypeは少し特殊な方法かも知れませんが、多くの場合>>957さんの方法で行っているようです。
私もバックアップの事を考えている中でMySQLに入れることを考えたのですが、OpenPNEは画像ファイルもアクセス制限のためにDBに入れるなど、システム毎にいろいろな方法があるんですね。
ありがとうございました。
気持ち悪いというか、valueフィールドはchar型にしなければならないので、ブール値や数値を一々変換するのが少々手間がかかる上に無駄に感じていますね。
そのために設定テーブルを作ると考えたのですが、それであれば設定を追加する度にテーブルを変更する必要が有り、1レコードしか無いテーブルを持つことになるのでそれも無駄に感じてしまいます。
私のシステムを変更してみたので、しばらく使ってみようと思います。
そのために設定テーブルを作ると考えたのですが、それであれば設定を追加する度にテーブルを変更する必要が有り、1レコードしか無いテーブルを持つことになるのでそれも無駄に感じてしまいます。
私のシステムを変更してみたので、しばらく使ってみようと思います。
何故世界中の多くのシステムでDBが使われているのか
それを考えたら答えは出るよな
無駄だと思うのは設計が間違っているか、DBを必要としないか
今作っているシステムがテキストファイル保存で事足りるならそれでええと思うよ
それを考えたら答えは出るよな
無駄だと思うのは設計が間違っているか、DBを必要としないか
今作っているシステムがテキストファイル保存で事足りるならそれでええと思うよ
【質問】
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
※「＊」は半角アルファベｔット
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
※「＊」は半角アルファベｔット
>>968
tinyintにすれば処理速度はあがります
個人的には、tinyintが好きではないのでsmallintを使います
データの大きさにもの凄くシビアであれば、tinyintを使った方がいいのだと思います。
mysqlのバージョンが変われば、データ型の取り扱いが変わる。（MySQL3.23の頃とchar型が違う）
こんなこともあるので、あまり多くのデータ型を使いたくないのが本音ではあります。
ただ、smallintとintegerでは、違いがかなりあるので、ある程度の使い分けは仕方なし。と考えています。
tinyintにすれば処理速度はあがります
個人的には、tinyintが好きではないのでsmallintを使います
データの大きさにもの凄くシビアであれば、tinyintを使った方がいいのだと思います。
mysqlのバージョンが変われば、データ型の取り扱いが変わる。（MySQL3.23の頃とchar型が違う）
こんなこともあるので、あまり多くのデータ型を使いたくないのが本音ではあります。
ただ、smallintとintegerでは、違いがかなりあるので、ある程度の使い分けは仕方なし。と考えています。
intやtinyintの()の中の数字は、表示幅だからあんまり関係ない
速度が上がるということについて信頼の置けるソースがなかな見つからず。
カーソルロケーションを見失っている感じではあるんですよね。
INSERT INTOでExcuteしてレコードを追加するのをやめてみました。
VB6なので、カーソルロケーションをadUseClientに指定した上で、レコードをオープン
addNewでレコードを追加して、Updateすると
double型項目に71.4をセットしても、更新可能になりました。
SQL文で、Excuteするときに、カーソルロケーションを指定することって可能ですか？
INSERT INTOでExcuteしてレコードを追加するのをやめてみました。
VB6なので、カーソルロケーションをadUseClientに指定した上で、レコードをオープン
addNewでレコードを追加して、Updateすると
double型項目に71.4をセットしても、更新可能になりました。
SQL文で、Excuteするときに、カーソルロケーションを指定することって可能ですか？
>>974
MySQLの話だと思ってる？
MySQLの話だと思ってる？
>>976
MySQL以外のDBだと発生しないという事を確認すること
その上で、他の人が再現する上で必要な情報を書くこと
例えばテーブルの定義、インサートするサンプルデータ
VBでやらないといけないなら、その部分のソースも
最低限、ここまでは書かないと誰もコメントくれないと思う。
MySQL以外のDBだと発生しないという事を確認すること
その上で、他の人が再現する上で必要な情報を書くこと
例えばテーブルの定義、インサートするサンプルデータ
VBでやらないといけないなら、その部分のソースも
最低限、ここまでは書かないと誰もコメントくれないと思う。
ついでなので。
サーバのコマンドラインから、MySQLに入り
INSERT INTOで、double型に71.4という値をセットしてレコード登録
INSERT INTO ***_*** set seqno = 1, **** = 71.4;
端末（Win 2K）からAccess2000で、該当のテーブルのリンクを表示（ODBC5.1）
ACCESS上から登録した71.4の値を変更しようとすると、「このレコードは他のユーザーによって変更されています」
カーソルロケーションを見失った時のような動きになります。
サーバのコマンドラインから、MySQLに入り
INSERT INTOで、double型に71.4という値をセットしてレコード登録
INSERT INTO ***_*** set seqno = 1, **** = 71.4;
端末（Win 2K）からAccess2000で、該当のテーブルのリンクを表示（ODBC5.1）
ACCESS上から登録した71.4の値を変更しようとすると、「このレコードは他のユーザーによって変更されています」
カーソルロケーションを見失った時のような動きになります。
>>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で起こった現象が再現できます
サンプルですか。
では、現象が発生するデータを作ります。
環境は>>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
調べてはみました。
INSERT INTO で、double型に「71.4」をセットしてレコードを登録したときのみ発生するのかは分かりませんでした。
自分には見つけられそうに無いので、申し訳ないですが原因を教えてください。
調べてはみました。
INSERT INTO で、double型に「71.4」をセットしてレコードを登録したときのみ発生するのかは分かりませんでした。
自分には見つけられそうに無いので、申し訳ないですが原因を教えてください。
>>981
なんでも人に頼るのはよくないよ。googleったら俺もすぐ見つけられたし。
http://bugs.mysql.com/bug.php?id=38147
これに載ってるところだとODBCドライバを更新するといいんじゃないのかな。
なんでも人に頼るのはよくないよ。googleったら俺もすぐ見つけられたし。
http://bugs.mysql.com/bug.php?id=38147
これに載ってるところだとODBCドライバを更新するといいんじゃないのかな。
>>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
教えていただきありがとう御座いました。
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最近使ってないけど、そんな頻繁にまともに接続できない事態に陥るかね。
>>984が事実なら相当ひどいが。
>>984が事実なら相当ひどいが。
MySQL+PHPのPDOで内部結合した後のfetchなんですが
表に内容が違うカラムがあった場合に、変数的に同じ名前になってしまいます。
テーブルA、テーブルBに果物というカラムがあって
それぞれ、りんご、みかんだった場合
$result = $stmt->fetch(PDO::FETCH_ASSOC);
$result["果物"]はみかんになってしまいます。
foreachで回してみても、りんごはどこにも居ないわけですが
これはテーブル設計が駄目で
対応はテーブルAにテーブルBを内部結合、またはテーブルBにテーブルAを内部結合といった
対策をとるしかないのでしょうか。
表に内容が違うカラムがあった場合に、変数的に同じ名前になってしまいます。
テーブルA、テーブルBに果物というカラムがあって
それぞれ、りんご、みかんだった場合
$result = $stmt->fetch(PDO::FETCH_ASSOC);
$result["果物"]はみかんになってしまいます。
foreachで回してみても、りんごはどこにも居ないわけですが
これはテーブル設計が駄目で
対応はテーブルAにテーブルBを内部結合、またはテーブルBにテーブルAを内部結合といった
対策をとるしかないのでしょうか。
select A.果物 as A_果物, B.果物as B_果物 from ～
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 は使用していません。
もっとこうした方がいいとか、助言があればよろしくお願いします。
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 は使用していません。
もっとこうした方がいいとか、助言があればよろしくお願いします。
>>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なんてすっかりサポート対象外だろうから、いろいろ覚悟したほうがいいかと。
どんなパッケージでもいえることだけど、こういうのを順に追っかけるのが一番の近道だと思う。
互換性のない変更もあるから、アップグレードするたびにチェックすること。
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なんてすっかりサポート対象外だろうから、いろいろ覚悟したほうがいいかと。
>>986
そう？
Win2kは、まだ10台くらいある
Xpは30台くらい
うちは全部で200台くらいだけど、そのくらいの規模で一々MSのご都合に合わせてPC全部買い換えるとこがどれくらいあるんだろ。
そう？
Win2kは、まだ10台くらいある
Xpは30台くらい
うちは全部で200台くらいだけど、そのくらいの規模で一々MSのご都合に合わせてPC全部買い換えるとこがどれくらいあるんだろ。
200台ってクライアントじゃないの？MySQL入れるの？
まあそれでもクライアントならパフォーマンスやハードのサポート切れたりするから
Win2kはないなあさすがに
まあそれでもクライアントならパフォーマンスやハードのサポート切れたりするから
Win2kはないなあさすがに
>>994
いろいろ言いたいけど、ピンポイントでいうなら、なぜ買い換えるという発想になるの？
いろいろ言いたいけど、ピンポイントでいうなら、なぜ買い換えるという発想になるの？
>>997
なんでこんな関係ない話しを広げようとするのか分からないけど･･･
買い換えるという発想にならないから、Win2kやXPも残っているという話しなんですが。
どうして、これに食いつくのか理解出来ない。
なんでこんな関係ない話しを広げようとするのか分からないけど･･･
買い換えるという発想にならないから、Win2kやXPも残っているという話しなんですが。
どうして、これに食いつくのか理解出来ない。
前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / 
mysql スレッド一覧へ類似してるかもしれないスレッド
- MySQL 総合 Part25 (947) - [94%] - 2017/6/18 6:30
- MySQL 総合 Part14 (1001) - [94%] - 2008/11/23 10:17 ☆
- MySQL 総合 Part23 (992) - [94%] - 2013/8/11 17:00
- MySQL 総合 Part22 (1001) - [94%] - 2012/7/10 16:45
- MySQL 総合 Part26 (860) - [94%] - 2023/2/2 9:30
- MySQL 総合 Part21 (1001) - [94%] - 2011/12/25 22:16
- MySQL 総合 Part20 (995) - [94%] - 2011/10/17 4:48
- MySQL 総合 Part12 (1001) - [89%] - 2008/1/30 17:34 ○
- MySQL 総合 Part18 (986) - [89%] - 2011/1/17 15:46
- MySQL 総合 Part13 (996) - [89%] - 2008/6/10 21:02 ☆
- MySQL 総合 Part15 (1001) - [89%] - 2009/4/20 12:15 ☆
- MySQL 総合 Part17 (1001) - [89%] - 2010/6/10 20:47 ○
- MySQL 総合 Part19 (982) - [89%] - 2011/6/9 2:33
- MySQL vs PostgreSQL Part2 (941) - [36%] - 2022/5/26 1:30 ○
トップメニューへ / →のくす牧場書庫について