ないよそんなの

今年初めにSun（MySQL ABを買収したとこ）をORACLEが買収したとは言え、
ORACLE系DBと連動や移植、それに差別化とかはどうなってるのかねぇ？

>>802
お前が情弱ってことは理解してあげたから、このスレのログぐらい読んでから
レスする程度の知能はつけろよ…

>>802
MYSQLをつぶす方向に進んでるよ
サポート料金も跳ね上がったとか

>>804
ちゃんと内容読んでこいよ。
安いほとんどサポート内容のないプランをやめただけ。
残ったプランは前と比べてよくなった部分も多い。

つぶそうとしてるかはわからん。まぁ潰れたとしても他に多くのforkがあるし、完全に死ぬことはないだろう。

mysql 5.1.41 OS XP

トリガー、ストアドプロシージャなどをバックアップするのってどうするんですか？

oracleのストアドをさくっと書き換えるコツ
教えてください

MySQLってストアドもないのか
ダメ過ぎる

Web系のスキルの低さをなめんな。
セットで使われるのはPHPなんだぜ？

>>811
お前が無知なのと自分で調べる能力がないバカなのはわかった。
ストアドプロシージャ自体は存在する。PL/SQLのような言語がないってだけだ。

しっかし、この手のバカは粘着するんだよなぁ…

ストアドが無くても代換があり速度もそこそこならば
無くても問題なさそうな気はするが。

>>814
簡単な移行手段が無いのが問題かと思う。
同じことが同じソースで書けないのはつらい。

DBMS間でのSQLの移植性なんてあってないようなものだもんなあ
複数DBMS対応で売ってるものって実際問題どうしてるんだろう?

DBMS固有の機能を使わなければいいだけじゃないの？

PHPのarray（64文字の文字列を30個）をMySQLで保存しておきたいのですが、どのような実装が一番スマートでしょうか？
今考えているのがSQL上にlog0～log30という名のフィールドを確保して一行づつ保存する方法と、PHPのserializeを使って一つにまとめてから保存する方法を考えています。
前者はフィールドを配列の個数分確保するのがダメっぽいし、後者は一行の変更でも全部書き換えるのがダメっぽくて実装に踏みきれません。

30個しかないなら後者の方法で一行更新したってたかがしれてるとは思うが
配列のキーのフィールドと値のフィールドでテーブルを作ればいいんじゃないのか

すみません、説明不足でした。
db_userというテーブルにidその他のフィールドがあって、個人のデータとしてログのようなものを３０行保存したいのです。
serializeで処理してしまっていいんですかね…

なんか目的がちょっと想像出来ないけど、
頻繁に更新するなら後者の方がいいような気もする。
また、一時的なものならmemcachedとかの方が楽そう。
serializedせずそのままarrayを入れられるし。

それで機能しなくなるなら
なんのためのインデックスだって話だよ

ただし追加削除時にインデックス更新のオーバーヘッドはあるよ

MYSQLを使ったプログラムを始めたばかりのビギナーです。
どうしていいか分からなくて行き詰まったのでどなたか教えて頂けないでしょうか？

データベースの中で、データにIDを採番していく事にしたのですが、新たなデータ作成時にそのIDが採番済みかを調べるのに、
BINARY型の255バイトのデータ数千個で管理しようと考えました。（IDは途中が削除されて空き番に成り得ます）
IDが1番から順番に、そのデータの対応ビットをONOFFして採番済みかチェックし、ビットOFFなら採番済みとしてそのIDでデータ追加可能にする感じです。

ですが基本的な部分ですがこのデータ手動での初期値投入方法が分かりません。
INSERT文で入れるにしても例えば全ビットoffなら255個の連結したBINARY型データをどう記述するのか分かりません。
文字列として記述不可能だと思うのですがどうすればいいのでしょうか？

それとももっと効率が良いとか、一般的な手段があるのでしょうか？

よろしくお願いします。

なお、明日も仕事が早いので寝ないといけないのでアドバイス頂いても返事は遅れてしまうと思いますがお許しください。

単に他のレコードと重複しないユニークな数値で良いなら
insert 時に自動的に連番を振る AUTO_INCREMENT という機能があるが
これでは駄目かな？

ビギナーなのになぜわざわざわかりにくい方法をとるのか

codezineていうサイトでphpのプログラム例を読んでいたのですが、
mysqlを使った例題で、レコード同士の紐付けに関して

http://codezine.jp/article/detail/3908?p=2

に説明が書いてはあるのですが、読んでいても理解できないので
どなたか教えて下さい。

お願いします。

読むのﾏﾝﾄﾞｸｾお前ら要約しろって事ですね、わかります

ち、違います。誤解です。
質問の仕方が悪かったですね。
単純に紐付けの仕方と、aテーブルの1つのレコードに
bテーブルの複数の紐付く場合の、紐付け方と
読み出し方を教えて下さい。

リンク先の文字を読む気力がないので記憶だけで解説してみる
見当違いな解説してたらごめん。

aテーブル
ID name
1 上条当麻
2 御坂美琴

bテーブル
ID fruit
1 リンゴ
2 バナナ
3 キウイ

上条当麻はリンゴとバナナが好きで
御坂美琴はリンゴとキウイが好きというをテーブルにしてみる
cテーブル
id_a id_b
1 1
1 2
2 1
2 3

テーブルを連結するにはJOIN構文を使う
SELECT id_a,fruit FROM c LEFT JOIN b ON id_b=b.id
これで
id_a frout
1 リンゴ
1 バナナ
2 リンゴ
2 キウイ
ってテーブルが得られるはず。
この辺はmany-to-manyとかone-to-manyで検索したら山ほど出てくるから
ググってみてくれ

既存のDB設計を解析しております。
キャンペーンとしてテーブルがあり、「開始日(date)」と「終了日(date)」のカラムがあり、
「開始日」と「終了日」にプライマリキーが持たせてありました。
何かメリットはあるのでしょうか。

ER図を書く時にデータベースからリバースエンジニアリングしているのですが、正直この2個のカラムにプライマリキーはいらないんじゃないかと思います。

開始日が同じで終了日が異なるキャンペーンがあるんだろ。

>>839
となると、ER図にする場合は必要ないということですよね。
プライマリキーは他のテーブルと結合するために必要なキーだと認識しておりますが、
開始日・終了日みたいに結合する項目がない場合は外してもいいのでしょうか。

キャンペーンテーブルの内容と使用状況が判然としませんので、勝手な思い込みで書きます。

[ 開始日＋終了日 ] でプライマリーキーとすることで、index を作成する意図があるのかもしれません。

テーブルの使用状況として、開始日と終了日を組み合わせての検索が多いのであれば、そうした意図を含めてテーブルを作成する方も世の中に居たりします。

ER図にする上では、注目することではないとも考えられます。

>>841
恐らく仰る通りだと思います。
ありがとうございます。

プライマリキーの場合開始日と終了日にはNULLは許されないという制約を忘れるとまずいよ。

インデックス張るべきかどうかの判断指針ってありますか?

カーディナリティが高いかどうかとか

検索が遅ければ貼る

>>828

アドバイス有難うございます。
自分が付けてるIDは数字ではなく、独自形式なのと、
何度も何度もデータの追加、削除を限られた総量の中で繰り返す事を想定しているため、
削除したものの再利用が出来ない手段は取れません。

やはりIDの最後尾をどこかに保存しつつ、削除した時は削除済みID貯めこみ用のテーブルを作り、
そのテーブルで再利用出来るものが無かった時に再び最後尾から採番していくのが良さそうかなと思いました。

削除する時も他のデータの参照IDとして使われてないかチェックしないと中身のすり変わりが起こりますしね。

・プログラム起動時に、IDの最大値を取得する
・テーブルに削除フラグフィールドを追加する(indexも)
・情報の削除時、レコード削除ではなく削除フラグを立てる
・情報の追加時、削除フラグが立っているレコードを検索して存在すればそれを　update
　削除フラグが立っているレコードが存在しなければ、最大値の次の値を振って insert、最大値更新

インデックスマージって、どの程度効果があるものでしょうか。
個人的には、過度な期待は禁物な機能だと思っているのですが。
（複数カラムで1つのインデックスを張ったほうがずっといい）

感覚的ですみません。