Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options
 
PerlMonks  

Re: Re: How to calculate development time?

by Siddartha (Curate)
on May 31, 2001 at 20:30 UTC ( #84642=note: print w/ replies, xml ) Need Help??


in reply to Re: How to calculate development time?
in thread How to calculate development time?

Thanks for your comments.

I will seriously consider other options, if I knew what they are. The client is a startup company, so it doesn't have a huge bunch of capital to spend on the site. They also consider advertising to be the one thing to spend most of their money on, not the development of the site. Obviously the site is important to them, or they wont spend such a lot of their startup capital on it. The site will basically be their means of income, so it is a crucial part of the company.

So, why did I decide on Perl and MySQL?

Firstly because I know Perl (a bit at least, and I really don't want to use ASP), and have used MySQL before for other stuff.
It is the cheapest option.
I don't think the client can afford a dedicated server at all.
That basically leaves an ISP.
If anyone knows of a ISP that is not too expensive and lets you install Perl modules etc., then please tell me.
Regarding MySQL: I don't think that the posting of a job on a jobsite is the kind of data that warrants using Oracle etc. I will not use MySQL at all for billing purposes, at the moment I am looking at using an external service like NetBanx, but would appreciate other options.
I am basically looking for a Database that will store data that I can search. A flat file is too much hassle to use. I do think that MySQL is therefor the best option for me.
If however I find an ISP that has another Database and is not too expensive, I would consider it.

I would appreciate it if you can give me concrete reasons why Perl and MySQL would not be a good solution, even if it is hosted on an ISP.

-Siddartha


Comment on Re: Re: How to calculate development time?
Re: Re: Re: How to calculate development time?
by Starky (Chaplain) on May 31, 2001 at 21:36 UTC
    I've used MySQL for websites that get millions of page views involving up to hundreds of millions of queries per month without ever having a problem.

    I should repeat that for emphasis: I've never had a problem. No lost data. No mysterious crashes. Nothing except good performance and reliability. (Performance was about 9 times faster than Oracle by my benchmarks in the application I was running at the time it was ported to Oracle.)

    The link that questioned MySQL as an adequate database and questioned whether it was just waiting to fall apart at the seams because it doesn't have atomicity or rollback obviously was put together by someone totally unfamiliar with its use in a production environment and who seems like they were more concerned with communicating their knowledge of esoteric (but good to know!) database concepts than reality.

    Of course, it doesn't have as many features as Oracle or other large commercial databases, but it sounds like for your needs, it's just what you need.

      I should repeat that for emphasis: I've never had a problem. No lost data. No mysterious crashes. Nothing except good performance and reliability.

      And I know people who become 100 years old while smoking 2 packs of cigarettes and a handful of cigars every day. Never coughed in their lives. But that doesn't mean I'm convinced smoking isn't bad for your health.

      I have been a full-time Sybase DBA. And I have adminned a MySQL server too. I've seen things happening to boxes running my Sybase servers that would corrupt a MySQL database under heavy load, while the Sybase databases recovered flawlessly (that of course doesn't mean you'll never lose or get corrupted data with Sybase) I have turned the key of the wrong box, shutting down a 4 engine database with over 1000 simultanous connections. I've seen brown outs, causing 20 disks to think it's time to spin down while the box itself thinks there's no problem to worry about. I have typoed, deleting vital information in the master database, which I could simply roll back. Can MySQL make a *consistent* dump of a running database? Without referential intrigity or triggers? Can MySQL make incremental dumps? Say, every 15 minutes on a multi-gigabyte server?

      The link that questioned MySQL as an adequate database and questioned whether it was just waiting to fall apart at the seams because it doesn't have atomicity or rollback obviously was put together by someone totally unfamiliar with its use in a production environment and who seems like they were more concerned with communicating their knowledge of esoteric (but good to know!) database concepts than reality.

      Saying that Philip Greenspun is unfamiliar with the reality of using database in a production environment is barely less absurd than saying Larry Wall is unfamiliar with designing computer languages.

      -- Abigail

      I've used MySQL for websites that get millions of page views involving up to hundreds of millions of queries per month without ever having a problem.

      Page views? Great. MySQL is great for read-only databases that don't need any transactional capabilities. As long as you realize that its just a file system with a (very basic) SQL interface, then fine.

      I know of one company doing hight volume credit card transactions that has been using MySQL, and is moving to Oracle because MySQL can't handle the load without corrupting data which is another issue warned about in the article.

      And I hope you never have to back up that database/filesystem while the data is changing :)

      As for other free options, theres PostgreSQL

      Rollback and atomicity are NOT esoteric concepts.

      --

Re: How to calculate development time?
by Abigail (Deacon) on Jun 01, 2001 at 00:07 UTC
    Firstly because I know Perl (a bit at least, and I really don't want to use ASP), and have used MySQL before for other stuff. It is the cheapest option.

    That's not much of an argument, is it? Sure, you don't pay license fees for Perl nor for MySQL. But you don't pay license fees for Java, C or Python either. Nor for Postgres. Note, I am not advocating you should use any of those. But "I have used X and Y, and I don't want to use Z" doesn't make X and Y the cheapest solutions. Development, maintenance, modifications all take time - and people working on them will want to get paid for it. However, I wasn't argueing price.

    I don't think the client can afford a dedicated server at all. That basically leaves an ISP.

    Interesting. You don't even know whether the client can afford a dedicated server, yet you conclude using an ISP is the best option? Sorry to say, but that doesn't sound like you've done much of an investigation. However, there's nothing wrong with using an ISP. But it is wrong to tell your client his best option is to use an ISP that doesn't give you much freedom. If you can't even install modules of your choice, your client is much better off with an ISP that does give your client at least that.

    I don't think that the posting of a job on a jobsite is the kind of data that warrants using Oracle etc.

    Did you ask your client how important they think the data is? Can they afford losing the respect of their customers (the people using the website)? If your client doesn't care about losing the data (resumes, etc), then why are they collecting it in the first place? Is your client planning to make money (directly, or indirectly) with said data?

    I would appreciate it if you can give me concrete reasons why Perl and MySQL would not be a good solution, even if it is hosted on an ISP.

    I didn't say I objected to using Perl. There might be reasons not to use Perl, but your article didn't say (if the application is going to be developed and maintained by a team of 40 Java jocks with no Perl experience, Perl is likely not to be a good choice). I did, however, post a link to a page giving a multitude of reasons not to use MySQL. If those aren't concrete, what reasons are?

    -- Abigail

      Actually, just posting the data--that is, putting it into a simple database for read-only queries--isn't a bad use for MySQL, from what little I know about it.

      But keeping the data that's uploaded is a whole 'nother story. I read that MySQL has been improved in the year since the original article was written, but I wouldn't even think about using it as was for anything critical.

      Update: I spent a little time going through the MySQL manual, and I'm now convinced I wouldn't use it for most purposes. What improvements have been made are minor, from my point of view.

      The idea of having some tables in a large database optimized for speed in read-only access is kind of neat, but I think it'd make more sense to use a proper RDBMS and export such tables into something like MySQL for that access.

      adamsj

      They laughed at Joan of Arc, but she went right ahead and built it. --Gracie Allen

Re: How to calculate development time?
by pmas (Hermit) on Jun 01, 2001 at 03:52 UTC
    Siddharta wrote:

    The client is a startup company, so it doesn't have a huge bunch of capital to spend on the site. They also consider advertising to be the one thing to spend most of their money on, not the development of the site. Obviously the site is important to them, or they wont spend such a lot of their startup capital on it. The site will basically be their means of income, so it is a crucial part of the company.

    Company decided to be cheap on basic mean of income, and instead to spent most of money on marketing? Looks like "get-rich-quick" scheme to me.

    If you decide to go for it, at least get agreement to be paid step-by-step. Protect yourself before possibitity that company will go belly up before you got paid.

    For me is very hard to imagine a situation where I can use database without solid atomic transactions and rollback. If MySQL cannot support rollback, I will avoid using it for important production data even if paid to do so. And in no case for payment & Credit Card processing. Are you looking for troubles?

    You are taking rather big risk, I hope at least your award is worth it. :)

    pmas

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://84642]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (6)
As of 2014-10-02 05:01 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    What is your favourite meta-syntactic variable name?














    Results (49 votes), past polls