As a newcomer to Drupal I am considering using it for an application where you have multiple users.

User1, User2, User3 User n... (could be hundreds)

As an example There are 4 tables:

User, account, portfolio, symbol

each user would enter details into the database which are private to them and not available to other users.

This can be easily achieved in a relational databse using tables and foregin keys, then selecting data based on user id etc.

As each user is individual how would I replicate this in Drupal, so each user may be an account holder but they can't see data from another account holder.

Can views seperate the data in this way so that a user when logging on will only see the data they have entered.

Comments

niyas’s picture

You can accomplish this by using "permissions" in Drupal. Since admin will be able to set the permissions for the corresponding content type or field values. so the data entered by the user can be set as public/private.

twalls’s picture

Thanks Niyas.

If I add another level of complexity in another type of user. A Worker (possibly hundreds of these).

The worker does work for the users but only some users and has to be invited to do a specific job.

EG
User 1 has Job XYZ to do. This is displayed in a job list (private not viewable to any one else). This job is then offered/displayed to a specific worker and only that worker. The worker will complete the job and mark its as done.

Again easy using tables in a relational database but could permissions handle this.

niyas’s picture

May be this is what you need http://drupal.org/project/storm and there are plenty of modules available for this kind of jobs. Also I think there is no need to think about using relational databases as we have all these features in Drupal in the form of separate modules.

zilla’s picture

well, this to me seems more like a workflow challenge and thought process - you have to simply settle upon the rules and logic in this process, and then, beyond the obvious (permissions, which will let you control who can even see what), you can also consider something like Organic Groups to house and within that, private groups, to control Job display....you could also do something robust with entity relations, simply relating users to some other user/client/etc and then create views that expose content defined by that relationship (robust and powerful, a bit more tedious to set up)....OG may solve this IF you are relying on invites, which implies that you've already adopted a manual review process (then anything in that group is limited) - or alternatively, ditto for Entity Relations (using the field of entity relations to relate to Users who are manually invited, in this case being done by simply editing the node that is the "job description" etc...that way, you could also use simple Flags (flags module) to mark jobs as "done" or "taken" etc and exploit those in views as well.