🔷 オブジェクトフィールド（45 minutes, 13:50-14:35） ❗ ポインター ❕ OB Getで取り出す ❕ JSON Stringifyで評価された値を受け取る ❕ 時間はGetできるがSETできない ❕ ピクチャはダメ ❗ 利⽤データ ❕ Nutella: クレープ屋でおなじみのチョコレートスプレッド ❕ ダウンロード/160MBはほど良いデータサイズ ❕ CSV: 実際にはタブ区切り（TSV）ファイル ❕ 159フィールド/⾮常に細かいが，すべて利⽤されているわけでもない ❕ インポート/フィーラムに質問を投げかけた場合のレスポンス ❗ カード型 ❕ フィールドはテキストまたは実数 ❗ リレーショナル型 ❕ フィールドはN対N（ブリッジテーブルを介したリレーション） ❕ ブリッジテーブルのフィールドにはインデックスを設定 ❗ オブジェクト型 ❕ 横にあるのはインポートの過程で使⽤した⼀時テーブル ❗ ファイルサイズ⽐較 ❕ サイズは正規化（重複データのないこと）に⽐例 ❕ カード型はインポートダイアログで⾃動作成したのでプライマリーキー（インデック ス）がない ⚠ QUERYとリレートテーブルの関係 ❕ 1テーブルの値でNテーブルのクエリができる（例題9） ❕ Nテーブルの値で1テーブルのクエリ（例題17/v11） ❕ それ以外のリレーション/QUERY BY FORMULA/JOINモード ❗ リレーショナル型 ❕ すでに正規化されているのでインデックスはリレーションの分だけで済む ❕ 汎⽤的なテーブル ❗ オブジェクト型 ❕ データの構造が似ていればインデックスは意外に軽量 ❕ プロパティの有無だけでクエリすることになるので圧倒的に速い ❗ カード型 ❕ 確かに速度⾯は優れているが，汎⽤的にするためには⼤量のインデックスが必要 ❗ キャッシュに注⽬ http://www.4d.com/jp/blog/database-measures.html ❕ カード型は多くのキャッシュを必要とする（ハイメンテナンス） ❗ フィールドの数 ❕ 結論: 似たようなフィールドを識別する ❗ フィールド内の構造 ❕ 電話番号で検索: 実際にマッチしているのはFAX番号 ❕ 複合クエリ: タイプと番号はそれぞれ違うオブジェクトでマッチしている ❕ 結論: クエリの仕組みを正しく理解しないままコーディングを続けると⼤変なことに ❕ 連結クエリ: 異なるコマンドが連結できる唯⼀の事例 ❕ 結論: 連結を上⼿に活⽤してクエリを絞り込む ⚠ QUERY SELECTION BY ATTRIBUTE (v16) ❗ データを整理する ❕ フォーマットはいろいろ考えられる ❕ 1部屋を1オブジェクトで表現した配列 ❕ 1個の連想配列 ❕ 料⾦と部屋数で2個の連想配列 ❕ 部屋の集合を1オブジェクトで表現したもの ❕ ダメ1: データを突っ込んでいるだけ/部屋（料⾦とタイプ）の概念が失われている ❕ ダメ2: 形が違うだけで同じ ❗ 配列はlengthは[]がパスとして返される ❕ 例1: イエローはパスで指定したタイプの料⾦が返される ❕ 例2: ブルーでは客室のタイプに関係なく料⾦の⼀覧が返される ❕ 例3: イエローでは「シングル料⾦の合計・最⾼値・最安値・平均料⾦」といった情報が ⼀発で取れる ❕ 例4: ブルーでは「客室数の合計」「もっとも客室数の多いホテルの客室数」といった統 計が⼀発で取れる ❕ 結論: 正解はない/どういう使い⽅をしたいのか，から逆算してオブジェクトの形式を設 計することが必要 ❗ 新たな希望 ❕ 検索: サブテーブルの⽳を埋めてあまりある ⚠ ORDER BY ATTRIBUTE (v16) ❕ 構造体: BLOBやXML
© Copyright 2024 ExpyDoc
