はじめに
HTMLよりも優れたフロントエンドを望むためリッチクライアントが求められる
内容が古いため今の実情と乖離しているところもある
その理由は、パフォーマンスに関するアドバイスは、現実のシステム構成でパフォーマンスの測定を行ってみるまでは、当てにならないからである
現在になるまでこの点は一切変わってねえなあ。だからカオスエンジニアリングなど生まれたんだろうが
第1章
編集途中で消えて萎えたのでなし
第2章
レコードセットが何を指すのかわからん。 単なるRDBMSの行の集合ではなさそう。 → P36
レコードセット、つまりデータベースのテーブルの性質を持つ、テーブルと行で構成された包括的なデータ構造
第3章
3.2、ユニットオブワークという名前でDBデータ(レコードデータ)の書き込みを含めたオンメモリ上でのキャッシングの話をしているけど、 今の横にスケールさせるアーキテクチャではキャッシング機構が1サーバで完結しないので微妙な気がするね。 現代ではもっとシンプルなキャッシュとトランザクション手法が取られるんじゃないかなあ。
3.3、joinを使って複数のテーブルのデータを一気に返す方法、それはできるけどさすがに悪手だろw DBへのクエリ回数が膨大なシステムだとそうやって最適化する方法はあるかもしれないね。最終手段だろうけど。
3.4.1のオブジェクト型とリレーショナルデータベース間の関係情報の保持の仕方についての説明は非常によくわかる。 しかしその後の一意マッピングやレイジーロードといったアプリケーションサーバ内での頑張りすぎるキャッシング手法はあんまりイケてない。というか現代でやったら顰蹙モノの複雑さだと思う。
LOBに関してDB自体がその内包データを理解できないという欠点は、現代ではJSON型としてOracle, Mariaなど各プロダクトが限定的ながら解決しつつある感じ。
3.4の継承とRDBの問題については継承をそもそも否定的だからこの手法もややこしくなっているのだと思う。 たしかに説明されている3パターンは現実に取りうる解だが、そもそもオブジェクト指向とリレーショナルデータベースをうまいことマッピングするのがORマッパーなり各種DBライブラリの役割なわけで、継承という非常にオブジェクト指向らしい特徴をリレーショナルデータベースに持ち込む事自体が相当な悪手じゃねえかなあ。 しかしそれを考えるとオブジェクト指向とRDBでインピーダンスが発生しているという指摘は重い。DBの接合部分に全体の1/3のコーディング労力が割かれているというのもあながち大げさではあるまい。
3.5.1、相変わらず技術書の英訳はガバガバ。
The extra step only pays for itself when you have many commonalities, so you should use it when you have similar but annoyingly different physical data stores.
追加のステップは、多くの共通性がある場合にだけ有効なので、類似性はあるが異なる物理的なデータを格納する場合は追加のステップを使用するべきである。
data storesのstoresを動詞として約してしまっている。実際には名詞。 以下が適当か
追加のステップは多くの共通性がある場合にだけ有効なので、類似性はあるが異なる物理的なデータストアを2つ以上使用する場合に追加のステップを使用するべきである。
3.7 データベースのコネクションプールは本質的に状態を持ってしまっている(使い回されるコネクションが前回の利用の影響を受けていないことが保証できない。また接続されて最初のクエリとその後のクエリで挙動やレスポンスタイムなどが変わることもある) = immutableでない ことからあんまりよくないかも。サーバレスフレームワークが前提のアーキテクチャではコネクションプールは期待できないし、各リクエストの独立性を高めるためにも毎回コネクションを張り直す方式が取れるならそのほうが良い。またこの本自体にもそう書かれていた(意外)。
新しい接続の生成速度が速くなっているなら、プールする必要はない。
This advice leads to a couple of issues: making sure you have the connection everywhere you need it and ensuring that you don't forget to close it at the end.
この方法では、２、３の問題が生じるので、必要であれば接続し、終了時には忘れずクローズするべきだ。
ひどい訳。以下が適当。
この方法には次の２つの問題がある: あなたがコネクションを使うところすべてでそれを持つ(実質的に作る = コネクションを張る？)必要があることと最後にそれを確かにクローズしないといけないことだ。
しかしこれだけ面倒くさいRDBとオブジェクト指向型言語の間のパターンを多数見せられると両者の間のインピーダンスの高さを実感する。 RDBを使うのって今は当然だけど本当にそうか？オブジェクト指向型言語でいいのでは？ まあでもそれMongoDBか。
