Eu tenho um .csv
arquivo com um monte de dados que estou usando para carregar todos os dados em uma tabela de banco de dados. O arquivo não possui a coluna ID (porque é uma coluna interna gerenciada pelo nosso software e eles não se importam com isso).
Para evitar problemas com os dados minha "solução" foi mover a coluna id
para uma posição onde não interferisse nos dados do arquivo e que ficasse logo após a ActiveFlag
coluna ou apenas no final.
Verifique a imagem a seguir para obter uma representação gráfica da tabela:
Atualmente a id
é minha primeira coluna e não tenho nenhum problema, mas estou tentando ir para o final porque o problema que estou tendo com os dados, mas recebi o seguinte erro:
Operation failed:
Executing:
ALTER TABLE `sedb`.`volume_pricing_agreement`
CHANGE COLUMN `id` `id` INT(11) NOT NULL AUTO_INCREMENT AFTER `ActiveFlag`,
DROP PRIMARY KEY,
ADD PRIMARY KEY (`AgreementNumber`,`CustomerSiteID`, `CFProgramLevelID`, `Source`, `AgreementTypeID`, `id`);
ERROR 1075: Incorrect table definition; there can be only one auto column and it must be defined as a key
Não sei se a coluna tem que ser a primeira na definição da tabela e se há alguma forma de deixá-la onde eu quiser ou a solução talvez seja importar os dados pulando a id
coluna (supondo que seja a primeira ).
Eu estava verificando a sintaxe aqui , mas não tenho ideia de como pular uma coluna durante o carregamento:
LOAD DATA [LOW_PRIORITY | CONCURRENT] [LOCAL] INFILE 'file_name'
[REPLACE | IGNORE]
INTO TABLE tbl_name
[PARTITION (partition_name,...)]
[CHARACTER SET charset_name]
[{FIELDS | COLUMNS}
[TERMINATED BY 'string']
[[OPTIONALLY] ENCLOSED BY 'char']
[ESCAPED BY 'char']
]
[LINES
[STARTING BY 'string']
[TERMINATED BY 'string']
]
[IGNORE number {LINES | ROWS}]
[(col_name_or_user_var,...)]
[SET col_name = expr,...]
Esta é a saída do comando SHOW CREATE TABLE sedb.volume_pricing_agreement;
:
volume_pricing_agreement, CREATE TABLE `volume_pricing_agreement` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`AgreementNumber` int(11) DEFAULT NULL,
`AgreementName` varchar(60) CHARACTER SET utf8 DEFAULT NULL,
`CustomerSiteID` int(11) NOT NULL,
`CFProgramLevelID` int(11) DEFAULT NULL,
`Discount` decimal(5,4) NOT NULL DEFAULT '0.0000',
`Source` varchar(45) COLLATE utf8_unicode_ci NOT NULL,
`ActiveFlag` int(1) NOT NULL,
`AgreementTypeID` int(1) NOT NULL DEFAULT '0',
`created_at` datetime NOT NULL,
`updated_at` datetime NOT NULL,
PRIMARY KEY (`id`),
KEY `AgreementNumber` (`AgreementNumber`),
KEY `CustomerSiteID` (`CustomerSiteID`),
KEY `ActiveFlag` (`ActiveFlag`)
) ENGINE=InnoDB AUTO_INCREMENT=2763 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci
Qualquer ajuda? Como devo lidar com isso?
Não. A ordem das colunas em uma definição de tabela não importa, com uma exceção antiga. Nas versões mais antigas, a
TIMESTAMP
coluna "primeira" tinha umDEFAULT
valor padrão especial.Não é necessário ter um
AUTO_INCREMENT
. No entanto, é (essencialmente) necessário que você tenha um arquivoPRIMARY KEY
. Cheira comoAgreementNumber
seria tal? Tenha em mente que um PK deve serUNIQUE
(um requisito do MySQL).Como nota lateral, um A_I não precisa ser o PK. O único requisito é que seja a primeira coluna em algum índice. E lembre-se que um PK é uma chave única é uma chave.
Mas, esse não é o seu problema 'real'. Ou seja, você precisa fazer
LOAD DATA
sem oid
ser fornecido.Plano A: Carregue em outra tabela e copie-a. Ao copiar os dados, especifique todas as colunas, exceto o id; A_eu cuidarei do resto.
Plano B: Use
LOAD DATA
, mas especifique todas as colunas, excetoid
. NovamenteA_I
cuidará de padronizá-lo corretamente.Outras dicas, enquanto eu tenho você na linha:
int(1)
é um número de 4 bytes; o(1)
significa nada. Talvez você queira um 1 byteTINYINT
?INT UNSIGNED
onde apropriadoINT
quando apropriado; olhe para cimaMEDIUMINT
e faça-o novamente,MEDIUMINT UNSIGNED
se apropriado.NOT NULL
quando apropriado.Mais
Se você optar por ter uma
UNIQUE
chave de 6 colunas que inclua algumVARCHARs
, ter um A_I provavelmente é melhor do que torná-lo o PK.A
UNIQUE KEY
é duas coisas: um índice e uma restrição de exclusividade. Você pode usá-lo para um ou ambos.Um PK é um
UNIQUE KEY
que identifica a linha. Ele também é "agrupado" com os dados, tornando as pesquisas mais eficientes do que com uma "chave secundária" (qualquer que não seja PK).Quando a 'cardinalidade' de uma coluna indexada for muito baixa, como para um sinalizador, o Optimizer analisará dinamicamente o valor fornecido e verificará se menos de 20% da tabela tem esse valor. Nesse caso, usará o índice; senão não. O "20%" varia com a fase da lua. A razão para evitar o índice é que usar o índice envolve alternar entre o BTree do índice e o BTree dos dados por meio do PK. Isso pode ser mais lento do que simplesmente escanear os dados, jogando 80% das linhas. Uma chave secundária é um BTree contendo a(s) coluna(s) indexada(s) mais uma cópia do PK.