• table people: Filmography2 is pure hell from an economic point of view and if one happens to collect artist information in earnest it's responsible for more than 60% of database space claimed. This has to stop soon, really.
  
  A comparatively easy way to improve things would be to work with programmatic placeholders for recurring strings (like the main part of the akas.imdb URL).
  
  Slightly better would be an additional table for link types with an ID. That way you could have different fimography sources.
  
  An almost perfect way would be linking to a dedicated film table (will be mentioned later in this post again).


• table episodes: why do episodes have to follow a different path with audio links compared to movies? I would like to see things working the same way for both. Given that the movies table leads, a table EpisodeAudioLinks could be the solution.


• ...

• table movies: should only contain movie related information - nothing about the actual presentation format of it. Generally speaking: there's the (artistic) work - and there are presentations of this work (like on a DVD).
  Since we already have DisksLink, MovieFilesLink and AudioLink, we have a good starting point to clear the mess up (or add to it, it may be a matter of taste ). Here's a rough sketch of what I've in mind - it probably should get discussed where which fields are to be moved to - if this would ever get considered:
  

			* Movie ("the work")

			**  Movie item (a presentation)
				- Presentation Medium (Optical disc, Web, Magnetic Storage ...)
				- Presentation specifics
				  - Technical data (video specs, audio specs)
				  - Packaging
				  - Location (in a shelf, on a file system)
					
			Relating entries:

			* trailers, making-ofs
			* supplements (like press books, scripts)
			* artists
			* certifications
			* ratings
			* posters, fanart

			** source related information (like DVB-capture or discshop.se; purchase information / value information)
			** upcoming releases (on optical discs or tv broadcasts)
			** lending system
			** quality ratings
			** covers, screenshots
			** medium (Blu-ray, DVD, (S-)VCD ...; (S-)VHS; File system, External file system(s)

			options (not needed for every entry):

			** path information / location
			** video stream information (picture size, format, codec, fps, ...)
			** audio stream information (per stream | format, codec, channels, language, ...)
			** subtitle information (per available subtitle set)

• I want a MovieItem table, obviously. This would make it much cleaner to have multiple presentations of the same work organized. For instance I have different editions of the same movie on Blu-ray and DVD or I have an original DVD and a DVB capture (as a subbed version). Everything representation specific should be moved to the movie item hierarchy ... see previous point.
  (added 13*08/10) By freeing the movie table from the actual representation information it could be used for filmography purposes too. A simple boolean value like "in collection" could be used to distinguish between filmography-only and collection movies. Also helpful for wish / watch lists... ...the amount of data stored for different scenarios could be managed easily.
  


• ...

• Series Status


• Certification (I've mentioned some ideas here: http://www.binaryworks.it/forum/topic.asp?TOPIC_ID=9724&FORUM_ID=29 ... a table for Certification schemes and one for movie (id) specific certifications


• A Studio and a Distributor table ... and maybe according StudioLink / DistributorLink tables; we could treat studios like artists and collect information about 'em (like founded in, by - backlinking movies from our movies table to them etc.


• Awards ... could develop into a feature like described above for studios


• Condition (for a purchased item)


• Shops (purchase sources)


• Profession (added 13/08/10) ... A table for an artist's profession. Items should be multi-selectable. Currently, only comma separated values are stored in the profession field of the people table - what really annoys me: that it happens in no particular order. Also, it doesn't make sense to distinguish between actors and actresses - in the profession field, that is. It's bad for filtering and we already have a gender field.


• ...

• table country(added 13/08/10) ... Would be nice if the countries I've collected in a list would be accessible to me whenever there's a country field to fill. People (artists) are currently not entitled to make use of it. Additionaly, some sort of automatically collecting country entries would be interesting.


• ...

• It would be cool if XMM would be agnostic which db backend I use. A first step would be to allow / enable MSSQL (Express).


• If MSSQL express is an option it would be nice to have a function to get the connection string as some variable for MovieCards so vbscript can be used easily (it's quite fast using JET with MSSQL).


• ...

quote:

---

Originally posted by Mawu

Sounds like complete reprogramming of xMM. I'm not too optimistic that this will happen in the near future.

---

quote:

---

Originally posted by Odin

Quite a while back I suggested using SQL CE, which I think would be a great choice. It doesn't require SQL installed, all you need is the dll's added to your project in order to use SQL CE.
It would also make it very easy to go from SQL CE to regular SQL or SQL express. The only bad thing about SQL CE is that it doesn't allow you to use stored procedures.
But like Mawu said, it would required some work to get this done ;)

---