BenV's questions

Em um DB2 Explain Plan, o que significa TBSCAN GENROW(linha 5 abaixo)?

SELECT STATEMENT ( Estimated Costs =  1.811E+03 [timerons] )
   1 RETURN
      2 NLJOIN
          3 [O] TBSCAN
              4 SORT
                  5 TBSCAN GENROW
          6 [I] FETCH EKKO
              7 IXSCAN EKKO~1 #key columns:  2

Os documentos da IBM dizem que GENROWé

"Uma função interna que gera uma tabela de linhas, sem usar entradas de tabelas, índices ou operadores"

O que isso significa do ponto de vista do desempenho?

Além disso, isso está em um sistema SAP, se isso for importante.

Eu tenho as duas tabelas a seguir com uma chave estrangeira ativada status_id:

mysql> describe usr_cookbook;
+-----------+-----------+------+-----+-------------------+-------+
| Field     | Type      | Null | Key | Default           | Extra |
+-----------+-----------+------+-----+-------------------+-------+
| user_id   | int(11)   | NO   | PRI | NULL              |       |
| recipe_id | int(11)   | NO   | PRI | NULL              |       |
| status_id | int(11)   | NO   | MUL | NULL              |       |
| added_ts  | timestamp | NO   |     | CURRENT_TIMESTAMP |       |
+-----------+-----------+------+-----+-------------------+-------+

mysql> describe usr_cookbook_status;
+-----------+-------------+------+-----+---------+-------+
| Field     | Type        | Null | Key | Default | Extra |
+-----------+-------------+------+-----+---------+-------+
| status_id | int(11)     | NO   | PRI | NULL    |       |
| name      | varchar(45) | NO   |     | NULL    |       |
+-----------+-------------+------+-----+---------+-------+

Há duas linhas em usr_cookbook_status:

mysql> select * from usr_cookbook_status;
+-----------+-----------+
| status_id | name      |
+-----------+-----------+
|         1 | Try Soon  |
|         2 | Favorites |
+-----------+-----------+

Portanto, devo inserir no usr_cookbook, certo?

mysql> insert into usr_cookbook (user_id, recipe_id, status_id) values (3, 5, 1);
ERROR 1452 (23000): Cannot add or update a child row: a foreign key constraint 
fails (`tomato`.`usr_cookbook`, CONSTRAINT `fk_cookbook_status` FOREIGN KEY 
(`status_id`)
REFERENCES `usr_cookbook_status` (`status_id`) ON DELETE NO ACTION ON UPDATE
NO ACTION)

Por que a violação de restrição? O status_idque estou usando (1) existe na tabela pai. Tenho certeza de que há algo simples que estou perdendo aqui ...

Estou tentando sincronizar as alterações de esquema do MySQL Workbench para meu banco de dados. Estou recebendo o seguinte erro ao tentar criar uma chave estrangeira:

Executing SQL script in server
ERROR: Error 1005: Can't create table 'tomato.#sql-2730_1b8' (errno: 121)

Aqui está a instrução que está tentando executar:

ALTER TABLE `tomato`.`ing_allergy_ingredient` 
ADD CONSTRAINT `fk_ai_allergy`
FOREIGN KEY (`allergy_id` )
REFERENCES `tomato`.`ing_allergy` (`allergy_id` )
ON DELETE NO ACTION
ON UPDATE NO ACTION

Alguma ideia do que esse erro significa?

Nas definições de tabela do MySQL existe uma diferença entre INT(5)e SMALLINT(5)? Ou ambos representam o mesmo tamanho?

Existem diretrizes ou regras práticas para determinar quando armazenar valores agregados e quando calculá-los em tempo real?

Por exemplo, suponha que eu tenha widgets que os usuários podem avaliar (veja o esquema abaixo). Cada vez que exponho um widget, posso calcular a classificação média do usuário na Ratingstabela. Alternativamente, eu poderia armazenar a classificação média na Widgetmesa. Isso me pouparia de ter que calcular a avaliação toda vez que eu exibir o widget, mas então eu teria que recalcular a avaliação média cada vez que um usuário avaliasse um widget.

Ratings       Widgets
---------     -------
widget_id     widget_id
user_id       name              
rating        avg_rating  <--- The column in question

Estou projetando um banco de dados com várias tabelas de pesquisa contendo possíveis atributos das entidades principais. Estou pensando em usar uma chave de 4 ou 5 caracteres para identificar esses valores de pesquisa em vez de um número inteiro de incremento automático para que, quando armazenar esses IDs de atributo nas tabelas principais, veja valores significativos em vez de apenas números aleatórios.

Quais são as implicações de desempenho de usar um campo de caractere como chave primária em vez de um número inteiro?

Estou usando o MySQL, se isso importa.

[Editar]
Essas tabelas de pesquisa têm novos registros adicionados com pouca frequência. Eles são mantidos manualmente e as chaves baseadas em caracteres também são criadas manualmente. Aqui está um exemplo:

      CUISINES
 ID      Description
-----  --------------
CHNSE  Chinese
ITALN  Italian
MXICN  Mexican

Eu tenho os seguintes EXPLAIN PLANresultados de uma consulta em meu banco de dados DB2.

0 SELECT STATEMENT ( Estimated Costs =  5.928E+02 [timerons] )
       1 RETURN
           2 HSJOIN
               3 [O] FETCH LTBP
                   4 IXSCAN LTBP~M #key columns:  0
               5 [I] FETCH LTBK
                   6 IXSCAN LTBK~V #key columns:  0

O que significa a HSJOINlinha 2?

No MySQL, é melhor sempre permitir nulos, a menos que você saiba que um campo é obrigatório, ou sempre usar Not Null, a menos que saiba que um campo conterá nulos? Ou não importa?

Eu sei que em alguns DBMSs eles dizem para usar Not Nullo máximo possível porque permitir nulos requer um bit extra (ou byte?) Por registro para armazenar o status Nulo.