例えば、ordersテーブルに、productsテーブルの内容を追加する非正規化は流石にやりすぎだけど、商品名だけとか一部の必要なカラムだけを追加して、ordersにproductsをJOINしなくても注文一覧画面に必要なデータが揃うって感じかなぁ?
更に1個のテーブルになったから商品名もカバリングインデックスに含められるみたいな事が、インデックス狙いのクエリって事だろうか?
例えば、ordersテーブルに、productsテーブルの内容を追加する非正規化は流石にやりすぎだけど、商品名だけとか一部の必要なカラムだけを追加して、ordersにproductsをJOINしなくても注文一覧画面に必要なデータが揃うって感じかなぁ?
更に1個のテーブルになったから商品名もカバリングインデックスに含められるみたいな事が、インデックス狙いのクエリって事だろうか?
S3 Glacierにデータ移行したら大きな教訓を得た話|NAVITIME_Tech
S3 StandardからS3 Glacier Deep Archiveに、データを転送すると結構なコストが掛かるのか。AWS内の通信だしもうちょっと何とかならんのかな・・・
このアカウントは、notestockで公開設定になっていません。
Twitter、もしかしたらその内テキストのコピー防止とかしてくるんじゃないかとふと思った。絶対にやめて欲しいけど、やり兼ねないかもしれないと思ってしまう。
https://twitter.com/nakayoshix/status/1452823167865552896
https://twitter.com/nakayoshix/status/1452823167865552896/retweets/with_comments
この辺で語られてるRelational KVSと形容され、正規化を崩してJOINを減らしてると思われる、インデックス狙いのクエリありきのテーブルって、どんなのだろう?
正規化を崩してJOINを減らすとなるとサマリーテーブルを思い浮かべるけど、その結論で良いのかは自信が無い
常態化してきてしまってるけど、今年に入って、2度寝がなかなかできなくなってもう半年以上か。なかなか改善しないなぁ。改善のために何かしてるというわけでもないけど。というか、何をしたら改善するのかも分からないけど
このアカウントは、notestockで公開設定になっていません。