La façon universelle de stocker une adresse / un emplacement géographique dans une base de données est la suivante:
[Address] nvarchar(max) not null
Cela nécessite le moins de code de programmation (et donc réduit les coûts de maintenance) et est entièrement compatible avec n'importe quelle adresse. Il y a cependant trois grands problèmes:
L'absence de validation des données signifie que le champ peut être utilisé à d'autres fins que le stockage de l'adresse. L'un des objectifs est une attaque DOS destinée à remplir l'espace de votre base de données en entrant 2 Go de données dans le champ d'adresse.
Les données ainsi stockées ne permettent pas de les traiter à des fins de veille économique et d'exploration de données. Par exemple, combien d'utilisateurs viennent d'Inde? Il n'y a pas de moyen facile de le savoir, car ces adresses ne seront pas normalisées.
Les utilisateurs peuvent entrer par erreur une adresse incomplète ou manifestement erronée.
Afin d'atténuer le premier problème, limitez le champ à ce que vous pensez être une limite raisonnable. Personnellement, je commencerais par 1000 caractères, puis je le réduirais en fonction de la longueur des adresses saisies par les premiers utilisateurs une fois que vous aurez obtenu un ensemble de données suffisamment volumineux.
Afin d'atténuer les deux autres problèmes, vous pouvez utiliser une API tierce qui analyse les adresses et vous présente les données contenant le pays, la ville, le code postal, etc. Si possible, l'API doit pouvoir afficher l'adresse sur une carte à l'utilisateur pour réduire le risque pour l'utilisateur d'entrer une adresse incomplète ou erronée: la plupart des utilisateurs savent où ils vivent, et voir une position différente sur une carte leur donnerait immédiatement un indice qu'ils devraient vérifier leur entrée.
Notez que quelle que soit l'API que vous utilisez, elle ne sera pas parfaite. Il trouvera la plupart des adresses, mais pas toutes. Cela signifie que si l'API indique que l'adresse n'existe pas, mais que l'utilisateur insiste sur le fait, vous devez a priori faire confiance à l'utilisateur, même s'il peut se tromper.
Cela signifie également que vous devez toujours stocker l'entrée de l'utilisateur d'origine, côte à côte avec le résultat de l'API. Cela signifie que le schéma devient:
[RawAddress] nvarchar(max) not null
[ParsedAddress] xml null