I've seen a thousand request for a single page when logged in as administrator (since the menu structure for the admin interface comes from the database as well).
I talk about this a lot and I must admit I rarely use words as diplomatic as naive...
> I talk about this a lot and I must admit I rarely use words as diplomatic as naive...
That has to be the first time that I'm labeled 'diplomatic'. I have different words as well but I see no upside in using them, those who choose to pick drupal after many years of broken processes, lack of an upgrade path between major versions, abandoning large numbers of users on broken and unsupported code anybody that chooses drupal today really deserves what they get.
That was a deliberate design choice for Drupal 7. The reasons were:
- Loose coupling. Drupal has been becoming increasingly API-centric and storage engine agnostic. Focusing on the physical storage schema for a DB engine misses the point of the architecture.
- Performance(!) Supports schema changes on existing large datasets (migrations are only starting to appear in Drupal 8, and elsewhere bring their own complexities when you want zero downtime). Unsurprisingly there was some gnashing of teeth when this 'table per field' approach was introduced and as a result it was decided to build denormalized read layers on top (materialised views and bundles). However, it turned out that they showed no perf improvement over Drupal's object caching whilst adding complexity to the design and were therefore abandoned. (The fact that this performs as well as materialised views speaks very positively of Drupal's architecture and code quality.)
On the whole I would call this a thoughtful and reasonable design choice, and one that is supported by real-world implementation on millions of sites at all scales.
Much of this can be avoided by enabling caching. Running Drupal without entity or page caching is like running a desktop app in debug mode, or compiling without any optimisations.
Drupal wants end-users (not limited to developers) to be able to create new types of entities, add fields to those entities and store complete revision histories for those entities as they are created and edited. This should be achievable within a GUI and without needing to edit code by hand. It also wants developers to be able to distribute code that give these end users new types of fields to use.
It achieves this by creating two new tables for each additional field. One table stores just the current value of the field, and the other table stores the historical values of the field in previous revisions. An entity like a 'blog post' with three fields will therefore have a base table plus three additional tables for the current values, and a revisions table with three additional tables for the historical values. When loading an entity, these field values can be loaded via SQL joins, or (depending on the field type) via additional queries.
As this is expensive, entities can be cached, and the next attempt to load the entity will pull the complete object from memcached, Redis etc., and this is how most production sites would do it. Obviously in the case of zero caching, where you have entities with many fields (say, 30) and where you need to load many entities, you can quickly end up with many queries - hundreds or even thousands! But almost all of those go away with caching enabled.
Is this a bad design? It would certainly be possible to make the database schema line up better with the entities, which would reduce the number of queries - a single 'blog_posts' table could be queried, rather than hitting the 'node' table and then the additional field tables. But you would lose a lot of the end-user flexibility - the ability to define new entity types, add and remove fields or reconfigure those fields (changing their size or even their cardinality). Instead of adding new tables, you could add and remove columns from an existing table, but this brings other problems - your tables can become very large, and altering tables containing existing data is slow. Mutating a single table when you want to add/remove a field is a more dangerous tool to expose to an end-user than just adding/removing additional tables.
If only developers can do these things, then yes, you would expect to design your tables for optimal performance. There's a large body of knowledge on SQL optimisation that a developer would be able to bring into play. But if this requires giving up the ability of end-users to modify entity types via the GUI, it no longer achieves the original design goals. Drupal trades off best practice database design against delivering certain tools to end-users, and mitigates the performance impact with a fairly robust caching system. To me, that's good design, given the constraints.
You might argue that Drupal's design goals are wrong, or that those design goals make Drupal inappropriate for some use cases, but I don't think any of that makes it a fundamentally bad design.
EDIT: fixed some grammar in the db schema description
> It achieves this by creating two new tables for each additional field.
This is pretty much the epitome of bad design. It creates a nightmare data model. The only advantage is that you can get away with this in the most brain-dead way possible when adding/removing fields without having to create a proper migration.
The goals are fine, it's the implementation that sucks, nothing in the SQL standard would stop you from doing this properly but drupal purposefully chose to throw away vast amounts of performance and interoperability for their end users in return for a marginal speed up in their own development processes, presumably because they simply couldn't think of a better way of doing this.
It's amateur hour, and drupal is by far the worst CMS out there for these and many other reasons.
> This is pretty much the epitome of bad design. It creates a nightmare data model. The only advantage is that you can get away with this in the most brain-dead way possible when adding/removing fields without having to create a proper migration.
That's a pretty big advantage if you're an end-user who doesn't know how to create migrations. Yeah, you wouldn't do it that way if you were writing the code from scratch yourself, but you're not.
The 'nightmare data model' is only really a problem if you think of SQL as your level of abstraction. If you use the entity APIs, the data model looks fine. The whole point is that you shouldn't be poking around in the DB most of the time (I will admit that this is a principle frequently violated).
Entity storage in Drupal is pluggable, meaning that SQL databases are not the only possible storage. Tightly integrating SQL-specific design patterns would break pluggability (though again I would admit that SQL databases are by far the most common storage engines). Maybe making entity storage pluggable might be a bad idea, but it's not obviously bad design.
I'd imagine that other systems which can use SQL databases as dumb storage (Datomic does this, for instance) will probably not produce beautifully optimised tables and queries, because they're doing their optimisations at higher levels of abstraction. Drupal gives up thinking about tables and columns and instead thinks about entities and fields, which is how efficient caching of these entities is possible in the first place.
Sure, you or I could make something much more efficient by giving up a lot of this flexibility, but then you'd be looking at a different product with different design goals.
> That's a pretty big advantage if you're an end-user who doesn't know how to create migrations.
Such a migration should be created by drupal, not by the end-user in a proper design, you know, like everybody else does it.
> The whole point is that you shouldn't be poking around in the DB most of the time (I will admit that this is a principle frequently violated).
DB's tend to become the place to hook into other systems rather than to create yet-another-dependency on whatever framework is currently powering the front end.
Having a brain-dead schema means two thing: there will be no migration path out of the present CMS without a complete overhaul of the DB and it will make interoperating with other software accessing the same DB all but impossible.
> Sure, you or I could make something much more efficient by giving up a lot of this flexibility, but then you'd be looking at a different product with different design goals.
I don't think drupal had any actual design goals, and I think the lack of experience designing such systems is what lead to this mess, not any possible design goals they might have had.
What is sad is that they seem to re-invent several wheels with each new re-incarnation of drupal but they keep their brain-dead db architecture because they've double down on it so many times that to admit this was an error this late in the game would destroy whatever confidence people may still have in drupal. It's just sad.
Anyway, if you're a new user looking for a CMS do your future self a favor and stay as far away from drupal as you can.
Sorry but you sound like you don't know what you're talking about.
> I don't think drupal had any actual design goals
You dont THINK? Well maybe you should LEARN and then you will KNOW.
Actually Drupal is very good (the best framework I know) for migration and interoperating with other software. But you don't do that by connecting DBs directly like you seems to want to do... (which is wrong with any framework/cms)
> Sorry but you sound like you don't know what you're talking about.
I ran a drupal based business for years and I know the platform - and it's shortcomings - very well.
>> I don't think drupal had any actual design goals
> You dont THINK? Well maybe you should LEARN and then you will KNOW.
Well, I could have used stronger language there but I see no need. Because whatever I would have said you'd have found fault with the form rather than with the content. Believe me, I've spent enough time repairing and porting installations of drupal from one release to the next to know for a fact that their design goals are about as flexible as a rubber band and that they fail to deliver on the most basic ones (performance, ease of maintenance, backward compatibility and ease of upgrade).
> Actually Drupal is very good (the best framework I know) for migration and interoperating with other software.
Well, let's say our experiences probably are not identical.
> But you don't do that by connecting DBs directly like you seems to want to do... (which is wrong with any framework/cms)
For better or worse, DBs tend to be a relatively standard item and of course there is a 'right' way to do things (which is different for every platform), but having done several re-builds of large platforms we could probably agree on having a sane database schema and reasonable naming scheme to be a plus in such situations.
So from a pragmatic point of view this 'wrong' way is often the only way to achieve certain goals, and with drupal this way is nailed shut to the point that you are not only locked in to drupal, you are most likely going to end up being locked in to a specific drupal version (due to their modules usually not making it past an upgrade).
FWIW at some point in time I hosted thousands of drupal sites so I think (see, I'm doing it again, so feel free to take another cheap shot at me) that I have enough experience and familiarity with drupal to see it for what it is.
Your criticism seems to be well-founded in past experience, however as a casual developer and supported of Drupal sites for my own businesses and some charities, it 'just works', looks good, and is reasonably easy to look after. All my clients, are happy with the results. I have not ever bothered to examine performance nor work on it beyond enabling caching because there hasn't been a need to.
Now admittedly these are not sites with millions of visitors, however several run on a single 2GB RAM VPS. And, yes, there is the problem with version upgrades, which in the past I've handled by a site redesign every several years, and paying someone to handle the data migration / mapping.
From my point of view Drupal 'just works' for me (and several other web guys I know), clients are happy, hosting is cheap, and site performance is fine. In a world where there is always something to do, I still don't intend to look into it further than this, or fret over changing CMS because there is no need to.
I'm happy it works for you. Personally, drupal would need to do some very serious non-sexy re-factoring before I would consider it for any future project.
Comments like this, as well as "you sound like you don't know what you're talking about", break the HN guidelines. Please edit incivility out of your comments here, and keep them substantive.
You keep making sweeping statements about both drupal and about me without providing a single bit of information to the discussion, if you have factual information to contribute about why what I say is inaccurate I'm all ears.
I've provided that (1) drupal is inefficient, (2) drupal sucks when it comes to backwards compatibility, (3) that drupal has a totally broken approach when it comes to data base schema design and finally (4) that other CMS's (such as Symfony2 and Laravel, and Yii as well) in the PHP ecosystem show that it is entirely possible to avoid most of these pitfalls.
You say that 'drupal is how CMS's should be done, that's why all others fail' when in fact most of these others are succeeding where drupal is losing ground to all of the above and to the likes of wordpress and joomla (though those have less functionality).
If you feel that drupal is how a CMS should be done then I'm perfectly ok with that but don't make it seem as if that is anything more than your personal view with which I disagree for the above reasons.
And even if you're limited to the PHP eco-system, there are lots of alternatives.
One thing I did not mention, but which I'll be more than happy to comment on now is that another thing that bugged me about the drupal ecosystem is that it seems as if it is altogether too much self-centered, unwilling to absorb best practices from the rest of the industry and a fairly toxic community which tends to be openly hostile to anything and everything that is not 'drupal'. I don't like that particular aspect of drupal one bit and it is this kind of attitude that is the reason why drupal to this date sees such a huge level of abandonment when it comes to modules, past version and large numbers of sites marooned on that code.
It shows a total lack of respect, care and understanding of the kind of issues that the users of these systems have to deal with.
I understand perfectly well how drupal maps its external interface to it's data model and when I tell you that this approach is broken beyond repair it is not my understanding that is deficient, it is drupal, when seen against the backdrop of properly designed software, of which we -fortunately- have plenty of examples.
If you wish to ignore all that that is entirely your freedom, but recognize that this is akin to a religious point of view, you support it because you are invested in it rather than because you are aware of the alternatives.
A good data model and the cruft that drupal produces are not even on the same scale when it comes to maintainability and efficiency, if you feel like arguing that point with actual facts and data to back it up I'd be most interested but I fear you'll end up coming short or having to admit that maybe the drupal way isn't all that good after all.
3. Saying Drupal is self centered show that you don't know Drupal community (They team up with Symfony and follow now many Symfony paradigm for example...)
4. Sorry but saying Drupal has a totally broken data model is very exaggerate, you may not like it, you can have critics, but it's a perfectly valid model, which works perfectly.
5. You don't provide much information either...
6. All cms/framework with a large module ecosystem have trouble with backward compatibilty, Drupal is not the worst. For example WP have trouble with compatibily between module for the same version of WP. Drupal don't have this issue because their guidelines are strict.
7. Drupal is loosing ground to Joomla ? For someone with high standard, it's funny that you mention Joomla and WP as better replacement to Drupal. Very funny. Because, yes, I know these alternatives and they are really poorly designed and not just the data model (I dont know why you said I don't know alternatives...)
