MicBehrens's questions

Eu tenho 2 mesas. 1 contendo meus tópicos e 1 contendo os usuários vinculados a esses tópicos.

Eu quero encontrar o ThreadID com 2 UserIDs específicos anexados, nem mais nem menos.

Isto é o que eu vim com:

SELECT mt.ThreadID 
FROM MessagesThreads AS mt
WHERE (SELECT COUNT(DISTINCT mtau.UserID)
       FROM MessagesThreadsAccessUsers AS mtau
       WHERE
        mtau.ThreadID = mt.ThreadID
        AND EXISTS (
         SELECT 0
         FROM MessagesThreadsAccessUsers AS mtau2
         WHERE mtau2.ThreadID = mtau.ThreadID
         AND mtau2.UserID = 1
        )
        AND EXISTS (
         SELECT 0
         FROM MessagesThreadsAccessUsers AS mtau2
         WHERE mtau2.ThreadID = mtau.ThreadID
         AND mtau2.UserID = 2
        )
       ) = 2

Esta situação específica é sobre encontrar o ThreadID com UserID 1 e UserID 2 anexados. Se nenhum ThreadID for encontrado, preciso criar um novo mais adiante no caminho.

Minha pergunta é: esta é a melhor maneira de consultar isso ou pode ser mais inteligente?

Quando devo usar o modelo de recuperação completa e quando devo usar o modelo de recuperação simples para bancos de dados?

Eu sempre usei o modelo de recuperação completa porque é o padrão, mas hoje encontrei este erro:

Provedor Microsoft OLE DB para SQL Server (0x80040E14) O log de transações do banco de dados 'DATABASE NAME' está cheio. Para descobrir por que o espaço no log não pode ser reutilizado, consulte a coluna log_reuse_wait_desc em sys.databases

O banco de dados específico é, na verdade, um dos menores e mais inativos bancos de dados do meu servidor, então não tenho ideia de como o log pode estar cheio nesse banco de dados e não nos outros.

Para reduzir o log e tornar o banco de dados acessível novamente, alterei o modelo de recuperação de FULL para SIMPLE e reduzi o log do arquivo lógico, com o seguinte comando

alter database myDbName SET recovery simple
go
dbcc shrinkfile('LOG FILE LOGICAL NAME', 100)
go

Ajudou, mas agora preciso entender POR QUE ajudou, COMO essa situação começou e COMO evitar isso no futuro?

EDITAR:

Todas as noites, à 1h, estamos fazendo um backup com script de cada banco de dados no servidor. Isso está sendo feito por um script de 31 linhas onde a parte mais importante é

set @Filename = 'D:\backup\' + convert(varchar, getDate(), 112) + ' - ' + @DBName + '.bak'
set @Description = 'Full backup of database ' + @Filename
BACKUP DATABASE @DBName TO DISK = @Filename WITH INIT , NOUNLOAD , NAME = @Description, NOSKIP , STATS = 10, NOFORMAT

O novo modelo de recuperação e a redução de banco de dados entrarão em conflito com esse script?

Não estamos fazendo nenhum outro tipo de backup dos bancos de dados e, portanto, não dos logs de transações, não é?

É possível dizer ao banco de dados para executar um pequeno script, se uma linha for alterada em uma tabela?

Cenário: O banco de dados monitora constantemente a Tabela B para ver se as linhas foram inseridas, atualizadas ou excluídas. Se uma linha for inserida, atualizada ou excluída: Atualize a linha na Tabela A com o identificador de referência.

Configurar:

Table A
------------------------
UserID   Name   SalesSum
1        Carl   5
2        Peter  0
3        Oscar  3


Table B
--------------------------
UserID   Timestamp   Sales
1        01:00:00    3
1        02:01:00    1
1        03:54:00    1
3        01:20:00    2
3        02:45:00    1

O objetivo disso é não fazer uma subconsulta toda vez que o SalesSum for necessário no aplicativo, como:

Select A.Name, SalesSum = (select sum(B.Sales) from [Table B] as B where A.UserID = B.UserID) from [Table A] as A

Mas, em vez disso, "apenas" fazendo isso de maneira fácil, agradável e limpa:

Select Name, SalesSum from [Table A]

Ou há algo que eu possa ter supervisionado ou estou errado?

EDITAR:

Muitos deles descreveram o uso de junções internas para esses subcálculos. Mas ao "tentar" isso, recebo alguns erros: primeiro, tenho que incluir cada coluna na cláusula GROUP BY, a menos que seja definida por meio de uma função agregada. Mas ao tentar fazer isso, dá erro ao ter uma coluna de tipo de dados NTEXT na cláusula, pois não pode ser comparada.

Aqui está um exemplo da consulta original:

Select
 U.UserID,                                                                 ' Int - Primary Key
 U.Name,                                                                   ' Nvarchar(MAX)
 B.OrderID,                                                                ' Int - Primary Key
 B.Comment,                                                                ' Ntext
 SalesAmount = (select sum(C.Sales) from OrdersDetails as C),
 SalesPriceSum = (select sum(C.Sales * C.Price) from OrdersDetails as C)
From
 Orders as B
Inner join
 Users as U on B.UserID = u.UserID
Where
 ' Clauses on finding specific columns based on the Orders table and the Users table
Order By
 U.Name asc
 B.Period asc

A "nova" consulta, com outra junção interna, poderia ser algo como:

Select
 U.UserID,                                                                 ' Int - Primary Key
 U.Name,                                                                   ' Nvarchar(MAX)
 B.OrderID,                                                                ' Int - Primary Key
 B.Comment,                                                                ' Ntext
 SalesAmount = sum(C.Sales),
 SalesPriceSum = sum(C.Sales * C.Price)
From
 Orders as B
Inner join
 Users as U on B.UserID = u.UserID
Inner join
 OrdersDetails as C on B.OrderID = C.OrderID
Where
 ' Clauses on finding specific columns in Order table
Group By
 U.UserID
 U.Name
 B.OrderID
 B.Comment     <------- This errors because of the Ntext datatype!
Order By
 U.Name asc
 B.Period asc

Conforme escrito, este é apenas um exemplo e, portanto, pode haver um grande número de colunas selecionadas - especialmente da tabela Pedidos. Tudo isso precisa estar nas cláusulas Group By. Mas isso não pode ser feito com os tipos de dados Ntext. Então o que eu faço?

Estou tentando ansiosamente projetar a arquitetura de dados multitenant perfeita para meu banco de dados.

Estou me inspirando em um artigo postado pela Microsoft , baseado no cenário 3.

Recebi todas as minhas tabelas uma coluna de inquilino e depois criei uma VIEW correspondente

ALTER TABLE {table_name} add TenantID varbinary(85) DEFAULT SUSER_SID()

CREATE VIEW {view_name} 
AS 
   SELECT * 
   FROM {table_name} 
   WHERE TenantID = SUSER_SID()

Cada um dos meus clientes tem sua própria conta de usuário de banco de dados, esses usuários receberam os seguintes direitos:

db_datareader
db_datawriter
public

E então alterei o seguinte:

DENY SELECT ON {table_name} TO {user_name}
GRANT SELECT ON {view_name} TO {user_name}

De qualquer forma, estou perdendo alguma coisa por enquanto? :)

Atualmente, estou criando uma arquitetura de dados multilocatário em um produto SaaS BI.

O produto está usando banco de dados compartilhado e esquema compartilhado, mas com filtros de exibição de locatário e criptografia de dados de locatário (inspiração encontrada aqui: http://msdn.microsoft.com/en-us/library/aa479086.aspx )

Ao criar o filtro de exibição, posso fazer os dois:

CREATE VIEW TenantEmployees AS
SELECT * FROM Employees WHERE TenantID = SUSER_SID()

CREATE VIEW TenantEmployees AS
SELECT * FROM Employees WHERE TenantID = SUSER_ID()

Usando SID(), estou usando o identificador de segurança que se parece com isto:

0x3425F1595A67774ABF485CDC30285443

Usando ID(), estou usando o identificador normal que se parece com isto:

265

Qual é o melhor absoluto para usar e por quê? :) Espero que ambos sejam absolutamente únicos e nunca sejam reutilizados em novos logins de usuários

Verificando meu log do SQL Server, vejo várias entradas como esta:

Date: 08-11-2011 11:40:42
Source: Logon
Message: Login failed for user 'sa'. Reason: Password did not match for the login provided. [CLIENT: 56.60.156.50]
Date: 08-11-2011 11:40:42
Source: Logon
Message: Error: 18456. Severity: 14. State: 8.


Date: 08-11-2011 11:40:41
Source: Logon
Message: Login failed for user 'sa'. Reason: Password did not match for the login provided. [CLIENT: 56.60.156.50]
Date: 08-11-2011 11:40:41
Source: Logon
Message: Error: 18456. Severity: 14. State: 8.

E assim por diante.. Isso é um possível ataque ao meu SQL Server vindo dos chineses???! Procurei o endereço IP em ip-lookup.net, que afirmava ser chinês.

E o que fazer?

• Bloquear o endereço IP no firewall?
• Excluir o usuário sa?

E como eu protejo melhor meu servidor web?!

Desde já, obrigado!