中山テック 代表の中山です。
※開発者向けの記事となります
代表の技術遍歴をご紹介！～プログラミング編～では過去触ってきたプログラミングを抜粋の上紹介しました。
今回はサーバサイドエンジニアとして必要不可欠であるデータベース（以下ＤＢ）の技術遍歴をご紹介します。
最初のC言語を扱っていた4年間はDBアクセスライブラリがあったため
SQL書くこともアクセスすることもありませんでした。
なのでまだＤＢ歴は10年ほどしか触ってません。
そこから延々ＤＢ中心とした開発を行って来ましたが、主に下記を触ってきました。
１．Oracle
２．DB2
３．SQLServer
中でもOracleは携わった現場の8割方を占めており
ＤＢとしても非常に多くの機能を兼ね備えているため導入されるのも
頷ける気がしました。DB2、SQLServerも劣ることのない性能となっているのでお間違いなく。
SQL
データベースへアクセスしてデータを取得するプログラムをSQLと呼びます。
例えば下記のSQLを実行すると・・・
SELECT * FROM USER_DATA WHERE REGIST_DATE >= TO_DATE('2020/01/01','YYYY/MM/DD')１．SELECT・・・参照します。更新（追加、更新、削除）することはありません。
２．FROM テーブル名・・・データ取得するためのテーブルを指定します
３．WHERE カラム名・・・WHEREは条件式の宣言となります。
カラムはテーブルの中の列にあたります。ユーザID列はユーザIDカラムと呼びます。
上記コードの場合「2020年1月1日から登録した全ユーザデータを取得する」という条件を付けます。
複数テーブルに跨ったデータを取得したい場合はSQLはより複雑になります。
チューニング
ＤＢ操作に慣れてくるとチューニングを実施する機会が与えられることもあります。
これは、「データ取得に時間が掛かっているので、より良いSQLに修正する」や
「データ取得に時間掛かっているのでインデックスを付けましょう」とか
「データ取得に時間掛かっているのでテーブル分割しましょう」と言ったことを実施します。
上記のSQLでいうところの「WHERE」以下の条件が悪いことが殆どです。
まずはどの程度実行～取得までに時間掛かるのかを調べます（実行計画と呼ばれる技術を使用）。
その後、SQLで全レコード1個1個調べていないか（本来は必要な分だけを検索すべき）とか
そもそも取得レコードが多いのに、使用しないフラグがないとか。
1つのテーブルに対し普通に一千万～下手したら億単位のレコードが詰まっているので
1個取得するのに0.0000001秒の差が出ただけでパフォーマンスは劇的に変化します。
設計
新しいテーブルを追加する時に別テーブルの情報が必要なら参照カラムを追加する、インデックスは貼るのか
レコード数の見積次第ではインデックスは逆効果と言ったことを考えなくてはなりません。
さらにレコードが増えたことによる正規化を検討することで冗長処理が改善します。
まとめ
サーバサイドの開発を行う際は画面はもちろんのこと、ＤＢを鑑みないとなりません。
プログラミングも貰う情報＋ＤＢ処理方式に倣って記載することが殆どです。
ですので、プログラミングの勉強する方はＤＢの勉強もセットでするべきなのです。
