4 ms·

Exactly, a new CMS should drop sequel and move to mongo or a similar document store. Being able to arbitrarily add fields to a page, enabled by a store like mo

Exactly, a new CMS should drop sequel and move to mongo or a similar document store. Being able to arbitrarily add fields to a page, enabled by a store like mongo seems like a no brainer for a CMS.

alanctgardner2 13y ago
MongoDB is definitely not a no-brainer - what actual benefit is there to being able to 'arbitrarily add fields to a page'? The whole application layer has to support an arbitrary schema anyways, which is bound to be a security and config nightmare.
- Torgo 13y ago
  Look at the mysql schema of a Drupal system. Either you support arbitrary fields at the database level, or you write a ton of extra code (which will have bugs) and piles of support tables on top of your relational database. It's a waste of time and effort and adds unnecessary complexity.
  - alanctgardner2 13y ago
    I still don't think the correct solution is to just give up on the relational model and store a bunch of denormalized documents. Just because Drupal has technical debt (which is not surprising to me) doesn't mean it's impossible to model a CMS in a relational way. Can you point me to a particular part of Drupal which is well suited to the Mongo document model over relational, versus simply 'well it's relational now and they cocked it up'?
steveklabnik 13y ago
Drupal has been moving towards Mongo, IIRC.
dragonwriter 13y ago
> Exactly, a new CMS should drop sequel and move to mongo or a similar document store. Presumably, you are referring to SQL when you write "sequel"? > Being able to arbitrarily add fields to a page, enabled by a store like mongo seems like a no brainer for a CMS. You can do that using SQL-based databases, so its not really "enabled by mongo". With most SQL-based DBs, you may have to use a data model other than "one page is one row of one base table" to do it, but that's simple enough to do. (With Postgres, there's several ways to do it while still using a "one page is one row of one base table" model, as well, leveraging the XML, JSON, or Array types to hold the "flexible" fields.)

Exactly, a new CMS should drop sequel and move to mongo or a similar document store. Being able to arbitrarily add fields to a page, enabled by a store like mongo seems like a no brainer for a CMS.

alanctgardner2 13y ago

MongoDB is definitely not a no-brainer - what actual benefit is there to being able to 'arbitrarily add fields to a page'? The whole application layer has to support an arbitrary schema anyways, which is bound to be a security and config nightmare.

Torgo 13y ago
Look at the mysql schema of a Drupal system. Either you support arbitrary fields at the database level, or you write a ton of extra code (which will have bugs) and piles of support tables on top of your relational database. It's a waste of time and effort and adds unnecessary complexity.
- alanctgardner2 13y ago
  I still don't think the correct solution is to just give up on the relational model and store a bunch of denormalized documents. Just because Drupal has technical debt (which is not surprising to me) doesn't mean it's impossible to model a CMS in a relational way. Can you point me to a particular part of Drupal which is well suited to the Mongo document model over relational, versus simply 'well it's relational now and they cocked it up'?

steveklabnik 13y ago

Drupal has been moving towards Mongo, IIRC.

dragonwriter 13y ago

> Exactly, a new CMS should drop sequel and move to mongo or a similar document store. Presumably, you are referring to SQL when you write "sequel"? > Being able to arbitrarily add fields to a page, enabled by a store like mongo seems like a no brainer for a CMS. You can do that using SQL-based databases, so its not really "enabled by mongo". With most SQL-based DBs, you may have to use a data model other than "one page is one row of one base table" to do it, but that's simple enough to do. (With Postgres, there's several ways to do it while still using a "one page is one row of one base table" model, as well, leveraging the XML, JSON, or Array types to hold the "flexible" fields.)