Hi, I got a application actualy running on mysql, but, due a contract with a client, the application can get some complex queries and lots of users (like 10x more users). Its a academic application, and the company we are negociating have 7k+ students. Im worry about the database, its better stick with de mysql? migrate to postgresql? Which one can scale better with quality? Thanks! -- Posted via http://www.ruby-forum.com/.
Diego Bernardes wrote:> Hi, > > I got a application actualy running on mysql, but, due a contract with a > client, the application can get some complex queries and lots of users > (like 10x more users). > > Its a academic application, and the company we are negociating have 7k+ > students. > > Im worry about the database, its better stick with de mysql? migrate to > postgresql? > > Which one can scale better with quality?PostgreSQL is my default choice for all projects. It''s a better database overall than mySQL, and does not force you to choose between data integrity and speed the way mySQL does. I''m told it doesn''t handle clustering quite as well as mySQL, but that''s its only real disadvantage. However, it is likely that either database will scale suitably. The more immediate problems are likely to come from inefficient queries.> > Thanks!Best, -- Marnen Laibow-Koser http://www.marnen.org marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org -- Posted via http://www.ruby-forum.com/.
Scaling read queries with mysql is drop dead simple. Just add replicas. But you only have one server to do inputs on.Real simple. But a Quad core machine with a little memory, 16 GB, you can serve hundred thousand people easily. We do hundreds of thousands of heavy queries every minute on one box. Just create indexes, ''explain'' is your friend. Trausti On Tue, Oct 6, 2009 at 10:44 PM, Diego Bernardes < rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> > Hi, > > I got a application actualy running on mysql, but, due a contract with a > client, the application can get some complex queries and lots of users > (like 10x more users). > > Its a academic application, and the company we are negociating have 7k+ > students. > > Im worry about the database, its better stick with de mysql? migrate to > postgresql? > > Which one can scale better with quality? > > Thanks! > -- > Posted via http://www.ruby-forum.com/. > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Tue, Oct 6, 2009 at 4:10 PM, Marnen Laibow-Koser <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> PostgreSQL is my default choice for all projects.I usually think about the specs and requirements, then make a choice. -- Greg Donald http://destiney.com/
On Tue, Oct 6, 2009 at 10:44 PM, Diego Bernardes <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> > Hi, > > I got a application actualy running on mysql, but, due a contract with a > client, the application can get some complex queries and lots of users > (like 10x more users). > > Its a academic application, and the company we are negociating have 7k+ > students. > > Im worry about the database, its better stick with de mysql? migrate to > postgresql? > > Which one can scale better with quality? >+1 to PostgreSQL. It is my default too. I don''t know about clustering, though. I''ve had many bad experiences with MySQL in the past, specially with large amounts of data, tables just got broken. -- Leonardo Mateo. There''s no place like ~
Greg Donald wrote:> On Tue, Oct 6, 2009 at 4:10 PM, Marnen Laibow-Koser > <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote: >> PostgreSQL is my default choice for all projects. > > I usually think about the specs and requirements, then make a choice.So do I. But the type of projects I do are generally ones that are well suited to PostgreSQL. Anyway, mySQL and SQLite are problematic, and MS SQL and Oracle are too expensive to be justifiable for the sort of stuff I work on. So that doesn''t leave me much choice. :)> > > -- > Greg Donald > http://destiney.com/Best, -- Marnen Laibow-Koser http://www.marnen.org marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org -- Posted via http://www.ruby-forum.com/.
On Wed, Oct 7, 2009 at 5:50 AM, Marnen Laibow-Koser <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> Anyway, mySQL and SQLite are problematicI''ve used both much success over the years. What sort of problems are you having? -- Greg Donald http://destiney.com/
I too choose PostgreSQL by default. Here are some of my reasons. 1) It adheres more reliably to SQL standard than MySQL. 2) PostgreSQL has a better query planner than MySQL. 3) The number value zero in MySQL is treated NULL. 4) The default settings for MySQL make it case IN-sensitive. 5) Until version 5.0, MySQL did not support referential integrity, or advanced features like views, transactions, or triggers. Just my thoughts. Andrew
Andrew Pace wrote:> I too choose PostgreSQL by default. > > Here are some of my reasons. > > 1) It adheres more reliably to SQL standard than MySQL. > 2) PostgreSQL has a better query planner than MySQL. > 3) The number value zero in MySQL is treated NULL. > 4) The default settings for MySQL make it case IN-sensitive. > 5) Until version 5.0, MySQL did not support referential integrity, or > advanced features like views, transactions, or triggers.What he said. Also: * mySQL''s procedural language sucks (less of a problem than it used to be, since I don''t use stored procedures as much). * I use PostGIS a lot. There is nothing comparable for mySQL. * MySQL makes you choose between speed and data integrity. PostgreSQL does not. * I have yet to see anything in mySQL that Postgres cannot do better.> > Just my thoughts. > > AndrewBest, -- Marnen Laibow-Koser http://www.marnen.org marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org -- Posted via http://www.ruby-forum.com/.
> Here are some of my reasons. > > 1) It adheres more reliably to SQL standard than MySQL. > 2) PostgreSQL has a better query planner than MySQL. > 3) The number value zero in MySQL is treated NULL. > 4) The default settings for MySQL make it case IN-sensitive. > 5) Until version 5.0, MySQL did not support referential integrity, or > advanced features like views, transactions, or triggers.Actually, the only true reason to choose PostgreSQL over MySQL is this: you know PostgresSQL better. As for transaction support in MySQL it is not even funny anymore. But just in case: MySQL supports transactions since version 3.23.34a Regards, Rimantas -- http://rimantas.com/
On Wed, Oct 7, 2009 at 10:02 AM, Andrew Pace <andrewppace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > I too choose PostgreSQL by default. > > Here are some of my reasons. > > 1) It adheres more reliably to SQL standard than MySQL.No it doesn''t, they are both standards compliant.> 2) PostgreSQL has a better query planner than MySQL.MySQL''s explain works great for me. http://dev.mysql.com/doc/refman/5.0/en/using-explain.html Looks nearly identical to the PostgreSQL offering: http://www.postgresql.org/docs/8.4/static/using-explain.html> 3) The number value zero in MySQL is treated NULL.That''s a lie. mysql> select * from test; +----+--------+ | id | number | +----+--------+ | 1 | 0 | +----+--------+ 1 row in set (0.00 sec) mysql> select * from test where number is null; Empty set (0.00 sec)> 4) The default settings for MySQL make it case IN-sensitive.So what? You can easily make an individual table case sensitive by creating it with proper binary collation. mysql> create table test3 (name varchar(255)) character set latin1 collate latin1_bin; Query OK, 0 rows affected (0.04 sec) mysql> insert into test3 values (''Frank''),(''Google''),(''froogle''),(''flickr''),(''FlicKr''); Query OK, 5 rows affected (0.00 sec) Records: 5 Duplicates: 0 Warnings: 0 mysql> SELECT * FROM test3 WHERE name LIKE ''F%''; +--------+ | name | +--------+ | Frank | | FlicKr | +--------+ 2 rows in set (0.00 sec) mysql> SELECT * FROM test3 WHERE name LIKE ''f%''; +---------+ | name | +---------+ | froogle | | flickr | +---------+ 2 rows in set (0.00 sec)> 5) Until version 5.0, MySQL did not support referential integrity, or > advanced features like views, transactions, or triggers.This argument is useless. There''s a ton of things PostgreSQL used to not do when it was < 5.0. Replication, binary field storage, etc. -- Greg Donald http://destiney.com/
On Wed, Oct 7, 2009 at 10:27 AM, Rimantas Liubertas <rimantas-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> MySQL supports transactions since version 3.23.34aMySQL had replication before PostgreSQL too, I know I worked for a startup that helped fund it. MySQL supports 7 different table types so you choose the right type for the data at hand. PostgreSQL support one table type. PostgreSQL doesn''t even store user/host permissions in a database, talk about not eating your own dog food. -- Greg Donald http://destiney.com/
On Wed, Oct 7, 2009 at 10:11 AM, Marnen Laibow-Koser <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> * I use PostGIS a lot. There is nothing comparable for mySQL.This is a lie. http://dev.mysql.com/doc/refman/5.0/en/spatial-extensions.html> * MySQL makes you choose between speed and data integrity. PostgreSQL > does not.PostgreSQL has one table type. MySQL gives you 7 different table types to choose from. Sounds like you''re either not smart enough to choose the right one or you didn''t know you could make a choice. I''ve never has any speed problems with MySQL, even using it on mega-sites like ezsweeps.com back in the late 90''s. -- Greg Donald http://destiney.com/
>> 2) PostgreSQL has a better query planner than MySQL. > > MySQL''s explain works great for me. > > http://dev.mysql.com/doc/refman/5.0/en/using-explain.html > > Looks nearly identical to the PostgreSQL offering: > > http://www.postgresql.org/docs/8.4/static/using-explain.htmlI think what the GP was trying to say is that PostgreSQL picks a better execution plan for the query than MySQL does. Not all the time, but certainly some of the time. Several months ago I had both servers setup with the defaults, same schema, same indexes, same dataset, same query. The query was a three table join. Two smaller tables, one with 30,000 rows. PostgreSQL finished almost immediately. MySQL took 3 seconds. It kind of shocked me. I ran explain on both and MySQL simply would not use some of the indexes provided. This was with a 5.0-something release of MySQL. I''d heard that before, but it''s still an issue in certain situations.>> 3) The number value zero in MySQL is treated NULL. > > That''s a lie.Glad to know that''s fixed! It was true awhile back. So where the issues of inserting data that is too long and having it be silently truncated -- yes, I''m ignoring the warnings MySQL provides. It should raise an error... I notice that as of 5.0.51a-24 it still turns invalid dates into 0000-00-00 (with the warning, but no error).>> 5) Until version 5.0, MySQL did not support referential integrity, or >> advanced features like views, transactions, or triggers. > > This argument is useless. There''s a ton of things PostgreSQL used to > not do when it was < 5.0. Replication, binary field storage, etc.That''s not a very fair comparison. Version numbers are meaningless.. Compare the versions at the same time... I will happily agree that prior to 7.x postgres had some issues with these things. Replication is still not as simple as MySQL''s, but there are solutions out there. I''d suggest we let the original poster do some research on his own and figure out what works best. MySQL vs PostgreSQL is like VI vs Emacs vs TextMate :-) I don''t know how current these pages are, but they are interesting... http://sql-info.de/mysql/gotchas.html http://sql-info.de/postgresql/postgres-gotchas.html -philip
Rimantas Liubertas wrote: [...]> Actually, the only true reason to choose PostgreSQL over MySQL is this: > you know PostgresSQL better.Quite wrong. I know mySQL, if anything, a bit better than PostgreSQL. I know it well enough that I have run into its limitations, discovered that there''s no way around many of them, and given up on it as a result. I might even go so far as to say that the only reason to use mySQL is that you''re unaware of superior alternatives. :)> As for transaction support in MySQL it is not even funny anymore. But > just in case: > MySQL supports transactions since version 3.23.34aSure -- in InnoDB. If you need transactions and full-text search on the same table, or if you need the speed of MyISAM, you''re out of luck.> > > Regards, > Rimantas > -- > http://rimantas.com/Best, -- Marnen Laibow-Koser http://www.marnen.org marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org -- Posted via http://www.ruby-forum.com/.
Greg Donald wrote:> On Wed, Oct 7, 2009 at 10:11 AM, Marnen Laibow-Koser > <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote: >> * I use PostGIS a lot. There is nothing comparable for mySQL. > > This is a lie.Surely you can tell me you think I''m wrong without resorting to calling me a liar. Let''s keep this debate as civil as possible. :)> > http://dev.mysql.com/doc/refman/5.0/en/spatial-extensions.htmlSrsly? You''re claiming that these are comparable to PostGIS? As someone who has worked with both, let me assure you that they are not. In fact, my first PostGIS project was originally going to use mySQL and these very features. It quickly became clear to me that although I wasn''t doing anything fancy, mySQL would not suit my needs. So I found PostGIS, which got me into PostgreSQL (which, at the time, I knew nothing about). I can''t imagine going back.> >> * MySQL makes you choose between speed and data integrity. �PostgreSQL >> does not. > > PostgreSQL has one table type. MySQL gives you 7 different table > types to choose from. > > Sounds like you''re either not smart enough to choose the right one or > you didn''t know you could make a choice.Again, I''m sure you could have said this without insulting my intelligence. Anyway, I do know about mySQL''s plethora of storage engines. So tell me: which one (no, BLACKHOLE doesn''t count :) ) will get me transactions, foreign-key checking, and full-text search in the same table? As far as I know, the answer is none.> > I''ve never has any speed problems with MySQL, even using it on > mega-sites like ezsweeps.com back in the late 90''s.Fair enough. I have had speed problems with mySQL, but I''m not certain whether the cause was mySQL itself, poor DB design, or poor setup (and at the time, I really couldn''t tell).> > > -- > Greg Donald > http://destiney.com/Best, -- Marnen Laibow-Koser http://www.marnen.org marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org -- Posted via http://www.ruby-forum.com/.
On Wed, Oct 7, 2009 at 11:21 AM, Philip Hallstrom <philip-LSG90OXdqQE@public.gmane.org> wrote:> So where the > issues of inserting data that is too long and having it be silently > truncated -- yes, I''m ignoring the warnings MySQL provides. It should > raise an error...It does raise an error if you''re knowledgeable enough to know about the various strict modes you can set: mysql> create table test4 (name char(3)); Query OK, 0 rows affected (0.03 sec) mysql> insert into test4 values (''four''); Query OK, 1 row affected, 1 warning (0.00 sec) mysql> SELECT * FROM test4; +------+ | name | +------+ | fou | +------+ 1 row in set (0.00 sec) mysql> SET SQL_MODE = ''STRICT_ALL_TABLES''; Query OK, 0 rows affected (0.00 sec) mysql> insert into test4 values (''four''); ERROR 1406 (22001): Data too long for column ''name'' at row 1> I notice that as of 5.0.51a-24 it still turns invalid dates into > 0000-00-00 (with the warning, but no error).Similarly there is NO_ZERO_DATE strict mode for use with dates. -- Greg Donald http://destiney.com/
On Wed, Oct 7, 2009 at 11:51 AM, Marnen Laibow-Koser <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> Surely you can tell me you think I''m wrong without resorting to calling > me a liar. Let''s keep this debate as civil as possible. :)You lied. Stop telling lies and your problem will solve itself.> Srsly? You''re claiming that these are comparable to PostGIS?They have served me well. What problems are you having? -- Greg Donald http://destiney.com/
On Wed, Oct 7, 2009 at 11:21 AM, Marnen Laibow-Koser <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> Sure -- in InnoDB. If you need transactions and full-text search on the > same table, or if you need the speed of MyISAM, you''re out of luck.You can easily replicate a table to another table of a different type. What''s the PostgreSQL analogue for taking away table features you don''t need? Oh, right, there is none. You''re stuck with that one "everything but the kitchen sink" table type. -- Greg Donald http://destiney.com/
Greg Donald wrote:> On Wed, Oct 7, 2009 at 11:51 AM, Marnen Laibow-Koser > <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote: >> Surely you can tell me you think I''m wrong without resorting to calling >> me a liar. �Let''s keep this debate as civil as possible. :) > > You lied. Stop telling lies and your problem will solve itself.I did not lie. I stand by my original statement and see no reason to retract or revise it. I''m not "telling lies" as you claim -- I''m stating what I believe is true. You may disagree, but that doesn''t make either one of us a liar.> >> Srsly? �You''re claiming that these are comparable to PostGIS? > > They have served me well. What problems are you having?Oh, just that they were too underpowered to be of any use at all in implementing a simple geocoded system (terrestrial coordinates, spheroidal distance calculation) -- which PostGIS does beautifully. MySQL''s spatial features might be OK for some abstract geometry use cases, but that''s about it.> > > -- > Greg Donald > http://destiney.com/Best, -- Marnen Laibow-Koser http://www.marnen.org marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org -- Posted via http://www.ruby-forum.com/.
On Wed, Oct 7, 2009 at 12:27 PM, Marnen Laibow-Koser <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> I did not lie. I stand by my original statement and see no reason to > retract or revise it.You did lie. I have the email right in front of me. You said "I use PostGIS a lot. There is nothing comparable for mySQL.". Then I showed you the url for the MySQL spacial extension. Here it is again in case you missed it: http://dev.mysql.com/doc/refman/5.0/en/spatial-extensions.html It was created to solve the same problem as PostGIS, therefore they are indeed "comparable".> I''m not "telling lies" as you claim -- I''m stating what I believe is > true.Believe what you want, it doesn''t make your lie true. -- Greg Donald http://destiney.com/
Greg Donald wrote:> On Wed, Oct 7, 2009 at 12:27 PM, Marnen Laibow-Koser > <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote: >> I did not lie. �I stand by my original statement and see no reason to >> retract or revise it. > > You did lie. I have the email right in front of me. You said "I use > PostGIS a lot. There is nothing comparable for mySQL.". > > Then I showed you the url for the MySQL spacial extension. Here it is > again in case you missed it: > > http://dev.mysql.com/doc/refman/5.0/en/spatial-extensions.html > > It was created to solve the same problem as PostGIS, therefore they > are indeed "comparable".No. I saw that assertion, and I disagree with it. Their feature sets are not comparable. They cannot be used comparably in my experience. Perhaps you''d like to respond to my statements with *data* and *facts*, not ad hominem attacks.> > >> I''m not "telling lies" as you claim -- I''m stating what I believe is >> true. > > Believe what you want, it doesn''t make your lie true.If I am stating what I believe to be true, then by definition it is not a lie. It may be an error, but it is not a lie. Or should I start calling you a liar because I believe you''re simply wrong?> > > > -- > Greg Donald > http://destiney.com/Best, -- Marnen Laibow-Koser http://www.marnen.org marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org Best, -- Marnen Laibow-Koser http://www.marnen.org marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org -- Posted via http://www.ruby-forum.com/.
> Quite wrong. I know mySQL, if anything, a bit better than PostgreSQL.No you do not. You did not even know SQL_MODE. <…> Regards, Rimantas -- http://rimantas.com/
Greg Donald wrote:> On Wed, Oct 7, 2009 at 11:21 AM, Philip Hallstrom <philip-LSG90OXdqQE@public.gmane.org> wrote: >> So where the >> issues of inserting data that is too long and having it be silently >> truncated -- yes, I''m ignoring the warnings MySQL provides. It should >> raise an error... > > It does raise an error if you''re knowledgeable enough to know about > the various strict modes you can set:What is the default behavior?
Rimantas Liubertas wrote:>> Quite wrong. I know mySQL, if anything, a bit better than PostgreSQL. > > No you do not. You did not even know SQL_MODE. > <…>Yes, you found an obscure setting that I was unaware of. I''m sure there are more. I don''t know 100% of either system''s config parameters, and I don''t claim to. But I do know both systems well enough to have used both for advanced development.> > > Regards, > Rimantas > -- > http://rimantas.com/Best, -- Marnen Laibow-Koser http://www.marnen.org marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org -- Posted via http://www.ruby-forum.com/.
Guys, you''re turning this into a DB flamewar and I''m sure that''s what this thread was ment to. The thread title asks for the easiest DB for scaling. I agree that PostGIS rocks, and I don''t agree that MySQL sucks. I like PostgreSQL very much over MySQL, I think the logos for each product speak for themselves (a dolphin vs an elephant) and I also like PostgreSQL because of its "opensourceness" overall. But that''s all, it''s a matter of tastes and/or experiences with one or the other. This is not a flame war. Let''s help the guy here, after all, that''s what a mailing list should be useful for. Cheers. -- Leonardo Mateo. There''s no place like ~
On Wed, Oct 7, 2009 at 12:52 PM, Marnen Laibow-Koser <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> Their feature sets > are not comparable. They cannot be used comparably in my experience.That''s like saying you don''t drive red cars very much so it''s impossible to compare red cars and blue cars. -- Greg Donald http://destiney.com/
On Wed, Oct 7, 2009 at 1:06 PM, Marnen Laibow-Koser <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> Yes, you found an obscure settingObscure? It''s right there in the documentation! Jesus Christ man, it''s not like I went digging on some mailing list from 1997 to find it. I mean really, does this page/url look obscure? http://dev.mysql.com/doc/refman/5.0/en/server-sql-mode.html The version from 5+ years ago is even still available: http://dev.mysql.com/doc/refman/4.1/en/server-sql-mode.html> that I was unaware of. I''m sure there > are more. I don''t know 100% of either system''s config parameters, and I > don''t claim to. But I do know both systems well enough to have used > both for advanced development.That''s fine. But don''t start bashing MySQL thinking you know something about it when clearly you don''t. -- Greg Donald http://destiney.com/
Greg Donald wrote:> On Wed, Oct 7, 2009 at 1:06 PM, Marnen Laibow-Koser > <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote: >> Yes, you found an obscure setting > > Obscure? It''s right there in the documentation! Jesus Christ man, > it''s not like I went digging on some mailing list from 1997 to find > it. > > I mean really, does this page/url look obscure? > > http://dev.mysql.com/doc/refman/5.0/en/server-sql-mode.html > > The version from 5+ years ago is even still available: > > http://dev.mysql.com/doc/refman/4.1/en/server-sql-mode.html > > >> that I was unaware of. I''m sure there >> are more. I don''t know 100% of either system''s config parameters, and I >> don''t claim to. But I do know both systems well enough to have used >> both for advanced development. > > That''s fine. But don''t start bashing MySQL thinking you know > something about it when clearly you don''t.that''s something of a leap. Just because someone doesn''t know about a particular feature of MySQL does not negate them knowing "something about it."
On Wed, Oct 7, 2009 at 4:26 PM, Rob Saul <wyrd-Aea8cEl6xhQfJMFsPlWfYti2O/JbrIOy@public.gmane.org> wrote:>> That''s fine. But don''t start bashing MySQL thinking you know >> something about it when clearly you don''t. > > that''s something of a leap. Just because someone doesn''t know > about a particular feature of MySQL does not negate them > knowing "something about it."The only leap I''m seeing here is a database bigot claiming MySQL doesn''t do something when it has had the capability for more than 5 years. PostgreSQL is a fine database (I''ve been using it forever too) but loving it doesn''t doesn''t give you the right to spread lies about MySQL. -- Greg Donald http://destiney.com/
Greg Donald wrote:> On Wed, Oct 7, 2009 at 4:26 PM, Rob Saul <wyrd-Aea8cEl6xhQfJMFsPlWfYti2O/JbrIOy@public.gmane.org> wrote: >>> That''s fine. �But don''t start bashing MySQL thinking you know >>> something about it when clearly you don''t. >> >> that''s something of a leap. Just because someone doesn''t know >> about a particular feature of MySQL does not negate them >> knowing "something about it." > > The only leap I''m seeing here is a database bigot claiming MySQL > doesn''t do something when it has had the capability for more than 5 > years.You''re dragging in an irrelevant issue from a whole different discussion that forms a minor -- or rather, negligible -- part of my dislike of mySQL. And for the record, I''m not a database bigot. I love mySQL''s friendliness and ease of setup, but I think it has severe shortcomings. If those shortcomings were fixed, or if I turn out to be wrong about the ones that affect me, I would be *very* happy to never touch Postgres again.> PostgreSQL is a fine database (I''ve been using it forever too) > but loving it doesn''t doesn''t give you the right to spread lies about > MySQL.Of course it doesn''t. Which is why I don''t do that.> > > -- > Greg Donald > http://destiney.com/Best, -- Marnen Laibow-Koser http://www.marnen.org marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org -- Posted via http://www.ruby-forum.com/.
On Wed, Oct 7, 2009 at 2:43 PM, Greg Donald <gdonald-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > On Wed, Oct 7, 2009 at 4:26 PM, Rob Saul <wyrd-Aea8cEl6xhQfJMFsPlWfYti2O/JbrIOy@public.gmane.org> wrote: >>> That''s fine. But don''t start bashing MySQL thinking you know >>> something about it when clearly you don''t. >> >> that''s something of a leap. Just because someone doesn''t know >> about a particular feature of MySQL does not negate them >> knowing "something about it." > > The only leap I''m seeing here is a database bigot claiming MySQL > doesn''t do something when it has had the capability for more than 5 > years. PostgreSQL is a fine database (I''ve been using it forever too) > but loving it doesn''t doesn''t give you the right to spread lies about > MySQL.You know what the saddest part of this little flame war? It''s not even on topic. The OP asked about scalability and you''re all in a pissing contest over GIS support and default settings and how they affect date conversions. Seriously, you''d think someone insulted their mother based on the accusations flying around. Grow up. -- Aaron Turner http://synfin.net/ http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix & Windows Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin
Aaron Turner wrote:> On Wed, Oct 7, 2009 at 2:43 PM, Greg Donald <gdonald-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: >> doesn''t do something when it has had the capability for more than 5 >> years. �PostgreSQL is a fine database (I''ve been using it forever too) >> but loving it doesn''t doesn''t give you the right to spread lies about >> MySQL. > > You know what the saddest part of this little flame war? It''s not > even on topic.I had noticed that, and failed to act on that realization. You''re quite right. Best, -- Marnen Laibow-Koser http://www.marnen.org marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org -- Posted via http://www.ruby-forum.com/.
Greg Donald wrote:> On Wed, Oct 7, 2009 at 5:50 AM, Marnen Laibow-Koser > <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote: >> Anyway, mySQL and SQLite are problematic > > I''ve used both much success over the years. What sort of problems are > you having?This is my main reason against MySQL: PostgreSQL has a transactional DDL so when a Rails migration breaks the database undoes all the changes it made. MySQL leaves the database half-changed and maybe in an inconsistent state. That''s awful when it happens in production, maybe in a migration that was moving data around after having removed and added columns. It''s not always possible to test everything in pre-preproduction so PostgreSQL is a much safer than choice MySQL. Granted, it''s probably possible to code around this limitation of MySQL but it costs more than just using a (IMHO) better db. Paolo -- Posted via http://www.ruby-forum.com/.
Diego, Have a look at a version of MySql, Percona: http://www.percona.com/percona-lab.html It is an improved version of MySql and they have an improvement of InnoDB, XtraDB. I would just use a dedicated server for your DB, quad- core with a lot of RAM, that''s all. In the future you can add more MySql server in read mode... there are few ways to run MySql in a cluster. Check out this book for MySql performance, clusters and more: http://amzn.com/0596101716 On Oct 7, 7:06 pm, Marnen Laibow-Koser <rails-mailing-l...@andreas- s.net> wrote:> Rimantas Liubertas wrote: > >> Quite wrong. I know mySQL, if anything, a bit better than PostgreSQL. > > > No you do not. You did not even know SQL_MODE. > > <…> > > Yes, you found an obscure setting that I was unaware of. I''m sure there > are more. I don''t know 100% of either system''s config parameters, and I > don''t claim to. But I do know both systems well enough to have used > both for advanced development. > > > > > Regards, > > Rimantas > > -- > >http://rimantas.com/ > > Best, > -- > Marnen Laibow-Koserhttp://www.marnen.org > mar...-sbuyVjPbboAdnm+yROfE0A@public.gmane.org > -- > Posted viahttp://www.ruby-forum.com/.
(first of all, sry about my english) Ive been studing postgres and mysql, and they have theirs pros and cons. For me postgresql pros: - Im using OLAP, dont have alot of data today, but its growing, and is very intensive query, everyone say that postgresql is better on complex queries. - pl/ruby, this can help offloading somes intensive operations from application to databse, and programming in ruby :) (very, very, very nice!) For me mysql pros: - Easy to setup - Scalling is easy - Have more administrative tools Maybe i can have both databases, the main mysql running the whole website, something like the 37signalx box, lots of cores and memory and one postgresql database to run olap queries. What you guys think about it!? One thin im worry about in Mysql is data integrity, this is solved using InnoDB? or still Postgres more safe? Im talking about everything, transactions, corrupted data, incosistent data and so. Another question, about full text search, its better stick with the one inside de database or something external like Sphinx!? Im worring about speed and easy of use. Thanks everyone for helping me :) -- Posted via http://www.ruby-forum.com/.
> - Im using OLAP, dont have alot of data today, but its growing, and is > very intensive query, everyone say that postgresql is better on complex > queries.Generalizations like these do not make any sense because of lots and lots of variables involved: data set structure, size, query type, schema design, indexes, db engine in MySQL case, RAM, hardware, etc. Everything should bet tuned for particular task and only in that context we can talk about speed. Saying "X is slow and Y is fast" means nothing without context. And even in the case query Q is faster on dataset D on database X does not mean that database Y cannot be tuned to perform faster than that. <…>> Another question, about full text search, its better stick with the one > inside de database or something external like Sphinx!? Im worring about > speed and easy of use.My vote goes for Sphinx. MySQL full text search limits you to MyISAM tables and is only suitable if you need very basic search features and you dataset is not very big. PostgreSQL seems to have more advanced implementation but I doubt it can beat Sphinx in terms of features and speed. Regards, Rimantas -- http://rimantas.com/
>> Another question, about full text search, its better stick with the >> one >> inside de database or something external like Sphinx!? Im worring >> about >> speed and easy of use. > > My vote goes for Sphinx. MySQL full text search limits you to MyISAM > tables and is only suitable if you need very basic search features > and you > dataset is not very big. > > PostgreSQL seems to have more advanced implementation but I doubt > it can beat Sphinx in terms of features and speed.Agreed. tsearch2 is good, but being able to split off your search onto other hardware and not hit the database is also nice... Sphinx along with the thinking sphinx plugin is awesome.