AvTvM said:
for light editing work, lr is a really good tool, but the database and associated performance issues are a problem.
Others have attempted to convey this to you without success, so maybe I'm tilting at windmills here:
The association between Lightroom's database and its performance issues exists only in your imagination. It's a mistake to claim that SQLite is an
a priori cause of Lightroom's performance issues.
All of the fixes you suggest, especially storing all the metadata in the image headers, would be both slower, uglier and more failure-prone than Lightroom's SQLite approach. I'm not trying to insult you here, but your understanding of programming/computer science is not quite what you seem to think it is.
There's no shame in having an incomplete understanding of these subjects, but you might at least consider that people who do this for a living (including other posters on this forum and the Lightroom developers) have thought about these things and rejected them for good reason.
SQLite (or something very much like it) is the right tool for this particular job, though I'd have preferred a true multi-user database to allow catalogs to be stored on networked drives. Others have already explained why OSes are not databases and why Spotlight and the Windows search/indexing function would be worse than Adobe's use of SQLite. One thing I didn't see mentioned is that if you rely on the OS to build its own database for your photos, switching between Windows and OSX (either way) becomes enormously problematic.
Why would you want to lock yourself into a particular OS simply because your photo editing app relies on that OS's database? Additionally, because your "ideal" OS-database would be entirely different for Mac vs. Windows, Adobe would have to spend time and money developing hooks for two entirely independent database structures. Oh, and if those OS-based databases don't support exactly the same metadata, then your feature set diverges on the two platforms. Speaking generally about DAM software, you
really want a database, and you
really want it to be completely independent of the OS.
AvTvM, you don't seem to reject the idea of Lightroom using a database, but rather you seem to think that Adobe has chosen the wrong one. I'm going to go out on a limb here and speculate that you think that somehow SQLite is a "big," ponderous database, so you pin all of Lightroom's performance issues on SQLite. SQLite isn't a slow database. It's efficient and fast for small data sets, and no matter how big you think your catalog is, it's not a big data set in the grand scheme of things.
If you don't think that SQLite is a big, slow database, then what's your objection to it?
That's not to say that Lightroom doesn't have issues. It does, but I don't pretend to know the root cause of those problems. For example, as far as I can tell, exporting JPEGs and building 1:1 previews (which are basically the same thing) should be
embarrassingly parallel or nearly so. Yet, as the plot Diko posted shows, Lightroom doesn't efficiently use more than four CPUs for these tasks. In other words, building 1:1 previews should take half as much time with eight physical cores as it does with four, but instead it takes nearly the same amount of time.
There's a reason for that, and I don't know what it is. But I doubt that it's because all of the Lightroom developers know less about parallel computing than I do. (I don't know very much).
I'd love to see better performance from Lightroom. I agree that Adobe hasn't taken users' performance complaints seriously, and I agree that there are other workflows that have advantages over Lightroom. But pinning all of your complaints on SQLite only highlights your incomplete understanding of the issues at hand.