1) You can change this in your model. Check out "verbose_name" and "verbose_name_plural" for the model's Meta class.
http://docs.djangoproject.com/en/dev/ref/models/options/ 2) If you have a ManyToMany field to samurai on the item, you don't need the inventory model at all. A samurai's inventory could be obtained by doing "samurai.item_set" and it would return all their items. There are different reasons to do each one. However..... 3) Duplicates can be done by using the Inventory model. You could either add a new field called quantity, or simply have multiple Inventory records per item and samurai. If each item can have specific attributes (for example, I can have 2 of the same item, one of which has 55% durability, and the other has 70% durability) you would want to have separate records, and could put these attributes on the inventory model or item model. But if each item is the same, it's easier to just use a quantity field. 4) If status is a field that could have changing options, create a Status model and do a ForiegnKey(Status) on the item. If the choices aren't going to change frequently, the choices field could be an Integer or String field and use the Django choices functionality. http://www.djangoproject.com/documentation/models/choices/ I gather that you may not have a ton of experience working with relational databases. Perhaps an article on basic database design might help. It's best to really understand how a relational database works and should be designed before trying to work with Django's ORM. http://www.deeptraining.com/litwin/dbdesign/FundamentalsOfRelationalDatabaseDesign.aspx On Feb 18, 3:17 pm, Timothy Kinney <timothyjkin...@gmail.com> wrote: > Hello, I'm new to Django, but learning as fast as I can. I would > appreciate some technical help and some database design advice... > > ** > 1) Admin pluralizing question > > So I have three models: samurai, item, inventory > > When I login to the admin screen it has chosen to pluralize them as: > samurais, items, inventorys > > I'm a little bit anal, so this bothers me. Where can I change it to: > samurai, items, inventories ? > > ** > 2) Model relationships question > > Can someone validate that I am using the right relations for these? > Users will login with a unique id and instantiate a samurai, each > possessing various attributes (not shown below). Items have unique IDs > but many samurai can have many of the same items (including > duplicates)- also the items have a status as to the condition of the > item. There is one inventory for each samurai which links his items to > him. Based on this system, I believe I should do the following... > > Samurai model: AutoField ID (primary key, unique) > Item model: AutoField ID (primary key, unique), ManyToMany(Samurai) > Inventory: Foreignkey(Samurai), ManyToMany(Item) > > Did I do this right? > > ** > > And two design questions: > > 3) How should I implement duplicates of items for a single inventory? > For example, one samurai may have two identical fish. Should I store > this as an additional field in the inventory? If so, how do I link it > to the item id? Is it cleaner/faster/better to use a dictionary? > Actually, I've never heard of a dict in SQL. > > 4) How should I implement the status/condition of the items? For > example, I want them to be "New", "Used", or "Broken/Unusable". Should > I store this in the inventory or in a separate model called Status? If > the latter, should I use a foreignkey(item) and OneToOne(Inventory) or > something else? > > Thank you very much for your help. If you are aware of any tutorials > or available source code for coding RPGs, browser games, or > inventories, I will be happy to follow links and try to learn on my > own. > > -Tim -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
