はじめに
「要素」はXML形式データにはなくてはならないものです。XMLは要素によってデータを識別します。関係データベースにおける表名や列名に相当するものです。
基本的にあらゆるデータを表形式にとらわれずに表現できるのがXMLの特徴ではありますが、この要素名には決まりがあります。今回はそれを整理してみましょう。
要素のネーミング規則
以下に、要素名の許可ルールです。大まかに1文字目とそれ以外で分かれています。このルールはMarkLogicに限らずXMLファイルとしてのルールです。
| 文字の位置 | 利用可能な文字 |
|---|---|
| 1文字目 | 英字, _(アンダースコア), :(コロンただし非推奨), 漢字, 全角ひらがな, 全角カタカナ |
| 2文字目以降 | 1文字目に使える文字, 数字, .(ピリオド), -(ハイフン)など |
また以下の使用不可もしくは非推奨があります。例を示しつつ列挙してみました。
| 記述例 | 説明 |
|---|---|
| 2020年10月 | 先頭が数字は使用不可 |
| ﾌﾘｶﾞﾅ | 半角カナ、全角英数字、全角空白は使用不可 |
| xml | XML宣言の被るため使用不可。Xmlなど大小文字を混ぜるのも含む。 |
| 要 素 | 途中のスペースは使用不可 |
| a:date | コロンは名前空間で使われるため非推奨 |
先頭に数字が禁止されている点は、Oracleとも共通していたりします。「2018_10_30の売上高」といったような数字による分類があるときは気を付けましょう。一方で予約語については、それぞれのDBの特徴が出ています。例えば「DATE」というのはOracleの列名では使えませんが、XMLDBの要素名としては使えたりします。
要素の長さについて
ここで気になったのは、要素名の長さが性能に影響するかです。というのも表形式のデータの場合、最初の行だけに列名を書いていますが、XMLの場合は全ての列に要素名を記述することになるからです。そこで要素名長を変えつつ、データロードと検索を行ってみました。
データは基本的にこんな感じのものを100万ファイル用意します。実際には100万行のCSVファイルをContent Pumpを用いてロードしました。
<root>
<key01>Tjr5v8Ye_000000000001</key01>
<key02>0ZCIjYAg_000000000001</key02>
<key03>EdnTwU9F_000000000001</key03>
・・・ (47要素) ・・・
</root>
試験パターンとして各要素名の末尾に一定数の「kkk...k」という文字を付加してみます。例えば、key01の場合はkey01kkkkkkkkkkkkkkkkkkkkとします。
CSV出力クエリはこんな感じです。PROCESSクエリだけ表示します。$elementName-seqへの代入の部分は長くなるので省略しますね。
(試験環境やCoRBによるCSV出力方法についてはこちらをご参照ください。)
xquery version "1.0-ml";
declare variable $URI xs:string external;
let $elementName-seq := ("key01", "key02", ..., "key50")
let $doc := cts:search(/*, cts:document-query($URI))
let $text-seq :=
for $i in $elementName-seq
return $doc/*[fn:name() = $i]/text()
return fn:string-join($text-seq, ",")
結果はこうなりました。
| 末尾のkの数 | データロード[秒] | データサイズ[GB] | CoRBによるCSV出力[秒] |
|---|---|---|---|
| 0 | 2,685 | 12.83 | 898 |
| 20 | 2,831 | 13.73 | 922 |
| 40 | 3,007 | 14.25 | 942 |
おおよそ、要素名の長さに比例してロード時間・データサイズ・処理時間が増加しているようです。ただ、純粋なXMLファイルのサイズが1813→3813→5813文字とかなり増加していることを考えると、現実的には多少要素名の長さが増えるのは性能面で許容可能と見ることができます。
考察
要素名の長さについては議論の余地があります。短すぎる要素名は意味が分からなくなるかもしれませんし他の要素名と被る可能性が出ます。一方で、長くすると可読性が低下するほか性能にも微妙な影響を与えるようです。こういったことを総合的に判断して一定の制限を加えるのが妥当だと考えます。
おわりに
ソースコードのコーディング規約はよく作りますが、XMLについてはどうでしょうか？おそらくXMLDBを使わない限り、Webアプリケーションが利用する少数のXMLファイルに対してのみとなり、そこまで重視されないでしょう。
しかし、XMLのコーディング規約を作ってしまえば、要素のネーミング規則として挙げた「先頭文字を数字はNG」といったことは、そう変わることがないため使いまわしが可能と考えます。
\def\textsmall#1{%
{\rm\scriptsize #1}
}
免責事項
$\textsmall{当ユーザ会は本文書及びその内容に関して、いかなる保証もするものではありません。}$
$\textsmall{万一、本文書の内容に誤りがあった場合でも当ユーザ会は一切責任を負いかねます。}$
$\textsmall{また、本文書に記載されている事項は予告なしに変更または削除されることがありますので、予めご了承ください。}$