Sito web: Qual è il modo migliore per memorizzare un gran numero di variabili utente?

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

  •  20-09-2019
  •  | 
  •  

Domanda

Sto progettando un sito web utilizzando PHP e MySQL attualmente e come il sito procede mi ritrovo aggiungere sempre più colonne alla tabella utenti di memorizzare diverse variabili.

Il che mi ha fatto pensare, c'è un modo migliore per memorizzare queste informazioni? Giusto per chiarire, l'informazione è globale, può essere influenzato da altri utenti in modo cookie non funziona, anche avrei perso le informazioni se eliminare i cookie.

La seconda parte della mia domanda è, se non risultare che la memorizzazione in un database è il modo migliore, sarebbe meno costoso per avere un gran numero di colonne o meglio di combinare le colonne relative in colonne varchar delimitati e poi esplodere in PHP?

Grazie!

È stato utile?

Soluzione

Nella mia esperienza, preferirei ottenere il database destra di iniziare ad aggiungere campi separati da virgola in possesso di più elementi. Dover vagliare attraverso molteplici campi separati da virgola è solo andare a male l'efficienza del programma e la leggibilità del codice.

Inoltre, se il tavolo è in crescita a molto, allora forse avete bisogno di guardare in dividendolo in più tabelle unite da dipendenze estere?

Altri suggerimenti

Mi piacerebbe creare una tabella user_meta, con tre colonne:. user_id, key, value

Non vorrei andare per l'opzione di colonne di raggruppamento insieme e li esplodere. È un lavoro molto disordinato e ingestibile. Invece forse provare a diffondere quelle colonne su un paio di tavoli e utilizzando la funzione di transazione di InnoDB.

Se ancora piace l'idea di aggiornare spesso il database e se questo metodo è conforme con quello che stai cercando di raggiungere, è possibile utilizzare di APC la funzione di caching per memorizzare (cache) le informazioni "a livello globale" sul server.

MongoDB (e dei suoi cugini NoSQL) sono grandi per cose come questa.

La banca dati un gran bel posto per memorizzare tali dati, fintanto che sono variabili e non, per esempio, enormi file di immagine. Il database ha tutte le ottimizzazioni e le specifiche per la memorizzazione e il recupero di grandi quantità di dati. Tutto ciò che si imposta sul livello di file system sarà sempre essere battuto da ciò che il database è già in termini di velocità e funzionalità.

  

sarebbe meno costoso per avere un gran numero di colonne o meglio combinare colonne collegate in colonne varchar delimitate e poi farli esplodere in PHP?

Non è poi così tanto di una prestazioni di una domanda Manutenzione IMO - non è divertente per gestire le centinaia di colonne. La memorizzazione di tali dati - forse come serialize d oggetti - in un campo TEXT è una valida opzione - a patto che sia sicuro al 100% si avrà mai a fare domande su quei dati.

Ma perché non utilizzare una tabella user_variables normalizzata in questo modo: 

id  | user_id | variable_name | variable_value

E 'un po' più complesso per interrogare, ma prevede una molto pulita struttura della tabella a tutto tondo. È possibile aggiungere facilmente variabili utente arbitrari in quel modo.

Se si sta facendo un sacco di domande come SELECT FROM USERS WHERE variable257 = 'green' potrebbe essere necessario attenersi ad avere colonne specifiche.

La banca dati è sicuramente il posto migliore per memorizzare i dati. (Sto assumendo che stavi pensando di riporlo in flat file in altro modo) Farebbe sicuramente ottenere migliori prestazioni e la sicurezza di utilizzare un DB sopra la memorizzazione dei file.

Per quanto riguarda la memorizzazione dei dati in più colonne o delimitano ... E 'una scelta personale, ma si dovrebbe prendere in considerazione alcune cose

  1. Se avete intenzione di delimitare gli elementi, è necessario pensare a ciò che si sta andando a delimitare loro (cosa che non è probabile che affiorano nel testo il tuo delimitazione)
  2. spesso trovo che aiuta a cercare e visualizzare se un altro programmatore del vostro livello sarebbe in grado di capire quello che hai fatto con poco aiuto.
  3. Sì, come ha detto Pekka, se si desidera eseguire query sui dati memorizzati si dovrebbe attaccare con le colonne separate
  4. Puoi anche avere un leggero incremento delle prestazioni da non recupero e l'analisi di tutti i dati ogni volta che se si desidera solo un paio di campi di informazioni

Io suggerirei di andare con le colonne separate in quanto offre la possibilità di una maggiore flessibilità per il futuro. E non c'è niente di peggio che dover cambiare drasticamente la struttura dei dati e migrare le informazioni lungo la pista!

mi sento di raccomandare la creazione di un server di memcached (vedi http://memcached.org/ ). Essa ha dimostrato di essere vitali con un sacco di grandi siti . PHP ha due estensioni che integrano un client nel vostro tempo di esecuzione (vedi http://php.net /manual/en/book.memcached.php ).

Provatelo, non ve ne pentirete.

Modifica
Certo, questo sarà solo un'opzione per dati che sono frequentemente utilizzati e altrimenti dovrebbero essere caricati dal database ancora e ancora. Occorre tuttavia tenere presente che si avrà ancora per salvare i dati a una sorta di memoria persistente.

Un database document-oriented potrebbe essere quello che ti serve.

Se si vuole attaccare ad un relazionale di database, non prendere l'approccio ingenuo di solo la creazione di un tavolo con oh così molti campi: 

CREATE TABLE SomeEntity (
    ENTITY_ID    CHAR(10)    NOT NULL,
    PROPERTY_1   VARCHAR(50),
    PROPERTY_2   VARCHAR(50),
    PROPERTY_3   VARCHAR(50),
    ...
    PROPERTY_915 VARCHAR(50),
    PRIMARY KEY  (ENTITY_ID)
);

Invece definire una tabella degli attributi: 

CREATE TABLE Attribute (
    ATTRIBUTE_ID  CHAR(10) NOT NULL,
    DESCRIPTION   VARCHAR(30),
    /* optionally */
    DEFAULT_VALUE /* whatever type you want */,
    /* end_optionally */
    PRIMARY KEY   (ATTRIBUTE_ID)
);

Poi definire il tavolo SomeEntity, che include solo gli attributi essenziali (ad esempio, campi obbligatori in un modulo di registrazione): 

CREATE TABLE SomeEntity (
    ENTITY_ID   CHAR(10) NOT NULL
    ESSENTIAL_1 VARCHAR(30),
    ESSENTIAL_2 VARCHAR(30),
    ESSENTIAL_3 VARCHAR(30),
    PRIMARY KEY (ENTITY_ID)
);

E quindi definire un tavolo per gli attributi che si potrebbe o non potrebbe desiderare di negozio. 

CREATE TABLE EntityAttribute (
    ATTRIBUTE_ID    CHAR(10) NOT NULL,
    ENTITY_ID       CHAR(10) NOT NULL,
    ATTRIBUTE_VALUE /* the same type as SomeEntity.DEFAULT_VALUE;
                       if you didn't create that field, then any type */,
    PRIMARY KEY     (ATTRIBUTE_ID, ENTITY_ID)
);

Evidentemente, nel tuo caso, che SomeEntity è l'utente.

Invece di MySQL si potrebbe considerare l'utilizzo di un triplestore , o un valore-chiave negozio in questo modo si ottiene il benifits di avere tutto il multiutente multithreading, le prestazioni e il caching voodoo, capito, senza tutta la fatica di cercare di capire in anticipo che tipo di valori che si vuole veramente da memorizzare.

Svantaggi:. È un po 'più costoso per capire lo stipendio medio di tutte le persone in Idaho che ha anche propri cappelli

dipende da che tipo di informazioni utente si archiviano. se i suoi dati di sessione pertinenti, utilizzare sessioni PHP in coordinamento con i gestori di eventi di sessione per memorizzare i dati della sessione in un singolo campo di dati nel DB.

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