PHP データの検索

Question

下記のような情報をPHPで参照するにはどのような手法がよいでしょうか。
一般的な方法がわからず困っています。


> アラビア語・・・ar,ar-sa,ar-ae,ar-bh,ar-dz,ar-eg,ar-iq,ar-jo,ar-kw,ar-lb,ar-ly,ar-ma,ar-om,ar-qa,ar-sy,ar-tn,ar-ye
アフリカーンス語・・・af,af-za
アルバニア語・・・sq,sq-al
(以下略)

＜やりたいこと＞
例：
arという文字列渡すと、アラビア語と返す。
sq-alと渡すとアルバニア語と返す。
・・・



＜思いつく方法と考え＞
1. DBに格納する
速度も落ちるしデータ自体が不変のためよくない気がする・・・

2. 配列データに変換（シリアライズ化して外部化）
例：'ar'=>'アラビア語','ar-sa'=>'アラビア語'・・・
これが一番よさそうな気がする・・・

3. 正規表現を使う
例：if(preg_match(/ar|ar-sa|ar-ae/・・・){
return 'アラビア語';
}
重そうだしコードが・・・

4. if、スイッチ
if(== 'ar') return 'アラビア語';
if(== 'ar-sa') return 'アラビア語';

処理的には一番早そうだけどコード的に微妙・・・


よろしくお願いいたします。

Accepted Answer

2と4で悩みどころですね．2はハッシュが衝突しない限り処理時間が一律になりますが，配列を用意する時間がかかってしまいます．4は先頭のほうは非常に高速ですが，後ろのほうになると遅くなってしまいます．（といっても配列作ってる2より速い？）**なお，4はswitch文のフォールスルーを使ってもう少し見やすく書けます．**

総合的に判断すると4かな？

```php
function language_name($language_code)
{
    switch($language_code) {
        case 'ar':
        case 'ar-sa': case 'ar-ae': case 'ar-bh': case 'ar-dz':
        case 'ar-eg': case 'ar-iq': case 'ar-jo': case 'ar-kw':
        case 'ar-lb': case 'ar-ly': case 'ar-ma': case 'ar-om':
        case 'ar-qa': case 'ar-sy': case 'ar-tn': case 'ar-ye':
            return 'アラビア語';

        case 'af':
        case 'af-za':
            return 'アフリカーンス語';

        case 'sq':
        case 'sq-al':
            return 'アルバニア語';

        default:
            throw new \UnexpectedValueException;
    }
}

```

Answer

再利用や綺麗さを考えるとどれもイマイチですね。
1はDBというシステムと密結合、マイグレーションファイルで管理すればいいので△
2はPHP言語と密結合、いろんな可能性を考えた時の最適解に近そうなので○
3と4は保守し難いので論外…ただしコンパイル後としてはアリか？

あるべき姿で考えてDBサーバーに突っ込むのが嫌なら、JSONやSQLiteを利用する案もあります。

```JSON
{
  ar: "アラビア語",
  af: "アフリカーンス語",
  ...
}
```

しかしJSONファイルをPHPで都度読み込んでデコードし始めると速度はあってないようなもの。
速度を求めるなら自力でクイックソートのコードを書いたりする必要がありそうです。

速度と綺麗さを求めるのであれば、コンパイル用のNode.jsバッチを作成して…
JSONファイルから下記のようなPHPコードに変換してみてはいかがでしょう？
作ってみたら微妙なコードになっちゃいましたが、PHP7なら純粋な配列になるのでそこそこ速そうです。

```PHP
<?php
function jp_lang_of($prefix) {
  $codes = ['af','ar'...]; // 予め昇順に
  $langs = ['アフリカーンス','アラビア'...]; // こちらもindex値を揃える

  $index = 0; // クイックソートでindexを探す
  return $langs[$index];
}
```

---

ひらめきました。

```PHP
function lang() {
  return 'アラビア語';
}
```

config/langディレクトリの中に`ar.php`のようなファイルを生成して、includeで呼び出せばいいのです。
1回きりの処理なら間違いなしで最速です。

Answer

実行速度は気にせず、可読性と保守性(※)の観点から、ご自身がもっとも優れていると思う方法を採用すればよいかと思います。
※データの追加・修正があった際の変更のしやすさ

なぜなら、よほどシビアな性能を求められているのではない限り、アプリケーション全体の実行コストに対するこのコードの実行コストの割合は微々たるもののはずだからです。

ちなみに私なら、`-`以降は無視して
```php
$languages = array(
    'ar' => 'アラビア語',
    'af' => 'アフリカーンス語',
    'sq' => 'アルバニア語',
    ...
);

function get_language_name($arg) {
    $code = explode('-', $arg, 2);

    return $languages[$code[0]];
}
```

とやりますw

もしくは、`言語コード-国コード`の一覧に他の用途が想定されるなら、以下のようなテーブル構造のDBに格納してしまうかと思います。
```sql
CREATE TABLE languages (
    code char(2) PRIMARY KEY,
    name varchar(128) NOT NULL
);

INSERT INTO languages VALUES
    ('ar', 'アラビア語'),
    ('af', 'アフリカーンス語'),
    ('sq', 'アルバニア語'),
    ...;


CREATE TABLE countries (
    code char(2) PRIMARY KEY,
    name varchar(128) NOT NULL
);

INSERT INTO countries VALUES
    ('sa', 'サウジアラビア王国'),
    ('za', '南アフリカ共和国'),
    ('al', 'アルバニア共和国'),
    ...;


CREATE TABLE language_country (
    language_code char(2), 
    country_code char(2), 
    PRIMARY KEY (language_code, country_code),
    FOREIGN KEY (language_code) REFERENCES languages(code),
    FOREIGN KEY (country_code) REFERENCES  countries(code)
);

INSERT INTO language_country VALUES
    ('ar', 'sa'),
    ('af', 'za'),
    ('sq', 'al'),
    ...
```

これなら、DBの一意制約やリレーションを利用できるためにデータの管理が容易になるのと、
例えば
「国コードから、その国で使われている言語を取得する」
など、他の用途にも利用しやすくなるからです。

Answer

わたしなら用途によって「1.DBに格納する」か「2.配列データに変換」を使います。

ただ、

```php
array(
    'ar' => 'アラビア語',
    'ar-sa' => 'アラビア語',
    :
);
```

とかよりも、

```php
array(
    'ar' => 'ar',
    'ar-sa' => 'ar',
    :
);
```

```php
array(
    'ar' => 'アラビア語',
    :
);
```

のように２つに分けるほうがよいかもしれません（そもそも１つめのは必要？？）。

「1.DBに格納する」については、もしその値をRDBに格納することがあるのであれば（人物テーブルの言語フィールド、みたいに）、言語テーブルも同じくRDBに格納し外部キー制約を貼る必要があるかもしれないからです。

関連した質問