2009-09-20 9 views
3

Je suis en train de créer une application qui permettra aux gens d'afficher des informations dans différentes zones d'une ville (pour environ 10 villes). Connaissez-vous des bases de données/ensembles de données (normalisés) existants qui ont ce type d'information? Ou devrais-je en créer un à partir de zéro? Toutes les suggestions de pointeurs très appréciés!application basée sur la localisation

+0

Vous cherchez un schéma de base de données conçu pour ce type d'information, ou pour une base de données existante avec l'emplacement des choses. Si ce dernier, quel genre de choses voulez-vous? –

+0

Oui, un schéma db fonctionnerait. Je pense à un schéma pour relier les villes avec des zones spécifiques de la ville. Par exemple, NYC (centre-ville, centre ville, quartier chic, chelsea, etc ...). Je me demande si cela doit être basé sur des codes postaux et mapper les codes postaux aux noms de zone ... mon application va répertorier les entreprises dans différents domaines au fond ... Merci pour vos réponses! – berto77

+0

comme la façon dont ce site le fait: http://www.thrillist.com/list/Boston – berto77

Répondre

-2

Vous pouvez l'enregistrer comme deux entiers longitude et la latitude (je pense, si ma géographie est correcte)

1

Normalization dans ce cas est quelque peu problématique parce que l'exigence d'atomicité précise qu'un seul attribut stocke une valeur unique d'une domaine donné, et les choses deviennent assez floues ici en regardant les systèmes de coordonnées. Il y a quelques options. Chacun d'eux est parfaitement normalisé.

Points séparés Tableau

Dans cette approche, vous auriez une table qui serait comme (notation PostgreSQL):

CREATE TABLE geo_points (
    id bigserial not null unique, 
    x bigint, 
    y bigint, 
    z bigint, 
    primary key (x, y, z) 
); 

dossiers entreraient dans ce tableau et les commentaires seraient joints sur geo_points.id.

Type de Point approche

Diverses bases de données ont des types pour le stockage des points. Si nous supposons que tout est au niveau du sol et on n'a pas besoin de suivre l'altitude, nous pouvons:

CREATE TABLE tagged_location (
    id bigserial not null unique, 
    user_id int references users(id), 
    location point, 
    comment text not null, 
    primary key (user_id, location) 
); 

Avec cette approche, les points pourraient ressembler '(134.22222, 94.4444)' et différents systèmes de coordonnées peuvent être pris en charge par le système de gestion de base de données. Ceux-ci peuvent inclure des coordonnées plates, des coordonnées sphériques ou similaires. Le choix d'un système de coordonnées est très important car il affecte les unités qui sortent dans des choses comme les calculs de distance. Par exemple, si vous utilisez des coordonnées sphériques, la distance est généralement mesurée en degrés, donc si vous voulez convertir en miles ou en km, vous avez encore du travail à faire.

Tableau numérique Approche

Vous pouvez représenter un point comme un tableau numérique. C'est généralement une solution de contournement où il n'y a aucun type de point natif. Cela correspond à 1NF parce que chaque tableau représente des coordonnées 2D ou 3D pour un seul emplacement. L'ordinalité compte, et ainsi le tableau, pris dans son ensemble, représente une seule valeur (c'est-à-dire un tuple plutôt qu'un ensemble ou un sac). Ceci est équivalent à l'approche ci-dessus avec un type de point sauf que normalement vous devez faire vos propres calculs de distance, et le point ressemblera '{134.22222, 94.4444}'

En fin de compte avec tant d'approches différentes qui sont toutes parfaitement normalisées la question de la conception de base de données est vraiment limitée par votre SGBDR et votre cas d'utilisation. Vous ne trouverez probablement pas un design prêt à l'emploi qui convient parfaitement à votre cas d'utilisation.

Questions connexes