Re: [GENERAL] Re: MySQL's (false?) claims... (was: Re: PL/java?)
On Mon, 27 Aug 2001, Andre Schnabel wrote: > I simply wonder, if any of the guys ever took a lesson in database design. > If I had told such wonderful ideas on foreign keys to my professor i'd been > thrown out the university imediatly. I agree. While you're at it, tell him you won't have a corresponding drop for every create, and that outer joins are useless. Then, while he's laughing at you, tell him you'll restrict data to 8k per row, and that you won't truncate inserted data, because people will always follow the rules. Then, as he's rolling on the floor clutching his stomach, tell him you'll add "cool" stuff like table inheritance before even *considering* adding the things listed previously. Now he's died laughing. Great. You've killed your professor. Bastard. Now. Consider that until 7.1, all of the above was true about Postgres. Hmm... Bad DB design... what was that you were saying again? -- +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ | Shaun M. ThomasINN Database Programmer | | Phone: (309) 743-0812 Fax : (309) 743-0830| | Email: [EMAIL PROTECTED]AIM : trifthen | | Web : hamster.lee.net | | | | "Most of our lives are about proving something, either to | | ourselves or to someone else." | | -- Anonymous | +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [GENERAL] Re: MySQL's (false?) claims... (was: Re: PL/java?)
I simply wonder, if any of the guys ever took a lesson in database design. If I had told such wonderful ideas on foreign keys to my professor i'd been thrown out the university imediatly. So if I am asked wheter to tage MySQL or PostgreSQL my answer is ... if you want to be fast and have a rather primitive db-design, only a few concurrent users, use MySQL. I all other cases take PostgreSQL. - Original Message - From: "Jan Wieck" <[EMAIL PROTECTED]> To: "Tom Lane" <[EMAIL PROTECTED]> Cc: "PostgreSQL GENERAL" <[EMAIL PROTECTED]> Sent: Monday, August 27, 2001 6:34 PM Subject: Re: [GENERAL] Re: MySQL's (false?) claims... (was: Re: PL/java?) > Tom Lane wrote: > > > > I have no doubt that MySQL's comparison page will keep pointing to this > > issue as a fatal limitation of PG long after it ceases to be a problem, > > however ;-) > > Oh yes, I'm pretty sure about that too. How many years took > it for them to understand that transactions are useful at > all? Now they have them and are so proud of it that they have > 3 different table types supporting transactions. Well, I'm > sure if you mix those types you'll not have any sort of > cross-table deadlock detection, but anyhow, that's again some > useless, CPU wasting feature because you can allways do the > updates in the right order so you never risk a deadlock. > > From that I expect that it'll take them another 3-5 years to > understand what a foreign key beside of the "documentation > purpose" is good for. So far they still claim that it's a bad > thing because it eat's performance for something you don't > need if you program things in the right order. How to do that > in a concurrent multiuser environment without doing exactly > the same lookups with the same locks in the application is > beyond my immagination, but they say so, so the typical MySQL > user would surely bet the farm on it. > > Another interesting detail is, that only their MyISAM type is > capable of (or planned for, I'm not 100% sure) hot-backups. > But especially that table type has no transaction support. So > it's right when they point out that you can do hot-backups, > which is important for 24/7 setups. And they are right that > MySQL has transaction support now. They just leave out the > nasty little info that you cannot have transaction support in > 24/7. > > > Jan > > -- > > #==# > # It's easier to get forgiveness for being wrong than for being right. # > # Let's break this rule - forgive me. # > #== [EMAIL PROTECTED] # > > > > _ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > > ---(end of broadcast)--- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [GENERAL] Re: MySQL's (false?) claims... (was: Re: PL/java?)
IMNSVHO the biggest argument against cross-DB queries is this useless extensibility in PostgreSQL. As soon as someone creates a data type, operator, aggregate or function, things get complicated. Have a data type "acctno" defined in both databases. And yes, we have operators for equalness in both DB's too. Now we do a cross-DB join and have two "acctno"s in the WHERE clause. First off, all these objects will have different OID's in the two system catalogs. Next, how do you know if the two types will at least have a similar external representation? And which of the two "=" operator functions will get called? Jan Stephan Szabo wrote: > > >* You can access many databases from the same connection (depending of > > >course on your privileges). > > > > > >=> PostgreSQL does not allow you to access more than one database per > > >connection. This makes the system much safer and allows for more robust > > >design. > > > > How does that makes things safer etc etc? I believe that this is a genuine > > limitation. > > > > I hope the developers are honest why this limitation exists. There are > > probably valid and good reasons for this limitation but I don't think > > "safer and more robust" is a good one. If it really is, then it reduces my > > confidence level in Postgresql's access control design/internals. > > There are actually good reasons, the first being that the > postgresql view is that databases are distinct entities (as opposed to > schemas which will hopefully get there eventually) and as such it makes no > sense to cross-db query. Right now, it's more of a limitation due to the > fact that permissions to prevent object creation aren't there and that > schemas aren't there, but once that's done I don't think this is much > of a limitation anymore. > > In addition, there are questions about authentication that I think are > tricky here, such as, we query a view, it uses another db, what > user/password should be used? should we query the user? does the user > even *know* what other db this view uses and why he's being prompted for > a password? Every client program (even random libpq ones) potentially > need to be able to handle an authentication request in response to a > query? It's not a clear cut win. > > > ---(end of broadcast)--- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) > -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] Re: MySQL's (false?) claims... (was: Re: PL/java?)
As strange as this may sound, I had to do a cross database query at my last job. It involved moving information from our e-commerce database into the accounting system database. While there may have been another way of handling it, this did allow me to handle the move solely within MSSQL and not have to schedule something like a seperate program to run. (Which I'd have to do to accomplish this in PGSQL currently.) Stephan Szabo wrote: > > > >* You can access many databases from the same connection (depending of > > >course on your privileges). > > > > > >=> PostgreSQL does not allow you to access more than one database per > > >connection. This makes the system much safer and allows for more robust > > >design. > > > > How does that makes things safer etc etc? I believe that this is a genuine > > limitation. > > > > I hope the developers are honest why this limitation exists. There are > > probably valid and good reasons for this limitation but I don't think > > "safer and more robust" is a good one. If it really is, then it reduces my > > confidence level in Postgresql's access control design/internals. > > There are actually good reasons, the first being that the > postgresql view is that databases are distinct entities (as opposed to > schemas which will hopefully get there eventually) and as such it makes no > sense to cross-db query. Right now, it's more of a limitation due to the > fact that permissions to prevent object creation aren't there and that > schemas aren't there, but once that's done I don't think this is much > of a limitation anymore. > > In addition, there are questions about authentication that I think are > tricky here, such as, we query a view, it uses another db, what > user/password should be used? should we query the user? does the user > even *know* what other db this view uses and why he's being prompted for > a password? Every client program (even random libpq ones) potentially > need to be able to handle an authentication request in response to a > query? It's not a clear cut win. > > ---(end of broadcast)--- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] Re: MySQL's (false?) claims... (was: Re: PL/java?)
> >* You can access many databases from the same connection (depending of > >course on your privileges). > > > >=> PostgreSQL does not allow you to access more than one database per > >connection. This makes the system much safer and allows for more robust > >design. > > How does that makes things safer etc etc? I believe that this is a genuine > limitation. > > I hope the developers are honest why this limitation exists. There are > probably valid and good reasons for this limitation but I don't think > "safer and more robust" is a good one. If it really is, then it reduces my > confidence level in Postgresql's access control design/internals. There are actually good reasons, the first being that the postgresql view is that databases are distinct entities (as opposed to schemas which will hopefully get there eventually) and as such it makes no sense to cross-db query. Right now, it's more of a limitation due to the fact that permissions to prevent object creation aren't there and that schemas aren't there, but once that's done I don't think this is much of a limitation anymore. In addition, there are questions about authentication that I think are tricky here, such as, we query a view, it uses another db, what user/password should be used? should we query the user? does the user even *know* what other db this view uses and why he's being prompted for a password? Every client program (even random libpq ones) potentially need to be able to handle an authentication request in response to a query? It's not a clear cut win. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [GENERAL] Re: MySQL's (false?) claims... (was: Re: PL/java?)
Lincoln Yeoh <[EMAIL PROTECTED]> writes: >> => PostgreSQL does not allow you to access more than one database per >> connection. This makes the system much safer and allows for more robust >> design. > How does that makes things safer etc etc? I believe that this is a genuine > limitation. It's unlikely that the "one DB per connection" limitation will ever change. What is likely to happen (for 7.3, with any luck) is that we will implement SQL92-compatible schema naming within the traditional Postgres notion of a database. More than likely, most installations will then migrate to keeping all their stuff in multiple schemas within one big database, and the issue will cease to be a problem in practice even though the technical limitation is still there. I have no doubt that MySQL's comparison page will keep pointing to this issue as a fatal limitation of PG long after it ceases to be a problem, however ;-) >> * Tools to repair and optimize MyISAM tables (the most common MySQL table >> type). >> >> => In MySQL you have to repair your tables manually if corruption occurs. >> PostgreSQL is coded so that corruption cannot occur. > I sure hope so. A more accurate way of stating this is "we prefer to spend our development time on eliminating bugs, not on devising tools to clean up after bugs". regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[GENERAL] Re: MySQL's (false?) claims... (was: Re: PL/java?)
At 03:21 PM 8/26/01 +0200, Peter Eisentraut wrote: >* There are far moore books in print on MySQL than on PostgreSQL. >O'Reilly, Sams, Que, and New Riders are all major publishers with books >about MySQL. > >=> MySQL is so hard to understand and poorly documented, a plethora of >books had to come out before anyone could use it. I disagree. MySQL was quite easy to understand (furthermore it was limited in what it could do :) ). And it's well documented. The limitations were documented too - that part I liked very much. As for the justifications for their limitations, some valid and the rest not that important to me - ignorable. I found postgresql harder to understand when I first tried it (Postgres95). And performance was terrible then, so I had to revert to MySQL. Then there were these adhoc pgsql commands you run from the command shell which didn't work for me (createdb etc). I had turned on access controls in pg_hba which broke most of the command shell scripts which assumed no access controls, and the PGSQL documentation assumed that most people would use the command shell scripts/programs... >* MySQL has internal support for text search. See section 6.8 MySQL >Full-text Search. > >=> PostgreSQL has a number of different full text search solutions >available, or users can plug in their own. Yah, I hope you realised you used a similar argument against MySQL for their many APIs :). >* You can access many databases from the same connection (depending of >course on your privileges). > >=> PostgreSQL does not allow you to access more than one database per >connection. This makes the system much safer and allows for more robust >design. How does that makes things safer etc etc? I believe that this is a genuine limitation. I hope the developers are honest why this limitation exists. There are probably valid and good reasons for this limitation but I don't think "safer and more robust" is a good one. If it really is, then it reduces my confidence level in Postgresql's access control design/internals. >* MySQL has a much more sophisticated privilege system than PostgreSQL. > >=> MySQL has a much more complicated privilege system than PostgreSQL. Just different to me. >* Tools to repair and optimize MyISAM tables (the most common MySQL table >type). > >=> In MySQL you have to repair your tables manually if corruption occurs. >PostgreSQL is coded so that corruption cannot occur. I sure hope so. But I also hope that people look at things objectively and not blind themselves in defense of what they hold dear. Taking a long view of things, MySQL is likely to have some design and usage issues with the multiple ways of handling what they call transactions. They may have to do some pruning soon and leave only the good branches. Postgresql is better for what I currently need to do. I'm glad it has improved a lot. Cheerio, Link. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
