By markallenneil on

I'm developing a for-fun website using Drupal 6. The website will maintain a few database tables with user-entered data.

Question: Is it best to put these tables in the "drupal" database or to create a separate database and use db_set_active to switch back and forth?

I ask this as I can see pros/cons to both approaches...

1) Pro: Seems more proper to keep "site data" separate from "delivered data". Perhaps I'm old school... Drupal doesn't make this distinction for stories and pages... so why for my databases?
2) Con: Switch back and forth has drawbacks. Probably takes some time (albeit trivial). If the code on-page pukes you may be left pointing to the wrong database... and the page will not display correctly.
3) Pro: Cleaner to update the site. Already seems a pain (to me, perhaps I'm doing it wrong) to update the site from my localhost development copy and not bork the Users table (for example).

I am open to all opinions.

Mark

PS. Is there a repository for Drupal best practices?

⋅ Categories: Drupal 6.x

Comments

vm’s picture

vm commented

If the data is to be user entered any way? why not just do it through drupal using the CCK.module to build the forms or digging in and building a custom module to interact with the Forms API ?

that removes your last con, updates should work correctly even with user entered data as the tables will essentially be drupal tables.

marcvangend’s picture

marcvangend
he/him
Primary language Dutch
Location Amsterdam
commented

Hi Mark, welcome to the community.
I agree with VeryMisunderstood, CCK is the way to go if you're looking for a way to collect user generated content.

Re 1: Don't let the default content types 'story' and 'page' mislead you. They just illustrate the concept of content types - when I start a new site, I just delete them and create my own, because I find the names misleading.

Personally, I wouldn't put the 'delivered data' in a separate database. If your site's concept includes user generated content, then 'delivered data' = 'site data'. I have sometimes experienced problems updating a site, but never something that would have been prevented by using two databases.

Content types (the name says it all) are perfect to keep the different types of content apart. For instance, you could create a content type called 'product' (containing a name, description, manufacturer, price and image) and a content type 'product review' (title, body text, grade, reference to a product). Next, you can configure the permissions, so all logged in users can create nodes of the type 'product review', but only editors can create product nodes. It's that easy.

There is not really one repository for best practices, although you could see this site, drupal.org as one big repository. There is a lot of information in the documentation section (like here, under tutorials and howto's: http://drupal.org/handbook/customization), but also on the forum, in the project issues and on other drupal-related sites.

markallenneil’s picture

markallenneil commented

Thanks both of you for the replies... and for the welcome.

I'll leave everything one big database for now... as you recommend. I don't think I was clear that the issue is that I'm developing the site locally, exporting the Drupal DB to a SQL table, then using BigDump to import the data at a hosted site. For the static content, all is well... for the stuff users are populating (in my case a database... which in turn populates a bigger database)... for this I'll need to *not* export/import the tables so as to not blow away the live content. Still see that as an issue for the Users table... it still seems to me that there are some tables you want to preserve on the live site when updating from the development site.

I suppose I should just get less lazy... write a script to do the DB export... that way it'll be really hard to accidentally screw up the user-entered content.

Again, thanks...

Mark

marcvangend’s picture

marcvangend
he/him
Primary language Dutch
Location Amsterdam
commented

I understand the problem you're talking about. When I have to upgrade drupal or a module, I usually create a copy of the live site locally, test the upgrade, and if it works, repeat it online (in offline mode, after creating a backup of course). That way I don't have to import or export databases at all.

markallenneil’s picture

markallenneil commented

Lotta work, that procedure. You sound like you do this for a living... :) Me... just a hobby... if I get 10 visitors to my site I'll be surprised.

I'll just take care to preserve key tables for now. Just was interested in what other folks do.

Thanks again.

Mark

marcvangend’s picture

marcvangend
he/him
Primary language Dutch
Location Amsterdam
commented

You're right, it's part of my job to do this, but I also do it at home as a hobby. The average module update isn't a lot of work really: you copy or upload the files and run update.php, so the module can take care of database alterations, if any. That's all there is to it. In fact, on my personal hobby sites, I often don't even care about testing it locally. I just create a backup and install the update directly on the server.