データベースの主キーに日本語を使用するのはありか？

Question

MariaDBでカテゴリテーブル（性別グループと年代グループ、カラムはIDと名前）を作っているのですが、主キーのIDを日本語にしてほしいとクライアントからいわれました。
クライアントはCSVからデータを顧客情報テーブルへインポートするときや、テーブルを直接参照するときに直感的にデータを扱えないことを理由としています。

個人的に、シングルバイトの英字・数字以外の文字を主キーにするのは、管理上・パフォーマンス上問題ありそうで、日本語対応はIDとは別のカラムに入れて、SELECTで表示すべきものと考えているのですが、皆さんはどう思われますか？。

データベースの文字コードはutf8mb4です。

追記：
サロゲートキーを追加し、IDを日本語対応することも考えています。

Comments

[otn]

一般論では回答の通りですね。今回のケースでどうかと考えると、
> 主キーのIDを日本語にしてほしい

は具体的にどういう事でしょう？
性別テーブル：ID(主キー)=1、名前=男
を
性別テーブル：ID(主キー)=男
にしたいという事でしょうか？

また、
> クライアントはCSVからデータを顧客情報テーブルへインポートするときや、

は、インポートをツールそのままで行うのでなく、プログラムを一皮かぶせて変換することも考えられます。
それが良いのかどうかの検討も必要ですが。

> テーブルを直接参照するときに直感的にデータを扱えないことを理由としています。

これは、クライアントがMariaDBのSQLを対話的に入力実行するという事ですか？
プログラム経由ならそこで変換すれば良いので。

[くろちゃん]

> 性別テーブル：ID(主キー)=1、名前=男
> を
> 性別テーブル：ID(主キー)=男
> にしたいという事でしょうか？

その通りです。直感的ではないといわれた主キーの値は`M`,`F`、`10`, `20`...といったシングルバイトのCHAR型値を採用するということで決着しました。

> これは、クライアントがMariaDBのSQLを対話的に入力実行するという事ですか？

A5M2などSQLクライアントを用いて、1行目に物理名を記載したCSVファイルを対象テーブルにインポートする用途を想定していました。

Answer 1

クライアントからの依頼であれば「あり」ですが、リスクを十分に説明して本件に係るトラブルについてはノークレームもしくは有償対応になる旨きちんとにぎっておいてください。

日本語主キーのリスク

• 空白文字（スペースやタブ、改行）などを許容してしまうと主キーの一意性を損なう
• その他文字にゴミがまざったときに見極めが困難
• VARCHAR指定になるため無駄なデータ量になる
• 移植やデータ移行の際、同じキャラクターコードで運用されていない場合文字化け
• 主キーを指定した削除(修正も)がローレベルの環境でやりにくい
• RDBの正規化による管理方法とロジックがあわない（主キーなどユニークなコードと値の組み合わせがSQLの基本）
• 同じIDを利用して複数データを持つこと（マスターデータの履歴管理など）がしづらくなる。結局２カラムで主キーを設定することになるので煩雑でデータ管理しづらい

主キーとはレコードに一意アクセスするためのキーでしかないためむしろAUTOINCREMENTしたINT系のデータにしてブレを極限まで削るのがベストで、マスターデータなど外部キー結合する際のキーとする場合もなるべく意味を持たさないデータ（サロゲートキー）にするのが賢明です。
日本語を利用するのは論外だとして、なんらかの意味をもたしたIDを発行するにしても主キーではなくユニーク属性でデータ管理をすれば必要十分だと思います。

しつこいようですが、上記を説明したうえでそれでも日本語主キーを強要されるのであればそれはクライアントの意向に従うのが受託業者の宿命ですから諦めて従ってください

Answer 2

クライアント側と協議した結果、主キーに日本語などのマルチバイト文字を採用するのは無しということになりました。
クライアント側は日本語を主キーに採用することのデメリットを認識していなかったようで、性別ならM, F...、年代なら10, 20, 30...といった直感的な値を用いたシングルバイト英数字（データ型は何れもCHAR）を採用すればいいということで納得してくれました。

投稿後、多忙により返事が遅くなってしまったことをお詫びします。

Comments

[yambejp]

マルチバイト文字非対応は妥当な判断だと思います。性別については100以上あるという評価もあり、男女だけでMFとするのはあまりおすすめできません。最低でも男、女、どちらとも言えない、答えたくない（不明）の４つの選択肢は用意ください。

[otn]

医療系で使う生物学的性別は、ISO規格だと不明、男、女、適用不能の4種類です。昔JIS規格にあったときは適用不能は無かったかも。ジェンダー(社会的性別)は規格にはなさそうですが、最近の入力欄は生物学的性別に準じてか、その4つあることが増えてきました。マーケティング用にジェンダーを入力してほしいならその程度で十分な気がします。

Answer 3

そもそもIDをどうやって持ってるの？システムが自動採番しないなら、そりゃCSVからインポートする時に不便だって言われるのは当たり前だと思うんだけども。
その不便の解決策をITがわからん人に委ねたらダメでしょ。

IDとは別の列に入れて表示するべきというのは全くもって質問者さんと同じ見解です。

IDをどうのこうのしたいというのが、外部キーとの都合の話なのか、グループ化の為に複合主キーが必要という話なのか、がイマイチごちゃ混ぜになっている気がする。

主キーを日本語にすればテーブル構造が直感的になるってのは思いつきで言うてみただけだと思う。
構造の問題は変わらないし、もしそれで変わるなら質問の前提条件が不明

ああ、逆にCSVで顧客情報を取り込む時に性別欄があって、「男」「女」と入力したいところを「1」「2」のような入力しかできないなら、それはシステムが悪い。
ほかのシステム（それが手入力でもいいのだが）と連携できないわけだから。

Answer 4

やめといた方がいい理由はたくさんあるけど、絶対ダメな理由はない、という気がしなくもない。

日本語であるメリットがとても大きいというなら、リスクを説明した上で、やっちゃえばいいんじゃないでしょうか。
だってステータスに "CANCELED" とかたまに見ますよ。
"CANCELED" がいいなら "キャンセル済" でもいいんじゃないですか。

大昔、テーブル名・カラム名を日本語で作ったことがあるような記憶がありますが、特に問題なかったです。
SQL 読めないお客さんと、SQL 見ながら会話が成立してました。

以上、他人事なので無責任な意見でした。
わたしがやるならリスク費 5% 乗せ、この設計に起因する問題の解決は次フェーズ対応で別途費用請求、ですかねぇ。

Answer 5

全てのテーブル名や項目名に日本語を使ったシステムの開発に携わったことがありますが、とにかくSQLを書くのが面倒です。
シンプルなビューを作ってそちらで対応してもらっては？

例)

CREATE VIEW 書籍一覧 AS
SELECT bookId As 書籍番号, title AS タイトル, author AS 著者名 FROM books;

このビューは更新を受け付けます。

-- INSERT
INSERT INTO 書籍一覧 (書籍番号, タイトル, 著者名)
VALUES (1, 'キテレツの刃', 'フジコちゃーん');

-- UPDATE
UPDATE 書籍一覧
SET タイトル = 'キテレツの刃 1', 著者名 = 'フジコちゃーん'
WHERE 書籍番号 = 1;

-- DELETE
DELETE FROM 書籍一覧
WHERE 書籍番号 = 1;

Answer 6

仕事でなら「ありかなしか」では無く、クライアントがしたいと言うのなら、技術的問題点・常道を丁寧に (w) 説明（≒何かあれば責任はそちらという形に）した上で、やるかやらないかなんじゃないでしょうか。