This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
To: sfpug@sf.pm.org From: Michael Budash <mbudash@sonic.net> Subject: Re: [sf-perl] Boolean Search for MySQL Date: 1 Dec 2001 23:48:44 -0800 On Sat, 01 December 2001, David Fetter wrote: > > On Fri, Nov 30, 2001 at 12:14:24PM -0800, Mike Fleisher wrote: > > It seems like someone must have written some boolean search > > logic for a DBI database. > > It's called 'OR' and 'AND' both of which are implemented in even the > most pathetic, braindead excuse for a misbegotten attempt at an RDBMS, > which is to say that they work for MySQL :) could be in the translation from thai to english, but... are you actually calling mysql "the most pathetic, braindead excuse for a misbegotten attempt at an RDBMS"?? do you always make such blanket statements? in my opinion, you are flat out wrong. there are better rdbms's in many functional areas (transactions, subselects, triggers, etc.), but mysql is more than adequate for a huge portion of applications out there. > > I'm not sure exactly how this would work, but it seems like > > I should be able to instantiate an object, set some member > > variables with the names of the DB fields I want to search, > > pass a reference to the boolean search, and have the object > > build me a SQL string to pass to DBI. > > Instantiate? Object? Reference? WTF? > > Dude, the appropriate thing to do is learn SQL :) > > Anyhoo, have fun, check out PostgreSQL, and greetings to everyone from > sunny Bankok, Thailand. for a fuller comparison between mysql and postgresql, see, for example: http://www.mysql.com/doc/M/y/MySQL-PostgreSQL_features.html , and http://www.phpbuilder.com/columns/tim20000705.php3?page=1 === To: sfpug@sf.pm.org From: Star Morin <shift8@dnai.com> Subject: Re: [sf-perl] Boolean Search for MySQL Date: Sun, 02 Dec 2001 12:28:12 -0800 David Fetter wrote: >On Fri, Nov 30, 2001 at 12:14:24PM -0800, Mike Fleisher wrote: > >>It seems like someone must have written some boolean search >>logic for a DBI database. >> > >It's called 'OR' and 'AND' both of which are implemented in even the >most pathetic, braindead excuse for a misbegotten attempt at an RDBMS, >which is to say that they work for MySQL :) > >>I'm not sure exactly how this would work, but it seems like >>I should be able to instantiate an object, set some member >>variables with the names of the DB fields I want to search, >>pass a reference to the boolean search, and have the object >>build me a SQL string to pass to DBI. >> > >Instantiate? Object? Reference? WTF? > >Dude, the appropriate thing to do is learn SQL :) > >Anyhoo, have fun, check out PostgreSQL, and greetings to everyone from >sunny Bankok, Thailand. be it that the original poster didn't properly describe his problem or be it that he hasn't researched his topic enough, that's no excuse for you making the list an inhospitable place to ask questions. that was lame. ps. even with the cheap traveling costs of arround 40 baht to the us $, you might want to save some of that traveling money for the job search you have comming when you get back :) peas-out === To: sfpug@sf.pm.org From: Vicki Brown <vlb@cfcl.com> Subject: Re: [sf-perl] Boolean Search for MySQL Date: Mon, 3 Dec 2001 12:57:22 -0800 At 23:48 -0800 12/1/01, Michael Budash wrote: >could be in the translation from thai to english, but... are you actually >calling mysql "the most pathetic, braindead excuse for a misbegotten attempt >at an RDBMS"?? do you always make such blanket statements? in my opinion, >you are flat out wrong. there are better rdbms's in many functional areas >(transactions, subselects, triggers, etc.), but mysql is more than adequate >for a huge portion of applications out there. MySQL may well be "more than adequate for a huge portion of applications out there" but apparently that still does not quality it to meet the definition of an RDBMS. Or so I am told. http://openacs.org/philosophy/why-not-mysql.html (As former listmom, I ask everyone to please use caution in these discussions. Namecalling and strongly opinionated language _MAY_ be acceptable when used against large corporations, languages, and large packages (especially if you can back up your opinions with facts). Namecalling is never acceptable if used against people or small programs as written by said people.) === To: sfpug@sf.pm.org From: Michael Budash <mbudash@sonic.net> Subject: Re: [sf-perl] OT: MySQL (was: Boolean Search for MySQL ) Date: 3 Dec 2001 13:54:45 -0800 On Mon, 03 December 2001, Vicki Brown wrote: > > At 23:48 -0800 12/1/01, Michael Budash wrote: > >could be in the translation from thai to english, but... are you actually > >calling mysql "the most pathetic, braindead excuse for a misbegotten attempt > >at an RDBMS"?? do you always make such blanket statements? in my opinion, > >you are flat out wrong. there are better rdbms's in many functional areas > >(transactions, subselects, triggers, etc.), but mysql is more than adequate > >for a huge portion of applications out there. > > MySQL may well be "more than adequate for a huge portion of applications out > there" but apparently that still does not quality it to meet the definition > of an RDBMS. Or so I am told. > > http://openacs.org/philosophy/why-not-mysql.html > great link, vicki, and the back-and-forth discussion at the bottom of the page shows just what kind of a discussion *this* one could turn into... we as pros should certainly know that there is no single tool that is always "right" for the job. we need to know each tool's strengths and weaknesses. we all know where mysql is weak, and in some cases, those weaknesses simply do not matter. in that light, i will not summarily rule mysql out as one possible solution. === To: sfpug@sf.pm.org From: Rick Moen <rick@linuxmafia.com> Subject: Re: [sf-perl] OT: MySQL (was: Boolean Search for MySQL ) Date: Mon, 3 Dec 2001 22:13:09 -0800 begin Michael Budash quotation: > great link, vicki, and the back-and-forth discussion at the bottom of > the page shows just what kind of a discussion *this* one could turn > into... Both projects have come a long ways since that page went up. I find both useful, though I've used PostgreSQL more. Tim Perdue (designer of SourceForge) posted a slightly more current comparison -- http://www.phpbuilder.com/columns/tim20001112.php3 -- but it's still a year out of date. === To: sfpug@sf.pm.org From: Paul Makepeace <Paul.Makepeace@realprogrammers.com> Subject: Re: [sf-perl] Boolean Search for MySQL Date: Mon, 3 Dec 2001 22:48:06 -0800 On Mon, Dec 03, 2001 at 12:57:22PM -0800, Vicki Brown wrote: > MySQL may well be "more than adequate for a huge portion of applications out > there" but apparently that still does not quality it to meet the definition > of an RDBMS. Or so I am told. Wait, I store all my date in a big text file in a hidden directory under htdocs and then use perl and regexes inside my CGI script. Is that not how people do things any more? === To: sfpug@sf.pm.org From: David Fetter <david@fetter.org> Subject: Re: [sf-perl] OT: MySQL (was: Boolean Search for MySQL ) Date: Tue, 4 Dec 2001 00:36:47 -0800 On Mon, Dec 03, 2001 at 10:13:09PM -0800, Rick Moen wrote: > begin Michael Budash quotation: > > > great link, vicki, and the back-and-forth discussion at the bottom of > > the page shows just what kind of a discussion *this* one could turn > > into... > > Both projects have come a long ways since that page went up. True. PostgreSQL has implemented transactions, souped up their engine speed to an amazing degree, worked out bugs everywhere people cared. MySQL has said a lot--the hype could only compare to certain outfits in Redmond, WA, and added a choice of back-ends, none of which do foreign keys. This lack makes it a non-starter for any data whose consistency you care about. Put it this way...I'd recommend SQL Server from EvilEmpire over it. Come to think of it, I'd recommend Access over it. It's that bad. === To: sfpug@sf.pm.org From: Rick Moen <rick@linuxmafia.com> Subject: Re: [sf-perl] OT: MySQL (was: Boolean Search for MySQL ) Date: Tue, 4 Dec 2001 08:39:40 -0800 begin David Fetter quotation: > True. PostgreSQL has implemented transactions, souped up their engine > speed to an amazing degree, worked out bugs everywhere people cared. > MySQL has said a lot.... At the very minimum, one should strongly consider MySQL (on performance grounds) for sites that ordinarily do lookup only, e.g., for my http://linuxmafia.com/bale/ calendar page. I actually started converting that to PHP4 + MySQL, but decided I really liked PostgreSQL a great deal for all sorts of reasons, and so am shifting to that. Another thing that's changed lately is a couple of good books on PostgreSQL are finally emerging, notably this one, available both in print and on-line: PostgreSQL: Introduction and Concepts, by Bruce Momjian http://www.ca.postgresql.org/docs/aw_pgsql_book/ Recommended. Perl-based access software includes: Perl DBI, mod_perl, CGI.pm (though I haven't had occasion to try any of those). === To: sfpug@sf.pm.org From: Joe Brenner <doom@kzsu.stanford.edu> Subject: Re: [sf-perl] OT: MySQL (was: Boolean Search for MySQL ) Date: Tue, 04 Dec 2001 10:39:19 -0800 Rick Moen <rick@linuxmafia.com> wrote: > Another thing that's changed lately is a couple of good books on > PostgreSQL are finally emerging, notably this one, available both in > print and on-line: > > PostgreSQL: Introduction and Concepts, by Bruce Momjian > http://www.ca.postgresql.org/docs/aw_pgsql_book/ At the last Perl meeting, Rich Morin was showing of a set of Postgresql books put together from the on-line docs. I don't see them up on the "Prime Time Freeware" web-site yet though: http://ptf.com/ptf/ > At the very minimum, one should strongly consider MySQL (on performance > grounds) for sites that ordinarily do lookup only, e.g., for my > http://linuxmafia.com/bale/ calendar page. But it's interesting that when Great Bridge (the late Postgresql support company) paid someone to do benchmarks of various databases [1], postgresql actually beat MySQL in a read-only test. (If you're sneering "well they were paid by postgresql people, so they must have been biased", you should consider that most people base their opinion of MySQL almost entirely on the material posted on the MySQL website. ) Now, there were the usual complaints about how the MySQL set-up they were using wasn't "tuned" correctly. But at the very least this would seem to indicate that if you don't have a crack MySQL DBA on staff, you might not even get decent read-mostly performance out of it. (And read-mostly performance is all you're likely to get, because it does *table-level locking* on inserts.) Postgresql news: the 7.2b3 release (i.e. "the third beta") is out. Version 7.2 eliminates the table-lock from the VACUUM process, meaning you can run 24/7 with the new postgresql without any hassle. === To: sfpug@sf.pm.org From: Vicki Brown <vlb@cfcl.com> Subject: Re: [sf-perl] OT: MySQL (was: Boolean Search for MySQL ) Date: Tue, 4 Dec 2001 11:07:04 -0800 At 10:39 -0800 12/4/01, Joe Brenner wrote: > >At the last Perl meeting, Rich Morin was showing of a set of >Postgresql books put together from the on-line docs. >I don't see them up on the "Prime Time Freeware" web-site >yet though: > > http://ptf.com/ptf/ They'll be there when some tuits come in. He's still working on the web site; out of town this week "launching" the DOSSIER series at the LISA conference in San Diego. There would have been a MySQL set too but it turns out the docs are not GPL'd (only the code) :-( === To: sfpug@sf.pm.org From: Joe Brenner <doom@kzsu.stanford.edu> Subject: Re: [sf-perl] OT: MySQL (was: Boolean Search for MySQL ) Date: Tue, 04 Dec 2001 10:59:54 -0800 Joe Brenner <doom@kzsu.stanford.edu> wrote: > At the last Perl meeting, Rich Morin was showing of a set of > Postgresql books put together from the on-line docs. > I don't see them up on the "Prime Time Freeware" web-site > yet though: > > http://ptf.com/ptf/ Ah, found 'em: http://ptf.com/ptf/dossier/sets/Post.shtml === To: sfpug@sf.pm.org From: Rick Moen <rick@linuxmafia.com> Subject: Re: [sf-perl] OT: MySQL (was: Boolean Search for MySQL ) Date: Tue, 4 Dec 2001 16:43:35 -0800 begin Joe Brenner quotation: > But it's interesting that when Great Bridge (the late > Postgresql support company) paid someone to do benchmarks of > various databases [1], postgresql actually beat MySQL in a > read-only test. Interesting indeed. I'd forgotten about that. I do recall that one of the ways PostgreSQL has been improved most dramatically, over the last few years, has been in performance. I've personally been very happy with it, but never trid to compare recent versions toe-to-toe. This highlights one drawback of many well-worn debates on the Net: They're usually based on old data. > Postgresql news: the 7.2b3 release (i.e. "the third beta") > is out. Version 7.2 eliminates the table-lock from the > VACUUM process, meaning you can run 24/7 with the new > postgresql without any hassle. Ah! Now, that is even more welcome news. === To: sfpug@sf.pm.org From: David Fetter <david@fetter.org> Subject: Re: [sf-perl] OT: MySQL (was: Boolean Search for MySQL ) Date: Tue, 4 Dec 2001 20:29:39 -0800 On Tue, Dec 04, 2001 at 08:39:40AM -0800, Rick Moen wrote: > begin David Fetter quotation: > > > True. PostgreSQL has implemented transactions, souped up their engine > > speed to an amazing degree, worked out bugs everywhere people cared. > > MySQL has said a lot.... > At the very minimum, one should strongly consider MySQL (on performance > grounds) for sites that ordinarily do lookup only, e.g., for my > http://linuxmafia.com/bale/ calendar page. This is a great resource for Linux and other Free software stuff in the Bay Area :) As somebody else mentioned, even the performance gain is at best not as big as it appears to be. One common reason for people's using MySQL is that it's available through their hosting providers, who are...not always up to speed when you mention PostgrSQL. Luckily PostgreSQL is an easier sell vs. MySQL than Linux vs. M$ used to be :) > Another thing that's changed lately is a couple of good books on > PostgreSQL are finally emerging, notably this one, available both in > print and on-line: > > PostgreSQL: Introduction and Concepts, by Bruce Momjian > http://www.ca.postgresql.org/docs/aw_pgsql_book/ Also good is, oddly enough, Oracle: The Complete Reference from Oracle Press. ===