Domanda

Ho bisogno di memorizzare le informazioni di contatto per gli utenti.Voglio presentarvi questa data sulla pagina come un hCard e scaricabile come un vCard.Mi piacerebbe anche essere in grado di interrogare la banca dati per il numero di telefono, email, etc.

Cosa pensi sia il modo migliore per memorizzare questi dati?Dal momento che gli utenti potrebbero avere più indirizzi, ecc completa normalizzazione sarebbe un pasticcio.Sto pensando di usare XML, ma non ho familiarità con l'esecuzione di query XML db campi.Dovrei ancora essere in grado di cercare per gli utenti con informazioni di contatto?

Sto usando SQL Server 2005, se quello che conta.

È stato utile?

Soluzione

Consideriamo due tabelle per le Persone e i loro indirizzi: 

People (pid, prefix, firstName, lastName, suffix, DOB, ... primaryAddressTag )

AddressBook (pid, tag, address1, address2, city, stateProv, postalCode, ... )

La Chiave Primaria che identifica in modo univoco ogni riga) di Persone è pid.Il PK della Rubrica è la composizione del pid e tag (pid, tag).

Alcuni dati di esempio:

Persone

1, Kirk

2, Spock

AddressBook

1, home, '123 Main Street', Iowa

1, work, 'USS Enterprise NCC-1701'

2, other, 'Mt. Selaya, Vulcan'

In questo esempio, Kirk ha due indirizzi:una 'casa' e uno di 'lavoro'.Uno di quei due possono (e dovrebbero) essere notato come chiave esterna (come un cross-reference) in People nel primaryAddressTag colonna.

Spock ha un unico indirizzo con il tag 'altri'.Dal momento che è di Spock solo di indirizzo, il valore di 'altri' deve andare in primaryAddressTag colonna pid=2.

Questo schema ha il piacevole effetto di impedire che la stessa persona da duplicazione di qualsiasi di loro indirizzi accidentalmente il riutilizzo di tag, mentre allo stesso tempo permettendo a tutte le altre persone di utilizzare qualsiasi indirizzo di tag a loro piace.

Inoltre, con FK riferimenti in primaryAddressTag, il sistema di database stesso farà valere la validità delle primarie targhetta per indirizzo (via qualcosa di noi database geek chiamata di integrità referenziale), in modo che la vostra o -- qualsiasi -- applicazione non ha bisogno di preoccuparsi di esso.

Altri suggerimenti

Perché sarebbe completa normalizzazione "un pasticcio"?Questo è esattamente il genere di cosa che la normalizzazione rende meno disordinato.

Non abbiate paura di normalizzare i dati.La normalizzazione, come Giovanni, è la soluzione, non il problema.Se si tenta di utilizzo della denormalizzazione i tuoi dati, proprio per evitare una coppia entra a far parte, allora si sta andando a causare voi stessi gravi problemi in futuro.Cercando di refactoring di questo tipo di dati lungo la linea dopo un ragionevole dimensione del set di dati NON SARÀ DIVERTENTE.

Io consiglio vivamente il check-out Highrise da 36 di Segnali.Recentemente, è stato consigliato a me, quando ero alla ricerca di un online contact manager.Lo fa molto di destra.In realtà, la mia unica obiezione finora con il servizio, è che penso che le versioni a pagamento sono troppo costosi-che è tutto.

Per come stanno le cose oggi, non è adatta in un piatto indirizzo del profilo.Ho 4-5 indirizzi di posta elettronica che uso regolarmente, 5 numeri di telefono, 3 indirizzi diversi siti web e CHAT profili, che vorrei includere nel mio profilo del contatto.Se si sta iniziando a costruire un sistema di gestione dei contatti e sei libera da limitazioni architetturali (si pensi gmail cantacts essere digitato un indirizzo e-mail), quindi gli utenti un favore e rendere il vostro contatto con la struttura flessibile (normalizzato) possibile.

Evviva, -D.

Io sono consapevole di SQLite, ma che non aiuta - sto parlando trovare i migliori schema (indipendentemente dal database) per la memorizzazione di questi dati.

Per Giovanni, non vedo quale sia il problema con un classico schema normalizzato sarebbe.Non hai dato molte informazioni per andare avanti, ma tu dici che c'è un uno-a-molti rapporti tra gli utenti e gli indirizzi, quindi mi piacerebbe paffuto per un bog soluzione standard con una chiave esterna per l'utente e l'indirizzo di relazione.

Se si assume ogni utente dispone di uno o più indirizzi, il numero di telefono, ecc.... si potrebbe avere un 'Utenti' tavola 'Indirizzi per la Tabella' (che contiene una chiave primaria e quindi non univoco di riferimento per gli Utenti), lo stesso per i numeri di telefono, permettendo a più righe con lo stesso UserID foreign key, il che renderebbe l'esecuzione di query 'tutti gli indirizzi per l'utente X' abbastanza semplice.

Non ho uno script, ma ho mySQL che è possibile utilizzare.Prima che io detto che ci sembrano essere due gli approcci logici per la memorizzazione di file vcard in SQL:

  1. Archivio di tutta la carta e lasciare che il database di ricerca, (forse) enorme stringhe di testo, e in un'altra parte del codice o anche lato client.ad es.

    CREATE TABLE IF NOT EXISTS vcards (
    name_or_letter varchar(250) NOT NULL,
    vcard text NOT NULL,
    timestamp timestamp di default CURRENT_TIMESTAMP in aggiornamento CURRENT_TIMESTAMP,
    PRIMARY KEY (username)
    ) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_bin;

Probabilmente più facile da implementare (a seconda di che cosa si sta facendo con i dati), anche se le tue ricerche sono andando a essere lento, se si dispone di molte voci.Se questo è giusto per voi, allora questo potrebbe funzionare, (se si tratta di qualsiasi bene poi è mai solo per voi.) È possibile elaborare i file vCard lato client o lato server utilizzando alcune belle modulo che condividono, (o qualcun altro ha condiviso con voi.)

Ho visto vCard evolversi e sapere che ci sarà un cambiamento in /alcuni/ tempo in futuro in modo che io uso tre tabelle.

Il primo è la carta di credito, (questo per la maggior parte dei link al mio tabelle esistenti - se non avete bisogno di questo appartiene a voi può essere una versione ridotta).Secondo la definizione di carta, (che sembrano essere chiamato profilo in vCard parlare).L'ultimo è di tutti i dati per le carte.

Perché ho lasciato DBIx::Class, (sì, io sono uno di quelli) di fare tutto il lavoro del database questo, (tre tabelle) sembra funzionare piuttosto bene per me, (anche se, ovviamente, si può stringere i tipi di match rfc2426 più da vicino, ma per la maggior parte ogni pezzo di dati è solo una stringa di testo.)

Il motivo è che io non normalizzare l'indirizzo della persona è che ho già un indirizzo di tabella nel mio database e questi tre sono solo per i non-utente dettagli di contatto.

 CREATE TABLE `vCards` (   
 `card_id` int(255) unsigned NOT NULL AUTO_INCREMENT,   
 `card_peid` int(255) DEFAULT NULL COMMENT 'link back to user table',   
 `card_acid` int(255) DEFAULT NULL COMMENT 'link back to account table',      
 `card_language` varchar(5) DEFAULT NULL COMMENT 'en en_GB',
 `card_encoding` varchar(32) DEFAULT 'UTF-8' COMMENT 'why use anything else?',
 `card_created` datetime NOT NULL,  
 `card_updated` datetime NOT NULL,
 PRIMARY KEY (`card_id`) )
 ENGINE=InnoDB DEFAULT CHARSET=latin1 COMMENT='These are the contact cards'

   create table vCard_profile (
    vcprofile_id int(255) unsigned auto_increment NOT NULL,
    vcprofile_version enum('rfc2426') DEFAULT "rfc2426" COMMENT "defaults to vCard 3.0",
    vcprofile_feature char(16) COMMENT "FN to CATEGORIES",
    vcprofile_type enum('text','bin') DEFAULT "text" COMMENT "if it is too large for vcd_value then user vcd_bin",
  PRIMARY KEY (`vcprofile_id`)
) COMMENT "These are the valid types of card entry";
INSERT INTO vCard_profile VALUES('','rfc2426','FN','text'),('','rfc2426','N','text'),('','rfc2426','NICKNAME','text'),('','rfc2426','PHOTO','bin'),('','rfc2426','BDAY','text'),('','rfc2426','ADR','text'),('','rfc2426','LABEL','text'),('','rfc2426','TEL','text'),('','rfc2426','EMAIL','text'),('','rfc2426','MAILER','text'),('','rfc2426','TZ','text'),('','rfc2426','GEO','text'),('','rfc2426','TITLE','text'),('','rfc2426','ROLE','text'),('','rfc2426','LOGO','bin'),('','rfc2426','AGENT','text'),('','rfc2426','ORG','text'),('','rfc2426','CATEGORIES','text'),('','rfc2426','NOTE','text'),('','rfc2426','PRODID','text'),('','rfc2426','REV','text'),('','rfc2426','SORT-STRING','text'),('','rfc2426','SOUND','bin'),('','rfc2426','UID','text'),('','rfc2426','URL','text'),('','rfc2426','VERSION','text'),('','rfc2426','CLASS','text'),('','rfc2426','KEY','bin');

create table vCard_data (
    vcd_id int(255) unsigned auto_increment NOT NULL,
    vcd_card_id int(255) NOT NULL,
    vcd_profile_id int(255) NOT NULL,
    vcd_prof_detail varchar(255) COMMENT "work,home,preferred,order for e.g. multiple email addresses",
    vcd_value varchar(255),
    vcd_bin blob COMMENT "for when varchar(255) is too small",
    PRIMARY KEY (`vcd_id`)
) COMMENT "The actual vCard data";

Questa non è la migliore SQL, ma spero che aiuta.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top