Hi Greg, On Tue, May 5, 2009 at 4:18 PM, Greg Knaddison <Greg@growingventuresolutions.com> wrote:
This is some interesting feedback. I'd love to hear more of your thoughts so I can understand it better.
On Tue, May 5, 2009 at 7:51 AM, Bertrand Mansion <drupal@mamasam.net> wrote:
Drupal doesn't really need a relational DB and actually doesn't use the relational features properly (for example, the way tags are stored is not efficient). That's one of the reasons why it is slow and doesn't scale very well.
These are some pretty sweeping claims. Can you expand on them?
These are not claims, but only my opinion, based on my experiences with Drupal.
1. Tags are stored inefficiently (I can't think of a way to store them that is better for every use)
What do you mean by "every use" ? If you are interested in reading about tags and SQL, here are some pointers: http://www.pui.ch/phred/archives/2005/04/tags-database-schemas.html http://laughingmeme.org/2005/04/07/in-lieu-of-the-promised-article-on-tags-a... The way Drupal stores tags hierarchy is also inefficient.
2. Drupal doesn't scale very well (I've seen enough claims otherwise - is there a particular problem you can point to?)
Lots of problems for me, but that's off topic. Sessions, cache, sql queries, table structures, file storage, architecture and callback hell, etc. It's currently the best CMS for PHP I know, but still, it is sluggish (yes, this is subjective).
But going for another storage system would be better if implemented as a fork, IMO.
Various people just rewrote the entire DB API, so it is possible to make massive API changes within a release cycle. Why do you feel a fork is necessary?
Moving to something like CouchDB as was suggested in the thread or some other datastores (someone mentioned Hadoop but I think he meant BigTable, Dynamo or Tokyo Cabinet...) would need more than just rewriting the DB API in my opinion. That's why I can only imagine this as a fork. That would be my reply to the first post. -- Bertrand Mansion Mamasam