元スレMySQL 総合 Part19

mysql覧

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで

701 = :

>>700
それは普通に使うだろ

703 :

全角をつかって不具合が出たりはしないものなのでしょうか？

もう今は全角が普通なのかな。

いちいち日本語の単語から英語にするのに
頭使ってるのが馬鹿らしくなってきますね。

704 = :

>>703
最初に文字コードを決めてそれなりにテストを念入りにおこなえば
あとは特にトラブルはないな。
ただ記号文字、特に括弧とか～系の文字は必ず避けてる。

710 = :

時系列で株価の終値のデータを持っています
前営業日の終値と比較してその変化率を出したいと思っています

やり方、色いろあるとおもうのですが、どうやるのがスマートですかね？

711 = :

正確にいうと、変化率を出して、それをテーブルに戻そうと思ってます

土日や、終値がない日が存在したりすることを考えると、
どうやったら効率がいいのか。。。

716 = :

stored procedureで以下の文章が使えませんでした。

SELECT aaa INTO bbb FROM ccc;

cccがユーザ変数だったのですが、ストアドプロシージャでは
テーブル名にユーザ変数が使えないんですか？

717 = :

初心者なんですが、例えば
idが3の列のデータを全部削除した場合、id 4をid 3につめるという方法はあるのでしょうか？

718 = :

>>717
本名の他に、芸名を付ければいいんじゃないの？

719 = :

deleteしたあとupdateでもしてろよ

720 = :

>>719
まじでそれでいけるの？

721 = :

>>720
ALTER TABLE table AUTO_INCREMENT=3;

722 = :

>>721は釣りで良いんだよな…

723 = :

はぁ？

724 = :

>>720
馬鹿ならしね

725 = :

4以上をすべて -1 すればいいだけじゃね。
ちょっと考えれば思いつくと思んだが。
プログラムってアイデア勝負だな。

726 = :

MySQLはそこでorder byとかやらないとキー重複でエラーになるんだっけ？

727 = :

>>726
ならぬ

728 = :

プライマリキーをオートインクリメントで設定すると
どんどん増えていくじゃないですか。
だからidをつめた方がいいのかなと思ったんであります。

でも調べたら1日100万レコードの追加してもエラーがでるまで
12年くらいかかるっぽいんですね。だから気にすることはない。

この認識であってますか？

729 = :

>>725 馬鹿？
AUTO_INCREMENT付ければ勝手に連番付与してくれる

730 = :

>>728
RDBなんだから普通はIDが他のtableから参照されたりするだろ。
だから特定のtableのIDを詰めるようなことは行わない。
そもそもレコードを削除してしまうと情報が消えてしまうので
削除フラグを立ててレコードは残しておくことが多い。

731 = :

>>728
レコード削除でオートインクリメントカラムの数字を詰めたい・再利用したい　ってのは
独学初心者の典型的な発想。
詰める必要はないし、データ管理という観点でも「詰めちゃいかん」のだよ

732 = :

>>730-731
なるほど
まあDBは初心者なわけですがｗ

ではチャットみたいなやりとりもDBでは消さないで保存するシステムになってるのですかね？

733 = :

チャットをDBに保存する意味があるかどうかは別として、基本的には削除する必要はないだろ
何かあったときのための証拠として残しておけ！

734 = :

>>733
＞チャットをDBに保存する意味があるかどうかは

まさにこの部分なんですよ
何かしら一時的には保存してるわけでそれがDBに保存する場合、古いのは消していかないと
容量がどんどん増えていくんじゃないのかということで上記の質問をしたわけです。

735 = :

>>729
おまえが元コメ読んでない馬鹿だろ

736 = :

>>734
そういうのを必要に応じて消すというのはよくあるが
IDを振り直すというのはありえない
というのが結論

737 = :

>>728
どうしても空き番を再利用したいなら
オライリーのMySQL Cookbookのvol2に載ってるから
買って読むといいよ。

738 = :

>>735
>プログラムってアイデア勝負だな

馬鹿丸出しの文章恥ずかしくないの？

739 = :

>>738
一日遅れで随分離れたレスにツッコむお前が馬鹿丸出しだぞ。

740 = :

>>739
何て回答するか一日悩んだのだから仕方あるまい

741 = :

twitterじゃあるまいし昨日だろうが去年だろうがいいだろボケどもが

742 = :

そんなに長く考えてたらこのスレ終了しちゃうよ

745 = :

>>743
いちいち人に聞かずに少しは自分で調べろ

746 = :

>>745
ここで調べてるんだよ。何か悪いか？

って、本気で言われたことがある。

747 = :

自分で調べろと言って何か悪いか？

って、本気で言われたことがある。

748 = :

同じ値を集計して多い順に並べる、よくある感じのsqlだけど、
using tempとfilesortがどうしても掛かる。
致命的に遅いわけじゃなく許容できそうな遅さだけど、
これはどうしようもない？

example)
select hoge,count(hoge) as cnt
from tbl
group by hoge
order by cnt desc
limit 10

749 = :

バカを育てる事に意味があると思っている奴がいるんだ
そんなバカ担当にお任せしようじゃないの

750 = :

>>748
質問の意味が理解できません

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / 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 総合 Part18 (986) - [94%] - 2011/1/17 15:46
• 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 ○