Quote:The OP says he wants "unlimited countries." If he is thinking of a really high number, then it probably needs to be done with a one-to-many relationship, which does accommodate a really high number of values: millions, even gigs.

Just how many countries do you think there are in the world? There is a difference between theoretically unlimited, and unlimited in practice.Btw the answer is less than 200 countries. It varies a little over time.

If you are proficient in database design, then designing a database for this purpose isn't that great a deal. It does take a bit of planning, but it's not rocket science. Ideally it should be 100% normalized, but sometimes that's overdoing it.

So, I stand by my opinion that designing the database isn't the biggest challenge for the project as described. That's 40 years of professional programming talking ...

More challenging would be to decide on how to separate the physical medium (DVD) and the digital content (movie) and how to then get them back together again.

Loads of movies have basically only one list of cast and crew over all releases, worldwide. And then there are those movies with extended editions with different credits (e.g. LOTR) or localized credits (often true for animated movies).

Quote:The OP says he wants "unlimited countries." If he is thinking of a really high number, then it probably needs to be done with a one-to-many relationship, which does accommodate a really high number of values: millions, even gigs.

Just how many countries do you think there are in the world? There is a difference between theoretically unlimited, and unlimited in practice.Btw the answer is less than 200 countries. It varies a little over time.

If you are proficient in database design, then designing a database for this purpose isn't that great a deal. It does take a bit of planning, but it's not rocket science. Ideally it should be 100% normalized, but sometimes that's overdoing it.

So, I stand by my opinion that designing the database isn't the biggest challenge for the project as described. That's 40 years of professional programming talking ...

But has any of your experience been in database design? DVD Profiler is a *database* program, and that's the expertise you need here. A database is a very structured object. Any changes, even slight ones, to its structure, data format, field properties, etc. could involve a major operation. If you've had professional experience in databases then you MUST know this. DVD Profiler was made a long time ago and its database structure is long overdue for some improvements. More often than not, a database's structure RESTRICTS what you can do on the application end of things, which you must also know. And THAT is why some of the wish-list features for DVD Profiler are pipe dreams, as you call it, because they are very difficult to do if not impossible. Database structure always HOLDS BACK whatever you want to do on the application end, please understand this.

Quote:DVD Profiler is a *database* program, and that's the expertise you need here. A database is a very structured object. Any changes, even slight ones, to its structure, data format, field properties, etc. could involve a major operation. If you've had professional experience in databases then you MUST know this.

Duh! Condescending much?

Quote:DVD Profiler was made a long time ago and its database structure is long overdue for some improvements.

Again - Duh! What has that got to do with anything? We were discussing how difficult (or not) it would be to design a new database for a DVD Profiler clone.

Quote:Three mighty warriors. Let the games begin and a schema emerge!!!

Just sayin't. I've developed my own DB format over ten years ago to do statistical analysis on my profiles. I used MS Access as a database in DVD Profiler to Access. And it's pretty much open source for anyone who can open an Access database file.

And of course it's normalized and (for example) has a many-to-many relationship between profiles and CoO.