Drupal/database questions

[a_unique_person]

I have no clue about the pros and cons of Drupal. Notwithstanding, the critique you link to is clearly moronic, what with the complaining about certain data/metadata being stored in a database.

Gripe #1: Drupal Stores Just About Everything in the Database
Databases are great for storing passwords, content, and countless other things. These things do not include “views”, i.e. templates. That’s right, templates. In the database. Drupal stores templates in the database.

Storing data in a database? What a novel idea. SAP, the worlds most popular ERP software stores everything in it's database, including it's code, data dictionary, and everything else to do with setting up and configuring it. It's one of it's best points.

 

[varwoche]

Storing data in a database? What a novel idea. SAP, the worlds most popular ERP software stores everything in it's database, including it's code, data dictionary, and everything else to do with setting up and configuring it. It's one of it's best points.

Indeed.

Take logs for instance. What, this data is so uniquely unimportant that it gets relegated to a text file ? The foolishness is astounding.

 

[Morrigan]

Storing data in a database? What a novel idea.

Not ALL types of data is suited to be stored in a database. In fact most metadata structures often benefit more from not being in a database. No point in having more SQL queries than necessary.

SAP, the worlds most popular ERP software stores everything in it's database, including it's code, data dictionary, and everything else to do with setting up and configuring it. It's one of it's best points.

I don't know anything about SAP. But storing code in the database is a good thing to you? Really? How do you debug that kind of code? How do you version it? How do you even run it?
If SAP is so good and still does that, it probably has a very atypical architecture. But for a CMS, it's a stupid idea, plain and simple.

Indeed.

Take logs for instance. What, this data is so uniquely unimportant that it gets relegated to a text file ? The foolishness is astounding.

Did I say anything about text files? Not in particular. Ever heard of syslog?

Logs in database aren't a big deal, but it's usually easier and more convenient to implement log rotation on the file system or in syslog. It depends on your log volume, of course. Also, if you want to parse those logs and you have a table with million of rows... you'll need to create indexes (lest you crash your database by simply running a query), but then, it will slow down the insertions into your now-huge table. Oops.

 

[geni]

Too lazy. But thankfully others have taken the time to explain it.

And this guy doesn't even mention the fact that Drupal (unless this changed recently) doesn't use any classes or OOP. Fail, fail, fail.

Someone send them a copy of mediawiki I want to see their head explode.

 

[BenBurch]

Indeed.

Take logs for instance. What, this data is so uniquely unimportant that it gets relegated to a text file ? The foolishness is astounding.

Yeah, besides text file logs make it so very difficult to cover up one's intrusions!

 

[varwoche]

Not ALL types of data is suited to be stored in a database. In fact most metadata structures often benefit more from not being in a database. No point in having more SQL queries than necessary.

First point true. Second point goofy, as if a disk file read has some magical aspect to it.

I don't know anything about SAP.

I don't know much more than you -- my response to AUP was in the abstract.

But storing code in the database is a good thing to you?

Not particularly, though I can imagine some exotic scenarios where it might be beneficial.

But for a CMS, it's a stupid idea, plain and simple.

Nonsense of a high order, as if CMS is a special case situation where sound data management practices don't matter.

Logs in database aren't a big deal, but it's usually easier and more convenient to implement log rotation on the file system or in syslog. It depends on your log volume, of course. Also, if you want to parse those logs and you have a table with million of rows... you'll need to create indexes (lest you crash your database by simply running a query), but then, it will slow down the insertions into your now-huge table. Oops.

This is by and large nonsense, but I grant you there are certain situations where logging to a DB isn't possible/practical.

And if your database is crashing due to simply running a query, this suggests that you're using a system that is not at all robust. And your concern over a dinky little table with only a million rows suggests the same.

 

[Morrigan]

Bleh. There's too much straw in that post for me to be bothered in replying.

 

[bug_girl]

Wow, I go away for a week for a meeting and you guys really got into it!



Anyway, looks like we're going to go with a member management system built on Joomla.

 

[Morrigan]

Hahahaha, I quit my last job partly because I was forced to work with Joomla. Of course, it wasn't being used as a CMS, but rather as a framework for developing a custom app, which was a profoundly retarded idea but unfortunately I didn't manage to convince the people in charge of that.

So yeah, I loathe Joomla too. But, again, I can't say anything about its merits as a CMS. It seems to serve the JREF well enough. It just has a horrible, horrible software architecture.

 

[El Greco]

Well, what does one use for a simple (but highly customizable) online store ? If I'm not interested much in programming the damn thing, and all I want is something that is free, works easily, has a large base of users so that it won't fall into disuse a few years from now, and is highly customizable ? Is it Joomla with Virtuemart ? Wordpress with eCommerce ? Drupal e-Commerce ? Or something else ?