Thanks Carl, I wasn't aware of that function, that works :) Sometimes
normalization can just get you in trouble, slow things down. My question
was mainly regarding the efficiency in terms of storage, and how you query
that if you store the short version. I would not consider dividing the
dat
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):
s
On 12/17/2014 11:52 AM, Radomir Wojcik wrote:
>
> So to answer my own question, you wouldn't use the short version in the db if
> you plan to do like/contains queries on them. Correct me if I'm wrong.
True. I don't think I've ever seen a case where a field had choices and
I also wanted to do li
>
> So to answer my own question, you wouldn't use the short version in the db if
> you plan to do like/contains queries on them. Correct me if I'm wrong.
>
>
Unless I plan to use haystack later and index the human readable form
later. I think I understand now, thanks
--
You received this mes
On 12/17/2014 11:23 AM, Radomir Wojcik wrote:
>
> Thanks for the insight, I'm on the same page as you.
>
> My only real concern is that I will have to use a function, such as this
> one to get the human readable version of the stored data, then you need to
> lookup the value from the dict. And i
>
> Thanks for the insight, I'm on the same page as you.
>
>
My only real concern is that I will have to use a function, such as this
one to get the human readable version of the stored data, then you need to
lookup the value from the dict. And if you're doing querying on that object
using key
Hi Radomir,
On 12/17/2014 09:56 AM, 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 y
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
8 matches
Mail list logo
