MariaDB とはアプリのデータベース倉庫を管理操作するためのアプリケーション。倉庫にあるデータを高速に参照したり更新したり、計算したりできる。どんなプリでも基本的にデータベース倉庫と連携して動くので SQL には精通しておく必要がある。
データベースの構造
MairaDB のデータベースシステムは複数のファイル群によって実現される。構成ファイル群は以下のディレクトリに格納されている。
$ ls -d /usr/local/maria/data/sampledb ← ソースからインストールした場合 $ ls -d /var/lib/mysql/sampledb ← パッケージからインストールした場合 $ li -d /usr/local/var/mysql ← homebrew からインストールした場合
インストール
基本的には公式レポジトリからインストール。
例えば、CentOS の場合は /etc/yum.repos.d/MariaDB.repo に公式レポジトリを追加。
YUM Repository Configuration Generator
セットアップ
- 設定ファイル etc/my.cnf のモードや所有者を確認
- 設定ファイル etc/my.cnf のシステム変数などを確認
- /var/lib/mysqlディレクトリの所有者を mysql に変更
- ローカル利用ならリモート接続を禁止
$ mysqladmin -u root -p status $ vi /etc/my.cnf [mysqld] character-set-server=utf8 skip-networking
データベースの本質
データベースの本質は「実世界」のパラレルワールドをマシンの中に創造すること。データベースとは、人間の認識を反映する鏡。
実世界（やその状態）を「パラレルワールド」としてマシンの中に複製すると、遠隔マシンにバックアップしたり、Webアプリに整形して発展させたり、AIと抱き合わせて情報分析したりと、色々なことができるようになる。
RDB の場合、主にリレーション（２次元表）という表現手法に沿って実世界（やその状態）をパラレルワールド化していくことになる。ちなみに、他の表現手法には NoSQL や DIT などがある。
データベース設計
データベース設計においては特に、以下２点を強く意識すべき。
- マシンパワーの活用を大前提としたデータベース設計
- 目的から逆算した実世界の状態のパラレルワールド化
マシンパワーが大前提
データを管理するだけであれば別に紙やノートを使っても良いはず。わざわざマシンにデータ管理を任せるのだから「マシンにしかできない何か」を強く期待しているはず。
つまり、マシンパワーの活用と目的の実現とのバランスをしっかり前提とした上でテーブル設計やチューニングすることが大切。
実世界の「本質」を適切に表現
データベースの活用とはつまり実世界のパラレルワールド化。ゆえに、実世界を適切に認識してその本質的な状態をマシンにアップロードしていく必要がある。
しかし、実世界の本質的な状態とは流動的で常に変化していくもの。この性質をしっかりと踏まえ、将来を見越したデータベース設計をする必要がある。
ゆえに、パラレルワールド化の際には以下３点が特に大切。
- 実世界の状態や本質を適切に認識する能力
- 目的から逆算してデータを整理する能力
- その状態を適切に表現する能力
以上３点があれば、その人は適切にデータベースを設計できる。そのような人は自分の部屋と同様にデータたちのお部屋も綺麗に整理することができるはず。
具体的なテーブル設計指針
- そのテーブルの主人公は誰（なに）なのかを主キーで明確にする
- そのテーブルはどのような「状態」の述語なのかを明確にする
- 実世界において２つの事柄を同時に認識することはできない
- ゆえに認識の鏡であるテーブルにも２つの概念を混ぜてはいけない
- ２つの概念が混じっているように感じるならテーブルを分けるべき
- テーブルを分けた時は外部キーを利用して両テーブルの整合性を保証
- カラムに定義する属性は実世界の「状態」を適切に表現しているべき
- 命名はすべて短くて適切で本質的な表現であるべき
- １つの「状態」を２度も記述するような冗長なカラム設計は避けるべき
- NULL を許すと世界が 3VL になってしまいアプリ設計が非常に複雑になる
- NULL を許すとそのテーブルはオプティマイザとの相性が悪くなる
- NULL を許すとそのテーブルはインデックスとも相性が悪くなる
- NULL が入る余地があるということは DB設計に問題があるかも
- NULL 発生を引き起こす「ありえないデータ」は将来、悩みのタネになるかも
- SQL にはそもそも順序という概念がないので手続き型ロジックの実装は高負荷
- ゆえに、手続き型のロジックに頼るのは最後の手段にする
- 空間や時系列を表現したいのであれば RDB はやめる