[development] Database / SQL future thoughts
drupal at mamasam.net
Tue May 5 15:07:25 UTC 2009
On Tue, May 5, 2009 at 4:18 PM, Greg Knaddison
<Greg at 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 at 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:
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.
More information about the development