Comments on: Least common denominator http://blog.amber.org/2005/09/27/least-common-denominator/ Thoughts of a minor lunatic Thu, 24 Jul 2008 08:53:36 +0000 http://wordpress.org/?v=2.6 By: Balance On Rails : David Hansson e Opinionated Software http://blog.amber.org/2005/09/27/least-common-denominator/#comment-45792 Balance On Rails : David Hansson e Opinionated Software Tue, 05 Dec 2006 15:39:02 +0000 http://blog.amber.org/2005/09/27/least-common-denominator/#comment-45792 [...] Christopher Petrilli repete um frequente mal-entendido sobre Active Record, o ORM de Rails, em Menor Denominador Comum. O raciocínio diz que o MySQL está nos segurando de tomar vantagem de funcionalidades mais avançadas dos bancos de dados disponíveis no PostgreSQL, Oracle e outros. E que se pelo menos MySQL fosse mais esperto, tivesse mais funcionalidades, estaríamos abrançando-as de braços abertos. Errado. [...] [...] Christopher Petrilli repete um frequente mal-entendido sobre Active Record, o ORM de Rails, em Menor Denominador Comum. O raciocínio diz que o MySQL está nos segurando de tomar vantagem de funcionalidades mais avançadas dos bancos de dados disponíveis no PostgreSQL, Oracle e outros. E que se pelo menos MySQL fosse mais esperto, tivesse mais funcionalidades, estaríamos abrançando-as de braços abertos. Errado. [...]

]]> By: petrilli http://blog.amber.org/2005/09/27/least-common-denominator/#comment-6066 petrilli Wed, 29 Mar 2006 16:36:59 +0000 http://blog.amber.org/2005/09/27/least-common-denominator/#comment-6066 Actually MySQL still, in my experience, has all sorts of bizarre bogosity related to things it'll accept and silently do the wrong thing without warnings. That's just unforgivable. Referential integrity, etc., can of course be over-used, and some people might argue it should never be used, but I see it as a last line of defense for data. There are simply certain values, certain behaviors, that are never acceptable. Ever. Also, much of what I do ends up being an integration database for various reasons outside my control, and therefore the DB is one of the few places to enforce data integrity. If everything was a trivial PHP app, then the world would be different. But they're not, fortunately. Actually MySQL still, in my experience, has all sorts of bizarre bogosity related to things it’ll accept and silently do the wrong thing without warnings. That’s just unforgivable.

Referential integrity, etc., can of course be over-used, and some people might argue it should never be used, but I see it as a last line of defense for data. There are simply certain values, certain behaviors, that are never acceptable. Ever. Also, much of what I do ends up being an integration database for various reasons outside my control, and therefore the DB is one of the few places to enforce data integrity.

If everything was a trivial PHP app, then the world would be different. But they’re not, fortunately.

]]> By: Kelvin Westlake http://blog.amber.org/2005/09/27/least-common-denominator/#comment-6065 Kelvin Westlake Wed, 29 Mar 2006 14:52:47 +0000 http://blog.amber.org/2005/09/27/least-common-denominator/#comment-6065 MySQL was lacking in certain aspects until its more recent incarnation (perhaps still is) - But lets put the boot on the other foot, to many system have limitations due to the overkeen usage of referential integrity and stored proceedures. Unless theres multi-tier modelling reasons for this, processing and data validation should be performed within the top layer - burying this deep down makes them difficult to debug and more expensive to maintain. MySQL was lacking in certain aspects until its more recent incarnation (perhaps still is) – But lets put the boot on the other foot, to many system have limitations due to the overkeen usage of referential integrity and stored proceedures.

Unless theres multi-tier modelling reasons for this, processing and data validation should be performed within the top layer – burying this deep down makes them difficult to debug and more expensive to maintain.

]]> By: » Rails schema migrations : Pensieri di un lunatico minore http://blog.amber.org/2005/09/27/least-common-denominator/#comment-5412 » Rails schema migrations : Pensieri di un lunatico minore Mon, 20 Feb 2006 05:06:26 +0000 http://blog.amber.org/2005/09/27/least-common-denominator/#comment-5412 [...] 1 I suspect this is another latent sloppiness inherited from the MySQL brain-damage. MySQL, at least as late as 4.1, doesn’t really integrate transactions and DDL, and never will outside the InnoDB engine. This means you can’t actually have atomic schema migrations. Bad juju if you ask me. [...] [...] 1 I suspect this is another latent sloppiness inherited from the MySQL brain-damage. MySQL, at least as late as 4.1, doesn’t really integrate transactions and DDL, and never will outside the InnoDB engine. This means you can’t actually have atomic schema migrations. Bad juju if you ask me. [...]

]]> By: Cliff Wells http://blog.amber.org/2005/09/27/least-common-denominator/#comment-4961 Cliff Wells Sun, 18 Dec 2005 21:18:08 +0000 http://blog.amber.org/2005/09/27/least-common-denominator/#comment-4961 This is also why Rails isn't as DRY as it would like to be. As Robby Russell mentions, it's fairly easy to add support for foreign keys to your model, except that now you are defining your model in two places... definitely a case of repeating yourself. I think there may be technical reasons for compromises, but to claim they aren't compromises (and even coin phrases to add legitimacy: i.e. "single layer of cleverness") borders on dishonesty. My feeling on MySQL is much the same as many programmers feel about BASIC (or these days, PHP): it causes permanent brain-damage in otherwise apparently smart people. This is also why Rails isn’t as DRY as it would like to be. As Robby Russell mentions, it’s fairly easy to add support for foreign keys to your model, except that now you are defining your model in two places… definitely a case of repeating yourself. I think there may be technical reasons for compromises, but to claim they aren’t compromises (and even coin phrases to add legitimacy: i.e. “single layer of cleverness”) borders on dishonesty.

My feeling on MySQL is much the same as many programmers feel about BASIC (or these days, PHP): it causes permanent brain-damage in otherwise apparently smart people.

]]> By: Perrin Harkins http://blog.amber.org/2005/09/27/least-common-denominator/#comment-4002 Perrin Harkins Thu, 06 Oct 2005 18:34:17 +0000 http://blog.amber.org/2005/09/27/least-common-denominator/#comment-4002 MySQL has had transactions and foreign key constraints for several years. Extracting primary key and referential integrity data through DESCRIBE TABLE commands works fine, and the ORM framework I use supports this and uses this data. No naming convention requred. It's fair to complain that this data isn't available in a standard SQL way (unless you use 5.0), but saying it isn't available at all is incorrect. MySQL has had transactions and foreign key constraints for several years. Extracting primary key and referential integrity data through DESCRIBE TABLE commands works fine, and the ORM framework I use supports this and uses this data. No naming convention requred. It’s fair to complain that this data isn’t available in a standard SQL way (unless you use 5.0), but saying it isn’t available at all is incorrect.

]]> By: Louis http://blog.amber.org/2005/09/27/least-common-denominator/#comment-3463 Louis Sat, 01 Oct 2005 20:07:40 +0000 http://blog.amber.org/2005/09/27/least-common-denominator/#comment-3463 MySQL is perfectly free for use if you want to make money with what you're doing - the difference is you cannot *include* MySQL or use the embedded MySQL database (I believe), if you aren't writing GPL software. It's a bit of a myth that you have to pay MySQL AB to use their database in "for profit" software. Instead, you can pay MySQL AB for their support, or to distribute it easily with your product. That's all. So for developers, and many competent administrators, it's entirely free to develop and deploy with. And that's why it's popular. MySQL AB used to be very open about the differences between the GPL and Non-GPL licenses for their product, but since the new website redesign focused at enterprises, they've started to hide, or not talk about this. Instead, they've rebranded the two, to make businesses want to purchase the "Network Edition" instead of using the "Community Edition", see: http://www.mysql.com/network/compare.html Which is fine. It just means that if you want something for free, you've got it, and if you want to pay for something with the assurance of support and all the extra perks, you can do that too. It fits Rails / "Get Real" perfectly - you can start simple, and "scale out" as you depend on it more. MySQL is perfectly free for use if you want to make money with what you’re doing – the difference is you cannot include MySQL or use the embedded MySQL database (I believe), if you aren’t writing GPL software.

It’s a bit of a myth that you have to pay MySQL AB to use their database in “for profit” software. Instead, you can pay MySQL AB for their support, or to distribute it easily with your product. That’s all. So for developers, and many competent administrators, it’s entirely free to develop and deploy with. And that’s why it’s popular.

MySQL AB used to be very open about the differences between the GPL and Non-GPL licenses for their product, but since the new website redesign focused at enterprises, they’ve started to hide, or not talk about this.

Instead, they’ve rebranded the two, to make businesses want to purchase the “Network Edition” instead of using the “Community Edition”, see: http://www.mysql.com/network/compare.html

Which is fine. It just means that if you want something for free, you’ve got it, and if you want to pay for something with the assurance of support and all the extra perks, you can do that too. It fits Rails / “Get Real” perfectly – you can start simple, and “scale out” as you depend on it more.

]]> By: petrilli http://blog.amber.org/2005/09/27/least-common-denominator/#comment-3350 petrilli Fri, 30 Sep 2005 12:33:02 +0000 http://blog.amber.org/2005/09/27/least-common-denominator/#comment-3350 MySQL is free if you obsess over the GPL and ignore everything else. It's not free if you're in anyway "for profit." PostgreSQL, which is comparable to Oracle for most applications (80% or more) in capabilities is licensed under the BSD license, which is basically "do whatever." MySQL is free if you obsess over the GPL and ignore everything else. It’s not free if you’re in anyway “for profit.” PostgreSQL, which is comparable to Oracle for most applications (80% or more) in capabilities is licensed under the BSD license, which is basically “do whatever.”

]]> By: ECC http://blog.amber.org/2005/09/27/least-common-denominator/#comment-3322 ECC Fri, 30 Sep 2005 04:58:09 +0000 http://blog.amber.org/2005/09/27/least-common-denominator/#comment-3322 Forgot to add: There used to be a section in the MySQL docs (can't find the link), justifying their lack of transactions, and saying something like: "Data can *always* get lost. You *always* need backups, even if you were to have transactions. Even the famed Oracle is reputed to have lost data..." ...whew Forgot to add: There used to be a section in the MySQL docs (can’t find the link), justifying their lack of transactions, and saying something like:

“Data can always get lost. You always need backups, even if you were to have transactions. Even the famed Oracle is reputed to have lost data…”

...whew

]]> By: ECC http://blog.amber.org/2005/09/27/least-common-denominator/#comment-3319 ECC Fri, 30 Sep 2005 04:37:16 +0000 http://blog.amber.org/2005/09/27/least-common-denominator/#comment-3319 Glad you said it in print! Most people don't realize how feeble MySQL really is. And let's not kid ourselves: the reason it's become popular is because it's fast, easy, and most of all *free*! Which is more than we can say of any "real" databse (though I have no experience with Postgres). What DB do you recommend that meets those requirements? Glad you said it in print!

Most people don’t realize how feeble MySQL really is.

And let’s not kid ourselves: the reason it’s become popular is because it’s fast, easy, and most of all free! Which is more than we can say of any “real” databse (though I have no experience with Postgres). What DB do you recommend that meets those requirements?

]]> By: petrilli http://blog.amber.org/2005/09/27/least-common-denominator/#comment-3134 petrilli Wed, 28 Sep 2005 02:35:35 +0000 http://blog.amber.org/2005/09/27/least-common-denominator/#comment-3134 It's definately one of those "one of these things is not like the other" situations. Rather than dumbing the software down for a poor excuse for a database (really more of a structured file), you should write for the real target, and if you feel some over-arching need for portability, something that's severely over-rated around databases, then you should fill in where other's lack. The truth of the matter is that portability between most full-featured databses is pretty simple, and mostly a matter of syntax, and sometimes more work on stored proceedures. When MySQL is injected, you have to rip out the data-integrity component that should be in the store, and put it in the applications. That's a piss-poor decision. It’s definately one of those “one of these things is not like the other” situations. Rather than dumbing the software down for a poor excuse for a database (really more of a structured file), you should write for the real target, and if you feel some over-arching need for portability, something that’s severely over-rated around databases, then you should fill in where other’s lack.

The truth of the matter is that portability between most full-featured databses is pretty simple, and mostly a matter of syntax, and sometimes more work on stored proceedures. When MySQL is injected, you have to rip out the data-integrity component that should be in the store, and put it in the applications. That’s a piss-poor decision.

]]> By: Charles McKnight http://blog.amber.org/2005/09/27/least-common-denominator/#comment-3113 Charles McKnight Tue, 27 Sep 2005 20:44:27 +0000 http://blog.amber.org/2005/09/27/least-common-denominator/#comment-3113 Opinion: [Insert database/application/etc. name] is an excellent choice for a certain subset of problems. However, it is a poor choice for other problems. The adage about a carpenter knowing his tools and having a large number of tools to draw on is the most appropriate, yet least used approach when constructing applications/systems/etc. The specialist, per Mills, is the individual who continually focuses on an ever-decreasing scope approaching epsilon until at some point the specialist knows nothing about anything. Opinion:

[Insert database/application/etc. name] is an excellent choice for a certain subset of problems. However, it is a poor choice for other problems.

The adage about a carpenter knowing his tools and having a large number of tools to draw on is the most appropriate, yet least used approach when constructing applications/systems/etc.

The specialist, per Mills, is the individual who continually focuses on an ever-decreasing scope approaching epsilon until at some point the specialist knows nothing about anything.

]]> By: petrilli http://blog.amber.org/2005/09/27/least-common-denominator/#comment-3108 petrilli Tue, 27 Sep 2005 19:40:01 +0000 http://blog.amber.org/2005/09/27/least-common-denominator/#comment-3108 It is one thing to talk about "new applications" that are written with Rails, but when we you discuss retrofitting things onto an existing schema that is not modifyable, Rails starts to have some massive issues. Now, I accept that it's not within it's real "sweet spot," and that's fine, but it would do a _lot better_ were it to actually use the data dictionary to find these things out. It is one thing to talk about “new applications” that are written with Rails, but when we you discuss retrofitting things onto an existing schema that is not modifyable, Rails starts to have some massive issues. Now, I accept that it’s not within it’s real “sweet spot,” and that’s fine, but it would do a lot better were it to actually use the data dictionary to find these things out.

]]> By: petrilli http://blog.amber.org/2005/09/27/least-common-denominator/#comment-3100 petrilli Tue, 27 Sep 2005 18:42:48 +0000 http://blog.amber.org/2005/09/27/least-common-denominator/#comment-3100 I didn't write this shit. :-) Although honestly, Wordpress seems to be more flakey than most, and I really need to have Textdrive migrate my backend to Postgresql. They just make it harder than it should be. I miss running my own stuff. I didn’t write this shit. :-) Although honestly, Wordpress seems to be more flakey than most, and I really need to have Textdrive migrate my backend to Postgresql. They just make it harder than it should be.

I miss running my own stuff.

]]> By: Joe Grossberg http://blog.amber.org/2005/09/27/least-common-denominator/#comment-3095 Joe Grossberg Tue, 27 Sep 2005 17:29:38 +0000 http://blog.amber.org/2005/09/27/least-common-denominator/#comment-3095 P.S. The first time I tried to submit this, I got: WordPress database error: [Illegal mix of collations (utf8_bin,IMPLICIT) and (latin1_swedish_ci,COERCIBLE) for operation '='] SELECT comment_ID FROM wp_comments WHERE comment_post_ID = '1789' AND ( comment_author = 'Joe Grossberg' OR comment_author_email = 'josephgrossberg@hotmail.com' ) AND comment_content = '\"This isn’t rocket science, and it’s been well-documented since the 1960s. Why must we keep making the same mistakes over, and over, and over, and pretending they’re “new�.\" Ha! You should take a look at ColdFusion one day (e.g. no writing your own functions until version _5_, and they pitched it as \"UDF\" -- user-defined functions).' LIMIT 1 I guess you're in a glass house on this one. P.S. The first time I tried to submit this, I got:

WordPress database error: [Illegal mix of collations (utf8_bin,IMPLICIT) and (latin1_swedish_ci,COERCIBLE) for operation ’=’]
SELECT comment_ID FROM wp_comments WHERE comment_post_ID = ‘1789’ AND ( comment_author = ‘Joe Grossberg’ OR comment_author_email = ‘josephgrossberg@hotmail.com’ ) AND comment_content = ’\”This isn’t rocket science, and it’s been well-documented since the 1960s. Why must we keep making the same mistakes over, and over, and over, and pretending they’re “newâ€?.\” Ha! You should take a look at ColdFusion one day (e.g. no writing your own functions until version 5, and they pitched it as \”UDF\”—user-defined functions).’ LIMIT 1

I guess you’re in a glass house on this one.

]]> By: Joe Grossberg http://blog.amber.org/2005/09/27/least-common-denominator/#comment-3093 Joe Grossberg Tue, 27 Sep 2005 17:27:52 +0000 http://blog.amber.org/2005/09/27/least-common-denominator/#comment-3093 "This isn’t rocket science, and it’s been well-documented since the 1960s. Why must we keep making the same mistakes over, and over, and over, and pretending they’re “newâ€?." Ha! You should take a look at ColdFusion one day (e.g. no writing your own functions until version _5_, and they pitched it as "UDF" -- user-defined functions). “This isn’t rocket science, and it’s been well-documented since the 1960s. Why must we keep making the same mistakes over, and over, and over, and pretending they’re “newâ€?.”

Ha! You should take a look at ColdFusion one day (e.g. no writing your own functions until version 5, and they pitched it as “UDF”—user-defined functions).

]]> By: Ned Flanders http://blog.amber.org/2005/09/27/least-common-denominator/#comment-3092 Ned Flanders Tue, 27 Sep 2005 17:27:47 +0000 http://blog.amber.org/2005/09/27/least-common-denominator/#comment-3092 How dare you say something negative about Rails! Fear the wrath of DHH! How dare you say something negative about Rails! Fear the wrath of DHH!

]]> By: Zach Beane http://blog.amber.org/2005/09/27/least-common-denominator/#comment-3086 Zach Beane Tue, 27 Sep 2005 15:53:29 +0000 http://blog.amber.org/2005/09/27/least-common-denominator/#comment-3086 I mostly agree about MySQL, but I think there are some people using it who are extremely competent, aware of its flaws, and maximizing its strengths. Brad's presentation on the LiveJournal architecture, for example, gave me the impression that the way they use MySQL is more "fast data store we understand comprehensively" than "standards-compliant relational database". I mostly agree about MySQL, but I think there are some people using it who are extremely competent, aware of its flaws, and maximizing its strengths. Brad’s presentation on the LiveJournal architecture, for example, gave me the impression that the way they use MySQL is more “fast data store we understand comprehensively” than “standards-compliant relational database”.

]]> By: Robby Russell http://blog.amber.org/2005/09/27/least-common-denominator/#comment-3084 Robby Russell Tue, 27 Sep 2005 15:44:30 +0000 http://blog.amber.org/2005/09/27/least-common-denominator/#comment-3084 "In Rails, the system can introspect into the database to find all sorts of things—no need to define column names, etc. This is wonderfully useful. Unfortunately, it imposes a naming convention to find the primary key (it must be called id or you have to be explicit), you have to tell it how to find other tables, etc. " I am a HUGE PostgreSQL fan. This obstacle is overcome with one line of code in your model. If you choose to use id as your primary key, you don't have to add that one line. It's a convenience... and I think many of the people who bring this up don't realize that it's not a big deal. :-) “In Rails, the system can introspect into the database to find all sorts of things—no need to define column names, etc. This is wonderfully useful. Unfortunately, it imposes a naming convention to find the primary key (it must be called id or you have to be explicit), you have to tell it how to find other tables, etc. ”

I am a HUGE PostgreSQL fan. This obstacle is overcome with one line of code in your model. If you choose to use id as your primary key, you don’t have to add that one line. It’s a convenience… and I think many of the people who bring this up don’t realize that it’s not a big deal. :-)

]]>