I run a small music production and publishing company. We are in need of a very simple database solution that integrates directly with Google Drive. We use Apps for Work.
Spreadsheets are just too unwieldy for what we need to do. Basically we have a bunch of information to track the songs and recorded works of all our producers and composers internally.
Spreadsheets are not the best solution because while there may be one song, there are often multiple versions of the recorded work. They share some data in common but we need to track certain info for the songs themselves (song copyright, authors, co-publishers etc) and other info for the recorded works (producers, master use copyright info, isrc info and use status etc.)
We need to pull info from the dataset based on either a single piece of data (I.e. Title) but also to pull up a listing of all records that are needing isrc assignments for example, or that share a co-publisher, or are affiliated with a particular composer or PRO (performing rights organization) etc.
We also can’t have the entire data set exposed or available. Too much possibly of corruption or mishandling by interns or staff doing data entry or research. Some information is sensitive but mostly it’s too big of a risk of data corruption.
I’ve looked at Forms and also Fusion Tables but they are too complex for our needs (and skillsets).We just need a super simple relational database that we can create custom front end data entry forms and also to execute very simple queries.
It must be cloud based and integrated with drive.
The data sets are neither terribly complex not very large. Simplicity and ease of use are paramount.
MySQL fits all of your requirements. This is the book I used to learn MySQL, and oddly enough most of the examples center around a database for music, so you’ll find some very fitting examples there.
I’d looked at that. We are all music producers and marketing types. We’re all pretty computer savvy but we are not DBAs or coders. I can define exactly what the data is, and also what types of searches we would need to run but we wouldn’t have the first clue how to set it up or administer it. How complex is it? Can it be learned and administered by non-coders/dba’s easily?
Have a look at MySQL Workbench, see if that seems usable to you. Once you’ve built your database structure using that it should be pretty simple to build the interfaces add/query/remove/etc data from the tables you’ve designed.
Or you could always find someone who knows how to make an SQL database and pay them to build out the more difficult parts for you. wink wink, nudge nudge
I think in the interim we’re going to go with Obvibase. It’s not a true DB but does everything we need in the short term, and allows us to easily link records to our Dropbox (where we keep reference media of the audio works) and to our Drive (where we store contracts, catalogs and assignations).
It looks like mySQL is a good longer term solution, when we want to build this out. We have < 2000 records at this time, so mySQL seems overkill. Obvibase will easily handle up to 10k and will easily export when comes time to migrate to a more robust solution.
Thanks for the help, and when we need to build a custom DB solution, we’ll keep you in mind, CB!
Obvibase looks like a pretty good decision for your needs.
With all due respect to CinnamonBabka, you dodged a bullet not trying to build something complex on your own. Earlier this year I rebuilt a relatively simple Web application for a national non-profit group. They had let a amateur self-taught programmer build and maintain an ‘application’ (using mysql coincidentally) for years until their workflow became so sclerotic they gave in and had it rebuilt.
Even ditching every bit of his source code and starting over, we had to charge over $15,000 just cleaning up their data to a point we could build an application that could meet their requirements. Their data is more complicated than yours but frankly it should’ve been pretty simple. Initial bad design choices were made worse as he tried to fix them over the years.
I’m sure the guy had the best intentions but unfortunately when you don’t know what you’re doing you have no way of knowing just how much trouble your mistakes are going to create down the line.
I don’t think it was ever very well designed, but the fundamental problem began when they needed to go from salaried employees modifying the database, to letting members of the public submit new information or updated information, which required review by the right staff member. The staff needed to be able to accept/reject/modify submissions as well as continue to be able to make changes directly.
The updates and new data had pretty much always come from the general public, but initially they would call or e-mail or even mail or fax changes and an employee would approve and key them in. So letting the public enter changes online theoretically should’ve saved a whole lot of time. Unfortunately his implementation of the revision / approval system was very poorly done and by the time we were involved there wasn’t really anyone who had any idea how it was supposed to work or why certain things were done. You can probably imagine how confusing it would be to work with a database where there were multiple copies of data in various tables and no reliable way to determine what any of it was supposed to mean.