As I've explained here, I don't believe there's any reason to be concerned about the size of a database due to the images stored in it. I think you've created a huge inconvenience for yourself by splitting your database—at least the separation of movies and series. The program is carefully designed to handle these two video types together in one database. It's obviously much easier to maintain one database than two.
I agree in general that people should use as few databases as possible to avoid the additional work of maintaining several versions of templates, user defined fields, etc, and to be able to have the advantages of a database with links back and forth between movies, actors, other movies, etc.
BUT (at least in the current version and how i use PVD), movies and series seem to work not too well together:
Links to episodes of series (eg from "movie connections") do
not point to episodes below a main entry for the series, but to "main movie records", and after updating such series episodes with their title and a localized title, even the special formatting which IMDB uses to point to an episode of a series will be lost, making it very hard or impossible to recognize such entries as an episode (and to which series it belongs) instead of appearing like a movie. And updating a series to include new seasons or episodes from an internet source (without influence on already downloaded or changed episodes), or importing my own list of titles and localized titles for a series (from CSV or similar) is no trivial task either.
Thus in my database, I didn't modify anything in a series yet, and might create a second database to do such modifications not in the main database but only in a separate subset database which will be easier/faster to recreate than the entire database if/when problems get out of hand.
... (images in the database) ... Because of this, my database is becoming pretty huge (around 500 megabytes at last count).
There's no reason to be concerned about the size of your database due to the images that are being added to it. The images will take up as much room in the file system as they do inside the database. And I don't know for sure, but I suspect Firebird can manage them more efficiently than the file system. They're certainly a lot "safer" inside the database.
true: the total size of the database itself plus the size of all pictures would be the same in both cases, maybe even a little less when everything is put together in one file since the database might handle storage more efficiently or at least differently than a filesystem with given sector sizes and thus rounding up the size of every single file.
but also false: depending on the filesystem, it is a huge difference whether i have a database of a few dozen or even a few hundred MB and separate 4000+ pictures of 1 MB each, or a combined database file of 4+ GB which can't be stored on a FAT32 volume. Even when most computers nowadays have a version of Windows which fully supports NTFS (or some other operating system which can be upgraded with drivers to use NTFS), most movie players (i have an emtec movie cube) don't use windows and (almost) can't be modified in any way. Thus they support at most reading from NTFS disks, but otherwise require FAT32 and/or files smaller than 2GB or 4GB. And thus i now keep newly bought external harddisks formatted with FAT32 (to use them on my comp as well as with other devices) and would like to keep the largest files below 4GB (to store a drive specific database on the drive itself, or to back up a main database on any drive).
I read somewhere that it wouldn't be possible to undo the option of including pictures in the database.
Is this still true and/or will be true in future versions?As long as the database is small enough (less than 2GB or 4GB), I would like to follow the advice to keep pictures in the database, but I need to be able to later have files of no more than 2GB or 4GB in size, eg by extracting pictures to separate files and purging them from the database file. Another reason to keep pictures separate might be to view them directly on a media device (i don't have experience yet on how to do this best).
