3 ms·

Names are hard, don't force things into your assumptions. If you must, record fields such as: Full Legal Name - Freeform input no string input limitation. If

Names are hard, don't force things into your assumptions. If you must, record fields such as: Full Legal Name - Freeform input no string input limitation. If you feel like this is an attack vector, send the data out for human review. Full Mailing Address - Don't try to break this down, allow multi-line, free form input. This is something you might want to validate with your shipping carrier and/or a human. A short 'nickname' used as such.

tsimionescu 2y ago
You always need size limitation. You really don't want to allow 10GB strings to be stored in the full name field. Also, in almost any situation where you need a legal name, you actually want to follow a lot of rules. This idea that people's original names are somehow sacrosanct is a misunderstanding. If you're doing business in a European country for example, you have to write your name in Latin/Cyrillic letters, perhaps with a few symbols like ' or - allowed as well, and typically with a few accents/diacritics specific to each country. You certainly can't register as 田中 in any context that requires a legal name in France, you'd have to write that as Tanaka. And this is natural because legal records are meant for authorities in some specific country to read, and compare with other legal docs - so they need to at least be readable to those authorities.
- mjevans 2y ago
  A 10GB string does sound pathologically large; however it's an argument about the absurd. What size is for sure enough? Well I'm not so sure. What if someone has a lot of titles. What if society decides that someone's Legal Name requires a post quantum cryptography key that happens to be 20MB (binary) long? Also, FYI, at least PostgreSQL doesn't give you a free lunch for any variable length string; length requirements are a column constraint that DEGRADES performance because it has to check. An external name validator of some sort could check things. Commonly allowed cases could pass by computer check, while actual humans could review edge cases. Someone trying to abuse the name field like that probably needs human review elsewhere anyway.
  - tsimionescu 2y ago
    I would bet you that Postgres insert and query performance is better overall if all names in your table are, say, up to 10KB long than if you have a bunch of bots inserting 20MB-long "names". And 10GB long strings are just not supported by Postgres, at least with default settings. And the point of adding limitations on length is that you shouldn't even accept the HTTP request if it passes some size, as it will severely degrade performance if you allow someone to upload a 10GB string, even if you separate it into a human review area. Finally, if the legal requirements change and legal names can legitimately contain cryptographic material, than your system has to change. There is no point in designing a system that tries to work for any possible use case.
bigstrat2003 2y ago
Names aren't actually that hard. It's perfectly reasonable to assume that your system is going to be used in your country and culture, and handle the cases which are relevant for that. Edge cases within that context, and expanding to other cultural contexts, can be handled as they come up. But until then, YAGNI.

tsimionescu 2y ago

You always need size limitation. You really don't want to allow 10GB strings to be stored in the full name field. Also, in almost any situation where you need a legal name, you actually want to follow a lot of rules. This idea that people's original names are somehow sacrosanct is a misunderstanding. If you're doing business in a European country for example, you have to write your name in Latin/Cyrillic letters, perhaps with a few symbols like ' or - allowed as well, and typically with a few accents/diacritics specific to each country. You certainly can't register as 田中 in any context that requires a legal name in France, you'd have to write that as Tanaka. And this is natural because legal records are meant for authorities in some specific country to read, and compare with other legal docs - so they need to at least be readable to those authorities.

mjevans 2y ago
A 10GB string does sound pathologically large; however it's an argument about the absurd. What size is for sure enough? Well I'm not so sure. What if someone has a lot of titles. What if society decides that someone's Legal Name requires a post quantum cryptography key that happens to be 20MB (binary) long? Also, FYI, at least PostgreSQL doesn't give you a free lunch for any variable length string; length requirements are a column constraint that DEGRADES performance because it has to check. An external name validator of some sort could check things. Commonly allowed cases could pass by computer check, while actual humans could review edge cases. Someone trying to abuse the name field like that probably needs human review elsewhere anyway.
- tsimionescu 2y ago
  I would bet you that Postgres insert and query performance is better overall if all names in your table are, say, up to 10KB long than if you have a bunch of bots inserting 20MB-long "names". And 10GB long strings are just not supported by Postgres, at least with default settings. And the point of adding limitations on length is that you shouldn't even accept the HTTP request if it passes some size, as it will severely degrade performance if you allow someone to upload a 10GB string, even if you separate it into a human review area. Finally, if the legal requirements change and legal names can legitimately contain cryptographic material, than your system has to change. There is no point in designing a system that tries to work for any possible use case.

bigstrat2003 2y ago

Names aren't actually that hard. It's perfectly reasonable to assume that your system is going to be used in your country and culture, and handle the cases which are relevant for that. Edge cases within that context, and expanding to other cultural contexts, can be handled as they come up. But until then, YAGNI.