Обсуждение: Which database part 2
This is the follow up for my post a few days ago. First I want to thank everybody for their great replies. I must admit that I did ask the same question in MySQL list and also had many replies. From their perspective the only thing that PostgreSQL has and MySQL does not have is more features. In fact here's a short summary of the ideas from MySQL list: -MySQL is simple, powerful, indestructible. -PostgreSQL is very highly featured, but not as fast and not as rugged. -MySQL ran on NT with no fuss, while you needed cygwin and whatnot to run PostgreSQL. -PostgreSQL seemed to require more administration than MySQL. -If you need to work with extremely large databases (multi GB) I would go with MySQL. It scales to large files extremely well. -There seems to be much less support for PostgreSQL than MySQL, be it from books or other users. -MySQL has better support, larger community and better documentation. These are randomly orderered and posted by various MySQL list users. I thought it would be nice for part 2 to have PostgreSQL users comment these replies. I have been reading a little documentation and mail-lists from both sides. I noticed one interesting thing about MySQL: there are different table types with different properties. Why doesn't PostgreSQL have differently oriented/optimized table types? I found particularly intresting the heap table type which is being stored entirely in memory not on disk drive. Kaarel kaarel@future.ee
Here is one more question that has aroused uring these days: Why did SourceForge.net move from PostgreSQL to DB2? Kaarel kaarel@future.ee
-----Original Message----- From: Kaarel [mailto:kaarel@future.ee] Sent: Friday, June 13, 2003 2:17 PM To: pgsql-advocacy@postgresql.org Subject: [pgsql-advocacy] Which database part 2 This is the follow up for my post a few days ago. First I want to thank everybody for their great replies. I must admit that I did ask the same question in MySQL list and also had many replies. From their perspective the only thing that PostgreSQL has and MySQL does not have is more features. In fact here's a short summary of the ideas from MySQL list: -MySQL is simple, powerful, indestructible. -PostgreSQL is very highly featured, but not as fast and not as rugged. -MySQL ran on NT with no fuss, while you needed cygwin and whatnot to run PostgreSQL. -PostgreSQL seemed to require more administration than MySQL. -If you need to work with extremely large databases (multi GB) I would go with MySQL. It scales to large files extremely well. -There seems to be much less support for PostgreSQL than MySQL, be it from books or other users. -MySQL has better support, larger community and better documentation. These are randomly orderered and posted by various MySQL list users. I thought it would be nice for part 2 to have PostgreSQL users comment these replies. ---------------------------(end of broadcast)--------------------------- The truth: MySQL is simple. MySQL is powerful (but not as powerful as postgres) MySQL runs on NT with no fuss, does require cygwin for the shell (this is nitpicking), although uses OS managed file caching, this can cause problems. MySQL has a larger community. MySQL probably has better support, if you pay for the commercial license. Otherwise its roughly equal. I will say that postgres tends to attract a more highly skilled pool of developers (thus smaller). The untruth: MySQL is not indestructible. Pull out the power cord while writing with mysql, postgres and compare results. Administration is almost exactly the same. You install (actually usually preinstalled), create database, optionally add users, and enter SQL commands for both databases. MySQL does not 'scale' well with large files. Scaling with concurrent transactions is much more interesting anyways. (postgres has this hands down). Most things are rather subjective (speed), except for the ruggedness. On this single point postgres is the preferred solution. Merlin
Kaarel, > -PostgreSQL is very highly featured, but not as fast and not as > rugged. This is incorrect. Postgresql is slower in the common MySQL configuration, i.e. read-only database with a high simple, poorly-written query load. Postgresql is faster with complex queries, transactions, and read-write databases. And both databases are good for 99.5% uptime, so I don't know where MySQL gets "less rugged" from. Frankly, this sounds like FUD from MySQL AB rather than any kind of real experience. > -MySQL ran on NT with no fuss, while you needed cygwin and whatnot to > run PostgreSQL. True. We're working on a Windows-native version, but it will not be ready for a few months. > -PostgreSQL seemed to require more administration than MySQL. True as well, although with some databases the admin is entirely at installation time. On the flip side, PostgreSQL is more configurable by a trained DBA than MySQL is. > -If you need to work with extremely large databases (multi GB) I > would go with MySQL. It scales to large files extremely well. MySQL may scale well (I haven't tried). PostgreSQL is proven to scale extremely well; as evidence: the .ORG domain; the previous version of SourceForge; several databases on the Performance list with up to 2TB of data. And if MySQL is so scalable, why are they adopting SAP-DB? > -There seems to be much less support for PostgreSQL than MySQL, be it > from books or other users. Books true, other users false. And how many books do you need, exactly? There are about a dozen for PostgreSQL. > -MySQL has better support, larger community and better documentation. The only one of those which is anything but entirely subjective is the "larger community". However, I will point out that MS Access has a very large community; that doesn't mean I'd consider using it. MySQL has slightly more documentation. On the other hand, the official docs are full of marketing by MySQL AB, so choose your preference. > These are randomly orderered and posted by various MySQL list users. > I thought it would be nice for part 2 to have PostgreSQL users > comment these replies. Glad you gave us the chance. > I have been reading a little documentation and mail-lists from both > sides. I noticed one interesting thing about MySQL: there are > different table types with different properties. Why doesn't > PostgreSQL have differently oriented/optimized table types? Because it's an administrative headache, impairs scalability, and is a violation of relational theory, that's why. An important tenet of relational theory is that the theoretical implementation of the database (e.g. the DDL statements) be kept competely seperate from the physical implemenation of storage. This has been part of database theory since 1973. In my experience, though, the MySQL development team have little regard for theory (or, for that matter, international standards), so I'm not surprised they ignored this. This abstraction is not just a "purist" approach. Failure to seperate the theoretical and physical layers of the database makes it very hard ... if not impossible ... to implement sophisticated schema, such as enterprise-wide constraints, business rules, foriegn keys, and sophisticated views. I think that the MySQL development team has recognized this fundamental problem with MySQL which is the reason that they are incorporating SAP-DB code and ideas. How about a sum up: PostgreSQL is the DBA's database. MySQL is the web designer's database. -Josh Berkus Aglio Database Solutions
On Fri, Jun 13, 2003 at 21:28:01 +0300, Kaarel <kaarel@future.ee> wrote: > Here is one more question that has aroused uring these days: > > Why did SourceForge.net move from PostgreSQL to DB2? I think they became involved with IBM shortly before the change.
Kaarel, > Why did SourceForge.net move from PostgreSQL to DB2? Perhaps because VA Software made a multi-million dollar deal with IBM? <grin> (Actually, I know as a VA stockholder that that was one of the conditions of the IBM deal) -Josh Berkus
Beware bias. I'm unashamedly a PostgreSQL fan. I'm trying to be fair to MySQL, but... Kaarel wrote: > This is the follow up for my post a few days ago. First I want to thank > everybody for their great replies. I must admit that I did ask the same > question in MySQL list and also had many replies. From their perspective > the only thing that PostgreSQL has and MySQL does not have is more > features. In fact here's a short summary of the ideas from MySQL list: > > -MySQL is simple, powerful, indestructible. Simple, yes. The other two...I would be very frustrated using MySQL because of the limited query syntax. I hear it's getting better, but I don't watch very closely. And "simple" doesn't necessarily mean it's easier to use. PostgreSQL has a lot more features, but I do not find that they get in your way if you don't use them. That's certainly not always true...Oracle's features are very much a mixed bag. Very, very useful in some cases (almost a necessity) but there's definitely a lot of overhead to them in that you notice them even if you aren't using them. > -PostgreSQL is very highly featured, but not as fast and not as rugged. The "not as fast" is debatable. The benchmarks the MySQL people talk about are quite old. I would bet, that with any reasonable amount of concurrency, PostgreSQL would do considerably better. But I haven't done the work to back it up. The "not as rugged" is a big fat lie. In fact, I believe it's the other way - MySQL fails the "Durability" part of ACID even now; it doesn't sync to disk before every commit returns, and it should. > -MySQL ran on NT with no fuss, while you needed cygwin and whatnot to > run PostgreSQL. That's true. There are people working on fixing it, though. > -PostgreSQL seemed to require more administration than MySQL. I don't buy this. Installing PostgreSQL is easy. Administration is not hard...it basically boils down to running a script nightly that does a "vacuum analyze" and an online dump of all your databases for backup purposes. You certainly can do more, but I wouldn't say you have to, any more than you do with MySQL. > -If you need to work with extremely large databases (multi GB) I would > go with MySQL. It scales to large files extremely well. PostgreSQL does also. > -There seems to be much less support for PostgreSQL than MySQL, be it > from books or other users. That's true. MySQL seems to be more widely used. > -MySQL has better support, larger community and better documentation. Hmm. More != better. It's debatable. I find that a lot of the MySQL community follows some very poor practices. Obvious things like not using foreign keys...when you don't, you have to worry that every join condition will cause rows to silently disappear from your query. When you use foreign keys, you are _guaranteed_ to not have to worry about things like that. And many other examples where they do stuff in their application that the database server should be doing. In part this comes from MySQL not having these features for a long time. But now that it has more of them, they still are not using them properly. This certainly is not true of everyone who uses MySQL, but it's enough so that I look on any project that uses MySQL with a lot more skepticism than one that uses PostgreSQL. The same for PHP...they've got some good code out there (PEAR) but most people don't use it. So when I find a PHP/mySQL project, I tend to assume it's crap. It's not necessarily so, but it's a pretty good bet. > > These are randomly orderered and posted by various MySQL list users. I > thought it would be nice for part 2 to have PostgreSQL users comment > these replies. > > I have been reading a little documentation and mail-lists from both > sides. I noticed one interesting thing about MySQL: there are different > table types with different properties. Why doesn't PostgreSQL have > differently oriented/optimized table types? I found particularly > intresting the heap table type which is being stored entirely in memory > not on disk drive. Because PostgreSQL has one good one. MySQL's initial table types were just not very good. My impression is that the InnoDB and BerkeleyDB-backed tables are the ones you'd want to actually use. I believe the heap one exists because MySQL does not have as good caching as PostgreSQL. > Kaarel > kaarel@future.ee Scott
On Fri, 2003-06-13 at 14:17, Kaarel wrote: > This is the follow up for my post a few days ago. First I want to thank > everybody for their great replies. I must admit that I did ask the same > question in MySQL list and also had many replies. From their perspective > the only thing that PostgreSQL has and MySQL does not have is more > features. In fact here's a short summary of the ideas from MySQL list: > > -MySQL is simple, powerful, indestructible. I find the indestructable part hard to believe, if for no other reason than they have had to create their own "corruption recovery" tools. I'm also starting to question the simple part since you have different table types that behave completly different and are not always compatible with one another. Add in the mix of the new mysapdbsql and things just get worse. > -PostgreSQL is very highly featured, but not as fast and not as rugged. I guess I'll point to the .org domain system's conversion from oracle to postgresql as proof to refute this. I don't remember any mysql based proposals. > -MySQL ran on NT with no fuss, while you needed cygwin and whatnot to > run PostgreSQL. this one is fair enough, though we should have native windows support in the next version. while I don't know how well it will stand up in a production environment, from a commercial standpoint SRA's native windows threaded postgresql back end would seem pretty promising. > -PostgreSQL seemed to require more administration than MySQL. this really depends on the application, but in general is probably true. i don't know enough about the innodb internals to know how much maintenance they require. i would say that if the auto vacuum daemon works as well as i hope, many of those issues will go away. > -If you need to work with extremely large databases (multi GB) I would > go with MySQL. It scales to large files extremely well. uuh... i don't get this one, since we've had what, a 4 TB database reported. > -There seems to be much less support for PostgreSQL than MySQL, be it > from books or other users. books yes. users... i couldn't say. maybe from the standpoint that if you post a postgresql question on a php list your less likely to get response than a mysql question. posting on the postgresql lists seems pretty good to me though. > -MySQL has better support, larger community and better documentation. > better support based on... ? larger community...yes. larger developer community, i don't think so. better documentation... i've heard this one go both ways, but i tend to think our docs are pretty good. > These are randomly orderered and posted by various MySQL list users. I > thought it would be nice for part 2 to have PostgreSQL users comment > these replies. > > I have been reading a little documentation and mail-lists from both > sides. I noticed one interesting thing about MySQL: there are different > table types with different properties. Why doesn't PostgreSQL have > differently oriented/optimized table types? I found particularly > intresting the heap table type which is being stored entirely in memory > not on disk drive. > You'd have to get a specific reason from one of the hackers involved, but i'd guess they just never had the need to break things down this way. currently postgresql already tries to store tables in memory based on actual usage. > Why did SourceForge.net move from PostgreSQL to DB2? The official reason was becuase they needed something that could scale better than what they currently had. My personal belief is they recived a lot of funding from IBM to make it work on DB2, which helped them sell the sourceforge software to more corporations as well. You might want to ask why did sourceforge migrate from mysql to postgresql? (Of course that answer is nicely available here: http://www.phpbuilder.com/columns/tim20001112.php3?page=1) Robert Treat -- Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
> > -PostgreSQL is very highly featured, but not as fast and not as > > rugged. > > This is incorrect. Postgresql is slower in the common MySQL > configuration, i.e. read-only database with a high simple, > poorly-written query load. Postgresql is faster with complex > queries, transactions, and read-write databases. I'm ashamed to admit it, but I've been running with MySQL databases for about 5 years now. That said, complex queries for MySQL is defined as two or three table joins, beyond that, MySQL starts to fall on its face. Single table queries, it's good at. > And both databases are good for 99.5% uptime, so I don't know where > MySQL gets "less rugged" from. Frankly, this sounds like FUD from > MySQL AB rather than any kind of real experience. This I can't attest to, however. At Cisco, MySQL would regularly fall flat on its face (Solaris) and would go into a death spiral taking 100% of the CPU, and not allowing any new connections. In my own experiences, MySQL regularly (~once a month) does the same thing (Linux back in the day, now FreeBSD). MySQL's done this for ages and ages if you push it. At ApacheCon I spoke with a few folks _from_ MySQL AB who said that when they talk to customers, they hear reports of people with this problem, but their developers can never seem to reproduce this and deny that it's a problem. PostgreSQL, on the other hand, has been a rock. The _only_ time I've had a problem with PostgreSQL is when I had a few errant applications leaving transactions open causing queries to build up until it reaches its max connection limit. I can't emphasize the stableness of PostgreSQL compared to MySQL: the difference is non-trivial and the difference is much greater than 0.5% difference in uptime. Downtime in PostgreSQL is upgrading between major versions, in MySQL it's regular, irritating, requires running myisamchk several times with several options, running myisamchk regularly regardless of crashes and you still find inconsistencies, and unless you have a monitor pinging your MySQL database, you're likely going to be hosed until someone notices and repairs/restarts MySQL. In terms of simple query speed, the biggest difference between the two is overhead for creating a new connection. In PostgreSQL it takes longer than MySQL (thread vs. process creation time), but once a connection is established, PostgreSQL is so feature rich, that depending on what it is that you're trying to do, I bet you can get PostgreSQL to outpace MySQL. > > -PostgreSQL seemed to require more administration than MySQL. > > True as well, although with some databases the admin is entirely at > installation time. On the flip side, PostgreSQL is more > configurable by a trained DBA than MySQL is. Ehh... I may have different experiences here, but once you get a PostgreSQL database up and running, it's a fire and forget type thing: I don't generally have to go back and visit the DBs once they're rolling (I do hourly VACUUM ANALYZEs and nightly backups via cron). > > -If you need to work with extremely large databases (multi GB) I > > would go with MySQL. It scales to large files extremely well. > > MySQL may scale well (I haven't tried). PostgreSQL is proven to > scale extremely well; as evidence: the .ORG domain; the previous > version of SourceForge; several databases on the Performance list > with up to 2TB of data. > > And if MySQL is so scalable, why are they adopting SAP-DB? Um, MySQL has an upper limit of about 30M rows in real life. I've taken PostgreSQL to about 1B and had no noticeable problems other than 1B rows takes more diskspace than 30M rows (funny how that works). > > -There seems to be much less support for PostgreSQL than MySQL, be > > it from books or other users. > > Books true, other users false. And how many books do you need, > exactly? There are about a dozen for PostgreSQL. This is true and unfortunate, but there isn't as big of a need for PostgreSQL documentation given the quality of PostgreSQL's documentation. It really is quite good, IMO. > > -MySQL has better support, larger community and better documentation. > > The only one of those which is anything but entirely subjective is > the "larger community". However, I will point out that MS Access > has a very large community; that doesn't mean I'd consider using it. > MySQL has slightly more documentation. On the other hand, the > official docs are full of marketing by MySQL AB, so choose your > preference. If support == tradeshow presence, then I believe that. PostgreSQL isn't developed as a commercial product that's open source, PostgreSQL is an open source project that has commercial support. If you use your database in a product, you have to pay MySQL AB, you don't with PostgreSQL (something to keep in mind). > > I have been reading a little documentation and mail-lists from both > > sides. I noticed one interesting thing about MySQL: there are > > different table types with different properties. Why doesn't > > PostgreSQL have differently oriented/optimized table types? Because each of MySQL's table types has a specific niche, but none of them do things particularly well (though I liked the innodb table format on MySQL because of its transaction bits... just don't pull the plug though). PostgreSQL has very good speed, and transaction support with a single table type, why add more? If you need something that's not WAL backed, use a temp table and PostgreSQL really flies (in fact, if you wanted to compare query speeds between MySQL and PostgreSQL, compare temp table speeds since they're closer to on par then). > How about a sum up: > PostgreSQL is the DBA's database. > MySQL is the web designer's database. I wouldn't be so kind as to describe MySQL that way. I'd sum it up as closer to MySQL users are willing to buy into the hype (MySQL spends a lot of effort in hyping/promoting their DB, PostgreSQL doesn't) and don't do their due diligence to investigate other DB's. I have MySQL around for two reasons, legacy (I didn't know better once upon a time), and because of MySQL's SHOW TABLE syntax for examining the DB. MySQL is the Windows of the free databases (even though MySQL's not for commercial use in products) and PostgreSQL's closer to FreeBSD/Linux. -sc -- Sean Chittenden
On Fri, 2003-06-13 at 14:17, Kaarel wrote: > This is the follow up for my post a few days ago. First I want to thank > everybody for their great replies. I must admit that I did ask the same > question in MySQL list and also had many replies. From their perspective > the only thing that PostgreSQL has and MySQL does not have is more > features. In fact here's a short summary of the ideas from MySQL list: Thanks for the note about what the list said. It's always interesting to read the opinion others have about a product. > -MySQL is simple, powerful, indestructible. Agreed, until it does destroy itself (power failure will do it). > -PostgreSQL is very highly featured, but not as fast and not as rugged. Agreed on speed point for simple queries (single table, indexed, low concurrency, 99% read requests). PostgreSQL had stability issues 4+ years ago. > -PostgreSQL seemed to require more administration than MySQL. This is true if the system is running perfectly. Personal experience has shown that both can be ignored if they're running well, and both have aches and pains if something goes wrong (bad hardware). PostgreSQL can handle some failure scenarios better than MySQL (power failure). MySQL will continue to run in an extremely low resource scenario. This can be a blessing (websites storing a blog or comment database) as you may not miss the data when it goes disappears. > -If you need to work with extremely large databases (multi GB) I would > go with MySQL. It scales to large files extremely well. Multi-GB is what goes for large these days? Very well, PostgreSQL supports extremely large databases very easily. Main limits are generally disk I/O, but that has little to do with the database. Don't forget to tweak configuration settings and buy appropriate hardware. Neither database functions well on a busy multigigabyte database with a Palm Pilot for hardware. I'm not sure I follow the large file remark. What does a large file have to do with table or database size? Isn't it up to the filesystem to deal well with large files? -- Rod Taylor <rbt@rbt.ca> PGP Key: http://www.rbt.ca/rbtpub.asc
Вложения
Sean, > PostgreSQL, on the other hand, has been a rock. The _only_ time I've > had a problem with PostgreSQL is when I had a few errant applications > leaving transactions open causing queries to build up until it reaches > its max connection limit. I can't emphasize the stableness of > PostgreSQL compared to MySQL: the difference is non-trivial and the > difference is much greater than 0.5% difference in uptime. *sigh* One of my clients did extensive reliability testing for PostgreSQL. The results were really, really encouraging ... but I can't report them due to an airtight NDA. > > How about a sum up: > > PostgreSQL is the DBA's database. > > MySQL is the web designer's database. > > I wouldn't be so kind as to describe MySQL that way. I'd sum it up as > closer to MySQL users are willing to buy into the hype (MySQL spends a > lot of effort in hyping/promoting their DB, PostgreSQL doesn't) and > don't do their due diligence to investigate other DB's. I've personally found MySQL to be idea for one type of client: the type that doesn't have a DBA or skilled tech and doesn't intend to hire one. MySQL is good for a certain amount of idiot-proofing in that regard. Of course, I also recommend Filemaker for the same clients, so that's grounds for comparison. -- -Josh Berkus Aglio Database Solutions San Francisco
Josh Berkus wrote: > Kaarel, > > >>Why did SourceForge.net move from PostgreSQL to DB2? > > > Perhaps because VA Software made a multi-million dollar deal with IBM? > <grin> So this has been transitioned already? The SF.net site has been extremely flaky recently (have been trying to do things on it extensively in the last few weeks). Wonder if it's transition or DB2 related? Regards and best wishes, Justin Clift > (Actually, I know as a VA stockholder that that was one of the > conditions of the IBM deal) > > -Josh Berkus > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
On Friday 13 June 2003 20:17, you wrote: > This is the follow up for my post a few days ago. First I want to thank > everybody for their great replies. I must admit that I did ask the same > question in MySQL list and also had many replies. From their perspective > the only thing that PostgreSQL has and MySQL does not have is more > features. Hi Kaarel, Upon your request, I sent you privately a list of known defects in MySQL. I can read the same complains on Hackers. But personally, I don't feel like criticising MySQL as it is free software (at least until now, things may change in the future). Now, one question: why do you keep on asking questions about MySQL? Can't you just download PostgreSQL 7.3.2, pgAdmin3 and PhpPgAdmin 3.0 and make your own opinion? Is it because you don't know the SQL language and need a Marketing input? IMHO, marketing cannot be the answer. At some point, you need to put your hands in the dirt, which in the case of PostgreSQL will take a day. Cheers, Jean-Michel POURE
On Sat, Jun 14, 2003 at 12:42:35 +0800, Justin Clift <justin@postgresql.org> wrote: > Josh Berkus wrote: > >Kaarel, > > > > > >>Why did SourceForge.net move from PostgreSQL to DB2? > > > > > >Perhaps because VA Software made a multi-million dollar deal with IBM? > ><grin> > > So this has been transitioned already? The SF.net site has been > extremely flaky recently (have been trying to do things on it > extensively in the last few weeks). Wonder if it's transition or DB2 > related? The change happened quite a while ago. I don't remember exactly, but I think it was over a year ago.
> Now, one question: why do you keep on asking questions about MySQL? Can't you > just download PostgreSQL 7.3.2, pgAdmin3 and PhpPgAdmin 3.0 and make your own > opinion? Hey I thougth there's no penalty for asking. Or is it that these are _my_ questions that are generating the most traffic in advocacy list? OK that one was ment to be a joke or whatever. Actually PostgreSQL sympathizes more to me than MySQL. However I don't have that much experience with them to convince someone to use PostgreSQL. When my boss is convinced that MySQL is almost as fast as Oracle then it won't help to say "but I like PostgreSQL". I thought why not ask the same question (which database to use) from both parties and then let them analyze opposite's answers. So I would get a nice list of reasons to operate with and also be prepared for some counter arguments. Besides asking this one question I have been reading PostgreSQL and MySQL mail-lists, searched some archives and read some articles over the internet. This is how I asked about SourceForge and DB2. I have got some very interesting new knowledge for the past week or so. Bear in mind that I will put anything you told me that isn't true on your conscience :) Kaarel
> >Now, one question: why do you keep on asking questions about MySQL? Can't > >you just download PostgreSQL 7.3.2, pgAdmin3 and PhpPgAdmin 3.0 and make > >your own opinion? > > Hey I thougth there's no penalty for asking. Or is it that these are > _my_ questions that are generating the most traffic in advocacy list? > > OK that one was ment to be a joke or whatever. > > Actually PostgreSQL sympathizes more to me than MySQL. However I > don't have that much experience with them to convince someone to use > PostgreSQL. When my boss is convinced that MySQL is almost as fast > as Oracle then it won't help to say "but I like PostgreSQL". Simply put, PostgreSQL _is_ faster than Oracle, not almost faster. Check the archives, there are many many testaments that concur with PostgreSQL being faster. -- Sean Chittenden
On Saturday 14 June 2003 22:12, Kaarel wrote: > Besides asking this one question I have been reading PostgreSQL and > MySQL mail-lists, searched some archives and read some articles over the > internet. This is how I asked about SourceForge and DB2. I have got some > very interesting new knowledge for the past week or so. Bear in mind > that I will put anything you told me that isn't true on your conscience :) You are welcome on this mailing list. We will do the best to inform you. But, again, could you tell us more about your knowledge in database technologies? For example, do you know the difference between a SELECT and an UPDATE clause, a TABLE and VIEW? Do you know what is a SCHEMA? Do you know what ACID rules mean? Do you know the difference betwenn a LEFT and a RIGHT JOIN? Do you know what is a subselect? etc... Your questions about MySQL/PostgreSQL are just like comparing Ms Access/Oracle. At the first glance, a responsible developper is able to give an answer. But, you should not forget that good developpers are able to create nice and working applications using whaterver tools they have (even Windows 95 or MySQL). Men and women skills are more important than tools. Therefore, the answer to the question "MySQL or PostgreSQL" relies mainly on you. If you are a good developper, you will create nice and working applications, be it under PostgreSQL or MySQL. In a way, the quest for PostgreSQL is a quest for knowledge and excellence. Whenever you study PostgreSQL, you learn more about databases technologies. You will then reach new limits, which in turn will ask you more questions... This is the never ending story ... Welcome in the PostgreSQL world, Jean-Michel POURE
> You are welcome on this mailing list. We will do the best to inform you. But, > again, could you tell us more about your knowledge in database technologies? I had two database courses in my University this semester. One course _required_ the homework to be done in MS Access. The other _required_ the homework to be done in PostgreSQL and C. I have some experience in database development but these are all related to schoolwork and have been rather small scale where MySQL satisfies. > For example, do you know the difference between a SELECT and an UPDATE clause, > a TABLE and VIEW? Do you know what is a SCHEMA? Do you know what ACID rules > mean? Do you know the difference betwenn a LEFT and a RIGHT JOIN? Do you know > what is a subselect? etc... So yes I knnow the difference I wouldn't have passed the exams. Actually I have even bought a book "PostgreSQL" by Korry and Susan Douglas. > Your questions about MySQL/PostgreSQL are just like comparing Ms > Access/Oracle. At the first glance, a responsible developper is able to give > an answer. Well some epeople compare MySQL and Oracle... > Welcome in the PostgreSQL world, > Jean-Michel POURE Reminds me of the "Welcome to the real world, Morpheus" Hope the PostgreSQL world isn't as dramatic though :)
Dear Kaarel, > I had two database courses in my University this semester. One course > _required_ the homework to be done in MS Access. The other _required_ > the homework to be done in PostgreSQL and C. I have some experience in > database development but these are all related to schoolwork and have > been rather small scale where MySQL satisfies. So you are a real professional. When asking this question, my concern was that many sofware companies now communicate using "buzzwords" like "speed", "transactions", "replication", etc... in order to impress end-users and financial investors. > Reminds me of the > "Welcome to the real world, > Morpheus" > Hope the PostgreSQL world isn't as dramatic though :) Sorry, I did not intend to make this comparision. PostgreSQL is being developped so fast, that you feel like you will never be able to say "I know PostgreSQL completely". In a way, PostgreSQL is a quest for knowledge... Cheers, Jean-Michel
> So you are a real professional. When asking this question, my concern was that > many sofware companies now communicate using "buzzwords" like "speed", > "transactions", "replication", etc... in order to impress end-users and > financial investors. I wouldn't say professional...or I wouldn't be asking all these questions here. I know what are transactions, replication, table, view etc and the syntax of them but I really lack practical experience. So for me the best way to get to know the main differences between PostgreSQL and MySQL was to read articles and ask mailing list. And thanks to all of you I now have a lot more knwoledge than I had a week ago :) Kaarel
On Fri, 13 Jun 2003, Josh Berkus wrote: > Kaarel, > > > Why did SourceForge.net move from PostgreSQL to DB2? > > Perhaps because VA Software made a multi-million dollar deal with IBM? > <grin> > > (Actually, I know as a VA stockholder that that was one of the > conditions of the IBM deal) As a followup to this, I, and many of my friends, noticed that sourceforge's search capability was much more limited and much slower after converting.
On Fri, 13 Jun 2003, Kaarel wrote: > I have been reading a little documentation and mail-lists from both > sides. I noticed one interesting thing about MySQL: there are different > table types with different properties. Why doesn't PostgreSQL have > differently oriented/optimized table types? I found particularly > intresting the heap table type which is being stored entirely in memory > not on disk drive. any points I would have had have been addressed by other folks except for one. In MySQL if you define one table of MyISAM (non-transactable) and one of innodb (transactable) and you do this: begin; update myisamtable set field='value' where id=2; update innodbtable set field='value' where id=2; rollback; you now have one table that updated and one that didn't. I don't consider that a feature.
On Sat, 14 Jun 2003, Justin Clift wrote: > Josh Berkus wrote: > > Kaarel, > > > > > >>Why did SourceForge.net move from PostgreSQL to DB2? > > > > > > Perhaps because VA Software made a multi-million dollar deal with IBM? > > <grin> > > So this has been transitioned already? The SF.net site has been > extremely flaky recently (have been trying to do things on it > extensively in the last few weeks). Wonder if it's transition or DB2 > related? It happened some time in the spring of 2002 I believe.
Guys, > > > Perhaps because VA Software made a multi-million dollar deal with IBM? > > > <grin> > > > > So this has been transitioned already? The SF.net site has been > > extremely flaky recently (have been trying to do things on it > > extensively in the last few weeks). Wonder if it's transition or DB2 > > related? > > It happened some time in the spring of 2002 I believe. BTW, as a VA stockholder, I supported the decision, just because VA would have been Chapter 11 otherwise .... -Josh
Didn't know they made the switch - but, my intuition tells me it has to do with the fact that Sourceforge has for some time sold a proprietary version of the software, and "partnering" with IBM would help make sure the revenue stream for that version of the product remains in tact. No worries - when PostgreSQL eventually outperforms DB2 there won't have been any reason for switching. --Richard Schilling On 2003.06.16 11:38 scott.marlowe wrote: > On Fri, 13 Jun 2003, Josh Berkus wrote: > > > Kaarel, > > > > > Why did SourceForge.net move from PostgreSQL to DB2? > > > > Perhaps because VA Software made a multi-million dollar deal with > IBM? > > <grin> > > > > (Actually, I know as a VA stockholder that that was one of the > > conditions of the IBM deal) > > As a followup to this, I, and many of my friends, noticed that > sourceforge's search capability was much more limited and much slower > after converting. > > > ---------------------------(end of > broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faqs/FAQ.html >