Y at-il un avantage à stocker les données d’adresse de rue distinctement au lieu d’une chaîne?

StackOverflow https://stackoverflow.com/questions/1626432

Question

Actuellement, nous stockons nos données d'adresse comme suit:

string suiteNumber (ie. unit number)
string streetNumber (building number)
string streetName
string streetDirection (N/NW/S/etc.)
string streetType    (rd/st/ave/etc.)
// ... etc. (postal code/city/province/state/country

Mais je suis confronté au problème (commun de ce que je peux dire) d’analyser les 5 premières parties d’adresse lorsqu’il s’agit de traiter et d’importer des adresses.

Je pense que tout cela serait considérablement plus simple si l'adresse de la rue n'était qu'une chaîne (varchar dans la base de données).

Il y a 2 arguments qui m'ont été donnés pour expliquer pourquoi nous devrions le conserver tel quel: 1. La recherche est plus facile lorsque vous pouvez rechercher JUSTE le nom de la rue ou le numéro, etc., mais je pense qu’un script SQL s'inspirant de SELECT x FROM adresse WHERE streetAddress LIKE "% INPUT % " ;; Bien sûr, ce n’est pas aussi rapide, mais cela fonctionnerait (et le jeu de données pour cette recherche s’applique uniquement aux clients est incroyablement plus petit que l’ensemble des adresses que nous avons stockées).

  1. Actuellement, nous avons un système qui signale les appartements. Si vous trouvez qu’une personne à l’adresse A est un appartement, nous les signalons et elle recherchera toutes les autres personnes portant ce numéro / nom de rue et les marquera un parfois besoin commercial important

Je les ai déjà tous stockés sous forme de chaînes en raison de la myriade d'exceptions dans les adresses.

Je vous pose donc la question suivante: existe-t-il des raisons particulières pour lesquelles vous souhaitez / souhaitez stocker les éléments d'adresse municipale séparément?

Était-ce utile?

La solution

J'ai écrit tout un article sur ce blog il y a quelque temps. Il y a de très bonnes raisons de stocker chaque donnée dans un champ séparé. Notamment pour la validation des données d'adresse.

Bien sûr, cela dépend de l’industrie dans laquelle vous travaillez et de l’utilisation des informations. Si des adresses non valables ne coûtent rien à votre entreprise, stockez des données invalides. Sachez cependant qu’à terme, vous voudrez peut-être utiliser ces données pour les mailings, les rapports démographiques, etc. Si les données ne sont pas valides, il n’est pas facile de les corriger après coup.

Voici mon article de blog:

http://www.endswithsaurus.com/2009 /07/lesson-in-adress-storage.html

En outre, en ce qui concerne la recherche "Où StreetAddress Like"% what%% '". C’est très bien si vous effectuez une recherche rapide pour votre propre bénéfice, mais lorsque vous essayez d’automatiser des parties de votre système qui reposent sur des données d’adresse ou même de supprimer des doublons, de proposer aux utilisateurs une suggestion automatique, etc. etc., les performances sont dégradées à un point tel qu’elles deviendront inutilisables à mesure que la table d’adresses sera volumineuse.

Si des adresses non valides ne vous font pas craindre des coûts réels pour l'entreprise, ce n'est pas un problème - mais si vous n'utilisez les adresses pour quoi que ce soit qui soit économiquement (ou susceptible de l'être) l'avenir), alors pourquoi stockez-vous ces informations en premier lieu?

@Snorfus Ah, vous devez être dans les Prairies. J'avais négligé de publier des descriptions de terres dans mon blog, mais c'est quelque chose que je pense pour un post ultérieur.

Les subdivisions légales (LSD) sont principalement utilisées dans Oil & amp; Les industries du gaz et des autres ressources primaires en Alberta, en Saskatchewan et au Manitoba (bien qu’elles soient présentes dans certaines parties de la Colombie-Britannique, leur utilisation n’est pas aussi répandue). Ils prennent tous le même format: section, canton, rangée, méridien. Par exemple:

  

SE 28-12-17-W5

Il s’agit du coin sud-est de la section 28, canton 12, rang 17, à l’ouest du cinquième méridien.

Vous pouvez simplement utiliser un seul champ et l’analyser avec des expressions régulières ou le décomposer en champs distincts contenant la ventilation du LSD. Exécuter des expressions rationnelles dans SQL Server peut être difficile en termes de performances. Mon point de vue est le même que celui des données d'adresse en général, c'est-à-dire que chaque donnée est une donnée unique et distincte qui doit être stockée dans des champs distincts. Cependant, étant donné que la grande majorité de ce type de données d’adresse n’est pas utilisée par le grand public au lieu d’une adresse postale, je pourrais recommander de concevoir quelque chose qui permettrait de séparer cette information (mais lié à) vos données d'adresse principale. Cependant, étant donné que la description du terrain / LSD fait également partie de chaque adresse canadienne, je pourrais être tenté de le stocker dans mon tableau d'adresses principal en fonction du public cible de la base de données.

Voici un article sur la répartition du système de ressources en terres de l'Alberta:

http://www1.agric.gov. ab.ca/%24department/deptdocs.nsf/all/agdex10302

Une chose que vous trouverez souvent dans Oil & amp; Selon Gas au moins (c’est l’essentiel de mon expérience), les travailleurs ne se réfèrent souvent qu’aux deux premières parties du LSD - c’est-à-dire 28 sur 12, ou 43 sur 16. Le reste du LSD est impliqué par le localité de l’adresse - c’est-à-dire Grand Prairie, Fox Creek, Wolf Lake, etc.

Autres conseils

J'avais l'habitude de penser que c'était une bonne idée, jusqu'à ce que mes applications soient déployées et qu'un flux constant de demandes parvienne à des modifications. À l'époque, j'habitais en Ontario, au Canada et je pensais savoir à quoi ressemblait une adresse standard. Jusqu'à ce que certains clients aient une adresse qui combine le P.O. Boîte et adresse en une. Ensuite, les clients de l’Alberta ont commencé à utiliser les codes structurés mentionnés dans une autre réponse. Puis les adresses de la Colombie-Britannique où il n’y avait ni rue ni numéro de rue, mais seulement un site et un compartiment et une route rurale. C4, S16 RR7 Mountainville. Et puis, avec les fournisseurs américains, les règles du code postal ont été ignorées. Et puis, un client britannique occasionnel est apparu dans la base de données et tout ce que vous pensiez savoir sur les adresses est mis à l'écart. Un nom de bâtiment sans numéro de rue, deux noms de rue, deux noms de ville, le tout dans une adresse!

Bright House,
Waverly Crescent off Oxford Road,
Seething-under-Norton, Banbury,
Oxfordshire
OB7 3VT
United Kingdom

C'est un exemple inventé, mais ils existent. Les Britanniques parviennent à se débrouiller, car chaque entreprise locale dispose d’une base de données d’adresses nationale à jour et n’a besoin que du code postal et du nom ou du numéro de la maison. Le reste est rempli à partir de la base de données.

Dans le cas de cette adresse, il y a probablement un autre croissant Waverly à Seething-under-Norton, ce qui explique le nom de la deuxième rue. Et Seething-under-Norton était un village qui a longtemps été incorporé à la ville de Banbury. Les deux noms sont donc dans l'adresse. Dans les adresses britanniques, vous obtenez souvent des municipalités qui n'existent pas. Ils sont considérés comme des villes postales en ce qu'ils n'existent que dans le système postal. Il y a généralement une base historique pour le nom. De nombreuses adresses londoniennes ressemblent à cela, avec des personnes écrivant Londres une fois, et Leyton ou South Ruislip ou Hillingdon une autre fois. Les lettres sont toutes livrées rapidement.

Donc, à moins qu'une des fonctionnalités de votre logiciel ne soit d'empêcher la saisie d'adresses étrangères dans le système, ne le faites pas!

En passant, vous avez mentionné l'identification de toutes les personnes d'une même rue par leur nom. Avez-vous vérifié à Denver Colorado où il existe des noms de rue qui se terminent et reprennent, un kilomètre plus loin. Une fois, je me suis égaré à Littleton (banlieue de Denver) en essayant de trouver une certaine adresse, mais on m'a dit qu'il me fallait une autre rue telle ou telle qui était ailleurs. Il y a ensuite la pratique britannique d'utiliser deux noms ou plus pour chaque route. Par exemple, il y aura un chemin Homerton qui s'appellera alors Marsh Hill, puis Homerton High Street, puis le chemin Urswick et ensuite le chemin Lower Clapton, le tout sur un kilomètre ou deux. Plus généralement, il y aura un chemin Norton dans le village de Wick. Si vous le suivez, vous remarquerez que, après un kilomètre et demi, vous vous trouvez maintenant sur Wick Road et que vous entrez dans le village de Norton.

À mon avis, cela présente certains avantages, mais dans tous les cas où j’ai vu l’essayer, le coût et la complexité de cette opération dépassent les avantages négligeables.

Le moindre de vos problèmes va être de former / obliger les utilisateurs à respecter tous les champs que vous leur donnez pour entrer toutes les différentes parties qui composent et adresser dans un format cohérent - la plupart des gens ne pensent tout simplement pas une adresse municipale composée de 5 parties différentes au maximum, qui entrera vraisemblablement comme d'habitude.

Donc, s’il n’ya pas eu de personnes qui essaient réellement d’utiliser le système, c’est probablement une bonne idée.

En Europe, l’adresse postale est généralement un nom plus un "numéro". (où nombre peut être quelque chose comme "3a"). J'ai vu des bases de données les stocker séparément pour une raison unique: vous pouvez rechercher les noms de rue dans une base de données officielle pour les vérifier (par exemple, pour vous protéger contre les fautes de frappe). Pour ce cas d’utilisation, il est donc logique de conserver les parties vérifiables et non vérifiables dans des colonnes différentes.

Je doute que vous puissiez trouver une raison de la décomposer davantage, à l'exception d'une peur floue de perdre des informations.

est un avantage si vous suivez une approche orientée objet pour modéliser votre domaine entier. Votre question me rappelle ce titre de blog Mars n'est pas un chiffre . Quelque chose d'analogue pourrait être dit à propos des rues et des adresses ("une rue n'est pas une chaîne"). SnOrfus souligne un problème valable dans son commentaire.

Bien que le stockage indépendant de chaque composant d’une adresse puisse présenter des avantages, vous devrez évaluer le coût par rapport aux besoins et aux exigences de votre entreprise. Si vous ne faites rien dans le domaine du courrier ou de l'expédition, cela peut être excessif et compliquer considérablement les aspects de votre architecture. De plus, toute autre personne travaillant avec votre code risque de ne pas comprendre ce qui se passe et d’introduire des problèmes importants sans le savoir, corrompant ainsi la base de données.

Par exemple, aux États-Unis, la "ligne de livraison" est la suivante: d'une rue: PO Box 12345.

Dans ce cas, "Boîte postale". est en fait le nom de la rue tandis que 12345 est le numéro principal. Format normal " " Selon les idées reçues, le numéro principal doit être indiqué en premier lieu dans une adresse, comme dans "123 Main Street".

Si vous reformatez l’adresse de manière standard, vous devez vous rappeler à quoi elle ressemblait à l’origine.

C’est là que la vérification et la normalisation des adresses entrent en jeu. Au moins aux États-Unis et dans quelques autres nations, dont la Grande-Bretagne, vous avez l’avantage de pouvoir envoyer l’adresse à un service de vérification en ligne qui peut nettoyer, normaliser et vérifier votre adresse. Souvent, ces services renverront l'adresse telle qu'elle devrait apparaître sur l'envoi, ainsi que les éléments constitutifs de l'adresse. Si vous avez un besoin commercial pour les composants, vous pouvez les stocker indépendamment. Sinon, un autre appel sur le service Web de vérification des adresses doit renvoyer les composants à l’heure souhaitée.

Dans l’intérêt d’une divulgation complète, je suis le fondateur de SmartyStreets. Nous proposons des services de vérification d'adresse basés aux États-Unis et comprenant Validation CASS-Certified de vos adresses. N'hésitez pas à me contacter personnellement si vous avez des questions.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top