Dear friends. I am a Drupal "user/administrator" for few months. I developed a project which involves one main portal and some satellite portals. I decided that the administration should involve only the main portal in order to increase the maintainability.
Probably the biggest problem in doing that was to split the database, sharing some tables and duplicating others in the satellite portals. Things work but I had a lot of problems in deciding what tables could be shared and what should be duplicated. And I doubt about de future dependencies between tables and modules
A better documentation of the database structure could facilitate this kind of "different views of the database".
So I propose different possibilities in order to have this documentation:
- An UML diagram of the database. I think is difficult to maintain in a collaborative effort.
- A simple description of each table which could be made for each project involved in drupal. The items could be very simple: table name, project/modules, purpose of the table, table dependencies. This could be made as documentation tables in the drupal database or as a collaborative document. Probably including this as a metadescription of drupaldatabase in the drupal database is a good solution.
What dou you think? I do not know all the internal details of drupal but from an administrator point of view the dependencies beetween tables difficutl the task (for instance: If you want to have different image galleries in the satellite portals using taxonomies in the main portal you have to duplicate the gallery taxonomy in the main portal, manually modify the filed image_nav_vocabulary in table variable and IMPORTANT:duplicate the table vocabulary_node_types in order to avoid the diferentt taxonomies for an image. Obviously this is a complex structure but the other posibility which is to duplicate the taxonomies in all the portals implies to maintain a big amount of duplicate taxonomies).

Please, if you decide to document the tables I could provide a first approach of my (provisional) experience.
Thank you. jparets@ugr.es

Comments

puregin’s picture

puregin commented

Thanks for your suggestions - better documentation of the database structure and a better organization for this documentation is indeed a good idea.

There are a number of tools which attempt to automatically generate structure diagrams of various kinds directly from the database, or the SQL definition files. I'll have a look at whether these might be an acceptable way to address this problem.

I agree that documenting contributed modules w.r.t. their extensions/use of the database is another issue we should look at.

It would be nice to have clear, easy to find and easy to use documention for common database tasks.
(e.g. sharing a database among multiple installations, dealing with complications from upgrading, ...)

Djun

fgm’s picture

fgm
Primary language French
Location Paris, France
commented

I've created a few UML diagrams for the concepts in Drupal (not necessarily matching the physical implementation), which you can reuse (they're under the very open CC BY license):

Project module:
http://blog.riff.org/index.php/2005/10/02/28-grokking-drupal-the-project...

Aggregator (not Aggregator2)
http://blog.riff.org/images/aggregator8.png

eCommerce (2 diagrams)
http://blog.riff.org/index.php/2005/08/07/9-grokking-drupal-e-commerce

beginner’s picture

beginner commented

All the links in #2 are broken.

A Database structure documentation would in many cases be useful, just like api.drupal.org is VERY useful in documenting functions.
I don't see anything like this in the handbooks, yet.

But the database structure changes with every Drupal release... maybe the documentation would be better suited for api.drupal.org where changes between versions can be documented?

fgm’s picture

fgm
Primary language French
Location Paris, France
commented

Hi, here are the updated links. Note that most of them have been incorporated in the Drupal handbooks, AFAIK:

Core:
http://blog.riff.org/2006_05_14_data_model_for_drupal_4_7_core

eCommerce (2+1 diagrams)
http://blog.riff.org/2005_08_07_grokking_drupal_e_commerce
http://blog.riff.org/2006_10_07_grokking_drupal_ecommerce_dependencies

Project module 4.6:
http://blog.riff.org/2005_10_02_grokking_drupal_the_project_module
Project module 4.7:
http://blog.riff.org/2006_07_28_grokking_drupal_the_project_module_in_dr...

Aggregator (not Aggregator2)
http://blog.riff.org/2005_09_17_grokking_drupal_the_feed_aggregator

beginner’s picture

beginner commented
Title: Database structure documentation » api.d.o: docs for DB structure.

I'm speaking about core only.
I didn't see the handbook page with it, but if you say that it's already been incorporated in the handbook, then this issue can be closed.

Or else, the issue can be kept open to follow up on the proper, per Drupal version documentation of the DB structure, within api.d.o, as I discussed above.

sinasalek’s picture

sinasalek commented

Looking for the same thing, it's amazing that drupal does not have any database structure documentation!!

add1sun’s picture

add1sun commented

Note that in Drupal 6 this has changed. There is now a description in the new schema API and all of core has been documented. In the code these are seen in the .install files where the db schema is built on install. api.d.o doesn't parse it yet but the awesome Schema module does. So now you can just download 6, install Schema module and you have your own local DB docs.

sinasalek’s picture

sinasalek commented
Status: Active » Closed (fixed)

sounds great :) thanks

beginner’s picture

beginner commented
Status: Closed (fixed) » Fixed
Anonymous’s picture

Anonymous (not verified) commented
Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.