It would be initially quite small, but could grow pretty quickly. Furthermore, it would be nice if I had file storage.

So, ok, I should probably just give y'all parameters, eh?

I want to build a two-pronged songwriter database/app. On the one side would be A&R type analysis. I'd keep track of which writers are writing which songs for which artists, and then track how those songs do in the charts. Ideally I'd build out from there, so that eventually I'd have the data that showed me everything from what range an artist sings in, to who's in his camp in a variety of positions, to what tempo/topic etc. his songs are. This prong is market research for song pitching, basically. I could eventually pull in social media and other elements to track which smaller acts are likely to rise, etc.

The second prong is song management. So then I know who I want to pitch to and what they're looking for these days. I know when their last album came out and what the average time between albums was so I know if they're likely in the studio or not.

So then I have to manage my own writing. I need to know what songs I have, again in what tempo's, etc. If they've been pitched, and to whom (so I need publishers, music supervisors, etc. in the mix) and what their status is. Who my cowriters and producers are. Then the document storage portion comes in, and I would probably do this leg last because there are other ways to deal with this out there right now. It's just that there isn't anything all together like this. So I'd eventually want to be able to store lyric sheets, legal documents like split sheets, work-for-hire statements, contracts. Plus maybe eventually the music itself. So, .mp3s probably initially, but later, I'd want to store the pro tools projects, or at least the stems, which would be heavy heavy amounts of data.

Then I would want to be able to query across the two sides to match up artists' needs with my work.

So, ambitious, but I think I could chunk it and work on little bits. I know Access & SQL but from waaay back, so I'd need to get current even there.

You probably don't want to store documents and projects in the database itself. It's probably more efficient to store them as individual files in their own area, with links or addresses to the files stored in the database.

You're gonna want to go with some flavor of SQL for the kinds of queries you're gonna need, but with the documents and mp3s and such you may want to think about a web front end, with some Access forms for the administrative stuff.

(It really has been a while. It took me a minute to come up with the word "queries" for what I was trying to express. Yeesh!)

Yeah, that sounds about right.

I'm probably go with MySQL or Postgres for the database as they are free and good and easy to set up. MySQL has a program called MySQL Workbench that makes managing the database pretty easy.

Libreoffice base (also free) might make a okay front end, but I haven't used it. A web-based front-end would be best but that involves a fair bit of coding.

Right now I'm working on a project for my Wife's upcoming study that uses a MySQL database, PHP for server-side endpoints, and Angular2 + Bootstrap for the web front end. I could share some code to help you with a jumping off point, but I've just started it so I don't have much yet.

At work, we use a Cassandra database, a made-from-scratch server for endpoints, and mobile apps. So I know that stuff pretty well too, but that's way overkill made to handle millions of users.

I agree with DX that you probably just want to link to files. There are NoSQL databases that deal well with storing documents, but SQL will be easier to work with. SQL databases can be harder to scale but that's not a concern here.

That would be fantastic, Gud.

My market wouldn't ever hit millions of users, but I think there is a reasonably sized songwriter market out there that might bite, if I got it off the ground beyond, hey this sure is nice for me. I would have to give some thought to the ins & outs of monetization at that point, though, because the bit that makes it valuable is also sort of sensitive data, and I'm not sure how well the labels would take to me encroaching on their ground, even if I am using all publicly available info. And I guess I'd need to figure out how I'd scale once I got to that point.

Linking to files is fine. It's more just that I need to have one place I know I can go to in a hurry to get the right info in a predictable format. I mean, I need to do that sort of data organization work on my side anyway, regardless of how I access it, so that's probably just a project on its own.

Ok, thanks a lot, guys, this gives me a good point to get researching on. It'll be fun to get my code feet wet again.

Cool. I'm sorting out authentication on the front-end right now. Once that's in order I can shoot some code your way.

Perfect. I really appreciate it.

Not quite sure if this is the best place to ask...but I need some advice on buying walkie talkies. I am one of the coordinators of our Good Ole Fashioned Hoedown at the stables in April. We want to get 4 units so that we can communicate easier. The longest distance is about a mile over hilly terrain and a few buildings.

We need something that is reasonably priced but reliable. Any tips?

Hey Liese,

What I'll probably do is create a project on GitLab with a generalized version of what I'm doing for this study. I still have a bit to work out before I can get there though.