元スレMySQL 総合 Part18
mysql覧 / PC版 / みんなの評価 :
前へ
801 = :
ないよそんなの
803 = :
>>802
お前が情弱ってことは理解してあげたから、このスレのログぐらい読んでから
レスする程度の知能はつけろよ…
804 = :
>>802
MYSQLをつぶす方向に進んでるよ
サポート料金も跳ね上がったとか
806 = :
>>804
ちゃんと内容読んでこいよ。
安いほとんどサポート内容のないプランをやめただけ。
残ったプランは前と比べてよくなった部分も多い。
つぶそうとしてるかはわからん。まぁ潰れたとしても他に多くのforkがあるし、完全に死ぬことはないだろう。
809 = :
oracleのストアドをさくっと書き換えるコツ
教えてください
811 = :
MySQLってストアドもないのか
ダメ過ぎる
812 = :
Web系のスキルの低さをなめんな。
セットで使われるのはPHPなんだぜ？
813 = :
>>811
お前が無知なのと自分で調べる能力がないバカなのはわかった。
ストアドプロシージャ自体は存在する。PL/SQLのような言語がないってだけだ。
しっかし、この手のバカは粘着するんだよなぁ…
814 = :
ストアドが無くても代換があり速度もそこそこならば
無くても問題なさそうな気はするが。
815 = :
>>814
簡単な移行手段が無いのが問題かと思う。
同じことが同じソースで書けないのはつらい。
816 = :
DBMS間でのSQLの移植性なんてあってないようなものだもんなあ
複数DBMS対応で売ってるものって実際問題どうしてるんだろう?
817 = :
DBMS固有の機能を使わなければいいだけじゃないの？
820 = :
30個しかないなら後者の方法で一行更新したってたかがしれてるとは思うが
配列のキーのフィールドと値のフィールドでテーブルを作ればいいんじゃないのか
825 = :
それで機能しなくなるなら
なんのためのインデックスだって話だよ
ただし追加削除時にインデックス更新のオーバーヘッドはあるよ
826 = :
MYSQLを使ったプログラムを始めたばかりのビギナーです。
どうしていいか分からなくて行き詰まったのでどなたか教えて頂けないでしょうか？
データベースの中で、データにIDを採番していく事にしたのですが、新たなデータ作成時にそのIDが採番済みかを調べるのに、
BINARY型の255バイトのデータ数千個で管理しようと考えました。（IDは途中が削除されて空き番に成り得ます）
IDが1番から順番に、そのデータの対応ビットをONOFFして採番済みかチェックし、ビットOFFなら採番済みとしてそのIDでデータ追加可能にする感じです。
ですが基本的な部分ですがこのデータ手動での初期値投入方法が分かりません。
INSERT文で入れるにしても例えば全ビットoffなら255個の連結したBINARY型データをどう記述するのか分かりません。
文字列として記述不可能だと思うのですがどうすればいいのでしょうか？
それとももっと効率が良いとか、一般的な手段があるのでしょうか？
よろしくお願いします。
827 = :
なお、明日も仕事が早いので寝ないといけないのでアドバイス頂いても返事は遅れてしまうと思いますがお許しください。
829 = :
ビギナーなのになぜわざわざわかりにくい方法をとるのか
830 = :
codezineていうサイトでphpのプログラム例を読んでいたのですが、
mysqlを使った例題で、レコード同士の紐付けに関して
http://codezine.jp/article/detail/3908?p=2
に説明が書いてはあるのですが、読んでいても理解できないので
どなたか教えて下さい。
お願いします。
831 = :
読むのﾏﾝﾄﾞｸｾお前ら要約しろって事ですね、わかります
832 = :
ち、違います。誤解です。
質問の仕方が悪かったですね。
単純に紐付けの仕方と、aテーブルの1つのレコードに
bテーブルの複数の紐付く場合の、紐付け方と
読み出し方を教えて下さい。
838 :
既存のDB設計を解析しております。
キャンペーンとしてテーブルがあり、「開始日(date)」と「終了日(date)」のカラムがあり、
「開始日」と「終了日」にプライマリキーが持たせてありました。
何かメリットはあるのでしょうか。
ER図を書く時にデータベースからリバースエンジニアリングしているのですが、正直この2個のカラムにプライマリキーはいらないんじゃないかと思います。
839 = :
開始日が同じで終了日が異なるキャンペーンがあるんだろ。
840 = 838 :
>>839
となると、ER図にする場合は必要ないということですよね。
プライマリキーは他のテーブルと結合するために必要なキーだと認識しておりますが、
開始日・終了日みたいに結合する項目がない場合は外してもいいのでしょうか。
841 = :
キャンペーンテーブルの内容と使用状況が判然としませんので、勝手な思い込みで書きます。
[ 開始日＋終了日 ] でプライマリーキーとすることで、index を作成する意図があるのかもしれません。
テーブルの使用状況として、開始日と終了日を組み合わせての検索が多いのであれば、そうした意図を含めてテーブルを作成する方も世の中に居たりします。
ER図にする上では、注目することではないとも考えられます。
842 = 838 :
>>841
恐らく仰る通りだと思います。
ありがとうございます。
843 = :
プライマリキーの場合開始日と終了日にはNULLは許されないという制約を忘れるとまずいよ。
845 = :
インデックス張るべきかどうかの判断指針ってありますか?
846 = :
カーディナリティが高いかどうかとか
847 = :
検索が遅ければ貼る
848 = :
>>828
アドバイス有難うございます。
自分が付けてるIDは数字ではなく、独自形式なのと、
何度も何度もデータの追加、削除を限られた総量の中で繰り返す事を想定しているため、
削除したものの再利用が出来ない手段は取れません。
やはりIDの最後尾をどこかに保存しつつ、削除した時は削除済みID貯めこみ用のテーブルを作り、
そのテーブルで再利用出来るものが無かった時に再び最後尾から採番していくのが良さそうかなと思いました。
削除する時も他のデータの参照IDとして使われてないかチェックしないと中身のすり変わりが起こりますしね。
850 :
インデックスマージって、どの程度効果があるものでしょうか。
個人的には、過度な期待は禁物な機能だと思っているのですが。
（複数カラムで1つのインデックスを張ったほうがずっといい）
感覚的ですみません。
みんなの評価 :
mysql一覧へ類似してるかもしれないスレッド
- MySQL 総合 Part12 (1001) - [94%] - 2008/1/30 17:34 ○
- MySQL 総合 Part13 (996) - [94%] - 2008/6/10 21:02 ☆
- MySQL 総合 Part14 (1001) - [94%] - 2008/11/23 10:17 ☆
- MySQL 総合 Part15 (1001) - [94%] - 2009/4/20 12:15 ☆
- MySQL 総合 Part17 (1001) - [94%] - 2010/6/10 20:47 ○
- MySQL 総合 Part19 (982) - [94%] - 2011/6/9 2:33
- MySQL 総合 Part26 (860) - [89%] - 2023/2/2 9:30
- MySQL 総合 Part20 (995) - [89%] - 2011/10/17 4:48
- MySQL 総合 Part21 (1001) - [89%] - 2011/12/25 22:16
- MySQL 総合 Part22 (1001) - [89%] - 2012/7/10 16:45
- MySQL 総合 Part23 (992) - [89%] - 2013/8/11 17:00
- MySQL 総合 Part24 (1010) - [89%] - 2015/2/14 4:46
- MySQL 総合 Part25 (947) - [89%] - 2017/6/18 6:30
- MySQL vs PostgreSQL Part2 (941) - [31%] - 2022/5/26 1:30 ○
トップメニューへ / →のくす牧場書庫について