You've all made great points and I'm sure that I'll follow the advice
given but I'll ask you to indulge me just a bit more.
Chris, you've almost convinced me, but I have to ask, is it really so
inefficient to search through one directory with 5000 sub-directories
to find one that matches the (user) name your looking for? Isn't that
what Perl is supposed to be good at?
If you had 100,000 directories you could alphabetize and place them in
sub-directories that would hold, on average, less than the 5000
mentioned above.
If each directory held 2000 files and you know the name of the one your
looking for, it should take half as long to find the file as the
directory it resides in. If only one user can access the files in their
directory than locking files and race conditions aren't even an issue.
Even if you searched for a string to match in each of these 2000 files
would it take unbearably long?
It occurs to me that the unix os is basically a database in and of
itself and perl interacts directly with the os, therefore, using it to
store and retrieve data may not be that inefficient.
Now, if you have one server dedicated to serving only 2500 users and in
2-3 years you have 5000 users and upgrade that server to one twice as
fast and big, and so on....
The main disadvantage of using a database engine like MySQL is that
users cannot define data fields. If other applications are going to
access the data in question than you must reformat it to provide the
access. And again, I'm lazy (actually, I have other things I like to
do) and really don't want to learn more. I'd rather use what I already
know and leverage what I already have.
If Rick's "Dream" comes true I can just port the data at that time.
There are a lot of programmers out there working on faster, easier to
use, database engines that have more features. Chris, you may be right,
XML may be a fad, but the next big thing in data storage/retrieval
could be right around the corner too.
The above are some of the excuses I've come up with to avoid spending
more time learning stuff. If I'm deluded, it's because I have boxes
upon boxes of software that doesn't work anymore and time invested in
each of them. It's not that I don't believe that MySQL and other
database engines have a place, I'm just trying to avoid learning how to
use them if I don't really need too.
If no one here still believes that computers will soon be fast enough
to write slugware like I mention above, then I'll start cracking the
books.
Kindest Regards,
Bill Stephenson
- Re: [OT] MySQL for Web Apps Ian Ragsdale
- Re: [OT] MySQL for Web Apps kynan
- Re: [OT] MySQL for Web Apps Rick Measham
- Re: [OT] MySQL for Web Apps Chris Devers
- Re: [OT] XML in SQL (was: MySQL for Web Apps) Rick Measham
- Re: [OT] XML in SQL (was: MySQL for Web A... Rick Measham
- Re: [OT] XML in SQL (was: MySQL for ... Chris Devers
- Re: [OT] XML in SQL (was: MySQL ... Rick Measham
- Re: [OT] MySQL for Web Apps Rick Measham
- Re: [OT] MySQL for Web Apps Chris Devers
- Re: [OT] MySQL for Web Apps Bill Stephenson
- Re: [OT] MySQL for Web Apps Ian Ragsdale
- Re: [OT] MySQL for Web Apps Pete Prodoehl
- Re: [OT] MySQL for Web Apps Chris Devers
- Re: [OT] MySQL for Web Apps Matthew Montano
- Re: [OT] MySQL for Web Apps Conrad Schilbe