元スレMySQL 総合 Part20
mysql覧 / PC版 / みんなの評価 :
前へ
852 = :
OSのmysqlユーザが/home/hogehogeにアクセスできないんじゃないの
恒久対処にすると危ないのでいかんけど
$ chmod -R 777 /home/hogehoge
してみるとか
853 = :
>>852
返信ありがとうございます
hogehoge自体は755で、
その下に、mydataディレクトリが保存されてる状態です。
mydataディレクトリは、所有者はmysqlで、パーミッション700
権限的には問題ないと思うのですが・・・
854 = :
MySQLって1秒間に100回更新されるような状況でも大丈夫なんでしょうか？
SQLiteとかでは不可能なのですが
855 = :
1000回だろうが1万回だろうがハードウェアの処理能力が追いつけば問題ないだろ
856 = :
処理中に他の処理が働いても大丈夫とかそういうことか？
857 = :
>>854
最短の更新間隔を設定できなかったっけ？
858 = :
すみません！
自己解決できました
ありがとうございました
859 = :
どうやって解決したのか書いたら？
860 = :
いるよな、質問とか相談しに来たのに相手に一言もしゃべらせないで、
一歩的にマシンガントークして、そのうち満足して帰って行くやつ。
862 = :
>>860
問題解決にはうってつけの方法なんだよな。
相手に質問するために状況を把握しまとめる過程で
原因を見つけることは多い。
本来はまずテディベアに語りかけるべきなんだけど
その点2chは淫乱テディベアなのでうってつけだ。
863 = :
AppArmorが原因だったのか。
参考になったけど参考にならんな
864 = :
>>862
何故そこでテディベア？
日本人なら別の物だと思うが？
865 = :
>>864
確かに。日本人ならグルーミーか赤カブトだね。
866 = :
CREATE TABLEのときの「KEY `hoge` (`hoge`)」とは何でしょうか？
PRIMARY KEY (`id`)
UNIQUE KEY `username` (`username`)
などはわかりますが「KEY」の意味がわかりません
867 = :
>>866
パーティショニングじゃなくて？
「KEY `hoge` (`hoge`)」だけでなく create table 文の全文を書き出してみなよ
868 = :
>>867
調べていたら「パーティショニング」という単語も出てきましたが
何か違うような気がします。以下CREATE TABLE文です
CREATE TABLE `tbl_users` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`username` varchar(20) NOT NULL,
`password` varchar(128) NOT NULL,
`email` varchar(128) NOT NULL,
`activkey` varchar(128) NOT NULL DEFAULT '',
`createtime` int(10) NOT NULL DEFAULT '0',
`lastvisit` int(10) NOT NULL DEFAULT '0',
`superuser` int(1) NOT NULL DEFAULT '0',
`status` int(1) NOT NULL DEFAULT '0',
PRIMARY KEY (`id`),
UNIQUE KEY `username` (`username`),
UNIQUE KEY `email` (`email`),
KEY `status` (`status`),
KEY `superuser` (`superuser`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=3 ;
869 = :
>>868
あぁ、そりゃただのINDEXだね。マヌアルにも書いてあるよ。
http://dev.mysql.com/doc/refman/5.1/ja/create-table.html
「KEY は通常 INDEX の同義語です。」
871 = :
そのとおり。
872 = :
助かりました。ありがとうございました！
873 = :
お安い御用です。
874 = :
すごい素人な質問をさせてください。
文字列を格納するのに、charとかvarcharがありますが、
個人的には文字列は全部text型でいいのではないかと思うんですが、
間違いでしょうか？
こういう場合はcharを使うとか、この場合はvarcharを使うべきとかいったような使いどころについて教えていただけますでしょうか。
875 = :
>>874
間違いではないよ。
サイズ指定するとその幅をあらかじめ確保したり
それ以上格納できなくなったりするから、計算しやすく
DBサイズ固定化したり動作を早くしたりできるだけ。
876 = :
>>875
ありがとうございます、とても参考になりました。
878 = :
ある種のフラグのような固定されたサイズのカラムにtext使うのは如何かと。
879 = :
10年以上前ならともかく、今のシステムで固定長って意味あるのかねぇ
880 = :
一応、あるんじゃね？
絶対固定長とわかっていて、わざわざ可変長を使うメリットはないだろ。
881 = :
顧客コードとか商品コードとか固定長のほうがプログラム側が楽になると思うけど
882 = :
>>881
DBがハックされたりバグったときのことを考えてプログラム側に自衛の対策をしとくのは基本中の基本。
データを固定長と決め付けてプログラム側が楽になるなんて考えるのは素人の発想。
883 = :
本当のプロは冗長な設計はしない
884 = :
>>882
＞DBがハックされたりバグったときのことを考えてプログラム側に自衛の対策をしとくのは基本中の基本。
可変長だとどういう風に有効な対策になるの？
885 = :
最大長の変更がありそうな物以外だと無駄な事の方が多い気がするんだけど
886 = :
そりや可変長のが無駄なんだけど、
固定長でも頭をスペースとか０で埋めるのは変わらないし、
ヌルチェックは昨今の言語ならライブラリ用意されてるし
再利用性を鑑みて冗長な設計、作成が昨今のトレンド
固定長はCOBOL向け？
887 = :
＞再利用性を鑑みて冗長な設計、作成が昨今のトレンド
こんなの幻想に過ぎないだろ
888 = :
>>883
セキュリティ対策を軽視するのはプロとは言えない
889 = :
セキュリティ対策と冗長な設計の関係を詳しく
890 = :
セキュリティ対策は冗長な設計とは言わないだろう
むしろ必然
891 = :
セキュリティは対策しても無駄・・・最後は人間のモラルに行き着く。
人間の教育や待遇にお金を使うのがもっとも効果的である。
と死んだじ～ちゃんが言ってた。
892 = :
それは内部の人のうっかりミスや裏切りによる情報漏えいとかの話であって
外部からの攻撃には教育は関係ないんじゃなかろうか。
893 = :
東京電力みたいなやつだな
894 = :
東京電力を馬鹿にする奴は泣かす
895 = :
>>891
教育の改善で治安が保てるなら警察は不要。
人民は教育しても無駄だから社会秩序は実力行使で維持すべきである。
と死んだじ～ちゃんが言ってた。
896 = :
教育のない警察官が多くいたら治安は思いっきり悪くなる。
警察官には教育と高給が必要である。
と死んだじ～ちゃんが言ってた。
897 = :
規則を遵守しない警察官には見せしめに厳罰を与えれば抑止効果となる。
一般大衆に対しても同様であるから公開処刑を導入すべきである。
と死んだじ～ちゃんが言ってた。
898 = :
とりあえず、全部varcharでおｋ
とは、死んだばーちゃんは言ってなかったな。
899 = :
ばーちゃんは嘘つきだから信用するな。
嘘つきは泥棒の始まりといいますから。
900 = :
おまえらったらどうでもいい部分に突っかかるよなwwww
みんなの評価 :
mysql一覧へ類似してるかもしれないスレッド
- MySQL 総合 Part22 (1001) - [94%] - 2012/7/10 16:45
- MySQL 総合 Part21 (1001) - [94%] - 2011/12/25 22:16
- MySQL 総合 Part25 (947) - [94%] - 2017/6/18 6:30
- MySQL 総合 Part24 (1010) - [94%] - 2015/2/14 4:46
- MySQL 総合 Part23 (992) - [94%] - 2013/8/11 17:00
- MySQL 総合 Part26 (860) - [94%] - 2023/2/2 9:30
- MySQL 総合 Part13 (996) - [89%] - 2008/6/10 21:02 ☆
- MySQL 総合 Part14 (1001) - [89%] - 2008/11/23 10:17 ☆
- MySQL 総合 Part15 (1001) - [89%] - 2009/4/20 12:15 ☆
- MySQL 総合 Part17 (1001) - [89%] - 2010/6/10 20:47 ○
- MySQL 総合 Part18 (986) - [89%] - 2011/1/17 15:46
- MySQL 総合 Part19 (982) - [89%] - 2011/6/9 2:33
- MySQL 総合 Part12 (1001) - [89%] - 2008/1/30 17:34 ○
- MySQL vs PostgreSQL Part2 (941) - [36%] - 2022/5/26 1:30 ○
トップメニューへ / →のくす牧場書庫について