サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
先日の勉強会で話題になったので少しだけ。 カーソル処理はパフォーマンス問題の原因になります、という主張についてです。 私は勉強会などでカーソル処理は辞めた方が良い、と言います。 その理由は処理遅延が起きるからです。 その主張の根拠としているのは以下です。 ・SQLは結果セットでの処理に適した処理系であり、手続き型言語の処理に合わせたカーソル処理はRDBMSで処理するには無駄が多い（RDBMS内では1行1行処理するので、都度アプリとの通信が発生し、ターンアラウンドの時間が無駄になる） ・SQL Serverではカーソルの中間データは場合によってTEMPDBに保存され、都度呼び出される。つまりDISK IOが発生する要因となる カーソルは数百行程度の処理であればそれほどパフォーマンス問題は起きにくいと思いますが 数万行、数億行を1行1行丁寧に処理すると、1行の処理そのものは遅くなくても、処理全
仕事やらなんやらでMySQLのクエリの良し悪しを判断する必要があるとき、EXPLAINの内容だけだとどのぐらい良くなったり悪くなったのか分からないので SET long_query_time = 0; してrows_examined (そのクエリでrows_sent行の結果を返すために何行に触ったのか)も一緒に提示するようにしている(少なくともMySQL 5.7時点ではrows_examinedはslow_query_logでしか確認できないはずperformance_schemaが有効ならevents_statements_historyやその仲間たちで確認できるとのこと*1MySQL ::MySQL 5.6 リファレンスマニュアル :: 22.9.6 パフォーマンススキーマステートメントイベントテーブル)。 例: 上の例のBeforeは、もともとDBAが書いた温かみのあるSQLでO
PostgreSQLとMySQL、使うならどっち？ データベース専門家が8つの視点で徹底比較！ オープンソースのデータベースとしてよく比較されるPostgreSQLとMySQL。どんな長所・短所があるのでしょう？ それぞれの専門家による対談で明らかにします。エンジニアとして働いていると必ず直面する悩み。それは、「どのリレーショナル・データベース（以下、RDB）を選ぶのが最善なのか？」です。RDBごとに長所と短所は異なっています。そのため自社サービスにマッチしないRDBを選んでしまうと、それがボトルネックとなり開発・運用にトラブルが生じるケースは少なくありません。 なかでもよく比較検討されるのが、PostgreSQLとMySQL。ともにオープンソースRDBのデファクトスタンダードであり、高い性能と数多くの機能を持っています。 では、両者は具体的にどのような長所・短所があるのでしょうか。そ
0. 背景 職場その他でいくつかのRailsプロジェクトを見て来て、同じ組織であってもリポジトリが違えば雰囲気が全然違うなと思い、その中でもこれはダメだろうと思ったことがありましたので、自分の備忘録も兼ねて記述します。 ここ２年ぐらいで出会ったRailsプロジェクトを見て感じた例ですので、他にも挙げようと思えば挙げられると思いますが、出会った中での記述ということでご理解ください。 また、技術的、より個別的な事象についてはRails AntiPatternsを読むといいかもしれません。 1.rubocopを導入していないrubocopはRuby StyleGuideをベースにしたrubyの静的解析ツールです。Rubyを使ったことのある人で知らない人はいないでしょう。また、Ruby StyleGuideについても、Rubyを勉強する初期に一読しておかなければいけないと言われる代物です。
ユーザごとに特定の機能に対して ON/OFF の設定値を持たせることはよくあると思います。RDB にそのような設定情報を持たせる場合の選択肢として大きく次の 5 つが考えるんじゃないかと思います。 設定項目ごとにカラムを割り当てる 設定項目ごとにレコードを割り当てる（追記：アンチパターンという意見があるので最後に補足を書きました） 設定項目ごとにテーブルを割り当てる（自分は思い付かなかった） 設定項目ごとに 1 つの整数型カラムの 1 bit を割り当てる 1 つのカラムに JSON 等で全ての設定情報を持たせる データベース理論的には 1, 2, 3 以外の選択肢はない気がしますが、実用上は 4, 5 も良い選択となることがあるので、メリット・デメリットを考えて選択する必要があると思います。 そんなわけで、それぞれの選択肢に関してメリット・デメリットを自分なりに考えてみました。 考慮す
オススメの結論から言うと 保存しない に一票かと思います。 理由 1レコードのデータ量が多くなり、クエリに時間がかかる 画像ファイルは通常のカラムよりデータ量が多いため、SELECT、UPDATE、INSERT共に処理時間が多くかかります。MySQLは最終的にテーブル単位の実ファイルにデータを格納します。 もし毎回画像データもSELECTした場合、大きなテーブル（ファイル）の中から該当レコードを読み込みます。 画像をUPDATEする場合、INSERTする場合も、通常のカラムではせいぜいvarchar(255)などに比べ、例えば4kb(4096byte)など、小さい画像でも、DBにとっては大きなデータになります。 故に 処理時間 は考慮した方が良いかな、と思います。DBのストレージ容量を圧迫する 画像を含むレコード数がどれくらいかわからないのですが、商品であったとして、継続的にデータが増
TokyoR 62 （2017年6月24日）で発表したときのスライドです。整然データ (tidy data) というデータ分析に役立つ概念を紹介し、Rでそれを扱うための手法を簡単に紹介しています。Rの初心者向けです。
JJUGCCC 2017 Springで、「データ履歴管理のためのテンポラルデータモデルとReladomoの紹介」という話をしてきました。 データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3 from HiroshiIto 今回の登壇は、株式会社FOLIOのスポンサーセッションです！FOLIOについてはこちらの入社エントリー記事もご参考ください。Toggetterは下のリンクから。togetter.com 世の中のみなさんが「論理削除フラグ」を使いたくなるモチベーションとしては、実は「削除」ではなく別のビジネスロジックを実装したいだけであることがほとんどだと思います。 たとえば論理削除フラグという名の死亡フラグ - @ledsunblogというエントリを参考にさせていただくと、下記のような要件の例があります。 ・社員が退職（・転
1リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
