Preciso usar STRING_SPLIT com ordenação habilitada:

Atualizamos todos os nossos servidores para o SQL Server 2022 e alteramos o nível de compatibilidade para 160, mas o código a seguir não está funcionando:

SELECT * FROM STRING_SPLIT('Lorem ipsum dolor sit amet.', ' ', 1);

O erro é:

Msg 8748, Nível 16, Estado 1, Linha 1 O argumento enable_ordinal para STRING_SPLIT suporta apenas valores constantes (não variáveis ​​ou colunas).

O ambiente de produção é:

Microsoft SQL Server 2022 (RTM-CU11) (KB5032679) - 16.0.4105.2 (X64) 
    Nov 14 2023 18:33:19 
    Copyright (C) 2022 Microsoft Corporation
    Standard Edition (64-bit) on Windows Server 2019 Standard 10.0 <X64> (Build 17763: )

A versão do SSMS é:

Testamos o código na CU mais recente:

A única coisa que encontrei foi esta resposta apontando que:

O problema é que o SSMS tem IntelliSense/dicas de ferramentas codificadas sem lógica condicional com base na versão, e o código está à frente do mecanismo. Atualmente, a funcionalidade está disponível apenas no Banco de Dados SQL do Azure, Instância Gerenciada e Synapse.

Ainda assim, não tenho certeza de onde está o problema: na documentação, no mecanismo, no SSMS ou em algo que não estou fazendo direito.

Observação: o problema é o mesmo no Azure Data Studio.

Configurar

CREATE TABLE persons
(
  person_id int not null,
  name TEXT 
);

INSERT INTO persons VALUES
(1, 'Adam'),
(2, 'Paul'),
(3, 'Tye'),
(4, 'Sarah');

CREATE TABLE json_to_parse
(
  person_id int not null,
  block json
);

INSERT INTO json_to_parse VALUES
  (1, '{"size": "small", "love": "x"}'),
  (2, '{"size": "medium", "love": "xx"}'),
  (3, '{"size": "big", "love": "xxx"}');

O erro

Isso funciona sem problemas

SELECT
  *
FROM
  json_to_parse
CROSS JOIN LATERAL
  json_to_record(json_to_parse.block) AS my_json(size TEXT, love TEXT)
INNER JOIN
  persons
ON
  persons.person_id = json_to_parse.person_id;

mas isso não

SELECT
  *
FROM
  json_to_parse,
  json_to_record(json_to_parse.block) AS my_json(size TEXT, love TEXT)
INNER JOIN
  persons
ON
  persons.person_id = json_to_parse.person_id;

e recebo o erro "referência inválida para a entrada da cláusula FROM para a tabela "json_to_parse""

Por que esse segundo erro de consulta? Os documentos deixam bem claro que LATERALé opcional para funções com valor de tabela

As funções de tabela que aparecem em FROMtambém podem ser precedidas pela palavra-chave LATERAL, mas para funções a palavra-chave é opcional; os argumentos da função podem conter referências a colunas fornecidas pelos FROMitens precedentes em qualquer caso.

dbfiddle

Tenho lido sobre os índices columnstore do Microsoft SQL Server recentemente e fiquei preocupado que minha experiência não corresponda à do setor. Os índices columnstore são projetados para tornar os agregados fáceis. É dito com muita frequência que, por esse motivo, eles são ideais para tabelas de fatos.

Isso me deixa desconfortável. Na minha experiência, tabelas de fatos não são agregadas . A lista de colunas para cada tabela de fatos que já fiz tem o formato "chave primária seguida por várias colunas de dimensão, seguidas por cada bit de informação que armazenamos sobre a chave primária". Elas então são despejadas em alguma ferramenta de BI como PowerBI ou ThoughtSpot, para que pessoas não técnicas possam filtrar com base nas dimensões e descobrir o que quiserem saber. Elas podem agregar de tempos em tempos, mas esse certamente não é o uso principal da tabela. Espero que essas tabelas tenham bem mais de 100 colunas.

O design da tabela e o padrão de acesso que estou descrevendo são o que se espera de uma tabela de fatos? Ou estou descrevendo um tipo de tabela totalmente diferente, cujo nome desconheço?

Tenho lido a documentação completa de pesquisa de texto no SQLite e tudo faz sentido, exceto que parece não haver acomodação para realmente poder vincular linhas FTS com linhas em outras tabelas. Acho que não quero colocar todas as colunas da minha entidade na minha tabela FTS porque não posso especificar tipos de dados (ou STRICT) para ela, e não preciso que todos os dados sejam indexados para um FTS. Então, eu queria usar um relacionamento FK para fazer um link 1:1 da minha tabela de entidade principal para sua tabela FTS, assim:

CREATE VIRTUAL TABLE usersFTS USING fts4(
    keywords,
    nicknames
);

-- Create the users table with an explicit foreign key reference to usersFTS
CREATE TABLE users(
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    name TEXT NOT NULL,
    email TEXT NOT NULL UNIQUE,
    usersFTS_id INTEGER NOT NULL,
    FOREIGN KEY (usersFTS_id) REFERENCES usersFTS (rowid)
);

-- ... then:

-- Insert into usersFTS and capture the generated rowid for Alice's meta
INSERT INTO usersFTS (keywords, nicknames) VALUES ('software developer linux open-source', 'Ally Alice');

-- Capture the generated rowid for Alice
SELECT last_insert_rowid();  -- Assume it returns 1

-- Insert into users using the captured rowid
INSERT INTO users (name, email, usersFTS_id) VALUES ('Alice', '[email protected]', 1);

-- ... so that:

SELECT usr.id, usr.name, usr.email, fts.keywords, fts.nicknames
FROM usersFTS fts
INNER JOIN users usr ON usr.usersFTS_id = fts.rowid
WHERE fts.keywords MATCH '"software developer"';

Mas isso falha na INSERTafirmação:

Erro de lógica SQL: incompatibilidade de chave estrangeira - "users" referenciando "usersFTS"

Parece que uma tabela virtual não pode ter seu rowid referenciado em um relacionamento FK normal. Então, como posso vincular uma linha na minha tabela de pesquisa de texto completo a uma linha em outra tabela que contém mais dados sobre essa entidade? Existe alguma maneira de fazer isso no SQLite que mantenha a integridade referencial?

Gostaria de adicionar informações de versão ao nosso BD - tudo o que será usado é para verificar se a versão do usuário de uma linha mudou desde que ele a leu. Estou pensando em adicionar uma coluna chamada _VERSIONàs duas dúzias de tabelas em questão. Como parte de uma UPDATEdeclaração em lote, eu teria algo como SET ..._VERSION=something_or_other. Sou agnóstico sobre quais dados essa coluna contém.

Uma solução que vi é usar uma coluna datetime e então obter o horário de início da transação de sys.dm_tran_active_transactions, selecionando a linha para CURRENT_TRANSACTION_ID(). Para nossas necessidades, a precisão de 1/300 será mais do que suficiente. Entendo que usar CURRENT_TIMESTAMPnão é tão útil nessa situação porque isso mudará conforme o lote prossegue.

Se isso for canônico, farei isso. É fácil de implementar.

Mas essa é a melhor maneira para usos realmente simples? Existe algum outro valor no sys.dm_tran...que fornece o mesmo resultado, mas pode ser mais fácil de armazenar e WHERE do que um datetime?

OBSERVAÇÃO: sim, estou ciente das tabelas temporais e do rastreamento de alterações da MS e me disseram para não usá-los.

Tenho vários arquivos: dois backups e uma lista de logs de transações.

Os backups são chamados:

• FB20241125_233033.bak
• FB20241126_233040.bak

(Os nomes dos arquivos correspondem à data/hora em que os backups foram feitos.)

Os logs de transações são chamados (trecho da linha de comando):

Prompt>dir *.trn

 Directory of C:\...\Transaction_Logs

25/11/2024  23:45         5.758.464 20241125224500.trn
26/11/2024  00:00         5.560.832 20241125230001.trn
26/11/2024  00:15         5.692.928 20241125231501.trn
...
26/11/2024  15:00         5.822.976 20241126140001.trn
26/11/2024  15:15         5.955.072 20241126141501.trn
26/11/2024  15:30         5.889.536 20241126143000.trn
27/11/2024  12:15         5.626.368 20241127111501.trn

(O mesmo motivo para nomes de arquivos se aplica.)

Então eu faço uma restauração deste diretório (pego os dois arquivos de backup e todos os arquivos de log de transações), usando as seguintes propriedades:

Esta é a mensagem de erro que recebo:

System.Data.SqlClient.SqlError: O log neste conjunto de backup começa em LSN 33845000000619000001, que é muito recente para ser aplicado ao banco de dados. Um backup de log anterior que inclui LSN 33816000000750400001 pode ser restaurado. (Microsoft.SqlServer.SmoExtended)

Pensei comigo mesmo " Mas isso é óbvio: meu último backup foi feito às 23h30m40s em 26/11/2024, enquanto o último log de transações data do dia seguinte, então não vamos incluir esse log de transações na restauração. ", mas isso não ajuda.

Alguém sabe o que posso fazer para restaurar o backup mais recente possível, contendo os logs de transações mais recentes possíveis?

Edit1: e quanto aos LSNs em arquivos "*.trn"?
Enquanto isso, executei a seguinte consulta SQL para os *.trnarquivos mencionados:

RESTORE HEADERONLY FROM DISK = 'C:\...\20241125224500.trn';
RESTORE HEADERONLY FROM DISK = 'C:\...\20241125230001.trn';
...

Estes são os primeiros resultados:

FirstLSN               LastLSN             
---------------------- --------------------
33758000001254200001   33759000000515900001
33759000000515900001   33759000001579300001
33759000001579300001   33760000000835100001
33760000000835100001   33761000000090800001
33761000000090800001   33761000001176400001
33761000001176400001   33762000000412500001
33762000000412500001   33762000001492100001
33762000001492100001   33763000000648100001
33763000000648100001   33763000001722200001

Como você pode ver, há muitos *.trnarquivos tendo 3375...e 3376...como primeiro Número de Sequência de Log (LSN), então por que a mensagem de erro está dizendo que o log neste conjunto de backup começa em LSN 3384...?

desde já, obrigado

Vamos supor que temos os seguintes dados com uma medição de temperatura por segundo. O intervalo de dados é de vários anos, então há um número considerável de linhas. São dados de medição de um dispositivo de campo. A tabela tem outras colunas também, mas elas não são relevantes para a questão.

Sei que posso usar uma GROUP BYcláusula para obter as médias em janelas de uma hora entre um horário específico de início e término, como esta:

  SELECT to_char("time", 'YYYY-MM-DD HH'), AVG("Temperature_deg_in_C")
    FROM "measurements"
   WHERE "time" BETWEEN '2024-11-01' AND '2024-12-01'
GROUP BY to_char("time", 'YYYY-MM-DD HH')

No entanto, essa sintaxe parece um hack e não se adapta a quadros de janela (ou partições) de 10 segundos ou outros mais complexos, por exemplo.

Além disso, gostaria de saber, especificamente, como isso é feito corretamente e com desempenho usando o OVER, WINDOW, PARTITION BY, e ferramentas semelhantes descritas no manual doRANGE PostgreSQL .ROWS

ATUALIZAÇÃO: Funções de janela não podem ser usadas para atingir esse objetivo no Postgres, pois elas não criam "buckets" ou "frames" da maneira que eu pensava que faziam. GROUP BYé a maneira de conseguir isso.

O objetivo final é encontrar uma solução onde o comprimento da janela e a unidade de medida (minutos, horas, dias), e o horário de início e término do período de observação sejam flexíveis, mas o corpo da consulta em si permaneça o mesmo. Uma consulta parametrizada que seja simples de entender, isto é.

Tenho duas tabelas: "Flight" e "Person". Person tem três colunas: "id", "last", "first".

O voo tem três colunas: "id", "P1_id", "P2_id", onde P1_id é o id da linha de uma "Pessoa" e P2_id também é o id da linha de uma "Pessoa".

Preciso selecionar cada linha de "Flight" com o "last" e "first" apropriados de "Person". Os dados da tabela parecem algo como -

Pessoa (id, último, primeiro)

1. ferreiro, joão
2. jones, fred
3. vidro, michael

Voo (id, p1_id, p2_id)

1. 1, 2
2. 2, 3
3. 3,
4. 3, 2

Preciso que a saída pareça -

1. ferreiro, jones
2. jones, vidro
3. vidro
4. vidro, jones

Obrigado pela ajuda.

Sou um pouco novato quando se trata de administração de banco de dados, então, vá com calma!

Eu tenho um banco de dados MySQL. No qual há cerca de 100 tabelas. Agora mesmo, cada tabela tem aproximadamente 50 linhas. Então, quando se trata de selecionar uma linha dessas linhas, o tempo de consulta é de cerca de 0,0004 segundos.

Agora, para minha pergunta: Suponha que uma dessas tabelas cresça e tenha cerca de 5 milhões de linhas. Então, se eu quiser selecionar apenas 1 linha dessa tabela, seu tempo de consulta aumentará? Em aproximadamente quanto?

Se sim, o que posso fazer para reduzir o tempo de consulta depois que a tabela crescer?

Um pouco de contexto da tabela: Cada tabela tem cerca de 10 a 11 colunas. Das quais cerca de 4 a 5 são inteiros de comprimento 11, e 1 coluna é longtext e outras são varchar de comprimento 255.

Preciso fazer backup dos dados de uma tabela específica por semana e depois restaurá-la, mas sem truncar a tabela. Esta tabela contém o fechaRegistro

Eu preparei o seguinte script, mas não tenho certeza sobre como declarar variáveis ​​de data. Você poderia me ajudar, por favor?

#!/bin/bash
# VARIABLES
FECHA=$(date +"%Y%m%d")
SERVIDOR="$(hostname)"
PASSWORD='PASSWORD'
BD=ordenes
TABLA="backlogPedidos"
ARCHIVO="$SERVIDOR-${BD^^}${TABLA^^}-$FECHA.sql"
RUTA_NAS="/tmp/"


# Establecer variables para calcular el rango semanal
INICIO_SEMANA=$(date -d "last sunday - 6 days" +"%Y-%m-%d 00:00:00")
FIN_SEMANA=$(date -d "last saturday" +"%Y-%m-%d 23:59:59")

# Se generar el backup por rangoo de una semana
mysqldump --databases $BD --tables $TABLA --where="fechaRegistro BETWEEN '$INICIO_SEMANA' AND '$FIN_SEMANA'" --skip-comments --compact --single-transaction --default-character-set=UTF8 --insert-ignore --complete-insert --skip-triggers --skip-routines --no-create-info --disable-keys --set-gtid-purged=OFF -q --lock-tables=false --user=backup -p$PASSWORD > /tmp/$ARCHIVO

echo "Backup semanal generado: $ARCHIVO"