Upgrade your account to a Community Supporter account and remove most of the site ads.

Reply to thread

Message: <blockquote data-quote="Pielorinho" data-source="post: 1120535" data-attributes="member: 259">Hmm -- wouldn't this be better to set off in a validation table, then?  It just seems to me inefficient to set it off with a foreign key; instead, you can create a combo-box on the appropriate form, set it so that you can only choose items from a list, and set the list to items on the "school" list.  That'll make the database smaller.  In your way, each spell will have an extra records, like spell_has_attribute_id:  07attribute_type_id:  [School]attribute_id:  [Conjuration]Spell_ID:  [Acid Fog]value:  - in addition to the nine records in the attribute table and the one entry in the attribute_type table.  My method adds only one field to the database, in the spell's description, as well as adding in a new table for validation purposes. If you hate new tables, you can avoid it in two ways: first, put all the schools in the attribute table anyway, along with the attribute_type of school, and then set the combo box to validate according to a query on the attribute table for all attributes with the attribute_type of "school".  Second, you can manually list the acceptable values for a combo box in the box's properties.  I'd not recommend doing the last, because the info on the form won't propagate to other forms or uses of the database; either the first (a separate validation table) or the second (a query based on attributes with the type "school") would work fine. Glad you like the idea!  I'm still a little iffy on it:  how well does Access do on performing numerical equations on text fields?  That is, if a given field contains the values, "9", "3", "5", and "A lump of bitumen", can Access list all fields with a value between 2 and 6?  If not, or if it's difficult, it might be best to find a different way to deal with material components.   At the risk of expanding the database further, perhaps the spell_has_attribute table can contain one more field, "attribute_note"?  This would be useful on only two current types of attributes -- focuses and material components -- but if someone added in a new type of attribute (maybe, for example, a new type of spell that required a certain skill level as a component, or required a feat as a component, or something like that), they'd have the "notes" field already there for them.  It'd be reserved for non-numerical information about the attribute that ends up being unique to a given spell. This is fun to think about!Daniel</blockquote>

Verification