私的良スレ書庫

不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterで
ログインするとレス評価できます。登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。

元スレMySQL 総合 Part12

mysql スレッド一覧へ / mysql とは? / 携帯版 / dat(gz)で取得 / トップメニュー

みんなの評価 : ○
レスフィルター : (試験中)

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ

/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで

101 : NAME IS - 2007/10/10(水) 19:47:56 ID:??? (-27,-30,-191)

もしかしてさんざん既出かと思うのですが、ざっとググった限りでは解決しなかったので
質問させてください。

今サーバで動いているMySQLはrpmでいれた5.0.22なのですが、コンパイルオプションとして
dont_use_default_fieldsを指定した動作になっているようです。開発環境のWindows版とで
insert時の挙動が異なり、大変不便な思いをしています。

これを解決するにはソースからコンパイルするほかないんでしょうか?
なお現在手に入る最新のrpmは以前のstandardではなくcommunity版となっており、
コンフリクトのためインストールできませんでした。

102 : NAME IS - 2007/10/10(水) 21:25:21 ID:??? (+14,+26,+0)

そのとおり

103 : NAME IS - 2007/10/10(水) 21:44:38 ID:??? (+22,+30,+0)

>>96
http://web.arena.ne.jp/suitepro/support/manual/webserver/apache.html

104 : NAME IS - 2007/10/10(水) 21:45:24 ID:??? (+22,+29,+0)

ごめん
こっちだった
http://web.arena.ne.jp/suite2/

105 : NAME IS - 2007/10/10(水) 21:51:45 ID:??? (+18,+30,+0)

http://web.arena.ne.jp/suitepro/service/spec_12.html

107 : NAME IS - 2007/10/10(水) 22:15:27 ID:??? (-21,-15,-2)

>>106
いまどき32bit環境かよ!

108 : NAME IS - 2007/10/10(水) 22:15:57 ID:??? (-28,-26,-2)

すまんかった、今すぐOpteron買ってくる！

110 : NAME IS - 2007/10/10(水) 23:07:16 ID:??? (-27,-30,-54)

アルェー(・3・)うち5.0.45なんだけドー

と思ったら

The Bytes_received and Bytes_sent status variables could hold only
32-bit values (not 64-bit values) on some platforms.

some platformsっすか・・・

112 : NAME IS - 2007/10/11(木) 00:58:35 ID:??? (-22,-29,-138)

スペース３個をスペース２個に置換をできるかぎりやる

１個→１個
２個→２個
３個→２個
４個→３個→２個
５個→４個→３個→２個

となって、必ずスペース１個か２個になる。
スペース３個がなくなったら、スペース２個を１個に置換すればおｋ

113 : NAME IS - 2007/10/11(木) 01:10:57 ID:dt5N6A3I (+19,+27,-4)

>>112
やっぱりデータベース内では限界なのかなあ？？？

117 : NAME IS - 2007/10/11(木) 10:55:56 ID:??? (-23,-6,+0)

>>115
範囲指定する。

119 : むこうの246 - 2007/10/12(金) 04:33:11 ID:??? (+26,+28,+0)

問題解決しました。どうもすいません。

121 : NAME IS - 2007/10/13(土) 15:35:09 ID:??? (+23,+29,-23)

>>120
マルチバイトで正規表現ってちゃんと使えるようになったの？
まだ鬼車パッチ当てなきゃだめ？

122 : NAME IS - 2007/10/14(日) 00:44:56 ID:??? (+22,+29,+0)

なってないような気がする。

123 : NAME IS - 2007/10/16(火) 17:22:51 ID:19Z+CTul (+30,+30,-153)

曖昧検索のやり方を教えてください。

検索用語「手伝う」

「おなかが減りました」
「手が痛いです」
「今日、母親の手伝いをしました」
「仕事を手伝う」

とあると、一番「手伝う」に近いものから出したいのです。
上記の場合だと

「仕事を手伝う」
「今日、母親の手伝いをしました」
「手が痛いです」
「おなかが減りました」

このように出したいのですが、そういった検索方法はありますでしょうか？

124 : NAME IS - 2007/10/16(火) 21:41:18 ID:??? (-11,-4,-4)

DBに曖昧検索機能など無い

125 : NAME IS - 2007/10/16(火) 21:44:19 ID:??? (-16,-4,+0)

つオントロジ

127 : NAME IS - 2007/10/16(火) 23:41:50 ID:JuRjnLqb (+24,+29,-7)

マッチ条件がだんだん短くなるような検索があればいいんだな、多分

128 : NAME IS - 2007/10/17(水) 01:17:33 ID:hXE7fedj (+30,+30,-152)

「手伝う」でマッチする文章を高いスコアとし、
「手伝」「伝う」でマッチするのはそれより低いスコア、
「手」「伝」「う」でマッチするのはもっと低いスコアとして

さらに出現頻度で合計して総合スコアをだせばいいのでは

どれくらいのスコアにすればいいのかは統計をとって最適値を求めればいいのでは

129 : NAME IS - 2007/10/17(水) 01:21:04 ID:??? (+27,+29,-6)

「てつだう」はスコア低くていいのかな

130 : NAME IS - 2007/10/17(水) 03:11:56 ID:??? (+32,+29,+1)

>>133
ないので自分で作ってください

131 : NAME IS - 2007/10/17(水) 16:27:20 ID:??? (-27,-30,-110)

かなりアクセスのあるデータベース(MySQL)を使用する際、

[構成A]
CPU:Core2Duo
メモリ:8GB
HDD:SATA
台数:4台

で行くのが良いのかそれとも

[構成B]
CPU:Core2Quad
メモリ:8GB
HDD:SAS 15000回転
台数:2台

で行くのが良いのかどちらでしょう。
読み込み中心ならメモリでキャッシュ処理できるから
構成Aのほうが圧倒的に優位な気はしますが。

参考コメントきぼんぬ

132 : NAME IS - 2007/10/17(水) 17:35:21 ID:??? (-21,-29,-46)

データの総量が8GB未満ならB。
ディスクにアクセスしないのでCPU性能が出るから。

データの総容量が8GB以上ならB。
ディスクが速いから。

構成書き間違ってない？

133 : NAME IS - 2007/10/17(水) 17:46:22 ID:??? (+43,+29,-42)

MySQLクラスタって参照のみでもそんなに速度がでないって言うし、それもプロ中のプロが限界まで調整した結果なんだろうし・・・・
相当単純なことしかさせない場合は別として、Bの方が安全かなあ？

134 : NAME IS - 2007/10/17(水) 18:49:45 ID:??? (+33,+29,-29)

会費制の会員システムをphp+mysqlで組もうと思うのですが、
料金部分のテーブル構成に非常に悩んでます。
どこか参考になるところないでしょうか。

ここの決定でほぼ決まるような気がします。

135 : NAME IS - 2007/10/17(水) 19:03:22 ID:??? (+32,+29,-42)

>>134
恐らくデータ型を悩んでいるんだと思いますが、
DECIMAL型で作成すれば、あとは特に問題は生じないと思います。
理由はお分かりだと思いますが、まるめ誤差を防ぐためです。

136 : 132 - 2007/10/17(水) 19:36:19 ID:??? (-19,-29,-136)

>>133
台数ってHDDの数じゃなくてサーバの台数？
勘違いしてた。前言撤回。
Aでレプリケーション組むのがいいと思う。
更新用が1台、参照用が3台。
MySQLは2コア→4コアの性能向上があまり良くないから。

ストレージエンジンはMyISAMかInnoDBで。
MySQL Clusterは忘れていいよ。あれは特定用途向けの単機能製品。
エンジンの機能実装がしょぼいのでちょっと凝ったSQL投げると性能劣化する。

137 : 133 - 2007/10/17(水) 20:41:11 ID:??? (+29,+29,-31)

>>136
すまんが俺は131じゃないんだ。
参照のみっていっても、必ずしもレプリケーションで対応できるわけでもないんじゃないかなっていう意味で>>133を捕らえて欲しい。

139 : NAME IS - 2007/10/18(木) 18:15:31 ID:??? (+21,+28,-1)

少なくとも案2はねえな。

140 : NAME IS - 2007/10/18(木) 20:24:54 ID:??? (-25,-30,-22)

案2にタグテーブルを追加して、
t_bookmark_taggingテーブルのtagをタグテーブルのプライマリキーに置き換える。

141 : NAME IS - 2007/10/18(木) 23:11:15 ID:??? (+30,+29,-14)

＞できればタグ同士をフォルダーのように関連付けたりもしたい

って具体的にどういうことがしたいん？

142 : NAME IS - 2007/10/19(金) 03:37:41 ID:H+ebEc3A (+35,+29,-4)

>>140
ありがとうございます！
汎用性高そうですね
勉強になります！
>>141
簡単にいうとgoogleみたいなことです

143 : NAME IS - 2007/10/19(金) 10:45:44 ID:??? (+37,+29,-11)

>>142
「googleみたいなこと」って全然意味が分からないのですが。
全文検索？

144 : NAME IS - 2007/10/19(金) 12:11:34 ID:??? (+7,+9,+0)

gmailのラベルのことを言ってるのかな

145 : NAME IS - 2007/10/19(金) 12:47:16 ID:??? (+18,+20,-2)

YouTube のタグみたいなのじゃなくて？

146 : NAME IS - 2007/10/19(金) 13:08:52 ID:vJ6ps9vK (+38,+29,-99)

>>143
キーワード「サル」の類義語として「ゴリラ」、「チンパンジー」などを階層的に保持したいのです。
サルで検索したらゴリラにカテゴライズされるものも表示したいのです。

自分なりに考えてみたのですが、ムズかしい！

147 : NAME IS - 2007/10/19(金) 13:46:45 ID:??? (+27,+29,-10)

そういうのはスマートにやろうとするより、ベタにやったほうがかえってうまくいったりする

148 : NAME IS - 2007/10/19(金) 14:21:48 ID:??? (+28,+29,-13)

>>146
そういうのは >>140 のタグテーブルにツリー構造を作るのがよかんべ。
ただ、ちゃんと考えないとパフォーマンス悪くなりそうだけど。

149 : NAME IS - 2007/10/19(金) 18:07:04 ID:??? (+32,+29,-19)

>>142
まずしっかり正規化してみる。おのずと答えが出るものだ。

150 : NAME IS - 2007/10/19(金) 18:09:44 ID:??? (+33,+29,-14)

google の関連検索見たいな事をTAGでやりたいのではないかと。
というか質問しておいて言葉足りな杉。

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ

/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで /

mysql スレッド一覧へ

みんなの評価 : ○

類似してるかもしれないスレッド

MySQL 総合 Part13 (996) - [94%] - 2008/6/10 21:02 ☆
MySQL 総合 Part19 (982) - [94%] - 2011/6/9 2:33
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 総合 Part18 (986) - [94%] - 2011/1/17 15:46
MySQL 総合 Part22 (1001) - [94%] - 2012/7/10 16:45
MySQL 総合 Part23 (992) - [89%] - 2013/8/11 17:00
MySQL 総合 Part26 (860) - [89%] - 2023/2/2 9:30
MySQL 総合 Part21 (1001) - [89%] - 2011/12/25 22:16
MySQL 総合 Part20 (995) - [89%] - 2011/10/17 4:48
MySQL 総合 Part24 (1010) - [89%] - 2015/2/14 4:46
MySQL 総合 Part25 (947) - [89%] - 2017/6/18 6:30
MySQL vs PostgreSQL Part2 (941) - [36%] - 2022/5/26 1:30 ○

トップメニューへ / →のくす牧場書庫について

総計:	126,368,627人
頁
昨日:	no data人
頁
今日:	人
頁