Re: Re: How to calculate development time?
by Siddartha (Curate) on May 31, 2001 at 20:30 UTC
|
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
| [reply] |
|
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
| [reply] |
|
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
| [reply] |
|
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
| [reply] |
|
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.
| [reply] |
|
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
| [reply] |
|
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
| [reply] |
|
Rollback and atomicity are NOT esoteric concepts.
--
| [reply] |
Re: Re: How to calculate development time?
by Henri Icarus (Beadle) on Jun 01, 2001 at 05:12 UTC
|
After reading this reply, and being a mySQL user, I naturally went to read much of the refered to page (it's very long).
It's a very interesting sequence of posts and responses, not so much because it was in any way conclusive on the "Not MySQL" front but rather because its a good lesson in how things change. It's a conversation that started a year ago and still continues, and shifts subtly as the various systems it discusses have changed over that time. It's also a good lesson in how inteligent people can have radically differing opinions because of the the questions they think are important to ask, and the problems they think are important to solve. I highly recommend it, but again not because it "proves" that MySQL shouldn't be an option. | [reply] |