Thomas Stringer's questions

Qual é a maneira mais eficiente de recuperar intervalos de datas com uma estrutura de tabela como essa?

create table SomeDateTable
(
    id int identity(1, 1) not null,
    StartDate datetime not null,
    EndDate datetime not null
)
go

Digamos que você queira um intervalo para StartDatee EndDate. Então, em outras palavras, se estiver StartDateentre @StartDateBegine @StartDateEnd, e estiver EndDateentre @EndDateBegine @EndDateEnd, então faça alguma coisa.

Eu sei que existem algumas maneiras de provavelmente fazer isso, mas qual é a mais recomendada?

Qual é o melhor design para uma tabela, um Typecampo que é de intou char(1)? Em outras palavras, dado este esquema:

create table Car
(
    Name varchar(100) not null,
    Description varchar(100) not null,
    VehType .... not null
)

É mais eficiente (em termos de desempenho) VehTypeser um intou um char(1)? Digamos que você tenha cinco tipos de carros, você deve usar os valores de incremento 0 -> 4 ou caracteres para os tipos (digamos; 'v', 's', 'c', 't', 'm')?

Se for mais do que isso, eu usaria uma tabela Type separada e teria um relacionamento de chave estrangeira, mas não vejo necessidade disso.

Percebo que a sys.objectsexibição do catálogo usa um caractere para o typecampo. Existe uma razão para isso? Estou apenas agarrando o ar aqui, e é o que quer que eu esteja mais confortável?

Qual é a maneira mais fácil e eficiente de projetar um banco de dados? Do meu ponto de vista, há algumas opções para o design do armazenamento de dados de um aplicativo:

1. Projete o banco de dados da melhor maneira possível antes de escrever qualquer código de aplicativo . Isso lhe dá a vantagem de ter uma estrutura de dados base para trabalhar. A desvantagem disso, na minha opinião, é que você terá muitas alterações como especificidades do aplicativo que afetam o que/onde/como das alterações de dados durante o ciclo de desenvolvimento do aplicativo.
2. Projete o banco de dados à medida que o aplicativo se concretiza . Quando você precisa de alguns objetos de banco de dados enquanto escreve o aplicativo, você desenvolve o banco de dados paralelo (cronologicamente) ao aplicativo. As vantagens seriam menos alterações na estrutura do banco de dados, a meu ver. A desvantagem seria a divisão de tempo e esforço de desenvolvimento entre o código do aplicativo e o desenvolvimento do banco de dados.

Em sua experiência, qual você considera o método mais produtivo e eficiente?

Este problema está realmente provando ser complicado (e bastante irritante).

No SQL Server Management Studio 2008, até alguns dias atrás, meu IntelliSense estava funcionando muito bem. Então, de repente, parou. O ícone está habilitado no menu da barra de ferramentas e, em Ferramentas -> Opções -> Editor de texto -> T-SQL -> IntelliSense, diz que está habilitado lá.

Eu tentei atualizar o cache do IntelliSense com Ctrl-Shft-R, mas isso também não funciona.

Alguma ideia do que aconteceu com o meu IntelliSense e o que preciso fazer para recuperá-lo?

Como desenvolvedor de software e aspirante a DBA, tento incorporar as melhores práticas ao projetar meus bancos de dados do SQL Server (99% do tempo em que meu software fica sobre o SQL Server). Eu faço o melhor design possível antes e durante o desenvolvimento.

Mas, assim como qualquer outro desenvolvedor de software, há funcionalidade adicional, bugs e apenas mudança de requisitos que exigem objetos de banco de dados alterados/criados.

Minha pergunta é: o ajuste de consulta deve ser proativo ou reativo? Em outras palavras, algumas semanas após alguma modificação pesada de código/banco de dados, devo reservar um dia para verificar o desempenho da consulta e ajustar com base nisso? Mesmo que pareça estar funcionando bem ?

Ou devo apenas estar ciente de que o desempenho abaixo da média deve ser uma verificação do banco de dados e voltar ao proverbial quadro-negro?

O ajuste de consulta pode levar muito tempo e, dependendo do design inicial do banco de dados, pode ser um benefício mínimo. Estou curioso quanto ao modus operandi aceito.

Lembro-me de ler este artigo sobre design de banco de dados e também me lembro de dizer que você deve ter propriedades de campo NOT NULL. Eu não me lembro porque este foi o caso embora.

Tudo o que consigo pensar é que, como desenvolvedor de aplicativos, você não precisaria testar NULL e um possível valor de dados inexistente (por exemplo, uma string vazia para strings).

Mas o que você faz no caso de datas, datetime e time (SQL Server 2008)? Você teria que usar alguma data histórica ou de fundo.

Alguma idéia sobre isso?

Muitas vezes todos nós ouvimos a mesma coisa. As recomendações sobre onde colocar os bancos de dados OLAP/OLTP, onde colocar o tempdb , onde colocar os logs de transações... etc.

Mas digamos que você esteja em um ambiente onde a definição física do armazenamento seja um mistério para você. Em outras palavras, com certeza você pode ver as unidades lógicas e pode ligar para o administrador do sistema e pedir mais espaço, mas nunca sabe realmente o que é uma unidade física diferente (digamos que haja uma SAN ou um NAS nos bastidores). Se você não sabe disso de fato, como pode seguir as práticas recomendadas colocando, digamos, o banco de dados tempdb fortemente atingido em uma unidade física diferente?

Qual é a melhor prática neste?