I've been using ACDSee since the mid 90s (ACDSee v3 IIRC) and I've been asking for DBMS support for most of that time. This is not a new request; it comes up with every new release and ACD Systems says that they'll consider it with every major point release.
But like all end-users, I've made the mistake of stating a feature requrest as a requirement rather than stating my actual requirements. The two primary requirements that I see as driving this are as follows:
- Ability to share the catalog on multiple computers, at the same time (CRITICAL as more and more families have have more than one computer).
- Ability to query the catalog outside of ACDSee
Implementing a DBMS is certainly the most obvious solution to these requirements, but it's not the only solution, by any means.
And please note that implementing a DBMS is a huuuuge undertaking which leaves ACD Systems with several problems. How do they give us power users DBMS support but still keep it simple for the majority of their user base?
They can either deploy a light weight DBMS with ACDSee Pro and write all of the export/backup/restore routines but then what happens if the dbms's data files become corrupt? What happens if the DBMS is down, temporarily? Does ACDSee refuse to start or does it act as Marc metioned above (many features are disabled until the DBMS comes back on line). I can envision times where the DMBS is down and people absolutely NEED to get those photos off of the camera, editted, and then shipped to printing NOW!!!!!! So refusing to start isn't a valid option. What happens if users want to migrate their existing catalog to the DBMS (or back to a file based system)?
Okay, so what about using ODBC? Bad idea. The windows implementation is nothing short of retarded and would frustrate many users. They would likely just give up and bitch about it even more.
The other option is to support the old catalog AND a DBMS. But that's expensive too because they need to rewrite one of two things. Either rewrite the existing catalog technology so that it accepts SQL queries (or use the Borland one... which I also think is a bad idea) which also means modifying their application to use SQL only. Or they need to add support for an SQL DB right along side support for their existing catalog (this is also terrible because it means they now have two storage code paths to maintain; bleh).
Then there is the question of what do they store in the DB? Catalog info only or do they allow you to store the images in the DB? If the latter, then that's a huuuuge problem because you start to need non-free versions of Oracle or SQL Server. And mysql suffers massive performance problems when you start storing files > 16MB in it. Do they also store thumbnails in it too? How much performance are you going to lose downloading the thumbnails from a dbms than from a local or network disk? So should the thumbnail cache be local?
And with a central catalog, storage of files is now an issue for sharing the catalog. Example: I store all of my files on a shared disk which I mount, globally, as drive 'G'. But the wife is constantly downloading files directly to her laptop (and I have tons of non-photographic images on my desktop). What happens when both my wife and I have different images of the same name in the same directory? Okay, store the 'machine name' along with the picture. Wrong. What happens if I reinstall my PC and rename it? I've now lost all of my catalog info, even though I've copied the files into the same place? Okay, what about using md5 hashes to identify files? Better, but now you have to calculate md5 hashes for every file, on the fly. That's expensive and takes CPU power. Okay, so do a query by per MachineName:/path/to/file, if it retuns no hits, do an MD5 hash on the file, query the DB for files matching the md5 hash and present the catalog info to the users. But wait... what if this is a duplicate file of another one that exists somewhere else? Do I allow the user to 'steal' this catalog record or 'duplicate' it?
What happens if I move my files from c:\users\dfidler\acdseepix to g:\shared\drive\acdseepix? How does ACDsee determine that the files have moved? Does it just create new catalog entries or does it ask me if I've moved my files based on the filesize and md5 checksum? (I'd prefer the latter so I can keep my catalog info for the moved files) If it creates new entries, I now have orphaned catalog info in my database which is wasting space (not to mention that I've lost the catalog info for my moved files). This means that they'll also need some kind of optimization process to clean out the database; per ACDSee instance.
They can go the Adobe route and build a server-based solution that stores all of the files for you (internally) and uses the DBMS as a back-end. You then check these files in and out to work on them. Then catalog info on all locally stored files is stored in the local catalog. There are problems with this implementation too. What platform do you write it for (windows is the obvious choice, but then everyone is going to bitch about Linux support; myself included). And in reality, this kind of implementation lends itself well to larger organizations rather than ACDSee's market, which is the home users and Pro shops that have 1-3 users. I suspect that most larger shops are already using the Adobe solution (and will continue to do so because of the integration with Photoshop).
And using MS SQL Server (or Oracle or DB2) as their primary data source is a really bad idea (assuming an integrated solution). Less than 1% of ACDSee users will be able to manage a DBMS (especially the 'big boys of the DB world). Mysql (though I don't really like it) is the most common dbms out there. More and more users have some kind of experience with it. But everyone who is not a mysql fan is going to bitch, endelessly, about the fact that their favorite DB flavour isn't supported.
So does ACD Systems create a pluggable API that does DB support?
Aside: I'd recommend that they make this a pluggable API; provide an abstract base class that provides all of the get/set functions required to interface with the application which saavy programmers can then use to add support for different databases. Of course, this API would need to do version checking to ensure that old DB plugins are not used with newer versions of the program; lest database corruption may ensue. Or they can simple decide to 'own' all plugins to ensure consistency of code quality but I suspect that ACD System's Engineering and QA teams don't currently have the expertise for that.
Anyways, I'm rambling, sorry.
While I've always been annoyed at ACDSee for not implementing this feature, I do understand (being a former DBA and Software Engineer, not affiliated with ACD Systems) the number of issues that surround this request. They are not insurmountable issues but they are expensive ones to solve. First and fore-most, ACDSystems has to implement something that is both rock solid and dead simple to use, yet flexible enough to satisfy the 'I want to share/query my catalog info'. That's no easy request.
As an aside: I must admit that I've recently switched to Adobe Bridge + Photoshop. Bridge provides the option to write all of the catalog info to the directory in which the files live. Unfortunately, Adobe RAW and Bridge are both riddled with memory leaks and various other "stupid software tricks" (tm) [and Adobe is slow to react to user feedback, if they even care to at all].
But the catalog info generally moves with my files as I move directories around (and my wife can see the edits and catalog info as soon as she clicks on the files). ACDSee and Bridge raw edits are also completely incompatible (this is not surprising) and my ACDsee edits don't carry over into Photoshop.
But then, I look at the cost of the Adobe solution; $1000 vs the $150 for ACDSsystems; ACDSee gives some truly amazing value for it's price point. And by switching to Bridge, I felt like I was stabbing an old friend in the back, but needs-must. I now only use ACDSee for quick edits, etc, that I don't care about (resizing already editted files, quick directory browsing, etc).
So I now question whether it makes sense for ACD Systems to implement the DBMS feature. I think it's truly great that they are committed to it (and, honestly, it's one of the two reasons that I started looking elsewhere for another package) but then, as I said, 99%+ of their users have no need for a DBMS.
So does ACDSee need to support a proper DBMS? I can't answer that question. Using a DBMS is certainly the first thing that comes to mind but it's not the only solution.
Anyways, I'm rambling again... sorry.
Cheers,
Dave.
New Content Since Last Visit
No New Content Since Last Visit
