RLH's questions

Tenho duas instâncias do SQL Server que gerencio. Uma é uma instância do SQL Server 2000 e a outra é 2005.

Alguns onde, nesses servidores, lembro-me de configurar alguns gatilhos de tabela que foram executados sob certas condições. Eu preciso procurar esses gatilhos como ponto de referência para um novo projeto, no entanto, para a vida de mim não consigo encontrá-los.

Existe alguma instrução SQL habilidosa que eu possa executar para iterar em todos os meus bancos de dados e, subsequentemente, iterar em cada tabela e gerar qualquer gatilho associado às tabelas?

Ontem fiz essa pergunta em relação a alteração do dbo de vários bancos de dados que possuo. A mudança faz sentido, mas quero ser claro.

Existe algum bom motivo ou circunstância para que eu não deva definir o dbo de um banco de dados como [sa]?

Eu gerencio uma máquina SQL Server (com SQL Server 2000 e 2005 instalados) que foi criada pela primeira vez em um domínio do Active Directory do qual estamos fazendo a transição e prestes a desligar. Todos os meus bancos de dados têm o proprietário do arquivo do domínio antigo.

Novas contas foram criadas com as permissões corretas para executar os serviços do SQL Server e executar todos os processos necessários do SQL Server. Minha pergunta é: qual é o benefício de atualizar a File's Ownerpropriedade associada em cada banco de dados?

Preciso atribuir uma nova conta do AD a cada banco de dados ou posso deixá-la como está, pois já existem contas configuradas com direitos totais de administrador para todos os meus bancos de dados?

Desculpe pela longa pergunta, mas deixe-me dar-lhe o meu cenário. Eu tenho um banco de dados que armazena dados exportados de outro banco de dados. As tabelas contidas são cópias do outro banco de dados (não SQL). Cada nome de coluna nessas tabelas de exportação é nomeado usando o seguinte padrão:

UserFriendlyName_OriginalColumnName

Como nossos usuários estão interessados ​​principalmente na parte UserFriendlyName da coluna, criamos uma View para cada tabela, onde o nome de cada campo é estritamente a parte UserFriendlyName do nome da coluna.

A maioria dessas visualizações são estritamente consultas de uma tabela de dados. Para algumas dessas exibições, no entanto, vinculo a uma outra tabela de dados para extrair um ou dois campos de descrição. Observe que isso nunca é mais do que uma tabela vinculada.

Em termos de desempenho, qual método é melhor? Se eu estiver vinculando uma tabela de dados a outra para um campo de descrição, posso vincular diretamente à visualização das tabelas de descrição para não precisar criar um alias para a coluna? É significativamente melhor usar duas tabelas de dados na exibição e alias cada coluna das tabelas pai?

Isso pode parecer um pouco arbitrário, mas esse projeto de exportação de dados está ficando cada vez maior. Gostaria de formalizar meu processo de como vincular minhas informações. O objetivo é usar estritamente as exibições de dados, se e quando possível. No entanto, se isso adicionar uma quantidade considerável de degradação de desempenho, prefiro sempre usar tabelas de dados em todas as minhas exibições de dados.

Muitos dos meus bancos de dados têm campos definidos como varchars. Isso não tem sido um grande problema desde que moro e trabalho na América (onde a única língua que existe é "americano". ahem )

Depois de trabalhar com bancos de dados por cerca de 5 anos, descobri que eventualmente tive problemas com a natureza limitada do campo varchar e tive que modificar meus campos para armazenar dados como nvarchars. Depois de fazer outra atualização em uma tabela, convertendo um campo varchar em um nvarchar, pensei-- por que ainda estamos fazendo dessa maneira? Há muito tempo tomei a decisão mental de definir todos os meus novos campos de texto para nvarchar, em vez de varchar, que é o que aprendi a fazer em meus livros didáticos quando estava na escola, 10 anos atrás.

É 2011 e houve uma nova versão do SQL Server no ano passado. Por que continuamos a oferecer suporte a um tipo de dados varchar quando podemos/devemos usar nvarchar?

Eu sei que muitas vezes é argumentado que nvarchars são "duas vezes maiores" que varchars, então o uso do espaço de armazenamento pode ser um argumento para manter varcars.

No entanto, os usuários de hoje podem definir seus nvarchars para armazenar os dados como UTF-8 em vez do padrão UTF-16 se quiserem economizar espaço de armazenamento. Isso permitiria a codificação de 8 bits, se isso for principalmente desejável, ao mesmo tempo em que garante que o raro caractere de 2 a 8 bytes que é inserido em seu banco de dados não quebraria nada.

Estou esquecendo de algo? Existe uma boa razão para isso não ter mudado nos últimos 15-20 anos?