内部IDによって一意に特定可能な行データが構成されるとともに、前記内部IDと前記行データの内部に保持される登録時間のペアが全順序関係を成すように構成されたデータベースで検索を行うデータ処理方法であって、前記行データを前記内部IDの順に取得する行データ取得工程と、前記取得された行データがユーザ指定の検索条件を満たすか否かを判定する検索条件判定工程と、前記検索条件判定工程で条件を満たすと判定されたときに行データを出力する行データ出力工程とを備え、登録時間順に検索結果出力することを特徴とするデータ処理方法。前記データベースからの行データのエクスポート時に、前記内部IDを含めて行データをエクスポート先に出力するエクスポート工程と、前記エクスポートされた行データのデータベースへのインポート時に、インポート元の行データの内部ID及び登録時間を取得する内部ID取得工程と、前記取得された内部IDがインポート先データベースの内部IDに衝突しないかを判定する内部ID衝突判定工程と、前記取得された内部IDと撮影時間のペアがインポート先データベースの内部IDと登録時間の組と全順序関係を維持できるかを判定する全順序関係判定工程と、前記内部ID衝突判定工程で衝突がないと判定され、かつ、前記全順序関係判定工程で全順序関係が維持されると判定された場合に、該行データをインポートするインポート工程とを備えることを特徴とする請求項1に記載のデータ処理方法。前記内部IDとして、登録時間、または登録時間の定数倍、または登録順序情報のいずれかを使用することを特徴とする請求項1または2に記載のデータ処理方法。前記全順序関係判定工程で全順序関係が維持されないと判定された場合に、前記インポート工程は、全順序関係を維持できるように、インポート行データの内部ID、またはインポート先データベースの行データの内部IDを変更してから行データをインポートすることを特徴とする請求項2に記載のデータ処理方法。内部IDによって一意に特定可能な行データが構成されるとともに、前記内部IDと前記行データの内部に保持される登録時間のペアが全順序関係を成すように構成されたデータベースで検索を行うデータ処理装置であって、前記行データを前記内部IDの順に取得する行データ取得手段と、前記取得された行データがユーザ指定の検索条件を満たすか否かを判定する検索条件判定手段と、前記検索条件判定手段で条件を満たすと判定されたときに行データを出力する行データ出力手段とを備え、登録時間順に検索結果出力することを特徴とするデータ処理装置。内部IDによって一意に特定可能な行データを保持したデータベースであって、前記内部IDと前記行データの内部に保持される登録時間のペアが全順序関係を成し、前記行データを前記内部IDの順に取得する行データ取得工程と、前記取得された行データがユーザ指定の検索条件を満たすか否かを判定する検索条件判定工程と、前記検索条件判定工程で条件を満たすと判定されたときに行データを出力する行データ出力工程とをコンピュータに実行させ、登録時間順に検索結果出力することを特徴とするデータ処理プログラム。請求項6に記載のデータ処理プログラムを記憶したことを特徴とするコンピュータ読み取り可能な記憶媒体。前述の特許文献1による対策は、ソートキーの順序に格納されたインデクスがたまたま存在するか否かを利用するというものであり、存在した場合のみ効果が得られるに過ぎない手法である。これに対して、低リソースの機器、例えばカメラにおいては確実に効果が得られる工夫が求められる。実際には、カメラの場合は検索結果を撮影時間順にソートすることがほとんどであり、時間順ソートが高速なら充分実用的であり、任意の並び順出力を高速化する必要はない。本発明は前述の問題点に鑑み、カメラのような低リソース機器においても、検索結果の時間順ソートを少ない負荷で高速に処理できるデータベースを実現して、機器上検索の操作性を向上させることができるようにすることを目的とする。本発明のデータ処理方法は、内部IDによって一意に特定可能な行データが構成されるとともに、前記内部IDと前記行データの内部に保持される登録時間のペアが全順序関係を成すように構成されたデータベースで検索を行うデータ処理方法であって、前記行データを前記内部IDの順に取得する行データ取得工程と、前記取得された行データがユーザ指定の検索条件を満たすか否かを判定する検索条件判定工程と、前記検索条件判定工程で条件を満たすと判定されたときに行データを出力する行データ出力工程とを備え、登録時間順に検索結果出力することを特徴とする。本発明によれば、検索結果を時間順に出力する場合に、検索結果集合抽出後の最終的な時間順ソート処理を省略できるため、低リソース機器においても高速に時間順検索結果を出力することができる。第1の実施形態以下、図面を参照しながら本発明の好適な実施形態を詳細に説明する。図1は、第1の実施形態のデータ処理装置100の構成を示すブロック図である。図1に示した構成において、CPU101はマイクロプロセッサであり、検索処理、エクスポート処理、インポート処理、撮影処理、画面遷移処理等のための演算、論理判断等を行い、バスを介してバスに接続された各構成要素を制御する。BUS106は、マイクロプロセッサCPUCentralProcessingUnit101の制御対象である各構成要素を指示するアドレス信号、コントロール信号を転送する。また、各構成要素間のデータ転送を行う。入力部102はボタン、タッチパネル、キーボード等であり、オペレータが各種の指示を行う。表示部103は液晶ディスプレイ等である。撮像部104は撮像センサ等であり、映像を読み取って電子データに変換する装置である。通信部105はデータ交換コントローラである。無線LAN、接続ケーブル等を介して外部とのデータ交換を行う装置である。インポート処理でインポートされるデータ、エクスポート処理でエクスポートされるデータはこの通信部105を介して外部の機器とやり取りされる。ROM107は読出専用の不揮発性メモリである。CPU101によるブートプログラム、及び各種処理で使用する初期データ等を記憶する。ブートプログラムはシステム起動時に初期データをRAM108にロードし、CPU101に制御プログラムを実行させる。制御プログラムについては、後にフローチャートを参照して詳述する。RAM108は読み書き可能なランダムアクセスメモリであって、各構成要素からの各種データの一次記憶に用いる。データを処理するためのスタック、必要データを一時記憶する各種ワーク領域、表示に必要な表示データを一時記憶するバッファ等、処理中に値変更が行われる各種データが格納される。インポート処理でインポートされるデータもこのRAM108に一次記憶されて処理される。DISK109は大規模記憶装置であり、大量のデータを変更可能に記憶するためのものである。ハードディスクあるいはフラッシュメモリ等で構成される。本実施形態のデータ処理装置100で使用する行データ、インデクス等が格納され、必要に応じて内容が修正される。前述した各構成要素からなる第1の実施形態のデータ処理装置100においては、入力部102等を介して入力される各種イベントに応じて作動するものである。入力部102等からインタラプト信号がCPU101に送られ、それに伴ってイベントが発生し、イベントに応じてCPU101がROM107またはRAM108内に記憶される各種命令を読み出し、その実行によって各種の制御が行われる。図2は、第1の実施形態が対象とする検索の処理例を示した図である。なお、検索のユーザ指定は、ユーザがタッチパネル等を指示して行い、受け付けられた検索指示はアプリケーションによって解釈され、DB操作言語SQL文等で記述された検索クエリの形式でDBMSに渡されることになる。図2aは、検索クエリSQL文の例を示す図である。ある写真集合を属性で検索できるように管理するデータベースPhotoAlbumの中から被写体Personが‘Kate’の写真を検索し、撮影時間Time順にソートして出力することを指定している。なお、第1の実施形態においては、カメラを想定しており、撮影時間はデータの登録時間を意味し、撮影時間順は登録時間順を意味する。図2bは、図2aの検索クエリに対する検索処理を示している。多数の写真を集めて管理している写真集合201がある。まず、最初のステップステップ1において写真集合201から検索条件を満たす写真を抽出して検索結果集合となる写真リスト202を作成する。次のステップステップ2において、この写真リスト203中の写真を検索クエリで指定する撮影時間順にソートし、ソートされた写真リスト203を作成する。この場合、ステップ2のソート処理はシステムに対して相応の負荷をかけることになる。もし、ステップ1の段階で、最終的に得られる写真リスト203の順に写真を抽出できれば、ステップ2の処理を省略できる。図2cはそのソート処理が省略できる場合の検索処理例を示している。今度は、写真集合204から検索クエリに見合う写真を抽出する際、1~4に示すように、最終的な出力順である撮影時間の順番に写真を抽出し、その順で写真リスト205を作成していく。このようにすると、最終的なソート処理を省略することができるので、処理負荷を減少させることができる。図3は、第1の実施形態におけるデータベースの格納構造を示した図である。基本的にはいわゆるB-Tree木構造の構造である。図3aは、行データの格納構造を示している。行データは、行を一意に特定可能な内部IDRowIDと呼ぶをキーとして、B-Treeの形式で格納される。なお、内部IDは行データを一意に特定するためのIDで、重複してはいけないという制約がある。そのため、通例、個々のデータベースごとに異なる体系を持ち、内部で閉じたIDとして使用される。データベースの格納単位はノード301であり、複数のノードから構成される。各ノードはキー302と枝303からなり、最も上位のノードルートノードから、キーの大小関係を判断して枝をたどることによって目的ノードまでたどることができる。最下層のノードリーフノードには複数の行データ304がRowIDの順に格納される。行データは行を特定するためのRowID305、撮影時間情報306、及びその他の列307から構成される。ここで、RowIDを時間撮影時間情報順としているので、格納順が時間順になっている。インデクスは、属性に従って行データを検索したい場合に、検索を高速化するために用意されるものである。高速検索が必要な属性ごとにインデクスを作成することになる。図3bはインデクスの格納構造の一例である。人名Personのインデクスを示している。PersonをキーとしたB-Treeの構造となっている。行データの格納構造と基本的に同一となるが、最下端のリーフノードに行データの代わりにキーであるPerson308とRowID309のペアが格納される点が異なっている。各ペアはPersonの値が同じ場合、RowIDの順、すなわち時間撮影時間情報順に格納される。このようにインデクスを介して検索した場合も、時間順に行データを取得できることになる。図4は、第1の実施形態におけるエクスポート/インポート処理の例を示した図である。エクスポート時は、機器1401において内部のデータベースDB1から部分データベースDB2402がエクスポートされ、外部に出力される。このとき、本来は内部のID情報であるRowID情報を含めて出力される。以降、データベースDB1をエクスポート元データベース、DB2をエクスポート先データベースと呼ぶ。エクスポートされたデータベースDB2は、機器2403に転送され、機器2内の一時記憶領域に格納される。あるいは、一旦、SDカード等の外部メディアに吐き出され、その外部メディアが機器2に装着されることによりデータ転送される。次に、インポート時は、該転送されたデータベースDB2が、機器2403において、内部のデータベースDB3にインポートされる。以降、DB2をインポート元データベース、DB3をインポート先データベースと呼ぶ。このとき、RowIDの値と時間情報がインポート先データベースDB3の内部で先後関係が矛盾しないようにRowIDの値が調整されてインポートされる。例えば、インポート元データベースDB2でのRowID=50の行データがRowID=1に変更されてインポートされている。図5は、第1の実施形態において、全順序関係に応じたインポート処理方法を説明した図である。図5aは、インポートされるべきデータインポート行データの例を示した図である。図4で説明したように、別のデータベースからエクスポートされて生成された行データである。行データは、RowID501、撮影時間情報502、その他の情報503の列からなる。RowID501は、図4の説明でも述べたように、本来は内部のみで使用されるIDであるので、通例はエクスポートされないデータであるが、第1の実施形態においてはエクスポートされて存在する。図5bは、全順序関係が維持できる場合のインポート例を示す図である。インポート前のDBを504で示し、インポート後のDBを505で示している。インポート後のDB505において、太枠部分は図5aがインポートされた行データである。RowID、撮影時間のペアがDB内でインポート先のDB内においても全順序関係を成しているので、RowIDが変更されずにそのままの値でインポートされていることが分かる。図5cは、全順序関係が維持できない場合のインポート例である。同様に、インポート前のDBを506で示し、インポート後のDBを507で示している。やはり同様に、インポート後のDB507において、太枠部分の行データがインポートされた行データであるが、今度は、RowIDの値が変更されていることが分かる。すなわち、RowIDが元のままではRowID、撮影時間のペアが、直前、あるいは直後の撮影時間の行と全順序関係を成さないので、全順序関係が成り立つようにRowIDの値が調整されてインポートされたのである。508の行データは、直前の撮影時間の行RowID=10と直後の撮影時間の行RowID=20の間になるようにRowIDの値が調整RowID=15されてインポートされている。509の行データは、直前の撮影時間の行が複数RowID=30と40存在するが、このうち最大の値RowID=40と直後の撮影時間の行RowID=50の間に調整RowID=45されてインポートされている。5010の行データは、直前の撮影時間の行RowID=70と直後の撮影時間の行RowID=71の間が存在せず、新たな中間のRowIDが設定できないので、インポート先データベースの周辺のRowIDが不連続値となるように変更されている。すなわち、RowID=71の行は80に、72の行は90に変更された。その後、直前と直後の中間値RowID=75が求められ、インポートされている。前述の動作をフローチャートに従って説明する。図6は、第1の実施形態におけるデータ処理装置100の動作を示すフローチャートである。より具体的には、CPU101の処理手順を示すフローチャートである。S601はシステムの初期化処理であり、各種パラメータの初期化や初期画面の表示等を行う処理である。S602は、タッチパネル等の入力部102から何らかのイベントが発生するのをCPU101において待つ処理である。イベントが発生すると、S603においてCPU101がこのイベントを判別し、イベントの種類に応じて各種の処理に分岐する。図6においては、各種イベントに対応した分岐先の複数の処理をS604という形でまとめて表現している。図7で詳述する検索処理、図8で詳述するインポート処理はこの分岐先の一部となる。他の処理としては、詳細は記述しないが、エクスポート処理、撮影処理、写真閲覧処理、通信処理、電源OFF処理などの処理がある。S605は上記の各処理の処理結果や処理終了を通知し、画面を各処理の指示に従って表示する処理である。エラーがあった場合のエラー表示、正常な処理が行われた場合の画面表示への反映など通常広く行われる処理である。図7は、図6のS604の一部である検索処理を詳細化したフローチャートである。S701において、初期設定が必要な変数、テーブルを初期化し、検索条件に応じた処理インデクスを選定する。例えば、SELECTFROMPhotoAlbumWHEREPerson=‘Kate’ANDPlace=‘Tokyo’ORDERBYTimeというクエリに対して、Personのインデクスを選定する。S702において、検索条件から検索範囲を設定し、その範囲の先頭にポインタを初期設定する。例えば、PersonインデクスのB-Treeを辿って行き、Kateの始まりの位置にポインタを設定する。S703において、ポインタに従ってRowIDの値を取得し、今度は行データのB-Treeを辿り、行データを取得する。既に説明したB-Treeのデータ構造に従って必ずRowIDの順、すなわち撮影時間順に行データ取得処理が行われることになる。S704において、取得された行データが検索条件を満たすか否かをチェックする。例えば、先の例では、Place=‘Tokyo’を満たすか否かをチェックする検索条件判定を行う。S705において、検索条件判定処理を行い、検索条件を満たしている場合にはS706に進み、満たさない場合はS707にスキップする。S706においては、検索条件を満たしているので行データ出力処理を行う。これによって検索結果出力が行われることになる。S707において、ポインタが検索範囲の終了位置に来ているか否かを判定し、終了位置のときは、これ以上の処理は不要なのでリターンし、終了でないときは、S708に分岐する。ステップS708においては、検索範囲内の次の行データをポイントするためにポインタを更新し、S703にループする。図8は、S604の一部であるインポート処理を詳細化したフローチャートである。S801において、インポートされる行データの集合を取得する。インポートされる行データは、例えば、機器内のRAM108内に一時記憶されている。S802において、インポートされる行データを1件取得する。その行の内部ID取得、撮影時間取得を行い、RowIDをR、撮影時間をTとする。S803において、行データが取得できたか否かを判定し、取得できなかったときは、処理終了でリターンし、取得できたときはS804に進む。S804において、インポート先データベースにRと同値のRowIDの行があるか否かをチェックする。すなわち、内部ID衝突チェックを行う。S805においては、ID衝突の有無を判定する、内部ID衝突判定を行う。同値のRowIDがある場合、すなわち、RowIDが衝突しているときはS811に分岐するが、衝突していないときはS806に分岐する。S806において、インポート先データベースからRより小さくてRに最も近いRowIDを取得し、その値をR1とする。S807において、R1の行の撮影時間を取得しT1とする。S808において、インポート先データベースからRより大きくてRに最も近いRowIDを取得し、その値をR2とする。S809において、R2の行の撮影時間を取得しT2とする。S810において、T1<T<T2を満たすか否かを判定する。すなわち、全順序関係判定を行い、全順序関係を成していないときはS815に分岐し、全順序関係を成しているときはS816に分岐する。S815において、全順序関係が成り立たない場合の処理を行う。すなわち、インポートされる行データを引数として、図9に詳述する内部ID再調整処理を呼ぶことによって、インポート先データベースあるいはインポートされる行データのRowIDを調整する。S816において、行データをインポートし、S817に移行する。一方、S805において、RowIDが衝突しているときはS811に分岐し、S811において、衝突している2つの行データの全列が同一であるか否かを判定する。同一の行データなら、そもそもインポート処理する必要がないのでS817に分岐して次の行データの処理に移る。同一でなければS812に進む。S812において、同期が必要な行データ同期データであるか否かをチェックする。チェック方法は、行データの指すコンテンツが一致する場合に同期が必要と判断する。別のチェック方法としては、予めコンテンツを一意に特定するID情報を定めておき、その情報を行データの列に保持しておき、その情報の一致で判断する、などの方法が考えられる。S813において、同期データか否かを判定する。同期データでなければS815に分岐し、同期データのときはS814に進む。S814において、同期処理を行う。同期処理は、2つの行データのうち、新しい行を選択して更新する処理である。あるいは、列単位で新しいデータに更新する場合もある。その場合、差分を抽出してどちらが最新か否かを判定し、更新することになる。あるいは、どのデータを選ぶかはユーザに選択させる処理を行う場合もある。その後、S817に移行する。S817においては、次の行データをポイントするためにポインタを更新し、S803にループする。図9は、S815の内部ID再調整処理を詳細化したフローチャートである。S901において、インポートされる行データの撮影時間を取得しTとする。S902において、インポート先データベースに存在してTより小さくてTに最も近い撮影時間を取得し、T1とする。S903において、T1を撮影時間としてもつ複数の行のうち最大のRowIDをR1とする。S904において、インポート先データベースに存在してTより大きくてTに最も近い撮影時間を取得し、T2とする。S905において、T2を撮影時間として持つ複数の行のうち最小のRowIDをR2とする。S906において、R1<R<R2を満たすRを取得する。S907において、Rが存在するか否かを判定する。存在しない場合すなわち、R1とR2が連番である場合、S908に分岐する。S908において、インポートされる行データのRowIDのうち、R1あるいはR2付近のRowIDの値が連番とならないようにすなわち、不連続の値となるようにリナンバーする。このリナンバーはインポート先データベース全体に対して実施することもできるが、R1、R2付近について局所的にリナンバーしてもよい。その後S906にループする。S907において、Rの値が存在した場合すなわち、R1とR2が連続値でなかった場合は、S909に分岐し、インポートされる行データのRowIDをRに変更してリターンする。なお、本発明は前述の実施形態に限定されるのではなく、本発明の趣旨を逸脱しない限りにおいて適宜変更が可能である。第2の実施形態これまで述べた実施形態においては、カメラ等のデバイス上でエクスポート処理、インポート処理等を実行することを想定して説明していた。ところが、カメラで撮影した写真等のデータはPC等で集中管理し、必要なデータをデバイスに配信してデバイス上で閲覧等するという使い方も存在する。このような場合、リソースの少ないカメラ上で複雑なインポート処理を行う必要性は少なく、PC上でカメラのためのインポート処理を行う方が妥当である。第2の実施形態は、このようにPC上でインポート処理を実現する場合の動作を説明する。図10は、第2の実施形態に係るシステムの全体構成の例を示した図である。図10aは全体構成であり、図1で示した全体構成とよく似た構成となっている。異なる点のみを説明する。CPU1001、入力部1002、表示部1003、通信部1004、BUS1006、ROM1007、RAM1008、DISK1009等の構成及び役割はほぼ同じである。本実施形態においては、PCであるため、図1の撮像部104は存在しない。通信部1004を介してデバイス1005例えばカメラと接続され、デバイス上のデータベースデバイスDB1が参照できる。RAM1008にはワーク領域として抽出データ領域が使用され、DISK1009には全体DB、デバイスDB2が格納される。全体DBには複数のデバイスから入手されたデータ写真等が集中管理される。デバイスDBは、デバイスにデータをインポートする際に使用するワーク領域である。インポートの際には、デバイス上のデータベースデバイスDB1がデバイスDB2に一旦コピーされる。全体DBに記憶されたデータのうち、デバイスにインポートしたいデータは、一旦、抽出データ領域に抽出され、このようにコピーされたデバイスDB2にインポート処理される。インポート処理が終了後、このデバイスDB2はデバイス上のデバイスDB1に書き戻され、最終的にデバイスが使用可能になる。図10bは、全体DBの論理構造表形式を示した図である。物理構造は、図3で説明したB-Treeの構造である。データベースを処理する場合に使用される本来のRowIDとして、1010の列が存在する。それとは別に、全体DBは各デバイスがDBを使用していたときのRowID情報を全て保管しておく。この場合、それを示したのが1011、1012であり、2つのデバイスの情報を保持する。例えば、デバイスDB1用のRowIDは1010の列に格納するとする。撮影時刻の情報は1013の列に格納され、その他の列の情報は1014でまとめて示した。このように全体DBの情報は、各デバイスが保有していた情報の全てを合わせて保有することになる。デバイスにインポートする際には、まず、インポートが必要なデータを抽出する必要があり、抽出データ領域1015に抽出したデータが作成される。この抽出の際には、ターゲットとなるデバイスが特定され、そのデバイス用のRowID情報のみが抽出されている。デバイスDB2の構成を1016で示し、抽出されたデータはここにインポートされる。このように構成することで、複数のデバイスに対応したRowIDをPCにおいて保持できるので、RowIDの調整処理が起動される可能性が少なくなり、システムのパフォーマンスを改善することができる。第3の実施形態これまで述べた実施形態においては、内部IDは時間に沿った値として特に詳しく定義して説明していなかった。実際には、機器や機能の事情に応じて、図11に示すような、様々な形態の内部IDが考えられる。図11aは、データの登録順序情報を使用する場合の例を説明した図である。データが登録される順序を1101で示し、データが登録された時間登録時間を1102で示す。登録時間1102の前後関係に応じて登録順序情報が与えられることになる。この方式によれば、内部IDが発番される機構を単純化でき、システムを低リソースで実現することができる。図11bは、内部IDとしてデータの登録時刻を採用した場合を説明した図である。登録時刻を1103で示しており、YYYYは年、MMは月、DDは日、hhは時、mmは分、ssは秒を示す。これに対し、内部IDRowIDの計算式の例を1104で示している。ここでは、シンプルに月の日数を31日に固定した起算日からの秒数を計算する式としたが、もっと緻密な計算式、例えば、月の大小、うるう年、などを考慮した計算式も容易に与えることができる。この形態は、発番の仕掛けが簡単であり、複数の機器間で順序の整合性をとりやすいという利点がある。ただし、同時刻に多数のデータ登録が行われた場合例えば、カメラで連写が行われた場合など、内部IDの衝突の可能性が高くなってしまう。図11cは、これに対して衝突の可能性をより低くした方式である。前述した登録時刻の定数倍を内部IDとして使用する。登録時刻が1103で与えられた場合、同様に1105の式で内部IDRowIDを与える。ここで、Cは定数を意味し、例えばC=10などの値で使用する。これによって、内部ID衝突の確率を大幅に低減することができる。前述した実施形態以外にも、本発明の趣旨を逸脱しない限りにおいて、構成を適宜変更することが可能である。その他の実施形態また、本発明は、以下の処理を実行することによっても実現される。即ち、前述した実施形態の機能を実現するデータ処理プログラムコンピュータプログラムを、ネットワーク又は各種のコンピュータ読み取り可能な記憶媒体を介してシステム或いは装置に供給する。そして、そのシステム或いは装置のコンピュータまたはCPUやMPU等がプログラムを読み出して実行する処理である。