The Nameless City

何故か製薬やSAS関連のブログ、の予定。

1ファイルのサイズは1GB以下にした方が良いのは、コンピュータ・システムという事を使っている要件による。

SDTMの1ファイルが1GB制限であるというのは、OSや各種ファイルシステム、アプリの要件であり、この規制は無意味ではなく通信の物理制約も含めて「担保出来る範囲」という事です。
現在はだいぶ通信も安定している環境が多いのであんまり気にならないのかと思いますが、1GBではなく2GBではファイルシステムやアプリで制限が出て来ます。
例えば、ZIPの元の規約では、1ファイルのサイズが2GBを超えられず、圧縮ファイル全体のファイルサイズも2GBを超えられません。


ファイルというものが、そもそもサイズ制限が「必ず」存在し、そこを超えられないという事を認識した方が良いです。


で、これらを解決する方法は、当たり前に「ファイルの分割しかない」んです。
圧縮などのアルゴリズムも、送り手と受け手側に同じ認識がないとダメですし。これをXMLフォーマットにした所で、「物理的ファイルのサイズは制限された方がいい」のは普通です。
例えばインターネットを介したファイルの転送では、社内だとネットワークドライブとか、「仮想的にローカルディスクっぽくして扱う」のが当たり前になっているでしょうが、本来「転送はしばしば失敗し、分割して送信されているパケットは順不同になったりもする」ものです。
1ファイル辺りのサイズが大きくなればなるほど、転送に失敗する確率も増えていきます。まあ、レジューム機能つきでの転送とかもない訳じゃないですが、あまりに長い時間転送しようとすると、その通路上でのトラブルが増えます。FWでのヘッダの改造が原因だったり、長時間のダウンロードの強制停止であったり、原因は様々ですが。
てか、まず、「分割するのが基本」と思った方が良いです。


ただ、この話、「SDTMのガイドラインとして考えるべきか」というと、それとは違うレイヤなんですけどね。
ODMとかそこら辺の話です。SDTMに付随する情報として扱うべきで、本来、ファイル名+ナンバリングで逃げるのは厳しい所なんですがね。
ただ、CDISCの各種規約、骨組みはともかくとして実装が進んでいるのがSDTMな為、歪な発展するのは仕方ないですけどね。まあ結局SDTMが越境してくるような形で各標準書き換えるんだとは思いますが。