Code Tester 1.9でコードカバレッジ分析をしよう (原文： Testing Object Types with Code Tester 1.9)
著者：QCTOblog , 投稿日： 2010年3月28日
テストが無事成功してステータスが青信号になることはとても重要です。それに加えてテストケースがあなたのプログラムのどの程度をカバーしているかを理解することも重要です。もしあなたのテストケースがすべて成功だとしてもプログラム中のわずか10%しかカバーしていなければ、そのテストは適切ではないと言えるでしょう。
続きはこちら
ハードコードよさようなら！ (原文： Say goodbye to hard-coding!)
著者：Steven Feuerstein, 投稿日： 2010年3月15日
ソフトウェアのコードがハードコードされるのは良くないということは皆さん良くご存じだと思います。しかしほとんどの開発者はハードコードと言えば、リテラル値を記述することくらいだと考えがちです。
続きはこちら
ヒントはSQL変換にどう影響するか (原文： How Quest SQL Optimizer works with Hints)
著者：Richard To, 投稿日： 2010年2月28日
最適化ヒントは、データベースSQLオプティマイザに、ユーザーが期待する特定の方法を選択するよう誘導してあげるために使用します。しかし必ずしもユーザーが指定したヒント通りにデータベースSQLオプティマイザが動くとは限りません。その場合単純にヒント文は無視されてしまいます。
続きはこちら
Questの再帰的SQL変換技術 (原文： Quest Recursive SQL Transformation Technology)
著者：Richard To, 投稿日： 2010年2月13日
Questの再帰的SQL 変換テクノロジーは、人間のSQL変換技術をシミュレートさせる革新的なAI技術を使用しています。変換ルールの集合体をSQL文のセクション単位に変換していきます。これにより人間が従来SQL文の書き換えで行ってきたトライアンドエラーの手法を代替します。
続きはこちら
最適化ヒントとは？(原文："From SQL Optimization Hints to Plan Instructions"）
著者：Richard To, 投稿日：2010年2月1日
ほとんどのデータベースベンダーは、データベースSQLオプティマイザに意図した実行計画を選択するように影響を与える、最適化ヒントを提供しています。OracleはSQL文のパフォーマンスチューニングを行うユーザーに対して、非常にオープンな最適化ヒントを提供しています。 このアプローチは、データベースのSQLオプティマイザがすべてのSQL文のパフォーマンスを保障できないことを認めていることになります。
続きはこちら
SQL最適化は解決できない問題か？（原文："Is SQL Optimization an Unsolvable Problem?"）
著者：Richard To, 投稿日：2010年1月24日
計算可能性理論では、「停止性問題」と呼ばれる、有名な決定問題があります。それは以下のように定義されているものです。
「チューリングマシンと入力が与えられたとき、その入力を与えられたプログラム（チューリングマシン）は停止（完了）するかどうかを求めよ。停止しない場合、永遠に動作し続ける。」
続きはこちら
ダミーの変換ルール（原文："Dummy SQL Transformation Rules?"）
著者：Richard To, 投稿日：2010年1月8日
様々なSQL変換ルールが、それぞれのデータベースSQLオプティマイザの振る舞いに対応するように、Quest SQL Optimizer に実装されています。これらの変換の裏側にある理論を理解するためは、データベース最適化理論とそれぞれのデータベースベンダーがSQL最適化のために実装している設計アプローチをより深く理解する必要があります。
続きはこちら
インデックス使用に関する変換ルール（原文："Transformation Rules Relating to Index Usage"）
著者：Richard To, 投稿日：2009年12月24日
インデックスを使用した変換ルールとは、特定のSQL文に対してデータベースのSQLオプティマイザがインデックスを使わせるようにするものです。変換には、インデックスを有効、無効にしたり、別のインデックスを使わせたりするものがあります。
続きはこちら
多数のテーブル結合をコントロールする方法 (原文："How to control many table join")
著者：Richard To, 投稿日：2009年12月11日
前回のブログでは、2つのテーブルを使った結合パスを制御する方法を紹介しました。今回は3つのテーブルを使ってさらに複雑なシナリオを考えてみましょう。A.key, B.key、 C.key はすべてインデックスが貼られていると仮定します。
続きはこちら
なぜ結合パスが重要なのか？(原文："Why Join Path Matters")
著者：Richard To 投稿日：2009年11月30日
ネステッドループ結合はほとんどのRDBMSでサポートされている基本的な結合処理です。この処理はメモリ消費も少なく、一時領域も少なくて済むのが特徴です。通常は、その他の結合処理よりも早い応答時間でデータを取得できます。しかしながらネステッドループ結合のパス（順序）が 結合処理のスピードに大きく影響することでもよく知られています。以下の例題でどのように動作するか見てみましょう。
続きはこちら
結合パスをコントロールする方法 (原文："How to Control Two Tables Join Path?")
著者：Richard To 投稿日：2009年12月6日
昔のバージョンのOracleでは、結合パスをコントロールすることは簡単でした。FROMに続くテーブルリストの順番を変えるだけで良かったのです。しかし今日のコストベースオプティマイザでは結合パスをコントロールすることは次第に難しくなってきています。これは他のデータベースでも同じことがいえます。今回は様々なデータベースで使える便利な方法をご紹介します。
続きはこちら