Melhor tipo de campo de banco de dados para um URL

Eu preciso armazenar um URL em uma tabela MySQL. Qual é a melhor prática para definir um campo que conterá um URL com um comprimento indeterminado?

1. Menor comprimento máximo de URL do denominador comum entre os navegadores populares: 2.083 (Internet Explorer)

2. http://dev.mysql.com/doc/refman/5.0/en/char.html Os
   valores nas colunas VARCHAR são cadeias de comprimento variável. O comprimento pode ser especificado como um valor de 0 a 255 antes do MySQL 5.0.3 e de 0 a 65.535 na 5.0.3 e versões posteriores. O comprimento máximo efetivo de um VARCHAR no MySQL 5.0.3 e posterior está sujeito ao tamanho máximo da linha (65.535 bytes, que é compartilhado entre todas as colunas) e ao conjunto de caracteres usado.

3. Então ...
   <MySQL 5.0.3 usa TEXT
   ou
   > = MySQL 5.0.3 usa VARCHAR (2083)

VARCHAR(512)(ou similar) deve ser suficiente. No entanto, como você realmente não sabe o tamanho máximo dos URLs em questão, talvez eu vá direto para TEXT. O perigo disso é, obviamente, a perda de eficiência devido ao fato de CLOBser muito mais lento do que um tipo de dados de string simples VARCHAR.

varchar(max) para SQLServer2005

varchar(65535) para MySQL 5.0.3 e posterior

Isso alocará o armazenamento conforme necessário e não deve afetar o desempenho.

Você desejará escolher entre uma coluna TEXT ou VARCHAR com base na frequência com que o URL será usado e se você realmente precisa que o tamanho seja ilimitado.

Use VARCHAR com comprimento máximo > = 2,083, como micahwittman sugeriu se:

1. Você usará muitos URLs por consulta (diferentemente das colunas TEXT, os VARCHARs são armazenados alinhados com a linha)
2. Você tem certeza de que um URL nunca excederá o limite de linhas de 65.535 bytes.

Use TEXT se:

1. O URL pode realmente quebrar o limite de linhas de 65.535 bytes
2. Suas consultas não selecionam ou atualizam vários URLs de uma só vez (ou com muita frequência). Isso ocorre porque as colunas TEXT apenas mantêm um ponteiro embutido e os acessos aleatórios envolvidos na recuperação dos dados referenciados podem ser dolorosos.

Você deve usar um VARCHAR com uma codificação de caracteres ASCII. Os URLs são codificados em porcentagem e os nomes de domínio internacionais usam o punycode, portanto o ASCII é suficiente para armazená-los. Isso usará muito menos espaço que o UTF8.

VARCHAR(512) CHARACTER SET 'ascii' COLLATE 'ascii_general_ci' NOT NULL

Isso realmente depende do seu caso de uso (veja abaixo), mas o armazenamento TEXTé um problema de desempenho e, VARCHARna maioria dos casos, parece um exagero.

Minha abordagem: use um VARCHARtamanho generoso, mas não excessivamente grande , como VARCHAR(500)esse, e incentive os usuários que precisam de uma URL maior a usar um encurtador de URL como safe.mn.

A abordagem do Twitter: para um UX realmente bom, forneça um encurtador de URL automático para URLs muito longos e armazene a "versão de exibição" do link como um trecho da URL com elipses no final. (Exemplo: http://stackoverflow.com/q/219569/1235702seria exibido como stackoverflow.com/q/21956...e vincularia a um URL reduzido http://ex.ampl/e1234)

Notas e Advertências

• Obviamente, a abordagem do Twitter é melhor, mas para as necessidades do meu aplicativo, a recomendação de um encurtador de URL foi suficiente.
• Os encurtadores de URL têm suas desvantagens, como preocupações de segurança. No meu caso, não é um risco enorme, porque os URLs não são públicos e não são muito usados; no entanto, isso obviamente não funcionará para todos. O safe.mn parece bloquear muitos URLs de spam e phishing, mas eu ainda recomendaria cautela.
• Observe que você não deve forçar seus usuários a usar um encurtador de URL. Na maioria dos casos (pelo menos para as necessidades do meu aplicativo), 500 caracteres são excessivamente suficientes para o que a maioria dos usuários o usará. Use / recomende apenas um encurtador de URL para links muito longos.

A maioria dos navegadores permite que você coloque grandes quantidades de dados em uma URL e, portanto, muitas coisas acabam criando URLs muito grandes. Portanto, se você estiver falando de algo além da parte do domínio de uma URL, precisará usar uma coluna TEXT desde o VARCHAR / CHAR são limitados .

Não conheço outros navegadores, mas o IE7 tem um limite de 2083 caracteres para operações HTTP GET . A menos que outros navegadores tenham limites mais baixos, não vejo por que você precisaria de mais caracteres do que 2083.

A maioria dos servidores da Web possui um limite de tamanho de URL (é por isso que existe um código de erro para "URI muito longo"), o que significa que existe um tamanho superior prático. Encontre o limite de tamanho padrão para os servidores Web mais populares e use o maior deles como tamanho máximo do campo; deveria ser mais que suficiente.

É melhor usar varchar (max), o que (em termos de tamanho) significa varchar (65535). Isso ainda armazena seus endereços da Web maiores e economiza seu espaço também.

O especificador max expande os recursos de armazenamento dos tipos de dados varchar, nvarchar e varbinary. varchar (max), nvarchar (max) e varbinary (max) são chamados coletivamente de tipos de dados de grande valor. Você pode usar os tipos de dados de grande valor para armazenar até 2 ^ 31-1 bytes de dados.

Consulte este artigo no TechNet sobre o uso de tipos de dados de grande valor