Re: Any benefit in storing shorter strings or numbers to represent data for a choice char field?

You might want to try using a many to one relationship, it adds a table
lookup but offers flexibility where the data is in the database instead
of the application and for large data sets can be much faster. It's
also good database normalization practice.

class StudentType(Models.Model):
short_name = models.CharField(max_length=2)
name = models.CharField(max_length=30)

class Student(models.Model):
student_type = models.ForeignKey(StudentType)

It's good to learn all the different ways of doing things because each
project is different and can benefit from either choice. For example a
traditional normalized database such as PostgreSQL offers many benefits,
whereas NoSQL used in Big Data is the opposite and also offers many
benefits.

https://docs.djangoproject.com/en/1.7/topics/db/models/#many-to-one-relationships
http://en.wikipedia.org/wiki/Database_normalization
https://en.wikipedia.org/wiki/PostgreSQL
https://en.wikipedia.org/wiki/NoSQL

Alan

On 17/12/2014 16:56, Radomir Wojcik wrote:
> The official django doc uses this as an example (see below). Is there
> any point to storing 'FR' instead of 'Freshman" so the choice matches
> what is stored? Is it faster at all? Saves room? What about for querying
> the data? Then you have to lookup the symbol 'FR' in the tuple if
> someone wants to query by 'Freshman'.
>
> What is the best practice? Is it even more efficient if integers were
> used, like 1 value to represent Freshman and so on? To me it makes sense
> to store 'Freshman' as 'Freshman' but I'd like to get some insight.
>
> fromdjango.dbimportmodels
>
>
> class Student(models.Model):
> FRESHMAN = 'FR'
> SOPHOMORE = 'SO'
> JUNIOR = 'JR'
> SENIOR = 'SR'
> YEAR_IN_SCHOOL_CHOICES = (
> (FRESHMAN, 'Freshman'),
> (SOPHOMORE, 'Sophomore'),
> (JUNIOR, 'Junior'),
> (SENIOR, 'Senior'),
> )
> year_in_school = models.CharField(max_length=2,
> choices=YEAR_IN_SCHOOL_CHOICES,
> default=FRESHMAN)
>
> def is_upperclass(self):
> return self.year_in_school in (self.JUNIOR, self.SENIOR)
>
> --
> You received this message because you are subscribed to the Google
> Groups "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to django-users+unsubscribe@googlegroups.com
> <mailto:django-users+unsubscribe@googlegroups.com>.
> To post to this group, send email to django-users@googlegroups.com
> <mailto:django-users@googlegroups.com>.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/e0a71f13-1541-437b-a7b9-24c06f08c7e5%40googlegroups.com
> <https://groups.google.com/d/msgid/django-users/e0a71f13-1541-437b-a7b9-24c06f08c7e5%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.

--
Persistent Objects Ltd
128 Lilleshall Road
Morden SM4 6DR

The Home of Lasting Solutions

Mobile: 079 3030 5004
Tel: 020 8544 5292
Web: p-o.co.uk
Skype: alan-hicks-london
Personal blog https://plus.google.com/+AlanHicksLondon
Company blog https://plus.google.com/+PoCoUkLondon/posts
LinkedIn https://uk.linkedin.com/in/alanhickslondon/
GitHub https://github.com/alan-hicks

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/5491D335.9070502%40p-o.co.uk.
For more options, visit https://groups.google.com/d/optout.