ReynierPM's questions

Estou corrigindo alguns dados incorretos e estou procurando uma maneira mais segura de atualizar uma determinada coluna quando o valor não existe mais na tabela relacionada.

Dê uma olhada no exemplo a seguir ( violino aqui ):

-- SET sql_mode = '';

create table if not exists table1
(
    id                           int auto_increment primary key,
    table2_id int
);

create table if not exists table2
(
    id                           int auto_increment primary key
);


INSERT INTO table1 VALUES(1, 1), (2, 2), (3, 3), (4, 4), (5, 5);
INSERT INTO table2 VALUES(1), (2);

SELECT * FROM table1;
SELECT * FROM table2;

SELECT * FROM table1 LEFT JOIN table2 ON table1.table2_id = table2.id;

a última consulta acima retornará apenas 2 linhas porque table2não tem os IDs: 3, 4, 5. Então preciso escrever uma ATUALIZAÇÃO para a tabela1 para definir os IDs: 3, 4, 5 para NULL.

Posso ter algumas ideias?

Estou usando o MySQL 5.7 e percebi algo que não consigo explicar para mim mesmo com meu conhecimento atual, então aqui vai.

Uma data "inválida" é 0000-00-00considerada igual NULLa um datetipo de coluna sem possibilidades de valores anuláveis? Veja o exemplo a seguir:

create table if not exists example
(
    id int auto_increment primary key,
    doskip date default '0000-00-00' not null
);

INSERT INTO example VALUES(1, '0000-00-00'), (2, '0000-00-00'), (3, '0000-00-00');

Ter o que foi dito acima e executar as seguintes consultas me deu exatamente a mesma contagem: 3 e eu me pergunto por que, há alguma explicação para isso?

SELECT COUNT(*) FROM example j WHERE j.doskip = '0000-00-00';
SELECT COUNT(*) FROM example j WHERE j.doskip IS NULL;

Aqui está um Fiddle mostrando esse comportamento, é por causa do modo?

Preciso construir uma consulta SQL, para MySQL 5.7, se for possível, para " GROUP BY" uide titleconcatenar a permissionscoluna e separar com um |? Estou dizendo GROUP BY, mas não sei se esse é o termo certo aqui.

+------+--------+------------------------------------------------+
| uid  | title  | permissions                                    |
+------+--------+------------------------------------------------+
| 1438 | Delete | /_permission_set.php|/process.php|/command.php |
+------+--------+------------------------------------------------+
| 1438 | Remove | /_permission_set.php|/process.php|/command.php |
+------+--------+------------------------------------------------+

Eu tentei o seguinte SQL (como você pode ver neste DBFiddle ) mas não funcionou

SELECT uid, CONCAT('|', permissions)
FROM some_table
WHERE uid=1438
GROUP BY uid, permissions;

Estou trabalhando em alguma otimização de código PHP e, enquanto procuro, encontro algumas instruções SELECT com as seguintes condições:

WHERE `date_exported` = '0000-00-00 00:00:00' OR `date_exported` IS NULL

Isso me faz pensar se a mesma instrução funcionará da mesma forma com apenas uma condição: a comparação com NULL ou a comparação com um datetime "inválido".

Acrescentarei ainda: usando MySQL Workbench e Datagrip (ou o equivalente de ferramentas como PhpStorm) não consigo ver a coluna com NULLbut 0000-00-00 00:00:00. Não tenho certeza se isso é uma coisa de configuração ou se deveria ser assim.

Este é o MySQL 5.7 e não tenho permissão para verificar itens de configuração ou insights sobre como esta instância está configurada.

Tentei definir um playground aqui , mas não me permite adicionar uma coluna 0000-00-00 00:00:00NULLdatetime

O SQL_MODEé definido da seguinte forma:

NO_ZERO,IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION

Nota: é 0000-00-00 00:00:00inválido?

Estou trabalhando em algo e encontrei esse SQL que não tenho certeza de como reescrever corretamente, ou seja, usando PHP PDO.

O SQL se parece com:

$sql = 'SELECT * FROM table WHERE column ' . isset($variable) ? . '=' . $variable : '>0'; 

Basicamente, o que a consulta está dizendo é: se $variableestiver definido (dentro do mundo PHP), use an =para a condição WHERE; se não estiver, use >0.

Posso limpar um pouco isso no PHP e fazer algo como:

$where = $variable ? 'column = ?' : column > ?'; // ternary operator to build the proper where condition
$sql = 'SELECT * FROM table WHERE $where';
$db->row($sql, [$variable ?? 0]); // bind parameters to the query, PDO way, and the operator will use the value of $variable if it is defined otherwise it will use 0 

e vai funcionar bem, eu acho. Agora, gostaria de saber se posso conseguir o mesmo usando SQL simples como uma condição dentro de WHERE igual a SELECT e, em caso afirmativo, é ideal? Ou programaticamente é melhor e mais rápido?

Tendo o seguinte trecho de tabela:

CREATE TABLE `some_table` (
    `exp_col_1` TINYINT(1) NOT NULL DEFAULT '0',
    `mark_col_1_as_exported` TINYINT(1) DEFAULT '0',
    `exp_col_2` TINYINT(1) DEFAULT '0',
    `mark_col_2_as_exported` TINYINT(1) DEFAULT '0',
);

existe uma maneira de escrever uma consulta para:

• atualize a coluna mark_col_1_as_exportedondeexp_col_1=1
• atualize a coluna mark_col_2_as_exportedondeexp_col_2=1

Eu sei que posso escrever um UPDATE para cada um deles mas isso é apenas um trecho, estamos falando aqui de cerca de 20 colunas a serem atualizadas

Talvez essa seja uma pergunta boa ou ruim, mas na minha pesquisa no Google não consegui encontrar uma boa resposta (talvez porque eu seja péssimo em fazer uma boa pesquisa). Em poucas palavras:

• um banco de dados pode ser criado sem um usuário e/ou proprietário?

Estou tentando responder uma pergunta no Stack Overflow e o usuário compartilhou a configuração do banco de dados e algo me chamou a atenção:

$db['default']['hostname'] = 'localhost';
$db['default']['username'] = '';
$db['default']['password'] = '';
$db['default']['database'] = 'gotche';
$db['default']['dbdriver'] = 'mysqli';

O banco de dados não tem um nome de usuário!

Independentemente do banco de dados usado - que está no cenário é MySQL (não sei a versão) - isso é possível?

Eu não acho que o nome de usuário e a senha foram removidos por motivos de segurança: seria melhor alterá-lo para algo como *****- nesse caso, todos saberiam que existe um nome de usuário/senha, mas posso perguntar ao usuário se esse é o motivo.

Tenho a seguinte tabela fields:

+----------+---------+-----------------+-------------+---------+--------------+---------------+-----------+------------------------------+-------------+------------------+
| field_id | form_id | form_section_id | is_required | grid_id | is_base_grid | field_type_id | field_seq |          field_name          | field_class | field_class_data |
+----------+---------+-----------------+-------------+---------+--------------+---------------+-----------+------------------------------+-------------+------------------+
|   220481 |    9926 | NULL            |           0 | NULL    | NULL         |             4 |        28 | Test                         | NULL        | NULL             |
|   281863 |    9926 | NULL            |           0 | NULL    | NULL         |            10 |        29 | insert after yes no question | NULL        | NULL             |
|   220496 |    9926 | NULL            |           0 | 11      | 1            |             5 |        30 | test                         | NULL        | NULL             |
|   249234 |    9926 | NULL            |           0 | 12      | 1            |             5 |        32 |                              | NULL        | NULL             |
|   279877 |    9926 | NULL            |           0 | NULL    | NULL         |             4 |        33 | Test Text Questions          | NULL        | NULL             |
|   281860 |    9926 | NULL            |           0 | NULL    | NULL         |            10 |        34 | Something                    | NULL        | NULL             |
|   281914 |    9926 | NULL            |           0 | 23      | 1            |             5 |        35 | sssss                        | NULL        | NULL             |
|   281960 |    9926 | NULL            |           0 | 38      | 1            |             5 |        36 | yuyuyu                       | NULL        | NULL             |
|   281972 |    9926 | NULL            |           0 | 40      | 1            |             5 |        40 | ttttt                        | NULL        | NULL             |
+----------+---------+-----------------+-------------+---------+--------------+---------------+-----------+------------------------------+-------------+------------------+

Como você pode ver, existem dois field_seqcom o mesmo valor 36neste caso.

Digamos que eu esteja inserindo uma nova linha logo depois field_id=281960e a field_seqpara essa nova linha vem como 36.

Eu preciso construir uma consulta ou até mesmo um procedimento armazenado onde eu possa descobrir se existe uma linha com field_seqigual ou maior que 36e se sim, atualize o valor de field_seqpara o valor atual mais 1.

Ex:

INSERT INTO `fields` VALUES(9999, 9926, NULL, 0, 41, 1, 5, 36, 'lllll', NULL, NULL);

Tendo isso veja os possíveis casos abaixo (com exemplos após cada um):

Caso 1: linha com field_seq=36 já existe na tabela

• Mantenha os dados INSERT como eles se tornarão a field_seq=36nova linha atual
• Atualize o valor da linha da tabela field_seq=current+1que se tornará37
• Se já houver 37, repita o passo anterior até que não haja mais repetiçõesfield_seq

Antes da:

+----------+---------+-----------------+-------------+---------+--------------+---------------+-----------+-------------+-------------+------------------+
| field_id | form_id | form_section_id | is_required | grid_id | is_base_grid | field_type_id | field_seq | field_nanme | field_class | field_class_data |
+----------+---------+-----------------+-------------+---------+--------------+---------------+-----------+-------------+-------------+------------------+
|   281914 |    9926 | NULL            |           0 |      23 |            1 |             5 |        32 | sssss       | NULL        | NULL             |
|   281972 |    9926 | NULL            |           0 |      40 |            1 |             5 |        36 | ttttt       | NULL        | NULL             |
|   281960 |    9926 | NULL            |           0 |      38 |            1 |             5 |        37 | yuyuyu      | NULL        | NULL             |
|   281978 |    9926 | NULL            |           0 |      38 |            1 |             5 |        38 | vvvvv       | NULL        | NULL             |
+----------+---------+-----------------+-------------+---------+--------------+---------------+-----------+-------------+-------------+------------------+

Depois:

+----------+---------+-----------------+-------------+---------+--------------+---------------+-----------+---------------------+-------------+------------------+
| field_id | form_id | form_section_id | is_required | grid_id | is_base_grid | field_type_id | field_seq |     field_nanme     | field_class | field_class_data |
+----------+---------+-----------------+-------------+---------+--------------+---------------+-----------+---------------------+-------------+------------------+
|   281914 |    9926 | NULL            |           0 | 23      | 1            |             5 |        32 | sssss               | NULL        | NULL             |
|     9999 |    9926 | NULL            |           0 |    41   |   1          |             5 |        36 | lllll               | NULL        | NULL             | => new row inserted here
|   281972 |    9926 | NULL            |           0 | 40      | 1            |             5 |        37 | ttttt               | NULL        | NULL             | => this was 36 now is updated to 37
|   281960 |    9926 | NULL            |           0 | 38      | 1            |             5 |        38 | yuyuyu              | NULL        | NULL             | => this was 37 now is updated to 38
|   281978 |    9926 | NULL            |           0 | 38      | 1            |             5 |        39 | vvvvv               | NULL        | NULL             | => this was 38 now is updated to 39
|   220524 |    9926 | NULL            |           0 | NULL    | NULL         |             5 |        40 | Patient Information | NULL        | NULL             | => we don't care about this cause there is room for one more, if one insert makes the rows above become 40 then this needs to be updated to 41
+----------+---------+-----------------+-------------+---------+--------------+---------------+-----------+---------------------+-------------+------------------+

Caso 2: linha com field_seq=36 já existe na tabela, mas next field_seqé maior que37

• Mantenha os dados INSERT como eles se tornarão a field_seq=36nova linha atual
• Atualize o valor da linha da tabela field_seq=current+1que se tornará37
• Neste caso, não precisamos continuar atualizando, pois há espaço suficiente para inserir mais algumas linhas antes que elas se tornem as mesmasfield_seq

Antes da:

+----------+---------+-----------------+-------------+---------+---------------+---------------+-----------+------------+-------------+
| field_id | form_id | form_section_id | is_required | grid_id | is_base_grid  | field_type_id | field_seq | field_name | field_class |
+----------+---------+-----------------+-------------+---------+---------------+---------------+-----------+------------+-------------+
|   281914 |    9926 | NULL            |           0 |      23 |             1 |             5 |        32 | sssss      | NULL        |
|   281972 |    9926 | NULL            |           0 |      40 |             1 |             5 |        36 | ttttt      | NULL        |
|   281972 |    9926 | NULL            |           0 |      40 |             1 |             5 |        40 | ooooo      | NULL        |
+----------+---------+-----------------+-------------+---------+---------------+---------------+-----------+------------+-------------+

Depois:

+----------+---------+-----------------+-------------+---------+---------------+---------------+-----------+------------+-------------+
| field_id | form_id | form_section_id | is_required | grid_id | is_base_grid  | field_type_id | field_seq | field_name | field_class |
+----------+---------+-----------------+-------------+---------+---------------+---------------+-----------+------------+-------------+
|   281914 |    9926 | NULL            |           0 |      23 |             1 |             5 |        32 | sssss      | NULL        |
|   281972 |    9926 | NULL            |           0 |      41 |             1 |             5 |        36 | lllll      | NULL        | => new row inserted here
|   281972 |    9926 | NULL            |           0 |      40 |             1 |             5 |        37 | ttttt      | NULL        | => previous row with field_seq=36 was updated to 37
|   281972 |    9926 | NULL            |           0 |      40 |             1 |             5 |        40 | ooooo      | NULL        | => nothing happen to this one since there is room for more
+----------+---------+-----------------+-------------+---------+---------------+---------------+-----------+------------+-------------+

Estou usando o Microsoft SQL Server 2016 (SP1). Como posso conseguir isso?

Eu tenho um .csvarquivo 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 idpara uma posição onde não interferisse nos dados do arquivo e que ficasse logo após a ActiveFlagcoluna 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 idcoluna (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?

Tenho a seguinte estrutura de tabelas (DDL):

CREATE TABLE restricted_components
(
    component_id INT(11) PRIMARY KEY NOT NULL,
    resources_id INT(11) NOT NULL,
    component_dom_id VARCHAR(50) NOT NULL,
    component_dom_class VARCHAR(50),
    component_dom_data_name VARCHAR(50),
    visible TINYINT(1) DEFAULT '0' NOT NULL
);

CREATE TABLE resources
(
    resources_id INT(10) unsigned PRIMARY KEY NOT NULL AUTO_INCREMENT,
    resources_name VARCHAR(64) NOT NULL,
    menu_href VARCHAR(128),
    menu_text VARCHAR(64) NOT NULL
);

CREATE TABLE acl_groups_to_resources
(
    groups_id INT(10) unsigned NOT NULL,
    resources_id INT(10) unsigned NOT NULL,
    bitmask SMALLINT(6) DEFAULT '0' NOT NULL,
    CONSTRAINT `PRIMARY` PRIMARY KEY (groups_id, resources_id)
);

CREATE TABLE groups
(
    groups_id INT(11) PRIMARY KEY NOT NULL AUTO_INCREMENT,
    groups_name VARCHAR(50) NOT NULL
);

Estou tentando obter uma lista restricted_componentscom suas informações relacionadas do restante das tabelas, significando resources_namee groups_name.

Eu fiz esta consulta:

SELECT
  `rc`.*,
  `rs`.resources_name,
  `gr`.`groups_name`
FROM `restricted_components` AS `rc`
  LEFT JOIN `resources` AS `rs` ON rc.resources_id = rs.resources_id
  LEFT JOIN `acl_groups_to_resources` AS `acl_gr` ON rs.resources_id = acl_gr.resources_id
  LEFT JOIN `groups` AS `gr` ON acl_gr.groups_id = gr.groups_id

Mas está errado, pois tenho resultados indesejados conforme a imagem abaixo mostrada:

Tenho certeza de que o problema está no computador LEFT JOIN, mas não consigo encontrar onde exatamente e como consertar isso.

Atualização nº 1: usar JOINem vez disso também não funciona.

Acredito que o problema esteja nos dados, mas não tenho certeza, espero que alguém tenha tempo para verificar isso.

Posso obter alguma ajuda?

Observação: deixei um conjunto de dados aqui para que você possa brincar com eles, se necessário, mas não é preciso, você precisará remover algumas colunas e seus valores.

Estou em permanente discussão com os desenvolvedores da empresa onde trabalho porque eles dizem que é melhor se livrar da imposição de relacionamento (via definições de restrição FOREIGN KEY) em um banco de dados relacional para agilizar consultas grandes e obter melhores atuação.

A plataforma em questão é o MySQL 5.x, e nenhuma FOREIGN KEY foi configurada, mesmo algumas restrições PRIMARY KEY das tabelas relevantes estão faltando, o que, pelo menos para mim, não é razoável. Talvez eles estejam certos e eu errado, mas não tenho argumentos suficientes para discutir sobre esta situação.

Esta tem sido a abordagem preferida há três anos. Sou novo nesta empresa (apenas um mês) mas, como o produto “funciona”, hesita-se em aumentar a base de dados; no entanto, a primeira coisa que notei é uma página demorando 1 minuto para carregar (sim, 60 segundos!).

Uma das alegações por trás do estado atual das coisas é que um banco de dados “desnormalizado” é mais rápido que um normalizado, mas não acredito que isso seja verdade.

A maioria das consultas relevantes inclui operações JOIN, o que as torna muito, muito, muito lentas com grandes quantidades de dados (o banco de dados contém milhões de linhas).

Normalmente, a manipulação de operações “CRUD” é implementada no nível do código do programa aplicativo; por exemplo, para EXCLUIR alguns dados DE, digamos TableA:

• é necessário primeiro verificar em tempo real se existe alguma relação entre as linhas de TableAe TableB,
• caso a referida relação seja “detectada”, então o código do programa app não permitirá EXCLUIR a(s) linha(s) pertinente(s), mas sim
• se por algum motivo o código do programa app falhar, então a operação DELETE terá “sucesso”, independentemente de haver algum relacionamento em relação às linhas e tabelas envolvidas.

Pergunta

Você poderia me ajudar a elaborar uma resposta boa, precisa e sólida para enriquecer o debate?

_{Nota : Talvez algo assim tenha sido perguntado (e respondido) antes, mas não consegui encontrar nada por meio do Google.}

Estou configurando um pequeno servidor local de desenvolvimento (é uma VM rodando CentOS 7) e por isso não adicionei nenhuma senha ao MySQL após rodar o comando: mysql_secure_installation. Agora eu preciso me conectar do host através do MySQL Administrator, mas não posso porque o usuário rootnão tem permissão para se conectar do endereço IP do host, então vou mudar isso dando roottodos os privilégios e o host.

Isso é o que eu fiz até agora:

$ mysql -uroot -p
Enter password:  [here is just ENTER because root hasn't a password]
Server version: 10.1.18-MariaDB MariaDB Server

MariaDB [(none)]> GRANT ALL PRIVILEGES ON *.* TO 'root'@'192.168.3.%' WITH GRANT OPTION;
ERROR 1133 (28000): Can't find any matching row in the user table

Eu encontrei esse erro, então fiz algumas pesquisas no Google e encontrei um monte de links, então escolhi alguns deles como este e tentei:

MariaDB [(none)]> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.01 sec)

MariaDB [(none)]> GRANT ALL PRIVILEGES ON *.* TO 'root'@'192.168.3.%' WITH GRANT OPTION;
ERROR 1133 (28000): Can't find any matching row in the user table

Mas ainda não está funcionando, é uma restrição e eu não estou ciente? é uma configuração no my.cnfarquivo? é um problema na consulta SQL? Qualquer ajuda?

Estou trabalhando em um diagrama de banco de dados e tenho uma tabela chamada cm_identifier_type. Cada registro desta tabela pode ter ou não um arquivo para download (salvo um caminho de arquivo). Identifiquei duas maneiras possíveis de conseguir isso.

• Coloque uma coluna download_filecomo VARCHAR(250)e defina como NULLpadrão (isso porque nem todos os registros terão um download relacionado)

• Crie uma relação entre cm_identifier_typee uma nova tabela cm_download_file:

Agora, em relação ao desempenho, economia de espaço em disco, economia de consulta e assim por diante, como você faria isso? Qual é a sua recomendação sobre este caso extremo?

Nota: no momento estou usando MariaDB 10.1.x, mas isso será em uma instância do MySQL, provavelmente 5.x ou mais, não tenho certeza, pois ainda não tenho esses detalhes

Então essa será a pergunta fictícia do ano, mas eu preciso perguntar já que não é a primeira vez que passo por isso. Dê uma olhada na seguinte definição de tabela:

Dê uma olhada na coluna from_numberque é VARCHAR(45)agora, mas conterá um número de telefone. Como não sei quantos números um telefone pode ter em todo o mundo, estou tentando cobrir quase todos eles. Eu quero manter a integridade do banco de dados o máximo possível, então acho que VARCHARnão é um tipo adequado para armazenar esse tipo de informação - talvez eu esteja errado, você me diz - então estou pensando em mudar para INTou mesmo BIGINT.

Quando estou definindo uma coluna no Workbench devo especificar o número entre parênteses ()não em todos os casos, mas naqueles que mencionei anteriormente tive que fazer. Então, se eu fizer isso: BIGINT()recebi este erro:

O que me orienta a ler um pouco sobre esse tipo de MySQL aqui . Basicamente a informação é esta:

Um grande número inteiro. ... O intervalo não assinado é de 0 a 18446744073709551615.

O que me faz perguntar: qual valor devo definir para parênteses quando estou definindo um BIGINT()tipo. (Estou usando o BIGINT porque não sei se o INT pode conter tantos números quanto um telefone poderia ter - talvez eu também esteja errado). Qual é a maneira correta de criar|projetar uma coluna em bancos de dados MariaDB/MySQL?

De qualquer forma gostaria de saber sua opinião, experiência e claro gostaria de obter uma resposta

Nota: Estou usando a última edição do MySQL Workbench para criar o diagrama ER. Estou usando também MariaDB 10.0.x

Eu tenho esta definição de tabela:

CREATE TABLE `media` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `brands_id` int(11) DEFAULT NULL,
  `media_type` varchar(45) COLLATE utf8_unicode_ci DEFAULT NULL,
  `title` varchar(45) COLLATE utf8_unicode_ci NOT NULL,
  `description` longtext COLLATE utf8_unicode_ci NOT NULL,
  `thumbnail_url` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
  `media_url` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
  `media_code` varchar(45) COLLATE utf8_unicode_ci NOT NULL,
  `inactive` tinyint(1) NOT NULL,
  `createdAt` datetime NOT NULL,
  `updatedAt` datetime NOT NULL,
  `titleHtml` varchar(45) COLLATE utf8_unicode_ci NOT NULL,
  `descriptionHtml` longtext COLLATE utf8_unicode_ci NOT NULL,
  `useHtml` tinyint(1) NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `UNIQ_6A2CA10CBF396750` (`id`),
  KEY `IDX_6A2CA10CE9EEC0C7` (`brands_id`),
  CONSTRAINT `FK_6A2CA10CE9EEC0C7` FOREIGN KEY (`brands_id`) REFERENCES `brands` (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci ROW_FORMAT=COMPACT;

Cada vez que tento inserir um novo registro recebo um erro devido a NOT NULLrestrições, tudo bem, agora se eu tentar atualizar o mesmo registro e deixar titlee/ descriptionou qualquer outro campo obrigatório vazio, o UPDATE é executado e a coluna é definido como em branco, por quê? Como posso evitar isso? Estou usando o MariaDB 5.5.46.

ATUALIZAR

Conforme solicitado pelo moderador, abaixo estão as consultas INSERT e UPDATE que tentei:

INSERT INTO media (media_type, title, titleHtml, description, descriptionHtml, thumbnail_url, media_url, media_code, inactive, useHtml, createdAt, updatedAt, brands_id) VALUES (null,"Media Title Test",null,null,null,"https://someurl",null,null,false,false,"2015-10-22 22:07:54","2015-10-22 22:07:54",null)

O INSERT acima falha porque as CONSTRAINTS no banco de dados

UPDATE media SET description = null, updatedAt = "2015-10-22 22:12:18" WHERE id = 13

O UPDATE acima passou e este é o problema porque a descriptioncoluna não pode ter valores NULL

Tenho uma tabela _sync_historycom esses dados:

+----+----------------+---------------------+
| id | object_name    | sync_time           |
+----+----------------+---------------------+
|  1 | territory      | 2015-07-21 22:29:02 |
|  2 | user           | 2015-07-21 22:29:19 |
|  3 | userterritory  | 2015-07-21 22:29:38 |
|  4 | account        | 2015-07-21 22:30:05 |
|  5 | accountshare   | 2015-07-21 22:39:04 |
|  6 | address_vod__c | 2015-07-22 00:47:38 |
|  7 | group          | 2015-07-22 01:23:30 |
|  8 | recordtype     | 2015-07-22 01:23:51 |
|  9 | user           | 2015-07-23 13:04:20 |
| 10 | account        | 2015-07-23 13:04:59 |
+----+----------------+---------------------+

Eu quero obter as linhas userentre 2015-07-21 22:29:19e 2015-07-23 13:04:20significando as linhas entre o último sync_time e o anterior sync_time para um determinado arquivo object_name. eu estava fazendo isso:

SELECT * FROM `user` WHERE lastmodifieddate > (SELECT sync_time FROM `_sync_history` WHERE object_name='user' ORDER BY sync_time ASC LIMIT 1)

Mas isso me dará apenas os do último sync_time e acima que não estão corretos, como faço para obter os que preciso?

Eu tenho dois INDEXem uma n:mtabela de relacionamento, como você pode ver nas fotos abaixo:

Agora eu posso ter isso também:

Minhas perguntas:

• Qual é a vantagem do último caminho (composto pic) sobre os dois primeiros?
• Pode #ter algum peso ou significado no ÍNDICE composto?

Eu preciso mudar os nomes nas colunas PK e isso tem relações com outras tabelas, o que significa que elas também são FK, então é isso que estou fazendo:

SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0;
SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0;
SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='ALLOW_INVALID_DATES';

#Drop FKs and IDX
ALTER TABLE `pdone`.`reps` DROP FOREIGN KEY `FK_485DE7B033B9A304`;
ALTER TABLE `pdone`.`reps` DROP INDEX `IDX_485DE7B033B9A304` ;

ALTER TABLE `pdone`.`targets` DROP FOREIGN KEY `FK_AF431E1333B9A304`;
ALTER TABLE `pdone`.`targets` DROP INDEX `IDX_AF431E1333B9A304` ;

ALTER TABLE `pdone`.`targets_brands_xref` DROP FOREIGN KEY `FK_85785F3E43B5F743`;
ALTER TABLE `pdone`.`targets_brands_xref` DROP INDEX `IDX_85785F3E43B5F743` ;

ALTER TABLE `pdone`.`territories_brands_xref` DROP FOREIGN KEY `FK_2265AB7933B9A304`;
ALTER TABLE `pdone`.`territories_brands_xref` DROP INDEX `IDX_2265AB7933B9A304` ;

#Change PK names
ALTER TABLE `pdone`.`reps` CHANGE COLUMN `veeva_rep_id` `rep_id` VARCHAR(45) CHARACTER SET 'utf8' COLLATE 'utf8_unicode_ci' NOT NULL COMMENT '';
ALTER TABLE `pdone`.`territories` CHANGE COLUMN `veeva_territory_id` `territory_id` VARCHAR(45) CHARACTER SET 'utf8' COLLATE 'utf8_unicode_ci' NOT NULL COMMENT '' ;
ALTER TABLE `pdone`.`targets` CHANGE COLUMN `veeva_account_id` `target_id` VARCHAR(45) CHARACTER SET 'utf8' COLLATE 'utf8_unicode_ci' NOT NULL COMMENT '' ;

#Add FK back based on new column names
ALTER TABLE `pdone`.`reps` ADD CONSTRAINT `FK_485DE7B033B9A304` FOREIGN KEY(`territories_id`) REFERENCES `pdone`.`territories`(`territory_id`); 
ALTER TABLE `pdone`.`reps` ADD INDEX `IDX_485DE7B033B9A304` (`territories_id`);

ALTER TABLE `pdone`.`targets` ADD CONSTRAINT `FK_AF431E1333B9A304` FOREIGN KEY(`territories_id`) REFERENCES `pdone`.`territories`(`territory_id`);
ALTER TABLE `pdone`.`targets` ADD INDEX `IDX_AF431E1333B9A304` (`territories_id`);

ALTER TABLE `pdone`.`targets_brands_xref` ADD CONSTRAINT `FK_85785F3E43B5F743` FOREIGN KEY(`targets_id`) REFERENCES `pdone`.`targets`(`target_id`);
ALTER TABLE `pdone`.`targets_brands_xref` ADD INDEX `IDX_85785F3E43B5F743` (`target_id`);

ALTER TABLE `pdone`.`territories_brands_xref` ADD CONSTRAINT `FK_2265AB7933B9A304` FOREIGN KEY(`territories_id`) REFERENCES `pdone`.`territories`(`territory_id`);
ALTER TABLE `pdone`.`territories_brands_xref` ADD INDEX `IDX_2265AB7933B9A304` (`territories_id`);

#Drop lastSyncAt column
ALTER TABLE `pdone`.`reps` DROP COLUMN `lastSyncAt`;
ALTER TABLE `pdone`.`targets` DROP COLUMN `lastSyncAt`;

SET SQL_MODE=@OLD_SQL_MODE;
SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS;
SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS;

Mas estou recebendo este erro:

Executing:
ALTER TABLE `pdone`.`reps` 
CHANGE COLUMN `veeva_rep_id` `rep_id` VARCHAR(45) CHARACTER SET 'utf8' COLLATE 'utf8_unicode_ci' NOT NULL COMMENT '' ;

Operation failed: There was an error while applying the SQL script to the database.
ERROR 1025: Error on rename of './pdone/#sql-85a_1b' to './pdone/reps' (errno: 150)
SQL Statement:
ALTER TABLE `pdone`.`reps` 
CHANGE COLUMN `veeva_rep_id` `rep_id` VARCHAR(45) CHARACTER SET 'utf8' COLLATE 'utf8_unicode_ci' NOT NULL COMMENT ''

Esta é a CREATEdeclaração para a pdone.repstabela:

CREATE TABLE `reps` (
  `veeva_rep_id` varchar(45) COLLATE utf8_unicode_ci NOT NULL,
  `territories_id` varchar(45) COLLATE utf8_unicode_ci DEFAULT NULL,
  `display_name` varchar(45) COLLATE utf8_unicode_ci NOT NULL,
  `avatar_url` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
  `rep_type` varchar(45) COLLATE utf8_unicode_ci NOT NULL,
  `username` varchar(45) COLLATE utf8_unicode_ci NOT NULL,
  `first` varchar(45) COLLATE utf8_unicode_ci NOT NULL,
  `last` varchar(45) COLLATE utf8_unicode_ci NOT NULL,
  `title` varchar(45) COLLATE utf8_unicode_ci DEFAULT NULL,
  `bio` longtext COLLATE utf8_unicode_ci,
  `phone` varchar(45) COLLATE utf8_unicode_ci DEFAULT NULL,
  `email` varchar(45) COLLATE utf8_unicode_ci NOT NULL,
  `inactive` tinyint(1) NOT NULL,
  `lastLoginAt` datetime DEFAULT NULL,
  `lastSyncAt` datetime NOT NULL,
  `repTokenId` varchar(150) COLLATE utf8_unicode_ci DEFAULT NULL,
  `createdAt` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
  `updatedAt` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`veeva_rep_id`),
  KEY `IDX_485DE7B033B9A304` (`territories_id`),
  CONSTRAINT `FK_485DE7B033B9A304` FOREIGN KEY (`territories_id`) REFERENCES `territories` (`veeva_territory_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci ROW_FORMAT=COMPACT;

Por que estou recebendo esse erro? Alguém pode me dar uma ajuda aqui?

Eu tenho dois bancos de dados pdonee arquivos veevan. pdoneé uma espécie de mestre e veevancontinua a sincronizar com fontes externas. Eu preciso realizar uma sincronização interna entre eles veevane pdonepor isso estou usando gatilhos para conseguir isso. Agora em pdonedb eu tenho uma mesa targetse em veevaneu tenho uma mesa address_vod__c. Sempre que um novo registro é inserido address_vod__cou sempre que um registro é atualizado, preciso atualizar a linha em, pdone.targetsentão é assim que o processo deve ser executado:

• INSERTum novo registro em veevan.address_vod__c, então SELECTa linha inserida atual (os valores) encontra a correspondência em pdone.targetse UPDATEcolunas
• UPDATEum registro em veevan.address_vod__c, então SELECTa linha atualizada atual (os valores) encontra a correspondência em pdone.targetse UPDATEcolunas

Isto é o que eu tenho até agora:

USE `veevan`;

DELIMITER $$

DROP TRIGGER IF EXISTS veevan.account_ai$$
USE `veevan`$$
CREATE DEFINER=`root`@`localhost` TRIGGER `veevan`.`address_vod__c_ai` AFTER INSERT ON `address_vod__c` FOR EACH ROW
BEGIN
    DECLARE vCount INT(6) DEFAULT 0;
    SET vCount=(SELECT COUNT(*) FROM pdone.targets WHERE targets.veeva_account_id=NEW.account_vod__c);
    IF (vCount>0) THEN
        SET @TargetLastMod=(SELECT targets.lastSyncAt FROM pdone.targets WHERE targets.veeva_account_id=NEW.account_vod__c LIMIT 0,1); 

        UPDATE pdone.targets
        SET
        `address1` = avc.address1,
        `address2` = avc.address2,
        `city` = avc.city,
        `state` = avc.state,
        `zip` = avc.zip,
        `phone` = avc.phone,
        `fax` = avc.fax,
        `lastSyncAt` = NOW(),
        `updatedAt` = NOW()
        FROM (
            SELECT 
            address_vod__c.name AS `address1`,
            address_vod__c.address_line_2_vod__c AS `address2`,
            address_vod__c.city_vod__c AS `city`,
            address_vod__c.state_vod__c AS `state`,
            address_vod__c.zip_vod__c AS `zip`,
            address_vod__c.phone_vod__c AS `phone`,
            address_vod__c.fax_vod__c AS `fax`
            FROM
                address_vod__c avc
            WHERE
                address_vod__c.account_vod__c = NEW.account_vod__c
                    AND external_id_vod__c IS NOT NULL
                    AND address_vod__c.primary_vod__c = 1
                    AND account.recordtypeid COLLATE utf8_general_ci IN (SELECT id FROM veevan.recordtype WHERE name = 'Professional_vod')
        )
        WHERE 
            targets.veeva_account_id=NEW.account_vod__c;
    END IF;
END$$
DELIMITER ;

Mas não sei se o UPDATEuso que SELECTvai funcionar e essa é a minha dúvida, como faço para conseguir um UPDATE a partir do SELECT? Sempre que tento executar esse SQL, recebo este erro:

Código de erro: 1064. Ocorreu um erro em sua sintaxe SQL; verifique o manual que corresponde à sua versão do servidor MariaDB para a sintaxe correta a ser usada perto de 'FROM SELECT address_vod__c.name AS address1, addr' na linha 19

Alguém pode me dar algum feedback e | ou ajudar sobre isso?

veeva_account_idé o PK ligado pdone.targetse account_vod__cé o FK (mais ou menos desde que o DB não tem relacionamentos reais) em veevan.address_vod__c.

Eu tenho trabalhado em um gatilho para INSERT|UPDATEvalores para um determinado registro com base no mesmo PK. O que o gatilho basicamente deve fazer é, foreach rowquando algum INSERTacontece em veeva_new.account:

• Verifique se o PK já existe, se existir, obtenha os valores veeva_new.accounte as UPDATEcolunas empdone.targets
• Se PK não existir, então INSERTa nova linha (copie a linha de veeva_new.accountpara pdone.targets)

Isto é o que eu tenho até agora:

#Account ON INSERT AFTER => Add a new record to the targets table or UPDATE its values if record already exists (checking by PK)
USE `veeva_new`;

DELIMITER $$

DROP TRIGGER IF EXISTS veeva_new.account_ai$$
USE `veeva_new`$$
CREATE DEFINER = CURRENT_USER TRIGGER `veeva_new`.`account_ai` AFTER INSERT ON `account` FOR EACH ROW
BEGIN
    DECLARE vCount INT(6) DEFAULT 0;

    SET vCount=(SELECT COUNT(*) FROM pdone.targets WHERE targets.veeva_account_id=NEW.id);
    IF (vCount>0) THEN
        SET @TargetLastMod=(SELECT targets.lastSyncAt FROM pdone.targets WHERE targets.veeva_account_id=NEW.id LIMIT 0,1); 

        IF (NEW.lastmodifieddate > @TargetLastMod) THEN
            # [Will execute a query for get values from veeva]
            SELECT 
                account.id AS veeva_account_id,
                account.lastmodifieddate AS veeva_timestamp,
                pdone.LCAPITAL(CONCAT(`first`,' ',`last`)) as display_name,
                'https://pdone.s3.amazonaws.com/avatar/no_avatar.png' AS avatar_url,
                account.title__c AS `title`,
                account.firstname AS pdone.LCAPITAL(`first`),
                account.lastname AS pdone.LCAPITAL(`last`),
                account.suffix_vod__c AS `suffix`,
                address_vod__c.name AS `address1`,
                address_vod__c.address_line_2_vod__c AS `address2`,
                address_vod__c.city_vod__c AS `city`,
                address_vod__c.state_vod__c AS `state`,
                address_vod__c.zip_vod__c AS `zip`,
                address_vod__c.phone_vod__c AS `phone`,
                address_vod__c.fax_vod__c AS `fax`,
                -- `state_licensed_id`
                'VEEVA' AS `target_type`,
                account.npi_vod__c AS `npi`,
                FALSE AS `inactive`,
                NOW() AS `lastSyncAt`,
                NOW() AS `createdAt`,
                NOW() AS `updatedAt`
                -- address_vod__c.primary_vod__c,
                -- address_vod__c.license_vod__c,
                -- address_vod__c.lastmodifieddate AS addresslastmodifieddate
            FROM
                account
                    JOIN
                address_vod__c ON address_vod__c.account_vod__c = account.id
            WHERE
                account.id = NEW.id
                    AND external_id_vod__c IS NOT NULL
                    AND address_vod__c.primary_vod__c = 1
                            AND account.recordtypeid COLLATE utf8_general_ci IN (SELECT id FROM veeva_new.recordtype WHERE name = 'Professional_vod');

            # [Will update all values for targets]
            UPDATE pdone.targets 
            SET
            `veeva_account_id` =,
            `veeva_timestamp` =,
            `display_name` =,
            `avatar_url` =,
            `title` =,
            `first` =,
            `last` =,
            `suffix` =,
            `address1` =,
            `address2` =,
            `city` =,
            `state` =,
            `zip` =,
            `phone` =,
            `fax` =,
            `target_type` =,
            `npi` =,
            `inactive` =,
            `lastSyncAt` = NOW(),
            `updatedAt` = NOW()
            WHERE targets.veeva_account_id=NEW.id; 
        END IF;
    ELSE
        INSERT INTO pdone.targets
        (`veeva_account_id`,`veeva_timestamp`,`display_name`,`avatar_url`,`title`,`first`,`last`,`suffix`,`address1`,`address2`,`city`,`state`,`zip`,`phone`,`fax`,`target_type`,`npi`,`inactive`,`lastSyncAt`,`createdAt`,`updatedAt`)
        SELECT 
            account.id AS veeva_account_id,
            account.lastmodifieddate AS veeva_timestamp,
            pdone.LCAPITAL(CONCAT(`first`,' ',`last`)) as display_name,
            'https://pdone.s3.amazonaws.com/avatar/no_avatar.png' AS avatar_url,
            account.title__c AS `title`,
            account.firstname AS pdone.LCAPITAL(`first`),
            account.lastname AS pdone.LCAPITAL(`last`),
            account.suffix_vod__c AS `suffix`,
            address_vod__c.name AS `address1`,
            address_vod__c.address_line_2_vod__c AS `address2`,
            address_vod__c.city_vod__c AS `city`,
            address_vod__c.state_vod__c AS `state`,
            address_vod__c.zip_vod__c AS `zip`,
            address_vod__c.phone_vod__c AS `phone`,
            address_vod__c.fax_vod__c AS `fax`,
            -- `state_licensed_id`
            'VEEVA' AS `target_type`,
            account.npi_vod__c AS `npi`,
            FALSE AS `inactive`,
            NOW() AS `lastSyncAt`,
            NOW() AS `createdAt`,
            NOW() AS `updatedAt`
            -- address_vod__c.primary_vod__c,
            -- address_vod__c.license_vod__c,
            -- address_vod__c.lastmodifieddate AS addresslastmodifieddate
        FROM
            account
                JOIN
            address_vod__c ON address_vod__c.account_vod__c = account.id
        WHERE
            account.id = NEW.id
                AND external_id_vod__c IS NOT NULL
                AND address_vod__c.primary_vod__c = 1
                        AND account.recordtypeid COLLATE utf8_general_ci IN (SELECT id FROM veeva_new.recordtype WHERE name = 'Professional_vod');
    END IF;
END
$$
DELIMITER ;

O gatilho não funcionará, pois tem muitos problemas e estou tentando corrigi-los, então, entre as linhas # [Will execute a query for get values from veeva], # [Will update all values for targets]devo executar uma consulta veeva_new.accounte obter a linha atual com base em PKporque ela PKjá existe e, em seguida, devo passar valores SELECTpara o UPDATEdeclaração antes # [Will update all values for targets]do comentário, como posso conseguir isso?