Use PostgreSQL
-
MySQL is not SQL92 compliant, and doesn't support transactions. If you have problems with it, then you were adequatly warned by me and you deserve what you get. PostgreSQL has a long history dating back to the mid-eighties at the University of California at Berkely.
-
MySQL is not SQL92 compliant, and doesn't support transactions. If you have problems with it, then you were adequatly warned by me and you deserve what you get. PostgreSQL has a long history dating back to the mid-eighties at the University of California at Berkely.
And what if you don't need transactions, and don't give a damn about SQL92 compliancy? ;P I vote pro drink :beer:
-
And what if you don't need transactions, and don't give a damn about SQL92 compliancy? ;P I vote pro drink :beer:
Nemanja Trifunovic wrote: And what if you don't need transactions, and don't give a damn about SQL92 compliancy? Then you should be fired because you are not qualified to do your job. :-D
-
Nemanja Trifunovic wrote: And what if you don't need transactions, and don't give a damn about SQL92 compliancy? Then you should be fired because you are not qualified to do your job. :-D
Martin Marvinski wrote: Then you should be fired because you are not qualified to do your job LOL :) However, there are cases when you really don't need transactions (read-only databases) and then MySQL can be a solution. I vote pro drink :beer:
-
And what if you don't need transactions, and don't give a damn about SQL92 compliancy? ;P I vote pro drink :beer:
-
MySQL is not SQL92 compliant, and doesn't support transactions. If you have problems with it, then you were adequatly warned by me and you deserve what you get. PostgreSQL has a long history dating back to the mid-eighties at the University of California at Berkely.
-
I agree, PostgreSQL rocks. If you're using mySQL then you're probably working for chump change on a trivially simple website at a two-bit operation.
But MySQL has a cute little dolphin!
-
Martin Marvinski wrote: Then you should be fired because you are not qualified to do your job LOL :) However, there are cases when you really don't need transactions (read-only databases) and then MySQL can be a solution. I vote pro drink :beer:
That doesnt mean you'll NEVER need it. often-times when I go upgrading old stored procedures, I spot many places where transactions are the only way to go. I cant even imagine what I would use a database engine that didnt support sprocs and transactions for... What use is it? may as well use a flat file without those features.
-
I agree, PostgreSQL rocks. If you're using mySQL then you're probably working for chump change on a trivially simple website at a two-bit operation.
You mean a trivially simple site like www.slashdot.org? Todd Smith
-
I agree, PostgreSQL rocks. If you're using mySQL then you're probably working for chump change on a trivially simple website at a two-bit operation.
Perhaps I should talk our bus. partner into looking into it. *sigh* I am stuck in a pickle. I have my complaints about how we run or operation. Such as the Data Server is too small or I need more mem allocated for SQL Server... But I wasn't ready for what happened when I sat own with them. They basically wanted live (to the second) auction data and stats on thier site. "Not a problem." I thought and my mind raced with the possiblities of web services or SQL replication down to a simple .js file sitting somewhere. As I got specs the clouds began to settle. They will not "punch" a hole in their firewall so a SQL replication was out. Then I found out they are running MySQL. So I suggested a web service. Thier director jumped on that one about concerned about security. (shush guys...not a word) I tried to convience them that it was all safe and fine. Anyway to make a long story short if your running Apache, MySQL on a linux box, admit that you're on a shoestring budget and would like to atleast look like your in the mainstream. :-D Thanks for the idea all. :cool: ===================================== Real programmers don't document. If it was hard to write, it should be hard to understand.
-
You mean a trivially simple site like www.slashdot.org? Todd Smith
Nono, I think he means a trivially simple site like http://www.microsoft.com/ hehe. :-)
-
I agree, PostgreSQL rocks. If you're using mySQL then you're probably working for chump change on a trivially simple website at a two-bit operation.
Ok, there is a definite leaning to PostgreSQL here. Can you comment on this article? http://www.phpbuilder.com/columns/tim20000705.php3 Now for my usage I am just needing something on my local machine to test with. My local database is never left up for more than a few hours and I am often cleaning it out and doing a reload of data with SQL statments from what ever sources. Do you really feel for this usage PostgreSQL is that much better? Especially when I see figures to 2 to 3 better performance for MySQL? Just asking given this thread exists. To be conscious that you are ignorant of the facts is a great step towards Knowledge. Benjamin Disraeli
-
MySQL is not SQL92 compliant, and doesn't support transactions. If you have problems with it, then you were adequatly warned by me and you deserve what you get. PostgreSQL has a long history dating back to the mid-eighties at the University of California at Berkely.
Good grief Martin! Those are typical storybook reasons that you've probably read somewhere on a post and haven't drawn the first conclusion from actual experience outside of tinkering around with it. For one, not being SQL92 compliant is almost a joke. Here's a list of the very few differences... http://www.mysql.com/doc/D/i/Differences_from_ANSI.html For two, a well constructed app can get by without the use of transactions. They are part of the DBMS to make life easier on the coder, but support was left out because the intent of MySQL was speed. MySQL is several times faster than Postgres. Also, wait until 4.x when transaction support is there and it's still gonna be a lot faster than Postgres. Now, will you hear me saying don't use Postgres? Not really, but I much more prefer MySQL. Jeremy Falcon Imputek
-
MySQL is not SQL92 compliant, and doesn't support transactions. If you have problems with it, then you were adequatly warned by me and you deserve what you get. PostgreSQL has a long history dating back to the mid-eighties at the University of California at Berkely.
Martin Marvinski wrote: PostgreSQL has a long history dating back to the mid-eighties at the University of California at Berkely No, you're thinking BerkleyDB which Postgres happens to support. Guess what Sherlock? MySQL supports it too. Jeremy Falcon Imputek
-
MySQL is not SQL92 compliant, and doesn't support transactions. If you have problems with it, then you were adequatly warned by me and you deserve what you get. PostgreSQL has a long history dating back to the mid-eighties at the University of California at Berkely.
Martin, from experience we've found postgres to be good for small amounts of data, but when the db gets bigger and bigger postgres gets slower and slower and sometimes even crashes [this is all on Redhat linux 7.x] Nish
Author of the romantic comedy Summer Love and Some more Cricket [New Win] Review by Shog9 Click here for review[NW]
-
Martin, from experience we've found postgres to be good for small amounts of data, but when the db gets bigger and bigger postgres gets slower and slower and sometimes even crashes [this is all on Redhat linux 7.x] Nish
Author of the romantic comedy Summer Love and Some more Cricket [New Win] Review by Shog9 Click here for review[NW]
Nishant S wrote: Martin, from experience we've found postgres to be good for small amounts of data, but when the db gets bigger and bigger postgres gets slower and slower and sometimes even crashes I don't know alot of my tables are over 200MB, and if I try to import one into Access 2000 via ODBC it crashes Access. I haven't noticed any slow down either. I think your DB is poorly designed and/or not properly optimized. Even Oracle sucks if your DB design is flawed.
-
Good grief Martin! Those are typical storybook reasons that you've probably read somewhere on a post and haven't drawn the first conclusion from actual experience outside of tinkering around with it. For one, not being SQL92 compliant is almost a joke. Here's a list of the very few differences... http://www.mysql.com/doc/D/i/Differences_from_ANSI.html For two, a well constructed app can get by without the use of transactions. They are part of the DBMS to make life easier on the coder, but support was left out because the intent of MySQL was speed. MySQL is several times faster than Postgres. Also, wait until 4.x when transaction support is there and it's still gonna be a lot faster than Postgres. Now, will you hear me saying don't use Postgres? Not really, but I much more prefer MySQL. Jeremy Falcon Imputek
Jeremy Falcon wrote: MySQL is several times faster than Postgres. I'll have to disagree with you on that. Because PostgreSQL has a lot of features doesn't mean it is slower. A properly designed DB that is optimized should run really fast. Even Oracle and DB2 suck when DB is not structured correctly. I have tables that are over 200MB in size and I get good response times, plus I have all the features that I want.
-
Martin Marvinski wrote: PostgreSQL has a long history dating back to the mid-eighties at the University of California at Berkely No, you're thinking BerkleyDB which Postgres happens to support. Guess what Sherlock? MySQL supports it too. Jeremy Falcon Imputek
Here's the history of PostgreSQL as I know it. http://www.daemonnews.org/199907/devhistory.html
-
Nishant S wrote: Martin, from experience we've found postgres to be good for small amounts of data, but when the db gets bigger and bigger postgres gets slower and slower and sometimes even crashes I don't know alot of my tables are over 200MB, and if I try to import one into Access 2000 via ODBC it crashes Access. I haven't noticed any slow down either. I think your DB is poorly designed and/or not properly optimized. Even Oracle sucks if your DB design is flawed.
Martin Marvinski wrote: I don't know alot of my tables are over 200MB Heh, 200MB+ is NOT a big table, even Access can handle that. It is when you reach a GB and more you can talk about a big table. Anyway, which dbms to use is not allways based on the overall performance. If all you want is very fast read operations, then why would you trade that for transactions?. At the company i work for we have a lot of relatively static data, all those tables are read in to shared memory and accessed through binary searching, no transactions here but pure speed. The procedure of picking the right dbms is too important to just go for the one with the best/most commercials. "It could have been worse, it could have been ME!"
-
But MySQL has a cute little dolphin!
Fair point, it does indeed have a dolphin. Quite a nice looking dolphin at that.