Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Unless someone explores a module and knows its inner-working through and through, its fairly tough to properly identify relationships between database fields. Unless you're running INNODB or a different database driver which can identify these relationships on its own, this can be a hassle to sort out.
A great example is the Drupal 6 term_node table.
(Now named term_index in Drupal 7).
Field structure:
- nid: Node NID (Primary key)
- vid: Node Revision ID (Primary key), easily mistaken for a Vocabulary VID
- tid: Term TID (Primary key)
- sticky: Drupal 7 only (I still haven't figured out how this is even used)
- created: Drupal 7 only (again, I'm not sure what this field really does for D7--especially if you have revisioning enabled)
I might even go so far as to say this could be put into Drupal 8's performance gates. Ultra-short field names make writing queries by hand marginally easier, but make long term maintenance a bigger pain--especially for someone who inherits a Drupal installation and needs to get up-to-speed on it. This might drive contributed module maintainers crazy for a while, BUT, I forsee that it would make extending certain database functions easier in the long run--and help take better advantage of other modules or core itself.
Any thoughts?
Comments
Comment #2
rolodmonkey commentedIs this still an issue? Properly written schemas allow you to write good descriptions for the fields. You can also define the relationships, both in the descriptions and as foreign keys in the schema array.
It is up to module developers to make sure their schemas are descriptive.
Also, there are modules that let you see these descriptions right in the UI. And, the schema system pushes these descriptions into the DB itself (when possible), so you should be able to see them with the corresponding DB tools.
Comment #10
quietone commentedI don't know when it started but Drupal requires INNODB. I agree with RoloDMonkey that there is nothing to do here.