Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
By dcrites on
I'm new to Drupal and am beginning to design a web site that has two primary types of information:
A. Static marketing information. E.g. why a visitor should buy my widget.
B. Structured user data wherein each user may only see and interact with their own data. The user data is generated by a sensor widget (e.g. Fitbit) that dumps the collected data into a mySQL database on the web server. Each user would like to login to the web site with their own user/login; personalize their account with their height, weight, age, etc; view graphs of their data; and get SMS message from the web site when they hit certain goals but are not logged-in.
The user data consists of 20 different tables of data, each with 5-10 columns, and tons of row data that can amount to hundred of thousands of records or even millions of records over a lifetime -- for each user.
1. I'm not stuck on this, but it might make sense for the web server to assign the user data to a separate database for for each user. This would allow permissions to be set per database. Is this a good approach? Is this compatible with Drupal? Can Drupal deal with data spread among many databases?
2. What modules should I be looking at to assist my efforts?
Thanks for any advice,
David
Comments
_
This is real easy to do with standard Drupal functionality. You could just create a simple content type for the user data and set the permissions so that only the user who created a record (node) could view that record. Drupal content types are very flexible and you can probably avoid making 20 of them, depending on the specifics of what you are trying to do. If you do need to create multiple, related content types, you can relate them to each other with Entity Reference module.
I think that's a pretty good starting place.
Now, content types are not the most performant things because they make use of Fields and come with a lot of features you might not need. They are very flexible, but if you are really going to work with tons of records of interrelated content types, then I might consider creating custom entities. Custom entities have their own tables where they store info (instead of having it spread all over like content types) so they perform better. The downside is that you are responsible for developing all the stuff you get for free with content types, like permissions and an admin interface.
Honestly, I would just start with content types. It's going to get your site online much faster. I am a big believer in solving the problems you have and not the problems you think you will have. So, if you get to the point where utilization of your site is getting high and you need to rethink performance, then maybe look into custom entities. Or caching. You will have more information about the issues, because you will have real data.
As for your idea about separate databases, I think it is not necessary because Drupal's permissions system is perfectly capable of handling your requirements. Also, you can connect Drupal to multiple databases, this is not something I know a lot about, but I think you are way out on an edge case here.
- Brendan
Thanks a ton for the reply
Thanks a ton for the reply Brendan. I took a look at Content Types and Fields and concluded that I could not make my database schema fit. The reason I have 20 tables is that my database schema requires it. The tables have interrelated fields (e.g. one-to-many and many-to-many relationships) primary keys, and indexes. If a Content Type is like a "table" then I need interrelated Content Types, which didn't seem to fit with Content Types and Fields.
So I'll now take a look at creating custom entities as you suggest.
Thanks again for pointing me in the right direction.
- Dave
_
I can't comment on whether or not this is the right approach because I don't know about your content. But a content type is not like a table in many ways. You can be easily mislead if you stick too close to a predesigned schema.
I'll give you an example. If I were building your application in a traditional web application I might have a base table for "exercise". That would have a many to one relationship to a location table (where a person exercised) and a many to many relationship to a table for type of exercise (cardio, weights (upper, lower), etc.).
In Drupal, you just don't worry about tables like this. For location, I would install the Location module. That makes "location" just another field. It even geocodes for you. Type of exercise is just a standard Drupal taxonomy.
You clearly have some web development experience and that will serve you well when working with Drupal. But Drupal can do so much with standard functionality and modules faster and better than you can with code. It's what Drupal is all about.
My guess is that you are going to get those 20 tables down to maybe 3 content types, 4 taxonomy vocabularies and the rest fields. And doing this is so fast. You can really get this up in a few hours. I think you are really missing out on taking advantage of what Drupal can offer you. If you let Drupal do this heavy lifting, you can concentrate on the things that really do need code.
If you want to post your schema, I would be happy to give you more targeted advice.
- Brendan
_
The most difficult thing about experienced web developers making the switch to drupal is to stop thinking in the familiar terms of db tables, fields, and schemas. Trying to control drupal at the schema level is going to give you no end of headaches and frustration if you don't know it well enough first. You can't shoehorn what you already know to fit drupal and make it work the way you want you.
Learn to do things the standard drupal way first (content types, fields, entityreferences, relations, views, etc). Then, when you encounter something that really does require more custom control use drupal entities and the drupal api.
If you're not willing or open to do that, then you probably shouldn't be using drupal in the first place. You'll just end up banging your head against the desk, screaming in the forums and all over the internet how drupal sucks, waste a ton of time, and up using something like django or codeignitor anyway.