Using Nodes like database Rows

burt.lo's picture

I promise, I'll stop beating this dead horse once I really understand how dead it is. Promise.

To me, Content Types are like SQL Tables, and Nodes are like SQL Rows. Using the Views module affirms that as I can/do query Drupal content like I would in SQL. Next step is processing data as such.

Does anyone have any suggestions or examples of processing a node of one Content Type based on the data in another (related/referenced) Content Type? I can think of some similar modules, but I'm hoping there's a more straightforward example.

Here's a scenario:

  • Content Type 1: "Test Response" with single Answer Value
  • Content Type 2: "Answer Key" (one node for each possible answer) with "Correct? (Yes/No)" field

I want to process my Test Responses to see if the Answer Value is correct, then store the result in the Test Response. After wrestling with this mind problem, I think this is the approach I want to take. It is, at least, the problem I want to solve.

Any suggestions? Thanks!

Login or register to post comments

well

kscheirer's picture
kscheirer - Tue, 2010-03-16 00:58

You can think of nodes as rows if you like, essentially that is true. However, you must understand that Drupal feels free to store all the information across however many tables it finds necessary. Even at the core level, a node object is really a node + revision, so its 2 rows, one from node and one from node_revisions.

Since you're doing so much custom processing, it sounds like you will end up writing a custom module to handle this part. Using node_load() you can get a fully loaded node object, no need to worry about where the data is stored. If you need to change values, modify the node object and call node_save() on it. If you want to write rows directly to a specific table, using db_write_record() can really save a lot of time.

If you'd later like to use Views to generate reports based on your own module's tables, you can write an integration hook that makes your module Views-aware, and will allow Views to work with your custom data.

Hope that helps,
-ks


Understood, so...

burt.lo's picture
burt.lo - Wed, 2010-03-17 03:18

Thanks, ks. I hear what you're saying, and after watching the Lullabot video on module development, I have a much clearer notion of what can occur within a custom module. I'll be delving into some development myself to cut my teeth on that project we spoke about and expect to be posting some thoughts on what I come up with. I appreciate your support.

Project Management: http://www.fitpm.com
Technology Solutions: http://www.ascendtechsd.com
Coaching Services: http://burtlo.info


reduce saving time

shaynl - Wed, 2010-04-07 10:15

I'm looking for a way to save nodes quicker…It's now taking about 4 sec to save a node in my drupal project. My goal is to reduce it to max 1 sec.
As I'm reading here, "write rows directly to a specific table, using db_write_record()" is an option to do so…
Where I can find example for using db_write_record() and using those record with views?
Can I use my current content types tables that I created using cck or I must create new tables?
Thanks


hmm

kscheirer's picture
kscheirer - Thu, 2010-04-08 23:29

4 seconds does seem kind of slow. This could be a symptom of too many modules being installed on the project (each one gets a chance to execute when a node_save() is called), not enough performance on the server (cpu/ram), or a poorly configured mysql install.

Be aware the node_save() already uses drupal_write_record() to do the bulk of the work, so simply using this function in your code may not speed up performance much. Docs are available here.