views:

95

answers:

2

I have a simple form that allows users to select an option from a select menu and then save it in the database. I need to store the full name so that views can use it. So the table in my database might look like this:

nid | uid | type
------------------
1   | 2   | 0
2   | 2   | 3
1   | 3   | 5
3   | 1   | 4

and so on... I was thinking of doing a basic one to many relationship table like:

tid | name
----------
0   | random name 1
1   | random name 2
2   | random name 3
3   | random name 4

but I only have 6-7 types at the most, so I'm not sure if that is efficient. Maybe simply storing the full name instead of an ID would be better in that case? Another way might be to use variable_get, but then I also need the custom field module that allows php code in views. Any better way to do it in drupal? Thanks.

+1  A: 

I would do this by putting the terms in a taxonomy and using that taxonomy in a CCK node type. Turn off the body field by clearing the body label and turn off the title field with auto nodetitle. That leaves your node add form for that type as just a select list of the taxonomy terms, and all saved nodes are exposed to views and filterable by user and/or term.

That'll give you a database that looks a lot like what you described, with an extra bit of overhead that you'll never notice because Drupal caches everything.

Scott Reynen
Hmm, maybe I'm not understanding this method too well, but I thought taxonomy doesn't store the user id? I may also need other custom fields as well such as when the user submitted the form.
Wade
I think he is suggesting that you put the types in a taxonomy and then have users create nodes which belong to that taxonomy so they have to select a value. Essentially your solution but without having to create custom tables.
Jeremy French
The node includes both the user ID and the taxonomy term ID, tying them together. So yeah, what Jeremy said. Drupal nodes will automatically record when the node was saved and expose that to views, but if you need more custom fields, you can always add more with CCK.
Scott Reynen
This form needs to be on the node view page, so I'm not sure how that'll work, but in the end I just decided to go with another table, wasn't as bad as I thought.
Wade
A: 

It's better, because require less supporting "after some time"... And perfomance i think will not so differrence, than keep it in field. Also you save memory, because stings store only in little table, and referencing numbers require not so much place...

Nikit

related questions