MM SQL Server

[lt.col.blair]

Hi,

I know there are other threads regarding MM with SQL Server in Background (mostly concerning MS SQL Express).
Well, I also wish MM would support some SQL Server, though I would prefer MySQL (two users, three opinions <g>), since it supports more platforms.

Reasons for my wish:
My entire library is located on a net storage system (Synology Disk Station). Usually i access it using LAN (100MBit or 1GBit) or WiFi (10-50MBit).
The bandwidths are completely enough to play or add media (music or videos), but organizing the Media-DB is a pain, if the DB resides on the NAS.

Problem with the DB (whether it's Access DB or SQLite) is, that both are designed as desktop databases, so that executing any query involves transferring all data involved through the network - heavy traffic.
With a true SQL server the query is executed on the NAS (or whatever MM Server), and only the results are returned to the client. - Less network traffic, faster responses, well, everything rdb servers were designed for.

The next logical step would be, to store all media in that database, and only extracting those pieces, that you want to transfer to somewhere else e.g. mobile devices. That would save lots of shoving files around.

Even though I already own the Gold edition, those would be features, I would even pay for a second time.

... looking forward to reactions.
Lutz

[Bello]

Hi Lutz,
I totally agree with you.
Espacially accessing with more than one session to the database is very frustrating.

I'm using MM for years and I was glad as the Access database was replaced.
I understood why the programmers decide to use SQLLite, but it would have been more comfortable if the user would have the choice between more different database solutions. As an example with SAM Broadcast you've the choice between Firebirde, MS-SQL and mysql.

[bump]

I'd love to see this too.

All my content is on a central file server. This is already running MySQL for my XBMC clients so to have the feature added for MM would be great.

Hope to see it soon.

[lucinde]

I totally agree.

MySQL support for the database would be brilliant.

With a decent server-client database sharing the library between a PC and laptop at home would be much easier. For the moment I take local copies, but that's just a waste of disk space and effort...

[dannyno]

It would be great to be able to run off a NAS stored mm.db. I gave up trying.

[oldetowne]

It has just become a necessity for me as well. As my library has grown, the amount of time required for a simple insert into the database has become intolerable. I have also added network access for my wife and even the initial connection time to the DB is unacceptable. I was finally forced to transition to an alternate Media Management product that uses MS SQL and was pleasantly surprised by the speed of updates, inserts, and query results that I discovered. As the size and sophistication of collections grows, it is quite obvious that the current DB used by MediaMonkey is very inadequate. Providing a choice seems the best alternative for all users.

[BitPusher]

If MediaMonkey is seriously considering going to a multi-user Client-Server type database system instead of SQLite, I would highly recommend IBM's DB2 Express C for the following major reasons:
1. It has versions that will run on Windows, Linux, and MAC OS X.
2. Unlike SQL Server, there is no database size limitation.
3. Like SQL Server Express, It is free.

Although I have some old applications I wrote that use SQL Server Express, anything new I'm writing is going to be using IBM's DB2 Express C product.

BitPusher

[lt.col.blair]

If MediaMonkey is seriously considering going to a multi-user Client-Server type database system instead of SQLite, I would highly recommend IBM's DB2 Express C for the following major reasons:
1. It has versions that will run on Windows, Linux, and MAC OS X.
2. Unlike SQL Server, there is no database size limitation.
3. Like SQL Server Express, It is free.

BitPusher

I don't know DB2 Express C, but I think the three reasons you mentioned also apply to Firebird SQL, MySQL, PostgreSQL. I just mentioned the MS SQL, since it has been named in other threads too.
Personally I would prefer MySQL (you even have it preinstalled on most web servers) or Firebird SQL (best trigger/procedure language), but for searching or editing the MM database on a network ANY SQL Server would be faster than a desktop database.

[oldetowne]

IBM's DB2 product would seem to be a very viable alternative to MS SQL. I worked for 20+ years on systems employing DB2 and can attest to the robustness and scalability of the product. That being said, I have not been exposed to the Express-C edition. I would have to research its limitations to determine whether it would be an appropriate selection. For those of you looking to products like MYSQL, these are considered limited DB products often poorly leveraging the server or missing key functions compared to the more sophisticated players like DB2 or Oracle (with MS SQL considered a somewhat weaker option). For example; a query request sent to MYSQL would return data to the client over the LAN and run the quesry on the client while in DB2 the query runs on the server and only sends the result subset to the client. I would be interested in hearing from and experienced DB user that has had the time to put DB2 Express-C through its paces.

[lt.col.blair]

For example; a query request sent to MYSQL would return data to the client over the LAN and run the quesry on the client while in DB2 the query runs on the server and only sends the result subset to the client.

The behaviour you describe (first) is exactly that of a so called desktop database (like the SQLite database, MM uses). MySQL is on the contrary a "real" server based database system - just as you describe it for DB2.
Most of thhe limitations of MySQL you seem to have heard of are overcome nowadays. MySQL has a procedure and trigger language and works transaction based.
Some remaining limitations of MySQL may have to do with scalability (like distributing a huge database to several servers etc.), replication and full text search.
All of these are functions, that you don't really need for managing a media db of the size, i suppose, MM users have.
I am sure, that a DB2 database server could do the job of managing a media database very good, but is it freely available for as many operating systems as MySQL or Firebird are?

Yes, we are bound to windows as a client system, when we use MM (which is good as it is), but most NAS systems use some kind of linux.
To store the library and media for MM on such a network drive, it would be best to have a DB server that can be easily installed (or is even pre installed) on such a system.

[Lowlander]

I think user choice is much better. I'd personally want to use MSSQL Server, but MySQL would be a great option for many as many NAS can run MySQL.

[dtsig]

An here it is 2014 and still no real official response from MM. I did ask specifically of developers in a newer thread but of course that was locked quickly. Guess really need to keep old hopes alive <G>.

I can't believe that it would be so hard to move this over to another db (if user wants). We have had to do same before and if done correctly goes pretty easily. My guess is that it would require a complete rework of the bits talking to the db. Too bad really SqlLite is really the weak link to MM

[Lowlander]

I did ask specifically of developers in a newer thread but of course that was locked quickly.

http://www.mediamonkey.com/forum/viewto ... =4&t=40381

I'd really like to see a different database because of multi-user environments. I don't really have an issue with robustness of SQLite, despite doing a lot of things to MediaMonkey the database doesn't fail. Unfortunately few users have requested this (especially since the change from MS Access) so it may not be worth the effort and licensing costs for the developers (keeping fingers crossed).

[Peke]

FYI SQLite also exists on NAS deices too My QNAP NAS supports SQLite without problems. Main issue is Full text search and custom collate function we currently use.

I would be first in a line to move DB natively into NAS as My music is already on there.

[dtsig]

Lowlander and Peke

First, thanks both for the replies.

This is not my first ride in the rodeo (as RovingCowboy might say) so I understand a change like a db could be at worst very complex depending on how the sw is written. If pretty modular then it should not be too big of a problem just possibly time consuming (which can be a problem on its own). Also it does make the support a little more complex with users using different dbs. I also get that most users don't know what is being used and really shouldn't care. At least that is what we tell most of our users.

For me I would really like to access the db (without going through the com) for a web site for streaming. (yes i know there are *addons* to connect but have written/enhanced streaming sites before and don't like closed solutions).

Again I know that this will be/is of limited interest. But hope springs eternal. Thanks again for the replies