Welcome to the MacNN Forums.

starman · May 10, 2004, 09:22 AM

Hi all,
Without disclosing what I'm working on, I'd like to get some advice on this issue I know I'm going to run into. The app is going to access a secure MySQL database. The problem is that if this app takes off, the SQL server's going to need to serve a wicked amount of data. Once the user gets the data, it will be stored on their hard drive locally, but there will still be a need for updates on a regular basis.

My issues are:

1) Management. This isn't going to be something I'll want to do full time.
2) Cost. At some point I'll have to charge for this and roll the costs into the bandwidth cost. I'm not sure how to factor that since I don't know how many users there will be. The actual amount of data per db item isn't that much, but when you multiply it, it could get pretty nasty.
3) A good provider for the database. I use GoDaddy now for my personal stuff, but they might not be the best solution for the long-term haul.

So I'm looking at how practical this whole thing is. I can't go into the details right now, but it is something that Mac users have wanted for a while and I'd really like to make it work.

There is a Windows version, but they refuse to support the Mac so I'm doing this on my own. I think I might be in over my head, though.

Mike

Moose · May 10, 2004, 09:57 AM

Sure.

starman · May 10, 2004, 11:03 AM

Originally posted by Moose:
Sure.

That was constructive

Moose · May 10, 2004, 11:30 AM

Originally posted by starman:
That was constructive

"I cannot tell you much about what I am planning to do, but I need to know if it is feasible."

You asked a very vague question. What exactly were you expecting in terms of a reply?

starman · May 10, 2004, 11:42 AM

Originally posted by Moose:
"I cannot tell you much about what I am planning to do, but I need to know if it is feasible."

You asked a very vague question. What exactly were you expecting in terms of a reply?

Just because I didn't say WHAT I was making doesn't mean everything ELSE isn't valid.

It wasn't vague at all....what kind of issues will I have with a massive SQL-based app in terms of management and pricing?

How about that?

Smartass remarks belong in the Lounge.

Mike

tipp-ex · May 10, 2004, 01:35 PM

Surely if your database structure is well thought out and you have plenty of error checking then the only issues with a big database are the size (and thus webspace) and bandwidth costs. Then again depends on what you're storing

Check www.segpub.com.au * to get an idea of what you can get for your money, then do some sums.

I'm not an expert either, so take this how you will.

* or any other amazing and good value for money hosting provider supporting MySQL.

mitchell_pgh · May 10, 2004, 03:13 PM

Perhaps if you could make a comparison to another application unlike the one you are working on...

mitchell_pgh · May 10, 2004, 03:14 PM

Are you talking about old school Napster level servers?

eyadams · May 10, 2004, 03:34 PM

It wasn't vague at all....what kind of issues will I have with a massive SQL-based app in terms of management and pricing?

No, it's still vague. Let's look at your issues one by one.

1) Management.

The only database that doesn't require active, daily management is the kind that isn't being used. Since you indicate that you're going to be moving a lot of data around, at the very least you're going to have to monitor how much disk space is being used. You'll also have to monitor things like the size of indexes, since frequent inserts and deletes will make indexes grow and grow. It is fairly common for an index to grow to twice the size of the data itself.

If you're not watching it, someone else will have to.

2) Cost.

How much you want to charge and how much people are willing to pay is entirely up to the nature of the application, and you have not given nearly enough information to guess. Lexis Information Services charges $150 per search to get an unlisted phone number with address; iTunes is only $.99 per song, with unlimited searches. If your application is targetted at people with lots of money who are used to paying for expensive stuff, you can charge a lot. If your application is targetted at people who are used to getting things for free, you won't be able to charge much, if anything.

The only concrete advise I can provide for this is to look at similar services and see what they charge. Could you charge less? Is your product better enough that people will pay more for it? You'll have to judge.

3) A good provider for the database.

I have no good answer for this. If you ultimately decide that the only decent provider is you, you could go anywhere between "free, if your time is worthless" and a quarter of a million dollars up front costs and tens of thousands of dollars in operating costs.

Is any of this helpful?

mindwaves · May 10, 2004, 04:29 PM

Please stay on topic. Thanks.

theolein · May 10, 2004, 10:13 PM

Originally posted by starman:
Hi all,
Without disclosing what I'm working on, I'd like to get some advice on this issue I know I'm going to run into. The app is going to access a secure MySQL database. The problem is that if this app takes off, the SQL server's going to need to serve a wicked amount of data. Once the user gets the data, it will be stored on their hard drive locally, but there will still be a need for updates on a regular basis.

My issues are:

1) Management. This isn't going to be something I'll want to do full time.
2) Cost. At some point I'll have to charge for this and roll the costs into the bandwidth cost. I'm not sure how to factor that since I don't know how many users there will be. The actual amount of data per db item isn't that much, but when you multiply it, it could get pretty nasty.
3) A good provider for the database. I use GoDaddy now for my personal stuff, but they might not be the best solution for the long-term haul.

So I'm looking at how practical this whole thing is. I can't go into the details right now, but it is something that Mac users have wanted for a while and I'd really like to make it work.

There is a Windows version, but they refuse to support the Mac so I'm doing this on my own. I think I might be in over my head, though.

Mike

I have to second the opinion that you have given a bit too little information to really offer useful advice.

1. If you have your MySQL skills down really pat, you could certainly automate a lot of the backup, replication, cleanups etc. But you will have to have someone who at least can keep an eye on this if you expect to charge for it. Users getting errors because the database is down would be upset if there was no one to call or mail for support.

2. and 3. Your best bet would be a managed colocation server. These are expensive but it would be the very least you could do with if you have paying users. Your real problem is obviously bandwidth if there turn out to be very many concurrent users. They could obviously overload your average server in no time. The actual use, of course, is something you'll only know when you actually start selling your product. Not having a clue as to what kind of product this could be (The one thing really missing for macs is groupware, calendaring etc) I can't really say what would be the best initial approach. My advice is that you design your application so that it can scale well, and then start off small, and if you're lucky, grow by hiring more colocated servers as your user base grows.

An alternative, of course, would be to sell the server application to companies, if it is that type of application, as that would save you the hassle of being overburdened by too many users.

mitchell_pgh · May 10, 2004, 11:10 PM

Please tell me it's a program that will clean up my iTunes library with high quality artwork etc. etc. etc.