Deciding whether to store personal data as nodes or users

show more Deciding whether to store personal data as nodes or users provides you with in-depth training on Web. Taught by Tom Geller as part of the Drupal 6: Online Presentation of Data show less
please wait ...

Deciding whether to store personal data as nodes or users

There is one Drupal specific point I think we should address ahead of time, that is whether to store a personal data as nodes or as users. This issue comes up whenever you want to store information about people on your site, and you might want to let those people actually log into the site and change their own data. Their information could be stored as part of the user profile or it could be stored in a separate node completely unattached to their user login. This video will talk about the advantages of setting up your site both ways, and we'll even show a third hybrid way that I've sometimes found to be better than those other two.

There are four good reasons for talking about this issue. First of all, it's a common question that often comes up whenever you are building a site featuring data about real people and where those real people might actually become users of the site. Secondly, we are specifically going to build a site that has personal information, and we could decide to architect it in several different ways. I want to be clear about the advantages and disadvantages among them before you see how we actually decide to do it. The third reason for talking about this now is once you decide to store your data, either in nodes or users, it's very hard to change later.

The last reason to talk about this is that it's an area of Drupal that's probably going to change with the release of Drupal 7, and that's going to happen in late 2009 or early 2010. Understanding the issues of nodes versus user is an important area that could help you to make the transition to Drupal 7 and keep your site alive for years to come. Now I should mention once again, this video assumes that you want to store personal data and have to decide whether to give the people in your site access as authenticated users. If you are planning to do some other kind of site, for example, something showing health care trends or a catalog site, you can skip it.

First, we are going to talk about storing the information in the user section of Drupal. This assumes that you've turned on the Profile module, which is installed with Drupal, but not actually enabled. To do that you would go Administer > Site building > Modules, then scroll down until you find the Profile module. We are going to turn it on now, and Save. There. But let's get back to talking about the advantages of using the user system. If you store personal information in the user part of Drupal, there are several advantages. The first is that, it connects the person that you are talking about with that person's online activity.

So if, for example, they make comments on certain nodes in your Drupal site or they visit pages, Drupal will actually keep track of that and you can have some online data tied in with whatever other information you've put in about them. The second reason is that users could then control their own information when they log in and they take a look at their profile they can edit it and change their information. It's a lot less work for the administrator, if you trust them to do it. The third advantage is that all of the data is in one place. You don't have to keep track of both the user and the node. But going against these advantages are some notable disadvantages. Largest among them is that the Profile module doesn't let you have as many different data types as a node module, and there is some other parts of Drupal that don't really interact with the user system as well as it does with the node system.

Drupal sees nodes as the place where you put content and users as a place where you put information about authenticated users, that is, not really extensive information, just enough so that they can get around the system. That leads to the other disadvantage, which is that some features aren't available. For example, let's say that you store all the information in the user section, then decide that you want to feature one of your users on the front page. Well, you can only do that with a node; you can't do that with a user. There is no way to promote a user to the front page. So let's talk about storing the information in nodes. The first advantage is you have very flexible field options. The CCK module or Content Construction Kit is designed specifically to add features to nodes. It's not available for users.

The second advantage is if you change anything in a node, it doesn't change any of the information that they personally feel that they own. For example, if you wanted to say that somebody had changed their email address, then you could do that in a node, and yet someone could still log on with the old email address because they are not connected. Thirdly, and this is actually quite important, more contributed modules work with nodes than work with users, so you got a lot of features that wouldn't be available if you decide to store the information as users. The disadvantages, well, you'll have to take care of all of those nodes, whereas if you'd stored them as users, the users would take care of the information themselves, you as the administrator either have to deputize people to take care of the information or you have to do it yourself. So if someone changes their address, you have to go and type it in yourself and so forth.

The other disadvantage, there is no connection to that user's online activity. They add comments, they visit pages; it's not really tied to whatever node you set up to store their information. There is a third solution, which is to use a module called Content Profile. The content profile module is available at The way that it works is it sets up a content type called Profile. You create a node in that content type and that becomes attached to the user's user information, so when they log in and they edit their user, what they are actually doing is editing that node. That gives them some control, but you have all of the advantages of working with nodes.

There is a pseudo-link between the two sort of. That is to say, the node is not actually a part of the user's profile, but it seems to be. And, as I mentioned the users can actually modify them themselves without any additional help from you. Finally, I'd like to talk about one big change that's coming in Drupal 7, which we expect to be released in late 2009 or early 2010, and that's called Fields in core. What that means is instead of having CCK, the Content Construction Kit as a contributed module that let's you create new content types, it will be built into Drupal itself. That's also going to carry with it some big changes in the way that Drupal handles such information internally.

This hasn't been completely decided, but I believe Fields in core will only affect nodes. That is, it won't be possible to add fields easily to users even after Drupal 7 is released. That's one reason that you might want to do your site with all of this information in nodes instead of users, but if you want to get the full discussion, and it's a 90 minute audio discussion, go to the URL that you see here. And I should mention that is a correct URL, where it says looking-forward. It was a typo on the site.

Deciding whether to store personal data as nodes or users
Video duration: 6m 37s 6h 8m Intermediate


Deciding whether to store personal data as nodes or users provides you with in-depth training on Web. Taught by Tom Geller as part of the Drupal 6: Online Presentation of Data

please wait ...