4 ms·

> 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

> 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.

jacquesm 11y ago
> 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.
- audessuscest 11y ago
  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)
  - jacquesm 11y ago
    > 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.

jacquesm 11y ago

> 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.

audessuscest 11y ago
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)
- jacquesm 11y ago
  > 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.