Nah, it doesn't work out in the end.
A movie is supposed to have one episode.
Group A releases the movie split into 3 SVCDs, group B releases the same movie as 2 VCDs.
You'll end up with five files. Files 1-3 contain a third episode each, files 4 and 5 a half. If a user has watched files 1, 2 and 4, he has seen 116,666% of the movie. That's ugly, hard to display, and not even true since there's a whole third he has never seen (the part contained in files 3 and 5).
Additionally, it's hard to find out which files I need to download in order to get the whole movie once. Since the DB doesn't know of a way to assign files belonging to the same episode to sub-episodes, I would get a list of all five files, sorted by their file size. Finding the three files that go into the SVCD release means I have to check the description for each file. A workaround could be to sort the list by the release group - but then what if a group releases the movie twice? Same old problem. Another workaround is to add more episodes to sort the different file packs or release types - but then nobody will ever be able to mark the movie as watched without adding at least one file of the other fake episodes.
Besides, fractions are hard to implement correctly, due to rounding errors and such. In the end, it'd have to be two fields added to the database: a number and a flag whether the number is a multiplicator or divisior. (Second thought: n > 0 => n is a multiplicator, n < 0 => abs(n) is a divisior. But that's ugly to the power of 10.)
Subfiles or Stealth Files (same thing, different name) solve all these problems. In the movie example, you would see one episode containing a number of files. Each file represents the first of a series of files. All other files belonging to that particular series are listed in a subgroup (indented, grouped below the parent file). In other words, the DB would look like this:
Episode 1
- File 6, (group, 3 parts)
- - File 1, ed2k link
- - File 2, ed2k link
- - File 3, ed2k link
- File 7, (group, 2 parts)
- - File 4, ed2k link
- - File 5, ed2k link
Of course I can only judge this according to my own coding habits, but in my "normal" environment, these subgroups would not be hard to implement and the database change would be minimal: a single field to assign a file to a parent (a 1:1 relationship) does the trick. Building the list of files however requires an extra query for each group that is encountered, but the number of split episodes seems to be quite low anyways.
Next, the other way around: What happens if a file contains more then one EP? Simple. The exact same thing as above is done, with the exception that the stealth file's DB entry references an episode that's different then the parent's. Now the DB looks like this:
Episode 1
- File 1, ed2k link
Episode 2
- File 2, (stealth, see: "File 1")
For such super-files (note: super-files is simply the reversal of sub-files), it's trivial to replace the ed2k link icon with a link to the parent file.
Lastly, the problems with the mylist. For stealth files the solution is simple: When the parent is added, query for all stealth files related to that parent and add them as well. The episode-count fixes itself. For groups, add the group parent and all subfiles as well. Subfiles are excluded when deciding whether the anime has been watched or not, so only the group parent's watched flag counts: 1 anime, 1 episode, 1 group owner, 0 problems.
