普通は３番でも、>>946がやる３番は、何か違うものになりそうな気がする・・・

>>944
実は必須ではないんだぜ。

こういう時に left join 使えばいいんですね…。

バッチで30個のテーブルに1万件ずつほどのデータを登録しようと思っています。
バッチで登録処理を行なっている間も他のプログラムからテーブルへの
参照が行われる事が考えられるのでトランザクションを貼ろうと考えていますが、
beginをバッチの開始直後,commitをバッチの終了時に行うと
凄くパフォーマンスが悪いように思えます。
テーブル単位でトランザクションを貼ると、
他のプログラムから参照を行ったときに
テーブル間のデータの不整合が発生することが考えられるのですが、
みなさんはこういう場合はどの様に設計されますか？

>>962

> バッチで登録処理を行なっている間も他のプログラムからテーブルへの
> 参照が行われる事が考えられるのでトランザクションを貼ろうと考えていますが、

参照が行われるからトランザクションを使う？
その発想にいたる背景がわからないので答え難い。

安易にバッチ処理での登録と考える前に、
登録処理中にテーブル参照されることで発生する不都合が何かを考慮してから、
データ登録の方法を考えるべきだと思います。

>>963

言葉足らずで申し訳ありません。

テーブルを参照するプログラムは
データの集計を行うプログラムになります。
Aというテーブルではバッチからの更新が終了しているけれど
Bというテーブルではまだバッチで更新中となっている場合
HOGEというプログラムが両方のテーブルの情報を集計するとなると
テーブル間の不整合が発生するのでトランザクションを使用しています。

そして今回はバッチで登録・更新をするテーブルの数が多いので
>>962にあるような質問をさせていただきました。

HOGE というプログラムが、テーブルAとテーブルBを参照するんですね?
そのHOGEというプログラムが、テーブルAとテーブルBに登録処理をしている最中でも稼動するんですね?

HOGE というプログラムがシステムの中で重要度が高いのであれば…

テーブルAとテーブルBにデータを登録する際には、HOGEというプログラムを考慮して、
テーブルAとBへのデータ登録は両テーブルの整合性が取れている状態として1件ごとに処理をする。

そんな方法を検討する可能性も有ります。

述べられている「参照するプログラム」が出力する結果が、そのシステムでどれだけ重要であるかを考慮する必要があります。

逆の意味で述べれば、テーブル更新が終了する前に、システムとして重要な出力結果を出すHOGEを実行しない、これが適切だとも言えます。

初歩的な質問ですが探してもわからなかったので質問します
MySQL5.1をInnoDB Pluginで使っていますが、
1つのテーブルのカラム数は大体このくらいまでにしておいた方が良い、ってのはありますか？
扱うデータが多くて、素直に組むとカラム数が200ぐらいになるのですが
これが1億レコードぐらいになると、パフォーマンスに結構影響しますか？
経験がなくてわからないので、皆さんの意見を聞きたいです

>>966
InnoDBは8KBのレコード長制限がある。
VARCHAR、TEXTなど長いカラムはページ外に保存されるのだけど、
200カラムは作れない可能性が高いので事前に確認しないとだめ
作れるなら性能はそんなに気にしなくてもよい

>>964
別にバッチ処理中か確認するようにすれば？
別テーブルにフラグみたいなもん立てるとか。

素直にトランザクションで解決してなにが悪いのかワカラン。
コミットに時間がかかってもバッチ処理なら問題ないだろうし。

ユーザー作成時に

CREATE USER ＜ユーザ名＞ IDENTIFIED BY '＜パスワード＞';

この時に同時に権限を設定するという事は出来ないのですか？これはあくまでもユーザーを作成するだけで
権限付与は従来からのgrant文でということ？

>>971

> カーソルを使って、１件ずつ読みだして処理する。。
> MySQLで同じような処理を行おうと思いましたが、
> カーソルに対応していないことを知りました。

あなたの言われている「カーソルに対応していない」とは、何を指しているのか理解できません。

>>974
カーソル知らないの？
1行ずつフェッチして、更新したりできるんだよ、大量データを逐次処理できるの

> カーソルに対応していない

カーソルは知っているけれども、対応していないが漠然としているのでは？

>>971
カーソルに対応しているmysqlがあるとでも？

>>978
http://dev.mysql.com/doc/refman/5.1/ja/cursors.html

>>979
それ、ストアドだって。
もともと、Cライブラリでカーソルとかいうことじゃね？

問題は、MySQLの通信プロトコル上、非prepare系のAPIでは
SQLを実行した瞬間に結果の全件がクライアントに送られるところ。
MySQLのカーソル操作はクライアント上でエミュレーションしているに過ぎない。
だからSELECT結果が5GBとかに達する場合、クライアントが32bitだと処理できない。

他のRDBMSでは「次のレコードをよこせ」というリクエストを送って
数十レコードごと逐次結果が返されるようになっている。

mysql_stmt_prepare()系は逐次レコードを返すはずだけど
そもそもMySQLでそういうバッチ処理を書く人があまりいないので
ノウハウが少ない。

>>965
レスありがとうございます。
>HOGE というプログラムが、テーブルAとテーブルBを参照するんですね?
そうです。
>そのHOGEというプログラムが、テーブルAとテーブルBに登録処理をしている最中でも稼動するんですね?
そうです。

>テーブル更新が終了する前に、システムとして重要な出力結果を出すHOGEを実行しない、これが適切だとも言えます。
こちらの方法を検討してみようかと思っています。
ただ、バッチは30分近くかかりそうなので、
その間HOGEが実行されないのが業務用件的にNGになりそうな気配もあります。


>>968
ありがとうございます。
その方向で少し検討してみます。

>>969
大量のデータを登録・更新するときって
トランザクションをずーっと貼りつづけていると
すこぶるパフォーマンスが落ちることってありませんか？
あ、バックグラウンドのバッチだからそんなの気にしなくてもいいじゃないかって
ことでしょうか？

>>983
> >>969
> 大量のデータを登録・更新するときって
> トランザクションをずーっと貼りつづけていると
> すこぶるパフォーマンスが落ちることってありませんか？

InnoDBのMVCCはそこまでアホな実装じゃない。
バッチだから仮に遅くても気にしなくていいってのはそう思うし。