LR5は正しい解だけど。
NIKONの Capture NX-D の正式版配布が7月に始まったのでrawの現像は純正アプリでやれば良く、その後のレタッチは onOne Software のPerfect Photo Suiteを使うので、写真の管理だけできれば良いのです。
http://imaging.nikon.com/lineup/microsite/capturenxd/jp/
今の構成は母艦のiMac (2009 Early！)にメタデータのインデックスファイル、写真のデータは外付けのUSB-HDDに置いている。
メタデータをそんなに大きくしない前提の場合、macbook air(2011 middle！)にメタデータのインデックスファイル、写真のデータはもとのまま外付けUSB-HDDで良いのではないかと思っている。ここで大きく変わるのは母艦がSSDになること。
最終手段は別途MySQLをインストールするだけれども、組み込みのDBを調べる（組み込みMySQLは無料で使えないらしいので省いてる）。
高頻度で登場するプロパティやらタグやらを格納するRDBMSとexifやらの謎大量プロパティをそのまま格納するスキーマレスの値を格納するKVSのデュアル構成かな？
複数スレッドからアクセスすることが無いと仮定すると、RDBMSは普通にSQLiteでもいいのか…
- URL: http://www.firebirdsql.org
- License: Initial Developer's Public License ( http://www.firebirdsql.org/en/initial-developer-s-public-license-version-1-0/ ※改変部分だけソースコードの公開義務がある？)
組み込み版の正式版はWindowsのみ、linuxやOSXでも可能ではある。
久しぶりに名前を確認した。InterBaseから成ったやつ。
RDBMSである。
- URL: http://symas.com/mdb/
- License: Licensed under the OpenLDAP Public License ( new BSD 系？ )
levelDB の出したベンチマークを使ったものを見ると速そうに見える。 http://symas.com/mdb/microbench/
- URL: https://code.google.com/p/leveldb/
- License: New BSD License
Google の出しているKVS。Facebookが言うにはメモリをあふれるととても遅いらしい。
Swiftから使うためのラッパー: https://github.com/ap4y/LevelDB
- URL: http://rocksdb.org
- License: BSD License
LevelDB の上に構築されてるらしく、メモリの5倍のサイズでも速いとFacebookは言っている。 for fast storageとのことなので、目的に合致する？
OSXではプロダクションユースしてないし、最適化フィーチャーが一部動作しないよって書いてあるな…