top
recent
MySQL
関連ページ
SQL
目次
- MySQLリファレンスマニュアル...
- TIMESTAMP型をDATETIME型に変換する...
- DATETIME型のカラムに現在時刻を入れる...
- MySQLリファレンスマニュアル:文字列比較関数:MATCH AGAINST...
- TIMESTAMP型に日付を入れる...
- MySQLは複雑なQueryを出来ぬと言うが...
- MySQLはTransactionを出来ぬと言うが ...
- 日本MySQLユーザ会...
- ストレージ・エンジンとしての MySQL の性能評価...
- TKS さんがなんぞかやってはりますな．...
- MySQLのTips...
- なければINSERT、あればUPDATE...
MySQLリファレンスマニュアル
http://www.mysql.gr.jp/jpdoc/
http://www.mysql.gr.jp/jpdoc/3.23/manual.ja_toc.html
signature: URL
[[id:74]] 2002-02-04 02:09:38
TIMESTAMP型をDATETIME型に変換する
ALTER TABLE t1 CHANGE c1 c1 DATETIME;
signature: Ｃａｋｅ
[[id:76]] 2002-02-03 22:10:44
DATETIME型のカラムに現在時刻を入れる
CREATE TABLE t1 ( c1 DATETIME );
INSERT INTO t1 VALUES( NOW() );
signature: Ｃａｋｅ
[[id:77]] 2002-02-03 22:10:54
MySQLリファレンスマニュアル:文字列比較関数:MATCH AGAINST
http://www.mysql.gr.jp/jpdoc/3.23/manual.ja_Reference.html#IDX690
MATCH (col1,col2,...) AGAINST (expr)
FULLTEXT インデックスが必要
‥‥‥。
やってみたけど、日本語は全くマッチしない。(T^T)
英単語はこのサイトのデータ規模だと全くの一瞬で
面白いようにあたるけど。
ドキュメントを見ると、multibyte textはこれからの
対応目標となってたし。
つーか
| WHERE contents LIKE '%文字列%'
で全く問題ない速度でしたよ。 (-_-;
signature: URL
[[id:162]] 2002-02-06 00:46:23
TIMESTAMP型に日付を入れる
insert into t1 values ( 20020205235012 );
これだけでいいらしい‥‥‥。(-_-;
signature: Ｃａｋｅ
[[id:214]] 2002-02-06 00:04:23
MySQLは複雑なQueryを出来ぬと言うが
果たしてそれは必要なんだろうか？
昔(?)の2層システムでは、不特定(?)多数のクライアントが同時にDB鯖にアクセスする
ので、その排他(?)処理とかをDB鯖が管理する必要があったが、
今(?)の3層システムでは、アクセスは必ず中間のロジック層を経由するんで、
排他も制御し放題である。
つまり、DB鯖の中にストアドプロシジャが有るか、
ロジック鯖の言語(ご存知の通りjavaとかphpとかrubyとか…)でプロシジャ相当のものを書けば良いか、の
違いに過ぎないはずである。クライアントから見れば。
違いはせいぜい、DB鯖プロセス(メモリ)内で動くかどうかという
パフォーマンスとかの差だけではなかろうか？
どうしても心配なら、たしかjavaで出来たものが実在するが、
ロジック鯖と同じVM(笑)上でDB鯖機能も動くようになれば良いのだ。
逆にいえば2層システムは、複数クライアントの面倒見だの、
ロジックだの、に踏み込んだ部分までDB鯖にやらせようという、
ちょっとリファクタリングしたくなる(笑)ようなシステム構成だ、
ということだと思う。
signature: 戯
[[id:249]] 2002-02-07 14:19:11
MySQLはTransactionを出来ぬと言うが
果たしてそれは必要なんだろうか？(ぉ
更新整合性の保証のため、と一言で乱暴(!)に片づけられるが、
細かくいえばそれは、データの書き込みの意味論的つじつまの保証と、
物理的などの障害によって生じるつじつま破壊からのリカバリ、
(うまく言えないなあ。判ってくれる？)という2種類のことを
意味していると思われる。
で、後者は、極論すればDB鯖が動いてるfilesystemが
Transaction(ジャーナリング)をサポートしていれば、
それで代用できるはずだ(まぁちょっと無理矢理な意見だが(ぉ
また前者は、書き込み手順の問題なのだから、MySQLは複雑なQueryを出来ぬと言うが
(#6) で書いたように、
ロジック鯖に保証させることにすれば済むとも言える。
色んな奴がテンデばらばらにデータを書き込むからそれの矛盾を蹴る、
という仕事をDB鯖自体にやらせるってのは、どうよ？ということ。
結局MySQLは、「どうしても必要」とは＊言えない＊機能を切り離した、
というだけのことのような気がする。
言い換えれば、頑張れば(笑)、それらの仕掛は「外付け」できるのではなかろうか？
signature: 戯
[[id:250]] 2002-02-07 14:25:23
日本MySQLユーザ会
http://www.mysql.gr.jp/
日本MySQLユーザ会（略称: MyNA = MySQL Nippon Association）
signature: URL
[[id:300]] 2002-02-11 00:49:38
ストレージ・エンジンとしての MySQL の性能評価
http://www.vce-lab.net/mysql-storage/
signature: URL
[[id:321]] 2002-02-13 09:53:08
TKS さんがなんぞかやってはりますな．
http://www.dive-in.to/~tks/diary/?20020201#01-3
signature: URL
[[id:323]] 2002-02-13 10:53:24
MySQLのTips
http://www.anesth.or.jp/gijutu/db/howto-db.php3
思わず移植したくなってしまうのはわたしだけではあるまい。
----
MySQLを何か（MSXとか？）に移植するのかと思った。（誤読）
signature: URL
[[id:359]] 2002-02-16 22:41:01
なければINSERT、あればUPDATE
MySQL独自の構文で
REPLACE INTO テーブル VALUES (....);
というのがあります。＞「このParagraphを参照してるParagraph」を一覧する機能、きぼん
(HashedWikiへの要望:DONE)
-それが有れば、ユーザーが自在に組めるTransactionが無くても、とりあえずTitleのような処理におけるAtomic性は確保できますね。
[[id:1179]] 2002-09-12 19:10:09
top
recent
HashedWiki version 3 beta
SHIMADA Keiki