Multiple/Seperate/Partitionable Databases Startup Selectable

[Jared]

Scanning the master list, I didn't see anything too close to this (other than a server/shared data base request).

Assume multiple collections. Assume a database for each collection. Assume collections may overlap, i.e. a physical song file may be in more than one collection.

Needed: A way to 1) select a databases at start up time (via command line parameter/registry), and 2) switch to another DB while running (similar to a exit followed by a start pointing to the new data base).

A way to use multiple data bases displayed together as a single DB.

DB features to split and join DBs (partial export and import?)

Possible Collection Structure: A root (or base) directory (default to My Music?) contains a MM data base. Point MM to the base; it finds the DB. Option to point MM to a base and a separate DB location/name, so multiple DBs can be kept in a single folder.

Perhaps the DB can contain the root folder so only the DB has to be indicated. If all the DBs were in a common folder then MM could present a list of all .mdb files for the user to select from.

The idea of a root folder could be faked by using an old DOS ASSIGN statement to create a drive letter for the base folder, thus keeping the existing internal DB structure based on drive letter qualifies a song.

Folder monitoring (and maybe some other options) needs to follow the database (if it doesn't already) so that monitoring will not fill one DB with songs from some separate set of folders associated with a different DB.

Enhancements: Be able to logically concatenate, de-concatenate databases so that multiple collections may be viewed together and and apart in arbitrary combinations.

Access song files through generic root node (read drive letter) so that a DB on a server can be mapped to different drive letters by different users. In other words, show path names in DB as ??:\ where ?? is substituted by the letter for (or path to) the desired root node to create the real file name. Probably will need ??1:\ ??2:\ etc. for multi-partiton hard drives.

I'm not a knowledgeable MS JET/SQL person (DB2 and IMS from the dinosaurs ) but the idea concatenating tables (vertically) out of differing DBs has been around forever. Just don't know how MS would have implemented it.

Incremental Development Goals:

1. Pick (locate) the DB at startup via command line switch, backed up by HKCU and HKLM registry entries.

2. Change to another DB "on the fly".

3. Access song files through generic root node (read substitutable drive letter), and let each execution of MM have a different drive letter for song files. Make sure a DB is multi-user sharable.

4. Locate song files via a root path, user specified as a URNC locater. Make sure a DB is cross system shareable.

5. Create several ways to find DB and base path, e.g. DB names the base, DB is a top of base, setup file (.ini) has both, a common (known name) folder has all DBs, etc.

6. Dual data bases -- for example "My Music" and "Shared Music" -- displayed by MM with all entries mixed together. Provisions to keep duplicate songs separated (i.e. qualified by DB) and to locate duplicate songs between the two DBs.

7. Identify/prevent overlapping trees between the two DBs, e.g. figure out soft and hard links which put the same song file in both DBs. This prevents a change in one DB from creating a dead link in the other DB as a side effect.

8. Allow overlapping trees between the two DBs and work to avoid dead links (e.g. a delete request warns that the physical song file is still used in another DB).

9. Partial data base export (only selected entries), Multiple imports (merged imports) into a DB.

10. Upgrade dual DB support to multiple (large number) DB support.

Regards,
Jared

[Lowlander]

I don't assume that this will be implemented as there are ways to seperate content in one database. This eliminates the need for multiple databases in the first place.

It seems to be an overly complex solution.

Import/Export probably can be done with m3u playlists.

[Teknojnky]

There is a script to choose the database at startup, but I don't have a link sorry.

[onkel_enno]

http://www.mediamonkey.com/forum/viewto ... 4699#34699

[Jared]

I don't assume that this will be implemented as there are ways to separate content in one database. This eliminates the need for multiple databases in the first place.

It seems to be an overly complex solution.

Import/Export probably can be done with m3u playlists.

Lowlander, thank you for your comments.

The first problem, switching data bases, indeed has a scripted solution. Thank you onkel_enno for the link.



There is an additional desire several people have cited, that is, sharing a database on a network drive. If we are to have reasonable sharing of a common DB, we need UNCs in the data base.

First, sharing a DB between users implies putting the DB on a network location (to make it shareable).

Second, locating songs via the network database means that

1) You use mapped drive letters or you change the DB internals.

2) Songs can't be on any machine's C: drive. YOUR C: drive is not the same as the person who donated the song's C: drive.

3) Ditto for some mapped network folders, like H: for the user's "home" folder.

4) There must be a system of drive letters used. Everyone needs to map everyone else's folders, both local and network, using the same drive letter scheme, or the drive letters in the DB won't be right for everyone.

Every machine must map J: to machine J's local drive, K: to machine K's local drive, X: to user X's network folder, Y: to user Y's network folder, etc.

5) Drive letters shortages come quick with decentralized song locations.

6) Using a centralized song location, i.e. all users copy their songs to the same network folder, leads to conflicts in naming conventions, tagging, etc. which can make management difficult. Not impossible, just a job requiring skill and no mistakes.

(Ditto for using systematic ways of keeping songs separated in the DB. Very doable when you are the only person managing the DB, but a real PITA when lots of cooks get into the kitchen...)


Bottom line: drive letters and a shared DB will grow quickly into a morass.



The solution for the even the simple requirement, i.e. making network sharing of just the DB itself possible, seems to require that the DB stop referencing song locations by drive letter and use UNCs instead. Sharing multiple user's songs via one DB also means UNCs.

The idea of MM supporting shared songs and shared DBs turns out to be a lot larger than the simple "I want to put the DB on a network drive so we all can use it". Following the chain of consequences...



What I've done is try and specify the minimum good solution, which is getting UNCs into the data base.

Then I've tried to break the solution into small steps, the first of which is indeed kludged by a script. But if we don't get to step 5 we won't have a manageable shared MM DB.

And when the DB is shareable, it will only be useful in an environment where all users play nice together, have technical expertise for network file sharing, and are aware of how their actions can affect everyone else.

If trouble comes, the next suggestion will be: "let each user keep their own DB and have MM logically join them together.

That's why steps 6-9 are on the list. Step 10 is where MM network sharing evolves from "a darn good tool for aficionados" into "a salable product from the masses". But I don't want to go there....

I've been there, done that, and my wisdom guided by my experience says that an effective usable database in a networked environment is a non-trivial but certainly doable. Let's try to cost it out and do a "back of the envelope" cost/benefit analysis.


PS: It's a real good thing that it's a .mdb file accessed by JET, MDAC, or SQL. It means the REAL sharing problems, like locking records for update, rolling back transactions, etc. have already been solved.

[Lowlander]

You have one mistaken idea here. MediaMonkey doesn't handle Mapped drives very well so the current advice is to use UNC paths for scanning music. UNC paths amount is limited to what your network supports which is more than the amount of mapped drives.

Anyway my main issue with you idea is that it's too complex (of use to only advanced users and only those who need this solution) to be included in MediaMonkey. A solution through an external application or script would be better in this case.