Entrevistamos Alexandre "Bar" Barkov para discutir as recentes melhorias na globalização MySQL que permitem aos usuários MySQL ao redor do mundo a usar o sistema de banco de dados mais fácil e naturalmente.
Q: Hi Bar, você pode nos contar um pouco sobre si mesmo? Há quanto tempo você vem trabalhando com MySQL e qual é o seu papel?
Bar: Eu comecei a MySQL AB em Novembro de 2001, juntamente com outros dois colegas da minha cidade de Izhevsk, Rússia. Nosso primeiro projeto foi o de fornecer suporte para tipos de dados GIS no MySQL 4.1, e eu mudei principalmente para tarefas de globalização depois disso. Os primeiros passos no processo de globalização incluem: suporte a conjunto de múltiplos caracteres (por coluna, a tabela de banco de dados), cliente-servidor de conversão conjunto de caracteres, conjuntos de caracteres Unicode utf8 e ucs2, bem como suporte Unicode algoritmo de agrupamento. Além de globalização que também participou em vários aspectos do desenvolvimento do MySQL, incluindo a correção dos erros, fazendo revisões de código, ocasionalmente desenvolver códigos para a globalização não-tarefas e fazendo alguns trabalhos de arquitetura de tempos em tempos, como escrever ou fazer tarefas Worklog análise da arquitetura para as descrições de tarefas.
Q: Você mencionou o termo "globalização". O que isso significa e por que é importante para o MySQL?
Bar: Por globalização entendemos dois aspectos do projeto: "localização", bem como "internacionalização".
Localização de meios de ajuste do MySQL para um determinado país ou de uma língua (a região). Este, por exemplo, inclui suporte para a região específica ordens de classificação (agrupamentos), conjuntos de caracteres nacionais, formatos numéricos, mensagens traduzidas, bem como outros aspectos que o tornam mais confortável para usuários internacionais para utilizar o MySQL. A localização é importante para popularizar MySQL em todo o mundo.
Internacionalização, por outro lado, é a infra-estrutura subjacente. Ele inclui suporte para os padrões Unicode, código de personalização agrupamento, e rotinas mensagem parametrizável erro. É o que torna a localização mais fácil.
Q: Quais são as principais características ou melhorias no MySQL 5.5 em termos de internacionalização?
Bar: Uma tarefa importante feito no MySQL 5.5 foi o suporte para caracteres suplementares. As versões contemporâneas Unicode atribui um monte de personagens fora do Plano Multilingual Básico. Isto é particularmente importante para os usuários chineses, japoneses e coreanos. Outra importante mudança que fizemos no MySQL 5.5 está lendo a informação de localização de funcionamento do sistema. Versões anteriores MySQL sempre iniciados ferramentas de cliente com conjunto de caracteres latin1 por padrão. Agora as ferramentas de cliente verificar o ambiente do sistema operacional e escolher o conjunto de caracteres mais adequados para a máquina atual. Isso é um passo importante para uma das regras de ouro MySQL - "facilidade de uso".
Outra característica interessante que 5,5 gostaria de mencionar é internacionalizado formato de número. Antes da versão 5.5, MySQL tinha apenas um hard-coded EUA formato numérico, com ponto como separador decimal, vírgula como separador de milhar, e com três dígitos de agrupamento. Isso nem sempre é conveniente para usuários internacionais. Por exemplo, na Alemanha é mais típico para uso da vírgula como separador decimal e ponto como o separador de milhar, na Rússia separador de milhar é o espaço, enquanto na Índia o agrupamento de dígitos não é sempre por 3!
MySQL 5.5 estende o FORMAT () para aceitar um terceiro argumento opcional que representa a região desejada (locale). Este exemplo demonstra o novo recurso:
FORMATO mysql> SELECT 'en_US' AS locale, (123.457.678,9, 3, 'pt_BR') AS formato -> UNION SELECT 'de_DE', FORMAT (123.457.678,9, 3, 'de_DE') - 'en_IN'> UNION SELECT, FORMAT (123.457.678,9 , 3, 'en_IN') -> UNION SELECT 'ru_RU', FORMAT (123.457.678,9, 3, 'ru_RU'); +----------+------------ ---------+ | locale | formato | +----------+---------------------+ | en_US | 123,457,678.900 | | de_DE | 123.457.678,900 | | en_IN | 12,34,57,678.900 | | ru_RU | 123 457 678900 | +----------+----------- ----------+
Além disso, vale a pena mencionar que no MySQL 5.5 fixamos dois antigos problemas relacionados com a globalização.
O primeiro problema foi resultado BINARY tipo de dados de uma função de cadeia quando um numérico ou um valor datetime é passado como um argumento. Este problema apareceu primeiro no MySQL 4.1 quando introduzimos o tipo de dados BINARY. Para consultas, tais como "SELECT CONCAT (" Data: ", coluna_data) FROM t1" ou "SELECT CONCAT (" Count: ', int_column) FROM t1 ", o CONCAT () operação retornou VARBINARY / BINARY metadados conjunto de resultados, que foi especialmente confuso para MySQL conectores, por exemplo JDBC ODBC e drivers, PHP driver, etc
Agora as consultas funcionam muito melhor e, como esperado. Os metadados conjunto de resultados de CONCAT () informa corretamente VARCHAR / metadados CHAR no lado do cliente. O resultado de tais CONCAT () as operações podem ainda ser passado para outras funções de cadeia, como LOWER () ou UPPER (), e retornar os resultados esperados.
O segundo problema foi a implementação incompleta de mensagens de erro internacionalizadas. Mensagens de erro não foram muitas vezes devidamente convertido para o caráter cliente. No MySQL 5.5 não só corrigiu todos os problemas de conversão, mas também simplificado tradução mensagem de erro.
Esta tarefa era perfeitamente codificados pelo meu colega Sergey Glukhov, que está trabalhando no escritório mesmo comigo aqui em Izhevsk. O erro de arquivo modelo de mensagem é agora inteiramente UTF-8. Em versões anteriores o arquivo de modelo consistia em uma mistura de diferentes conjuntos de caracteres, que era muito difícil de editar.
Além disso, Sergey adicionado suporte para argumentos posicionado. Printf-style argumentos colocados são bem conhecidos para os programadores C. Agora o MySQL suporta a mesma sintaxe nos templates mensagem de erro, o que dá ainda mais flexibilidade aos tradutores.
Vamos usar esse modelo de mensagem de erro como um exemplo:
ER_WRONG_VALUE eng "incorreta% -. 32s valor: '% -. 128s'"
que pode transmitir essa mensagem de erro final:
"Valor DATE incorreta: '2001-20-20 '"
Nota, o nome do tipo de dados está em primeiro lugar, eo valor é em segundo lugar. Isso parece bastante claro para falantes de Inglês, mas em algumas línguas é mais natural para usar uma ordem diferente das palavras na frase, como
"O valor '2001-20-20 'não é correto para DATE"
MySQL 5.5 tornou isso possível. Pode-se adicionar uma mensagem traduzida para o arquivo de modelo de mensagem usando parâmetros posicionados, como este:
ER_WRONG_VALUE eng "incorreta% -. 32s valor: '% -. 128s'" mylang "O valor '% 2 $ -. 128s' não é correto para% 1 $ -. 32s"
Então, agora a mensagem de erro em Inglês ainda usa a ordem "velho", enquanto a mensagem traduzida usa a ordem oposta.
Espero que esta extensão vai também dar mais divertimento e satisfação aos nossos potenciais contribuidores traduzir, e boas vindas ao nosso usuários para participar na tradução. :)
Q: O que você fez no MySQL 5.6 para melhorar o suporte a internacionalização?
Bar: No MySQL versão Milestone 5.6 Desenvolvimento, que melhorou significativamente a personalização de rotinas de agrupamento. Essa tarefa pertence à categoria de internacionalização (infra-estrutura). Ou seja, que melhorou o suporte para os chamados contrações, quando duas ou mais letras são classificados como uma única letra, e expansões, quando uma única letra é classificada como uma combinação de duas ou mais letras.
Versões anteriores MySQL suportado apenas contrações de dois Básica Cartas Latina, tais como CH em checo, e não suportar a personalização de expansão. A partir do MySQL 5,6 contrações não estão limitados a base Cartas latino-mais, e customização de expansão também é suportado. Usando essas melhorias que já adicionou agrupamentos Unicode para Croata com suporte para a letra DZ (uma contração), e German2 com suporte para regras Ä = AE, OE = Ö, Ü = UE (expansões).
MySQL 5,6 também inclui aprimoramentos de personalização um pouco mais collation:
expansões e contrações longos (até 6 caracteres)
"Reset antes"
alfaiataria longa
contexto anterior, para apoiar as marcas prolongamento
Essas mudanças todas abertas as portas para melhorias em futuras versões do MySQL, como agrupamentos nova linguagem (húngaro, Bengali, Myanmar, Maltês), e melhor suporte para chinês, japonês e coreano.
Q: Existe alguma plataforma específica melhorias?
Bar: Sim. No MySQL 5,6 fizemos um bom passo para uma melhor integração com o Windows.
Por exemplo, o Windows conjunto de caracteres Unicode nativo é UTF-16LE. MySQL 5.6 não só torna possível armazenar dados em UTF-16LE em suas tabelas, mas também recuperar dados do servidor MySQL usando UTF-16LE (mesmo se a tabela de origem se armazena dados em UTF-8 ou em um conjunto de caracteres 8-bit ) e usar os dados ainda mais em um aplicativo Unicode, sem ter que programa de código de conversão no lado da aplicação.
Q: Algum do seu trabalho foi em resposta às solicitações da comunidade MySQL? Você incorporou contribuições da comunidade em apoio MySQL é globalização?
Bar: Nós adicionamos dois comunidade contribuiu recentemente para implementar os patches Sinhala agrupamento e apoio romanche idioma para os nomes dos meses e semanas dia em funções datetime. Eu quero mencionar especialmente o patch romanche, que foi muito bom: é seguido MySQL estilo de codificação muito bem, desde que bem-cobrindo testes para MTR (o MySQL sistema de teste de regressão), e tinha referências ao romanche padrões de linguagem autoridade e documentos. Por isso, só nos levou poucos dias de receber o patch para empurrá-lo na árvore fonte oficial.
Além disso, nós adicionamos suporte ao idioma grego para as funções de data e hora, bem como agrupamento vietnamita. Patches para essas duas tarefas não foram totalmente feitos pelos contribuintes comunidade, mas a participação activa dos utilizadores gregos e vietnamitas, que estavam escrevendo solicitações de recursos e fornecimento de dados específicos da língua, nos permitiu concluir essas tarefas mais rapidamente.
Q: Que outras melhorias que você fez?
Bar: Alguns usuários podem encontrar uma nova WEIGHT_STRING () função útil. Ele retorna uma imagem binária sortable correspondente ao parâmetro seqüência de caracteres, tendo em conta o seu agrupamento. É muito perto do que o strxfrm () função faz em C.
Um dos casos de uso desta função é fazer do lado do cliente classificação. Vamos usar o exemplo a seguir. Suponha que criar e preencher uma tabela com alguns dados internacionais:
CREATE TABLE t1 (s1 VARCHAR (64) CHARACTER SET utf8 COLLATE utf8_unicode_ci); INSERT INTO VALUES t1 ('...'),('...'),('...'),...('. ..');
Então consultar a tabela:
SELECIONE s1, WEIGHT_STRING (s1 COLLATE utf8_polish_ci), WEIGHT_STRING (s1 COLLATE utf8_german2_ci), WEIGHT_STRING (s1 COLLATE utf8_swedish_ci), WEIGHT_STRING (s1 COLLATE utf8_czech_ci) FROM t1 ORDER por s1;
Quando os resultados são buscados no lado do cliente, eles são ordenados usando utf8_unicode_ci, de acordo com o agrupamento de s1, que é dado na lista ORDER BY.
Mas entre os dados em si, o cliente também tem informações sobre como classificar essas seqüências de acordo com polonês, German2, regras sueco ou checo. O aplicativo agora pode usar os dados da coluna 2, 3, 4 ou 5 para classificar a coluna 1 de acordo com regras desejadas. Por exemplo, o aplicativo pode chamar o qsort () função, com memcmp () como a rotina de comparação, a ordem das cordas do conjunto de resultados como o usuário do aplicativo escolhe. Isso pode ser especialmente importante no caso de uma consulta SQL pesados, quando re-executar a consulta com um ORDER BY alternativa não é desejável.
Q: E, finalmente, o que você está trabalhando agora? O que deve MySQL usuários esperam ver de você no futuro?
Bar: Nós vamos continuar a adicionar agrupamentos novo idioma no topo do agrupamento personalização melhorias que fizemos recentemente, que, como eu disse anteriormente, tornou possível a implementação de agrupamento (incluindo mas não limitado a) Bengali, maltês, Myanmar, chinês, japonês , coreano.
Além disso, estamos trabalhando em outra melhoria nas rotinas de agrupamento, que o apoio dos chamados níveis de classificação secundário e terciário, e que irá fornecer ORDER BY resultados ainda melhor. Por exemplo, mesmo agrupamento um case insensitive será capaz de classificar as letras pequenas antes de letras maiúsculas, assim, por exemplo 'a' sempre ir antes de 'A' no ORDER BY, mas ao mesmo tempo, 'a' e 'A' irão ainda ser igual ao outro em condição WHERE. Agora, a ordem de 'a' e 'A' não é previsível para um agrupamento diferencia maiúsculas de minúsculas, mas os níveis de classificação secundária e terciária vai resolver esta questão. Além disso, vai permitir mais rigorosa ordem de classificação para acentos em agrupamentos sotaque insensível. Isto é importante, por exemplo, para o francês e vietnamita.
Nenhum comentário :
Postar um comentário