On Tue, May 5, 2009 at 3:11 AM, Larry Garfield <larry@garfieldtech.com> wrote:
On Monday 04 May 2009 3:22:51 pm Yves Chedemois wrote:
Karoly Negyesi a ecrit le 04/05/2009 21:22:
One comment here.. the field API storage is pluggable.
... but some work is still needed for this feature to be really usable : http://drupal.org/node/443422
We need people to jump in, here :-)
Yves
I'd go a step farther and say that the field system backend is not pluggable in any useful sense until/unless it becomes at *least* per-object-type. Per-field is the ideal, but object type is the absolute minimum to call it "pluggable" with a straight face.
-- Larry Garfield larry@garfieldtech.com
I think we're comparing pears to apples here. This is not a question of SQL vs. not-SQL, but more a question of database architecture – relational vs. document oriented. I think that relational databases will still have their uses with data that are inherently relational and carefully structured. That is not the way the winds are currently blowing with CCK and fields in core where the database schema is mutable and constantly evolving, so here the document databases could of help, but so could materialized views (not related to Views the module) or sharding. It all depends on usage and the amount of time you're willing to spend optimising and caching. I don't think that swapping the persistence layer out is going to make anything inherently more scalable, and it is not the first thing I'd do. Look at Facebook – to my knowledge, they're still using MySQL combined with memcache and oodles of RAM. Being able to scale to their size and no further would be good enough for my usage ;) -- Regards, Mikkel Høgh