On Monday, 1 August 2016 13:56:55 UTC+1, Aymeric Augustin wrote: > > > On 30 Jul 2016, at 23:15, Donald Stufft <don...@stufft.io <javascript:>> > wrote: > > > > See #6 of > https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/ > > > I’m aware of this article. It's a entertaining read but, unlike the W3 Q&A > mentioned earlier, it doesn’t contain actionable advice for designing a > generic system that won’t perform too poorly in many use cases when you > have no idea of what these use cases will be. > > Having read the W3C Q&A carefully, the relevant comment on field lengths is "avoid limiting the field size for names in your database". There is no reference to 60 characters being "enough".
> Last names containing over 30 characters are sufficiently common — likely > tens of millions of people at this time — to deserve consideration. That’s > where this thread started. Let’s not block an easy win for these tens of > millions because the general problem is intractable. Besides, a last_name > field is already a severe simplification, as we all know. > > Last names containing over 100 characters are sufficiently uncommon to be > the subject of trivia articles on the Internet. I’m absolutely certain that > no website has tens or thousands of millions of last names over 100 > characters; in fact, not even tens of such names. > > If someone has access to real-life stats from a very large database of > names in a country that has long last names that could help us make an > optimal decision. > > Aren't we in danger of premature optimisation here? The field lengths are currently 30 characters. Even if we expanded it to 255, we would be adding at worst 255 bytes to the storage requirements for a user. If a site has 1 million users, that's 250MB of disk space - which for a site with 1M users is unlikely to be significant, let alone the main driver of disk usage. After all, with 1M users, you'd only need each of them to do something requiring a 200 byte record to use the same amount of space. For sites with far less users, it's proportionally much less of a problem - and those sites are the majority, and hence will benefit most from being able to deal with more user's names, while suffering the least cost. Sure, we'd be wasting some space on disks - but we'd be enabling Django to serve more of the world's population (and allowing sites to just use last_name as a full name if they don't want the fun of a custom user model). So if we don't want to go to full TextField for the username, at least let's go to the biggest number possible (currently 255, thanks MySQL). Premature optimisation is the root of all evil... Cheers, Malcolm -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/161214ba-560e-4ef6-ada8-4eb0067b3181%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
