Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.
By dovry on
Hi,
I'd like to know if it is possible to create a relational DB using Drupal?
Yes, I know that Drupal is built _on top_ of a relational DB, but what I'd like to know is if it is possible to model a database with multidimensional content, relations and views using Drupal? And get a nice GUI on top with the Drupal interface?
I am not thinking that *all* the bells and whistles of the DB should be replicated, that would surely defeat the purpose.
The CCK module might be just the right thing to use, taxonomy could also come in handy, but I do not know these would take you all the way (still lots of tweaking necessary, lacking functionality).
I'd appreciate comments from people with knowledge of Drupal/CCK!
Comments
Can you tell us some more
Can you tell us some more about what you need to accomplish?
You are right that CCK and taxonomy will serve you well when trying to build relations between nodes, but I wouldn't immediately call it an RDB.
For instance, you could create a content type 'customer' (name, email, address) and a content type 'product' (name, description, price, picture). Next you could create a third content type 'purchase' with a date and two node reference fields: one for the customer, the other for the product. Now you have something resembling an RDB - but I'm not sure if this is what you're after.
there's also various node
there's also various node relationship modules (node family, node relativity, node hierarchy, node queue, etc) that would be very helpful.
i find that unlike most other CMS (which are more "fully configured", for lack of a better expression), there's very little drupal can't do. It's more a matter of what has someone in the community already created that you can make use of.
Drupal is more of a framework for creating database driven web applications than joomla, wordpress, etc. It's pretty much exactly what you describe-- a front end for creating rdb apps that has a great deal of existing functionality, in the form of modules, available for your use coupled with a very nice theming/appearance system. And remember, whatever you can't poach from existing stuff, you can always write yourself with PHP. So, if PHP/mySQL can do what you want than so can Drupal-- Drupal just provides added value in terms of reusing stuff other folks in the community have already created.
but marc is correct-- with some more info we can better point you in the right direction. At minimum though, you'll want CCK, Views (which is essentially a query builder / display module) and some node relationship modules.
followup on my question
Thank you for your comments. Actually I am researching into moving a ms Access database to drupal, but I wanted to phrase the questions in more general terms.
I've been looking at some of the examples of usage of the CCK link modules, but I am not sure if these will do what I want. It seems that it is easy to add information on the 'many-side' of a 1:n link (e.g. add a parent-link to a number of child nodes) but I do not think it is possible to work on the 'one' (parent) side of the relationship (e.g. start with a parent item and add several related nodes, all sharing the same parent node - something like MS Access subforms). Another question would be how to add n:m (many-to-many) relationships.
Hope my questions are clear. What I am trying to find out is whether Drupal is a reasonable platform for a DB conversion, or if it would take so much tweaking and customising that the DB could better be built from the bottom up again, i.e. creating a standalone web app using php/mysql.
I hope I understand your
I hope I understand your question well enough to give an adequate answer. Here I go :-)
There are modules (I think one of them is called "add 'n' reference") which allow you to add and reference new nodes of a certain content type while editing/creating the 'one' side of the relationship.
I only have limited knowledge about databases, but isn't it considered a good practive to split up an n:m relationship into two 1:n relationships? Actually, the example I gave in my first post (customer - product - purchase) does just that.
I hope this helps.
Add and reference
Hi, thanks a lot for the tip!
I have been looking at the module, and it looks like unfortunately it does not work with newer (<4.x) versions of drupal. Another thing I've noticed is that there are several others looking for this specific functionality. One could call it subform functionality, but it would not necessarily have to be implemented as subforms (a la ms access), it is a question of keeping the context (parent node) when adding child nodes. (using i.e. sessions - this is what has made porting of add'n'reference to 5.x difficult, it looks like)
Re n:m, you are right that it often (always) is modelled using two 1:n relationships, and that it could be done as you've proposed. The problem is creating a GUI with simple/unified creation and edit of these nodes...
The problem is creating a
CCK and Contemplate should be very useful for you then. I've gotten some pretty sophisticated data entry forms for nodes with them. Unfortunately, they're not fully baked for D6 yet, but they do have dev/head versions so it shouldn't be too long. Besides, you'll want Views, which is still in alpha for D6, for any serious D6 site anyway.
context
thanks for all advice!
But contemplate requires php programming, yes?
So the question remains if the functionality is so far outside of Drupal's basic feature set, would I be better of creating a web application from scratch? (keeping in mind that it is not a regular CMS I am looking for)
hmmm... I don't really think
hmmm... I don't really think it's all that far outside drupal's basic feature set. I'm no professional developer, and I learned to use contemplate pretty quickly. The decision is somewhat dependent on your skillset-- for me the added functionality of the 100s of pre-existing modules for drupal far outweighs the grok curve.
A few years ago I did a business directory site for a friend based on mssql & asp.net (dotnetnuke, drupal, joomla, etc were still being born)-- I had to code the entire thing from scratch. It took forever. I'll never forget how complicated coding a simple paged alphabetic listing was. It took over a week... that's something you can do in drupal in a few minutes with 2 modules. In fact, the whole project, which took months of coding from scratch, is something I could probably do in a week or 2 with drupal now.
However, if you're an experienced developer and you could code what you need from scratch in a week or two anyway, then maybe grokking and using drupal doesn't buy you that much. For me the choice is a no brainer.
Not to mention the resusability for future projects.
Does that make any sense?
Contemplate does use php as
Contemplate does use php as a templating language, that's true. But I would not necessarily call it "php programming". Contemplate provides a list with all available variable and shows example output of each variable. With a single click, you add the php code which outputs the desired content to your template. Basically, all you have to do is to put those chunks of php in your own html code.
On the other hand, because a content template is written in php, you can use php programming if you happen to need it. That being said, it is hard for me to judge if you would need real php programming for your templates
Drupal is a mighty strong
Drupal is a mighty strong framework for handling nodes, i.e. texts. You could use a node as the basis of a typical database, e.g. "Personnel id - name - department" etc., but my impression is it would be lot of overkill to do it that way. Drupal, as you correctly state, is a relational database system, but I wouldn't use it to manage anything which can't be thought of as "texts" and "parts of texts". The typical database "atoms" (name - street - phone - salary...) don't fit in well with that paradigm.
To give but one example: Views, strong as it may be, is not meant as a general query builder, but as a Drupal-dedicated query builder. If you can squeeze something into nodes, Views will do wonderful things. But if you want to use Views to manage your own "my stamp collection" database, it won't help you.
You can, of course, make database tables, use your own php and your own mysql queries, and run all that within Drupal's framework, which would be a nice thing to control access rights etc., but for the real database handling and programming, you would be on your own.
And you can pour your stamp collection into a CCK construction, and with a decent taxonomy system you could probably make it work, but I think you'd be using Drupal for something that it actually isn't meant to. That said: the fact that you càn, proves its versatility :-)
There are a couple of database modules, but they are just tools to do certain things on the Drupal tables, and they do not qualify as general purpose database tools.
So, can you put your Access table in Drupal? Probably: yes. Should you do so? Probably no. At least, that's my gut feeling.
OK,
Thanks for your comment.
You are confirming the feeling I've got that Drupal is not the right tool for my project.
It is not that it is not powerful enough, it is just that even if (almost) anything is possible, it would take some tweaking, and that would take time, and that would make up for the advantages I was hoping for (to get something up and running quickly).