By chuffee on

I'm creating a site in drupal that is primarily used to display news and information about charities that my not for profit organisation works with. I'm very happy with the basics text elements of the site.

Currently we also use an internal database to record contact with these organisations and the clients we refer to them. I'd like to include this information within the site as a members only area. I'm also looking to include a spatial element so I can display the information geographicaly and intergate the data set using GIS. (proably googlemap api)

The question (finally!) is should I be looking to build an external database that I can connect to through drupal to display the information, but also use for the googlemap elements. Or should I be looking to incorporate the data into the site database as custom tables.

The database we currently use is large and structurally quite complicated. I'm worried that by replicating it as part of the drupal install I'm setting myself up for trouble. I'd have all my eggs in the one basket.

As you can probably tell I'm relatively new to drupal but confident with programming. Any pointers appreciated.

Cheers

⋅ Categories: Drupal 5.x

Comments

Magnity’s picture

Magnity commented

There are no particular issues why they cannot be in the same database, but if you have the additional database, then i'm sure it will make it easier to code for you if they are separate - simply because you know that nothing you do in that database will affect the core drupal installation.

Magnity

http://webdesign.magnity.co.uk
Drupal 5 themes | Drupal 6 themes

hershel’s picture

hershel commented

I would keep it separate. Less potential problems I would think.

chuffee’s picture

chuffee commented

That's what I thought. But as the data I'm storing largely relates to the more general content on the site I'm beginning to wonder if I'm just not able to get my head into the drupal paradigm. My site structure includes some duplication of some of the structure I'd need to include in the database. So maybe I need to think about saving this data within custom nodes?

hershel’s picture

hershel commented

That would generally be the correct approach--node data is the standard way to store content in Drupal.

zbricoleur’s picture

zbricoleur commented

...is that you can use the Drupal database abstraction layer. And you can write your synchronization code as a Drupal module, rather than as some stand-alone script. This will possibly save you a lot of work as you upgrade Drupal in the future. Not to mention, it will push you up the Drupal learning curve ;-)

I'm doing something similar to this at the moment--representing a legacy application and database on the Web via Drupal--and I've done it by mapping the legacy data to the Drupal node structure. Cron fires a couple of modules periodically that bring the changes from the legacy db forward into Drupal. (Obviously, I'm not worrying about 2-way synchronization, or even real-time updates.)