スレッドメモ

MLやNewsのスレッドをメモする試み。

2003|01|02|04|05|06|07|08|10|11|
2004|01|04|05|06|07|08|09|11|12|
2005|01|02|04|08|09|
2006|01|03|04|08|
2007|01|05|
2009|05|

2004-06-07 (月)

[pgsql-jp] PostgreSQL カンファレンスお礼および MySQL のデータが壊れる件

[33107] Ryuichiro Munechika (6/7)

さて、石井さんのお話の中にもあった「MySQLのデータがよく壊れる」 件について、以前もどこかで話を聞いたかもしれないのですが、本件に 関して出展をご存知無いでしょうか?

http://jp.xoops.org/modules/newbb/viewtopic.php?topic_id=3565&forum=11 あたりで問題になっていたようなことかと記憶しているのですが。

[33109] Tatsuo Ishii (6/7)

日経システム構築の2004年4月号の150ページあたりにある

  1. XOOPSでシステムを構築したが,DBMSがMySQLだったためかデータが壊れた.担当者曰く「MySQLのデータは壊れやすいということを改めて思い知らされた」(p150)

というのを見ました.

まあ,MySQLにデータの信頼性を期待してはいけません:-)

[33111] SUGIMURA Takashi 杉村 貴士 (6/7)

某携帯電話のメールシステムにて MySQL の InnoDB で 超大規模な分散 DB を構築したことがあるんですが、 単純に壊れやすいということはないように思います。

PostgreSQL や Oracle でも壊れるような運用をすれば壊れますし、 DB の種類だけで論じるのは危険だと思います。

[33112] Hidekazu Ikeda (6/7)

 うーん、「だったためか」と言うのが「FACT:事実」と言う には弱いような。。

 むか〜しの Access MDB とかだと、あるパターンで再現して たので、壊れやすいと言えたのですが、この情報だけでは良く 判らないですよね。

 Mysql-jp も読んでますが、「壊れやすい」と言う感覚には 私はならないのですが。。。

 英文でも良いので、「壊れやすい」「信頼性が期待できない」 の情報源が欲しいですね。

[33114] EBIHARA Yuichiro (6/7)

スペック的にはむしろMySQL(InnoDB)のほうが信頼性が高いと評価できそうなもん ですけどね。 メディアリカバリの分だけ。

エンタープライズ用途を考えるときには、PostgreSQLとMySQLの比較はInnoDBを前 提に語るべきだと思います。MyISAMはシステム要件によっては一考の価値ありの 便利なオプション、くらいの位置づけで。

僕自身もほんの数ヶ月前までMySQLなんて相手にならない、と思っていたものの、 実際に詳細を調べてみたら古い情報で大きな誤解をしていたことに気づき、今は 考えを改めています。

[33128] Tatsuo Ishii (6/7)

以下感覚論.

私がMySQLの信頼性に不信感を持っている一番の理由は,MySQLの開発者らが, 「トランザクションなんか要らない」とか「ロックの管理はユーザが自分でや る」とかDBMSの根幹を否定することを言っていたからなんです.つまり,彼ら にとって,DBMSが自律的にデータを守る,という考えがそもそもないのではな いんではないか,ということです.そうすると,最近になって急にトランザク ションとかACIDとか言い出したのはなぜかというのが謎なんですけどね:-)

他にもいい加減な根拠でPostgreSQLバッシングを盛大にやっていたとか, MySQLというよりは,MySQL ABには私は良い印象を持っていません.

[33134] TANIDA Yutaka (6/7)

> でもMySQLやOracleでも、ディスクが許す限りの大きなロールバックセグメントを
> とっておけば、あまり大きな違いはないような気もします。

そうですね。しかし、前もって大量の領域を用意しなければならないのであれば、 PostgreSQLのVACUUMが必要なアーキテクチャと似たり寄ったりじゃないでしょう か。

#それをまた「うちのはVACUUMがいらないからすごい」と欠点を隠して言う人が
#いるから話がややこしくなる。

[33145] Hidekazu Ikeda (6/7)

 以下のどちらが多いか? ですねぇ。

 実際の業務システムにおいて、DBMS の要求として
 1. 大容量の更新(commit せずにです)で、並列での更新
 2. 少容量(更新量が少ない)で、多数の並列での更新

のどちらが多いのかなぁ?って事じゃないでしょうかね。

Oracle は、2の方が業務システムでは多いと考えているから、 あのような実装だと考えてますが。。 個人的には、1項なら、単純にファイルのほうが良いようにも 思うのですが、、DBMS に向いてないシステムのような。


2004-06-13 (日)

[fj][fj.net.www.authoring] HTML での 空白の扱いについて

<20040613181552.0ea6beec.forest@ma.kcom.ne.jp> K.Moriyama (6/13)

前々から気になっていたのですが、HTML での空白の不自然な扱いは 如何なる理由によるものなのでしょうか?

 文の冒頭での半角スペースは無視される
 文章中では2個目以降の半角スペースは無視

幸い全角スペースについては、上記制約が無いようで正常に表示される のですが、この半角スペースの挙動は不可解です。

一応対策としては、

 A, &nbsp;を使用する
 B, <p> で囲って、indent をスタイルシートで指定する
 C, 見えない画像を張り付ける
 D, 全角スペースを使用する
 E, 最初から最後まで、pre で 括ってしまう。

が、有るようですが、[ A , B , C ] は面倒ですし [ D ]は、英米人が 使用しているとは思えません。結局 HTML としては、掟破りなので しょうが[ E ]当たりが妥協点でしょうか?

<3989852news.pl@insigna.ie.u-ryukyu.ac.jp> Shinji KONO (6/14)

一番頭に来るのは、改行が一文字空白に変換されるってあれですね。

> 書きだしに空白の無い不自然な文章のオンパレードです。

僕は開けないです。不自然だとも思わない。っていうか、コンピュ ータ関係だと、段落は一行開きの方が普通だと思う。
 こういう書き方は、かえって読みづらいですよね。段落が 変わった感じがないでしょ? 何故かと言うと、物理的な本と違って、 仮想的に無限の大きさを持つ画面表示では、段落分けに空間を取れ るからだと思います。

<cap9tn$4vo$1@news.sfc.keio.ac.jp> Masayasu Ishikawa (6/16)

おそらく日本語の文章中での改行の話だと思いますが、例えば

<p>



</p>

日本語

にならずに

日 本 語

のように表示されるならお使いのブラウザの空白処理がイケてないだけかと。

一般的に HTML/XHTML 中での空白文字の扱いをどうすべきかというのは HTML4 / XHTML 1.0 / Modularization of XHTML でそれぞれ微妙に食い違って たりしてなかなか頭の痛い点なんですが、将来的には表示に関しては現在 W3C 勧告候補になっている "CSS3 Text Module" の "7.2. White space control" の規定に従って処理すべし、ということに一本化されるはずです。

cf. http://www.w3.org/TR/2003/CR-css3-text-20030514/#white-space-props

<cb5jrk$hgm$1@caraway.media.kyoto-u.ac.jp> AIDA Shin (6/21)

> p {text-indent: 1em;}
>
> とか書いたファイルを用意しておいて、<head></head>の間で
>
> <link href="/basic.css" rel="stylesheet" type="text/css" title="basic">
>
> みたいな感じで引用すればOK、なのかな。

私も、サイトを構築するために CSS をいじっていた当初、 p要素にそのような指定をしていました。

しかし、p要素は箇条書きなどのブロック要素を中に入れることができません。 つまり、

のようにせざるを得ず、その結果、上記の CSS だと箇条書き直後に 余計なインデントが入ってしまいます。

<cb86ol$h1b$1@news.sfc.keio.ac.jp> Masayasu Ishikawa (6/22)

ちなみに

>でも div で解決するのは美しくないので、できれば
>section要素とか paragraph要素などがあってほしいんですけどね。

XHTML 2.0 では section 要素が導入されますし、p の中に箇条書きや引用文も 入れられます。


2003|01|02|04|05|06|07|08|10|11|
2004|01|04|05|06|07|08|09|11|12|
2005|01|02|04|08|09|
2006|01|03|04|08|
2007|01|05|
2009|05|