Batch removal of images

[AimHere]

Hi,

I was wondering, is there any [semi-]automatic or programmatic way to remove embedded images from a group of records?

I have screen shots (thumbnails, really) for most of my movies, as well as multiple photos for many actors and actresses, but my database is really swelling in size. I'm considering the removal of most or all of the screen shots, as well as the extra person photos (all but the first photo for any given person). But not if I have to go through all the records one-by-one and remove the photos manually!

I realize there's no real upper limit on the size of a PVD database, but I just fear that it'll eventually become unmanageable and start to slow everything down. Already, if I'm in People View and choose "View/Group by/Career", it takes a few seconds to process the over 4000 performers in my database.

So, it would be nice if there was a menu item or script for removing certain types of images, but since there doesn't appear to be, is there any alternative?

Aimhere

[rick.ca]

There are already "remove all" commands for images. They don't appear on any menu, but are available for assigning to the toolbar and/or hotkeys.

Removing images will not have any impact on how long it takes the program to sort or group a list—that's done using an index.

[AimHere]

There are already "remove all" commands for images. They don't appear on any menu, but are available for assigning to the toolbar and/or hotkeys.

Oh, thanks, I didn't see those. The "Remove all screen shots" command was exactly what I was looking for.

Removing images will not have any impact on how long it takes the program to sort or group a list—that's done using an index.

Maybe not, but it couldn't hurt. Surely, the larger the database, the more time it's going to take to process it in general (even if only for certain operations).

As a test, I made a copy of my main database (which is now 857MB), deleted all screen shots using the command you mentioned, then ran an "Optimize database" from the Tools menu. The file size was cut to 307MB, a savings of 550MB. If nothing else, that would be half a gig less data to copy whenever I back up the database.

I don't think it's necessary to take such a drastic step just yet with my main database, but it's nice to know the option exists.

Aimhere

[rick.ca]

Surely, the larger the database, the more time it's going to take to process it in general (even if only for certain operations).

Why? I can't think of any operation that should require reading all the images into memory, if that were even feasible. If many images are being added and deleted—and the database is never optimized—an operation requiring the processing of many image records might be degraded, but I can't think of any operation like that either.

Now that you've got one database with images and one without, why don't you test your theory. I would expect the initial loading time of the larger file to be a bit slower. Other than that, I'd really like to know if there is a measurable slow-down in any other operation. I don't believe it should be so.

[AimHere]

Ah, I'm sure your right about the database efficiency not really being affected. Too lazy to do further testing, too.

I just get nervous as I see the size of the database beginning to approach 1GB. 

Aimhere