How does one ask a question which (ultimately) has to do with the way Drupal is structured?

Question

On drupal.stackexchange.com, I often begin by asking a "how to" question which gets replies suggesting a different data structure design, so the discussion becomes removed from the actual question I asked and devolves into a discussion about what appears to be the "Drupal way" (vs. the traditional way of connecting relational tables). So this question of data structure design ends up being fundamental to the issue I'm trying to solve.

My questions are consistently put on hold for being "off topic".

Here are some samples:
What are the modules / pages / panels / or other features in Drupal which can be used to display an object which is made up of several content types?

I need a link from base table to join table

Advice needed on structure of content types and join tables (also content types)

Specifically, it has long been recommended to me to keep the join for data tables outside the entity. Using Drupal, the recommendations I get suggest adding the join table onto the original data table—which is quite contrary to relational data instructions.

There doesn't seem to be any documentation which I can find which discusses these issues. I've spent weeks perusing drupal.org, drupal.stackexchange.com, been through the table of contents of every book on Drupal 7 on drupal.org, Reilly media, Amazon, Johann Falks screencast lists (and many of the screencasts), videos from Code Karate, etc.

Should I not be asking these questions at all on drupal.stackexchange.com? Aren't these issues fundamental to understanding Drupal?

Can you suggest where I might look for resources? Thanks for your help.

Answer 1

First let me start with apologizing for 'taking over' your post. For me personally, most of the answers (and comments) I post are based on years of Drupal experience. Lots of things in the Drupal universe have unfortunately no, or very limited documentation.

When you specifically start requesting documentation on 'the Drupal way' of handing certain situations, you complicate it even more because there is no such thing as 'the Drupal way'. Drupal is a super flexible system and one could tackle every problem in numerous ways (though one might be more efficient than another) For an example take a look at this thread: How to disallow node authors to change node content if comments were submitted for that node?. It is up to the OP to choose which of the approaches he likes most, but none of the proposed answers came out of the book. They are all based on previous experiences.

You are free to go your own way and build what you feel works best.

Some loose remarks:

• Specifically, it has long been recommended to me to keep the join for data tables outside the entity. And they were right, and we never advised otherwise ;). Experience learns us that each and every Drupal field gets a dedicated database table. An entity reference field would not store its value in the entity, but in a separate table (basically the traditional SQL join table you were thought to use). The entity would then relate to this field and make the other side of the relation visible to the big modules (views, rules, etc). It also works the other way around, so the related modules have access to their parent's data.

• Perhaps provide some images on your data structures. Because of the extra join table you have a second relationship (entity relation would be only one). Since relationships are directional, it might also be valuable to include that in the post (image?). Currently there is a lot of text to read and interpret and the direction of the relations would influence the answer. (I did not answer it because I was not 100% sure I understood it correctly and proposed a simpler data structure.)