3月6日 Twitterに載せるには長いので

お疲れ様です。

久しぶりのブログ更新です。

いや、本当に久しぶりです。

もっと更新しないといけないですよね。

Twitterは毎日やっているのですが、ブログはなかなかできないんですよね。

元々日記つけるタイプではないですし。

では、何故今ブログを更新しているのか。

タイトル通り、Twitterに載せるには長いからです。

短い文章にしようかとも思いましたが、今回はブログを使ってアウトプットしようと思います。

（いつもやっているTwitterがアウトプットになっているのかは置いておいて←）

ということでアウトプット（もどき）させていただきます

今回カリキュラムで学んだのは下記内容となります

・DB設計の基礎

・テーブルの構成要素

その中で、私が特に印象に残ったのは

テーブルの構成要素で出てきた

インデックス

このインデックスについて、カリキュラムを読んで考えた私のイメージをこちらに記載したいと思います。

間違っていたら、ご指摘お願い致します

【私的『インデックス』イメージ】

テーブルの隣にカラムだけのテーブルを作成する→インデックス

（例：usersテーブルにageカラムがあったとしたら、ageカラムだけを切り取ったようなテーブルをusersテーブルの隣に置く）

そのカラムの検索がされると、まずカラムテーブルが検索ワードがヒットするまで、読み込まれる

ヒットしたら、テーブルに飛んでヒットしたカラムのレコードを取り出す

インデックスがないと、検索ワードがヒットするまで他のカラムのデータまで読み込んで検索する

だから、インデックスがあると便利

でも、データ保存更新時はテーブルの他に他のテーブル（インデックス）も一緒に保存更新をするから処理時間がインデックスがない（テーブルが１つ）場合よりも遅い

又、単純に考えてテーブルが増えたらDB容量圧迫される

テーブルとインデックスの関係は１対多

（例えば、usersテーブルで名字データが入るlastnameカラムと名前データが入るfirstnameカラムがあった場合はこの二つのカラムを切り出してインデックスにしてフルネーム検索が可能）

※インデックスはこの検索の仕組みのことを指す

私のイメージは以上となります

ここまでお読み頂き、誠にありがとうございましたm(_ _)m