アプリ開発の調査にかかる
時間を削減したい
内製化支援サービス
アプリを自分たちで
作成できるようになりたい
DX人材育成プログラム
プロに開発を依頼したい
アプリ開発導入支援サービス
SharePoint デザイン拡張サービス
X-SP Style
モダン化から運用管理までサポート
移行・モダン化コンサルティング
本記事では主キーをテーマにSharePoint リストにて様々な値を用いて実装し、それぞれの評価と比較をしましたので、ご紹介します。
補足: 主キーとは
主キーとは、レコードが唯一のものであることを示す項目のことです。
この項目を参照することで、他のレコードと被らずに目的のレコードを得られるようになります。 項目を主キーとするには、以下の制約が必要です。
主キー制約
- レコード間で値が重複してはならない(UNIQUE 制約)
- NULL 値を取ることはできない(NOT NULL 制約)
主キーの設定方法
SharePoint リスト に「主キー」という設定項目はないですが、UNIQUE 制約、NOT NULL 制約を満たすことで主キーとして扱うことができます。
この条件を満たすために、主キーとしたい列の編集画面を開き、この列に情報が含まれている必要がありますと一意の値を適用の 2 項目を「はい」に設定します。
主キー値の生成方法
主キーとする列を設定後、主キー値を生成するための処理を追加します。
今回は、Power Apps から自動で主キーを設定するときに使用できる以下の方法をご紹介します。
1.SharePoint の ID 列
SharePoint リストを作成すると自動的に作成されるID 列は、シンプルに使用するには最適の列です。
ID 列は、リストにレコードが追加されるたびに自動的に番号を振るオートナンバー機能が備わっています。
あまり Power Apps や SharePoint に慣れていない方は、まず ID 列を使用することをお勧めします。
メリット
- 初期設定不要で使用できること
- 競合が発生しないこと
ID 列は既定でオートナンバー機能が備わっているため、主キーの条件である 2 つの制約を自動的に満たします。そのため、設定なしですぐに使うことができます。
ID 列のオートナンバー機能はSharePoint にレコードが追加されるタイミングで番号を付与するため、同時に複数のレコードが追加された場合でも順番に番号が振られ、競合が発生することはありません。
デメリット
- SharePoint リストを移行するとき、ID を引き継げないこと
- 番号は 1 から始まり、1 ずつ増加する以外の設定はできないこと
ID 列は手動で値を変更できないため、他のリストに引き継ぐことはできません。また、「SubID」などの新しい数値列を作成して値をコピーした場合でも、オートナンバー機能がなくなってしまうため、やはり ID 列の代わりとして使用することはできません。
オートナンバーの設定を変更することはできません。必ず番号は 1 から始まり、1 ずつ増加する設定になります。また、レコードを削除した場合、そのレコードに付与されていた ID が再利用されず、歯抜けのようになります。
2.First 関数を用いたカスタム値
採番ルールが決まっている場合は、First 関数を主とした関数を用いて疑似オートナンバーを生成する方法を使います。
First 関数を使用することで現在の最新のレコードのナンバーを受け取り、[最新ナンバー+1]とすることで次の番号を入力することができます。
例として、“A[今日の日付(年月日)]-[オートナンバー]” というルールで主キーを生成する場合、以下のような関数になります。(PrimaryKey 列を主キーとする)
$"A{
Text(Today(),"yymmdd")
}-{
Right($"000{
Value(Right(
First(SortByColumns(お知らせ,"PrimaryKey",SortOrder.Descending)
).PrimaryKey,3))+1
}",3)
}"
この関数を使用して主キーを発行すると以下のようになります。
メリット
- ユーザーの視認性が高い
- 既存の管理番号などを踏襲できる
関数を駆使して作成した主キーは、ユーザーが理解しやすく、視認性が高いです。
ることができます。これにより、既に組織で番号作成のルールが決められている管理番号などを主キーとする場合でも、ルールをそのまま適用することができます。
デメリット
- Power Apps の知識が必要である
- 保守や移行が難しくなる
- 競合が発生する可能性がある
関数を組み合わせる都合上、ある程度 Power Apps の知識が必要です。
列を参照するケースもあり得るため、リストを移行するときに列名が一致しないなどの問題が発生し、移行後関数を修正する必要がある可能性もあります。
複数ユーザーが同時にレコードを登録した場合、競合が発生します。 これは、主キーを生成してから登録するまでの間に他のユーザーが主キーを生成すると同一のナンバーが生成されることによって、重複エラーが発生し後から登録しようとしたデータが登録できなくなる、というものです。
3.GUID 関数
GUID 関数は、Microsoft が採用しているグローバル一意識別子(例:9cef1e6a-594f-4a81-a5c4-1298fb6e0f71)を生成するための関数です。
メリット
- 主キーが重複しない
誰が生成しても重複しない値をそれぞれのアプリで発行するため、2.First 関数を用いたカスタム値で生じた主キーが重複する問題を回避することができます。
デメリット
- 値がランダムである
生成文字列がランダムで意味を持たないことから、ユーザーが手動で扱うのは不可能です。そのため、基本的に非表示にして裏で運用することになります。
4.Now 関数
Now 関数は、現在の日付時刻を取得する関数です。Power Apps では、以下のように Text 関数と組み合わせることで現在時刻の秒数まで表示することができます。
Text( Now(), "yyyy/mm/dd/ hh:mm:ss" )
メリット
- ユーザーの視認性が高い
- 1 秒以上間隔がある操作に対して、主キーが重複しない
カスタム値よりは自由度は低いですが、日付時刻はユーザーが理解しやすく、視認性が高いです。
値が 1 秒ごとに変わるため、2.First 関数を用いたカスタム値で生じた主キーが重複する問題をある程度回避することができます。
デメリット
- 1 秒以内に主キーを生成した場合、主キーが重複する
1 秒以内に主キーを生成すると同一のナンバーが生成されることによる重複エラーが発生してしまいます。
比較
上記で紹介した 4 つの生成方法について、性能を下記表にまとめました。
主キー値を選定する際は、こちらの表をご活用ください。
※◎ >〇> △ > × の順で高評価
比較項目 | ID 列 | カスタム列 | GUID 関数 | Now 関数 |
---|---|---|---|---|
設計しやすさ | ◎ | ✕ | 〇 | 〇 |
値の連続性 | ◎ | 〇 | ✕ | ✕ |
主キーの見た目 | △ | ◎ | ✕ | ○ |
複数ユーザーの使用 | ◎ | ✕ | ◎ | △ |
ルールの拡張性 | ✕ | ◎ | ✕ | ✕ |
リストの移行 | ✕ | △ | ◎ | ◎ |
まとめ
本記事では、主キー値の生成について、4 つの方法を比較しました。
どの方法がベストとなるかは要件によって変わるものの、重要なのは主キーは一意性を保つためのものであるということ。
今までの採番ルールを踏襲するために複雑な設計が必要なこともありますが、可能であれば主キーはできるだけシンプルな設計にしたいですね。
本記事がアプリ設計における検討の一助になれば幸いです。
最後までお読みいただきありがとうございました!
【こちらも合わせて読みたい】
池内佑哉
大手部品製造会社に新卒で入社したものの、部内でどんどん人が辞めていく流れに危機感を感じわずか2年でIT未経験のままアーティサンへ。
IT業界の荒波に溺れかけながらもなんとかしがみつき、気が付けば人に指示を出す側に回っていました。
趣味は殺陣にミュージカル、歌に作曲、謎解きにボードゲーム、紅茶とコーヒーとワインなど……とにかく色々なことに手を出しては、ちょこちょこアウトプット(舞台への出演や曲やボードゲームの製作など)を出しています(職業病?)
たまにはゆっくり温泉旅行にでも行きたい……♨
こんにちは。アーティサン株式会社の池内です。