Alex's questions

Tenho um monte de propriedades (colunas no banco de dados) que devem ter um valor de string de uma lista de valores predefinidos, por exemplo active, inactive, pending.

Fora do banco de dados, que é javascript (deno+react no front-end), eu realmente quero tê-los como enumerações de strings, e não como inteiros, porque isso adiciona alguma clareza ao código e, na verdade, reduz a quantidade de código que você precisa escrever.

No banco de dados, tenho duas opções: armazená-los como estão (strings) ou smallintconvertê-los de/para strings durante a seleção/inserção no banco de dados.

O problema com a segunda opção é que ela requer uma transformação adicional no código e, ao usar o TypeScript, essa transformação não é tão direta quanto fazer um mapeamento simples, porque o ts não permite que você reatribua tipos diferentes a propriedades existentes, então você precisa copiar e fazer mais coisas...

De qualquer forma, eu só queria perguntar, quanto é o desempenho do postgres e/ou sobrecarga de tamanho se eu armazená-los diretamente como strings no banco de dados também, para eliminar a etapa de transformação? Imagino que cada registro cresceria em cerca de 20 bytes se eu mudasse de smallintpara texte isso teria algum tipo de efeito no desempenho? Além disso, essas colunas precisam ser indexadas, e isso adiciona outros 20 bytes para cada registro

Se eu tiver uma chave composta feita de 3 colunas, como

constraint some_index unique (parent_store_id, store_type, store_name),

E também preciso poder fazer consultas de seleção com where store_type = ...ou where store_name = ..., ainda preciso criar índices separados para cada uma dessas colunas? Ou o índice exclusivo acima resolve esses casos?

select * from tblA a 
 left join tblB b on b.id = a.bId 
   group by a.bId 

Se eu agrupar com base em uma coluna, obtenho apenas o primeiro registro dos registros que têm o mesmo bIDvalor. Existe uma maneira de também obter o número total de registros que têm o mesmo bIdvalor para cada linha? Sem fazer uma consulta separada...

id | bId
--------
1  |  1
2  |  1
3  |  1
4  |  2
5  |  3


so in the above query I would expect

id | bId. | counts
-------------------
1  |  1  |  3   <- 3 records with bId = 1
4  |  2  |  1
5  |  3  |  1

Se eu tiver vários leitores de banco de dados, que são basicamente instâncias do SQLite que abrem o arquivo db no modo "leitura", é normal que um único gravador que abre o db no modo "criação" não consiga liberar uma transação até que todos os leitores fechem o banco de dados?

Estou tentando descobrir se é um comportamento normal do sqlite ou um bug/limitação de uma biblioteca sqlite específica que estou usando.

Não entendo por que um escritor precisaria esperar que os leitores parassem de usar o arquivo de banco de dados. Não faz sentido para mim, porque os leitores não podem alterar os dados.

Acredito que seja uma query bem simples de se fazer, mas por algum motivo não funciona no Postgres (funciona em outros dbs)

É assim que o esquema db funciona como:

tableA(
   id integer,
   ...
)

tableB(
   id integer
   tableA_id integer -- foreign key to tableA
   ...
)

E eu quero selecionar registros para tableB, juntar com tableA, então agrupar por tableA_id:

SELECT * from tableB b INNER JOIN tableA ON b.tableA_id = tableA.id
GROUP BY tableA_id
LIMIT 20

Funciona bem em todos os lugares, exceto Postgres, que lança aquele infame erro "id deve aparecer em grupo ou ser usado em função agregada". Mas se eu colocar b.id, group bynão removo os registros duplicados ...

Eu tenho uma chave DATETIME na qual classifico os resultados e a consulta está sendo executada muito lentamente. Será executado mais rápido se eu mudar para TIMESTAMP?

Porque notei que a ordenação por teclas numeradas é feita quase instantaneamente.

CREATE TABLE relations (

  object_id BIGINT(20) NOT NULL PRIMARY KEY,
  object_term BIGINT(20) NOT NULL,

  UNIQUE KEY link(object_id, object_term),

  CONSTRAINT fk_term FOREIGN KEY(object_term)
    REFERENCES terms(id) ON DELETE CASCADE ON UPDATE RESTRICT,

  CONSTRAINT fk_object FOREIGN KEY(object_id)
    REFERENCES objects(id) ON DELETE CASCADE ON UPDATE RESTRICT

) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

Tenho a sensação de que estou indexando object_id3 vezes e object_termduas vezes. Estou certo?

Se sim, como posso consertar isso e ainda manter as restrições e a força (object_id, object_term)para serem únicas?

ok, segunda tentativa:

CREATE TABLE relations (

  object_id BIGINT(20) NOT NULL,
  object_term BIGINT(20) NOT NULL,

  PRIMARY KEY link(object_id, object_term),

  CONSTRAINT fk_term FOREIGN KEY(object_term)
    REFERENCES terms(id) ON DELETE CASCADE ON UPDATE RESTRICT,

  CONSTRAINT fk_object FOREIGN KEY(object_id)
    REFERENCES objects(id) ON DELETE CASCADE ON UPDATE RESTRICT

) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

isso é melhor?