[development] Database / SQL future thoughts
m at ooh.dk
Tue May 5 09:10:38 UTC 2009
On Tue, May 5, 2009 at 3:11 AM, Larry Garfield <larry at 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 :
>> We need people to jump in, here :-)
> 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 at 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 ;)
More information about the development