Salvare l'URI nel database analizzato vs plain

Question

Salvare l'URI nel database analizzato vs plain

#1 da (3 voti)
#2 da (1 voti)
#3 da (1 voti)

3

Quindi voglio salvare diversi URI nel database.

Voglio che anche il formato sia forzato a cercare facilmente diversi URI.

È meglio creare una tabella come questa:

CREATE TABLE uris (
  id INT(11) UNIQUE PRIMARY KEY AUTO_INCREMENT,
  scheme VARCHAR(255) NOT NULL,
  host VARCHAR(255) NOT NULL,
  path VARCHAR(255) NOT NULL,
  port SMALLINT UNSIGNED,
  query VARCHAR(255),
  fragment VARCHAR(255)
);

O solo

CREATE TABLE uris (
    id INT(11) UNSIGNED PRIMARY KEY AUTO_INCREMENT,
    uri TEXT NOT NULL
);

UPDATE: utilizzare

Leggi, salva forse qualche analisi. Ricostruisci l'URI originale e se si tratta di reindirizzamento URL web. Può fare qualche ricerca, ecco perché penso che prima sia meglio.

Sono più interessato a quale vantaggio si ha rispetto a un altro o ci sono problemi nell'utilizzarne uno?

database data uri

posta nikachx 07.03.2017 - 13:51

fonte

3 risposte

Leggi altre domande sui tag database data uri

Come modellare lo stato genitore con singoli stati figlio Architettura API Gateway e Microservices [chiusa]

score 3 · Answer 1

Seriamente, hai intenzione di fare una ricerca per schema, percorso, porta, query o frammento? Probabilmente no. L'unica cosa che potresti voler cercare è l'host.

Ora, se gli URI hanno per lo più lo stesso schema (http), puoi costruire un indice sulla colonna di testo in forma libera e cercarlo usando l'operatore LIKE con una corrispondenza prefissata, se vuoi fare la ricerca dell'host. Se ci sono pochi schemi diversi, cerca " link ", " ftp: // foo % "ecc.

Quindi, è probabile che l'unica ricerca di cui avrai mai bisogno possa essere implementata memorizzando l'URI come testo in forma libera. Pertanto, consiglierei di non cercare di essere intelligente e di archiviare semplicemente l'URI come testo in forma libera.

Inoltre, quanti URI hai intenzione di memorizzare? Se è nelle migliaia e non in milioni, dovresti considerare che l'ottimizzazione prematura è la radice di tutto il male. Quindi, costruire indici che non avrai mai bisogno non ti aiuterà in alcun modo. Ciò favorisce anche la memorizzazione dell'URI come testo in forma libera.

Inoltre, c'è la possibilità minore che il formato degli URI cambierà in futuro. Ciò significa che devi aggiornare la tua applicazione per accettare il nuovo formato. Memorizzando l'URI come testo in forma libera, non è necessario farlo.

score 1 · Answer 2

Non vedo alcun motivo per cui non puoi fare entrambe le cose qui:

CREATE TABLE uris (
  id INT(11) UNIQUE PRIMARY KEY AUTO_INCREMENT,
  uri TEXT NOT NULL,
  scheme VARCHAR(255) NOT NULL,
  host VARCHAR(255) NOT NULL,
  path VARCHAR(255) NOT NULL,
  port SMALLINT UNSIGNED,
  query VARCHAR(255),
  fragment VARCHAR(255)
);

In questo modo puoi cercare rapidamente in questo modo o eseguire analisi su singole parti. Il meglio di entrambi i mondi. L'unico argomento a cui posso pensare di non farlo è a causa dei dati ridondanti, ma è solo una breve stringa che viene ripetuta e penso che il vantaggio e la semplicità superino una stringa duplicata.

score 1 · Answer 3

Gli uris hanno un formato ben definito, ma anche così penso che ti verrà difficile rappresentarlo come schema di tabella.

Ad esempio, il tuo esempio ha un numero di problemi

finirai a partire da ints
stringa di query può essere più lunga di 255 caratteri
a volte la porta non è indicata etc