To be honest, I've never dealt with huge data sets but in the cases I have dealt with it's never been a problem.
This might be relevant: http://dev.mysql.com/doc/refman/5.0/en/is-null-optimization.html Unless someone shows me pretty compelling stats otherwise, I'll always lean to implementing in a way that makes sense logically and worry about performance optimizations when they come up. Storing Nulls just make sense to achieve the goal so that's what I'd do until there's a reason for me not to. On Tuesday, August 20, 2013 3:46:16 AM UTC-7, Jani Tiainen wrote: > > On Mon, 19 Aug 2013 11:14:54 -0700 (PDT) > Jason Arnst-Goodrich <good...@gmail.com <javascript:>> wrote: > > > > > > > > > Problem is that usually databases aren't very fast to search NULL > values > > > so if you have to for example produce often list of products that you > can > > > buy "infinite amount", you would like to consider using value(s) that > don't > > > conflict from valid set of values. > > > > > > I'm pretty sure that's not true. > > My knowledge is limited per implementation but as far as I know, standard > implementation is not to include NULL's (since NULL means "does not > exist"). > > I think pretty latest PostgreSQL can use indexes to filter NULL values as > well (doesn't have facility to store them though). Oracle since 11g has > option to include null values in the index. > > MySQL uses table statistics to determine are NULL values indexed or not. > > For the rest I don't have knowledge about. > > That doesn't remove the fact that there will be a limit for ordering one > time - though I would be happy to know what "unlimited" amount of ordering > would mean and how to actually it would be implemented and what's the real > world use case... > > > +1 to store as Null. > > > > On Monday, August 19, 2013 1:07:27 AM UTC-7, Jani Tiainen wrote: > > > > > > On Mon, 19 Aug 2013 00:39:09 -0700 (PDT) > > > Victor Hooi <victo...@gmail.com <javascript:>> wrote: > > > > > > > Hi, > > > > > > > > I have a Django IntegerField that I'm using to store the purchase > limit > > > for > > > > a product. > > > > > > > > purchase_limit = models.IntegerField() > > > > > > > > > > > > I also need to represent no limit (i.e. infinity) as well in that > field. > > > > > > > > I was thinking of just using NULL to represent no limit. > > > > > > > > purchase_limit = models.IntegerField(blank=True, null=True) > > > > > > > > > > > > Zero would have a meaning for this field (you can't buy any), > however > > > > negative numbers don't have any meaning. > > > > > > > > Hence, another option is just to use say, -1 as the value to > represent > > > no > > > > limit. > > > > > > > > Any thoughts on either option, or which one is more "correct"? > > > > > > From mathematical point integers forms an infinite (countable) set. > Though > > > in computer science interger is usually a finite set. So what you need > is > > > just define a logic. Note that this also makes impossible to enforce > > > "unlimited" amount to buy so there will definitely be some maximum > amount > > > you can really buy. > > > > > > NULL is usually interpreted as "no value defined" which would suit > well in > > > that sense. Problem is that usually databases aren't very fast to > search > > > NULL values so if you have to for example produce often list of > products > > > that you can buy "infinite amount", you would like to consider using > > > value(s) that don't conflict from valid set of values. > > > > > > I personally would pick max value while leaving NULL to mean "no value > > > defined". > > > > > > -- > > > > > > Jani Tiainen > > > > > > > -- > > 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...@googlegroups.com <javascript:>. > > To post to this group, send email to > > django...@googlegroups.com<javascript:>. > > > Visit this group at http://groups.google.com/group/django-users. > > For more options, visit https://groups.google.com/groups/opt_out. > -- 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+unsubscr...@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. For more options, visit https://groups.google.com/groups/opt_out.
