Olá Rodolfo e PCC !

Só um adendo, sugiro que vc continue usando os campos lógicos como vem fazendo 0 e 1, porque com o CA vc tem uma flexibilidade muito grande em trabalhar com outros bancos, alterando apenas a conexão. Então quanto mais genérico for sua estrutura de dados e de consulta menos código vc precisará alterar p/ usar outros bancos !
O campo bit que existe no SQL Server, não existe em todos os bancos !

Para quem fornece softwaresa comerciais é uma boa prática, porque as vezes o novo cliente já tem um banco em produção e não faz sentido ele mudar o banco por causa de uma aplicação, então ele escolhe outra solução.

Caso vc desenvolva apenas para uma empresa que só vai usar um banco (pelo menos por um bom tempo ), você deve usar todos os recursos que o banco lhe oferece !

Uma outracoisa é vc usar uma ferramenta de modelagem que gera o script para vários banco !

No mais concordo com o PCC !



>Rodolfo,
>
>Ainda não sou nenhum "Fera" no SQL Server, mas vamos ver em que posso ajudar, pois só trabalho com ele a cerca de 6 meses.
>
>
>>Poucos Registros
>>Atualmente, quando o usuário entra no formulário de clientes, eu abro uma grade com todos os clientes. Então ele se movimenta na grade e pressiona ENTER para abrir a ficha daquele determinado registro.
>>Sei que não posso fazer isto usando SQL, pois preciso filtrar alguns registros. Como posso criar uma interface eficiente usando SQL? Pensei em filtrar pelo Nome ou CNPJ do cliente.
>
>

>Dê preferencia a fazer uma consulta baseado em uma coluna que contenha um indice.
>

>
>>
>>
>>Tipo de Dados
>>No DBC eu uso apenas 3 tipos de dados: Caracter, Numerico e Data. Para campos lógicos, utilizo a estrutura Numeric (0 = falso, 1 = verdadeiro). Vi que no SQL, temos vários tipos. Posso continuar usando esses mesmos 3 tipos ou é melhor utilizar um campo específico (questão de performance, segurança, normalização). Vou mostrar alguns exemplos que uso em VFP e gostaria de sugestões para converte-los no SQL:
>>Nome - Caracter 50
>

>Char(50)
>

>
>>Sexo - Caracter 1 (M ou F)
>

>CHAR(1)
>

>>Inativo - Numerico 1 (0=Ativo, 1=Inativo)
>

>Bit
>

>
>>Quantidade - Numerico 7 (de +999999 a -999999)
>

>Se for somente números Inteiros, utilize Int.
>

>
>
>>Valor Unitário - Numerico 12,3
>

>Voce Pode Usal Decimal(12,3), quando vc utiliza o Wizard do VFP para fazer a Migração ele coloca como Float.
>

>
>>Aniversário - Data 8
>

>Uso DateTime, porque o VFP também tem este tipo de dado.
>

>
>>
>>
>>Chave Primária
>>No DBC eu tenho um campo INTEGER que é sequencial. Tenho uma função que trava o registro, soma mais 1 no último e atualiza a chave primária do registro.
>>No SQL Server, vi que posso utilizar um campo IDENTITY ou GUID. As vantagens do IDENTITY é ser gerado automaticamente e ocupar menos espaço no banco. O GUID deve ser gerado através de uma função e ocupa mais espaço no banco, porém é único e pode ser muito útil para replicação.
>

>Uso somente o Identity.
>

>
>>
>>
>>Página de caracteres
>>Como ficam os acentos no SQL Server? No DBC eu uso SET COLLATE TO "GENERAL". No SQL tem alguma coisa parecida?
>>Além disso, se eu for pesquisar JOÃO e no banco de dados estiver JOAO, o SQL reconhece isso?
>>
>>
>>Índices
>>Os índices podem ser Clustered ou Non-Clustered. Vale a pena usar o índice Clustered?
>

>Me parece que vc so pode ter um indice Clustered, e quando vc cria uma chave primária é criado automaticamente um indice do tipo Clustered, quando não existe um defenido na tabela.
>

>>
>>
>>Log de Transação
>>Utilizando os triggers, eu construi uma rotina de auditoria em DBC. Vi que o SQL tem um recurso nativo. Funciona bem? Compromete a performance?
>

>Eu utilizo, mas não sei opinar de a performance, é afetada, pois sempre utilizamos os Logs. ( de preferencia em outro HD )
>

>>
>>
>>Begin Transaction / Commit
>>Funciona bem com Cursor Adapter?
>

>Sim, se utilizar o CA com ODBC, vc consegue utilizar as transações do VFP no SQL Server, se usar ADO, você tem que executar os comandos, do sql server.
>

>
>>
>>
>>Replicação / Backup / "Reindex"
>>Vou utilizar as ferramentas do próprio SQL Server, ok? Alguma recomendação?
>

>Uso o E.M.
>

>
>>
>>
>>Instalação do SQL Server
>>A idéia inicial era ter o mesmo sistema acessando DBC e SQL através do Cursor Adapter. Teria apenas um sistema e o usuário escolheria o banco de dados. Mas acho que usando apenas o SQL Server, vou ter um produto final muito mais estável e eficiente.
>>Porém, este produto será instalado em pequenos clientes. Uma máquina apenas, rodando Windows 98, funcionaria com o SQL Server? (neste caso estou pensando em usar o SQL Express...)
>

>O SQL Express, é do SQL 2005, que ainda será lançado oficialmente. Hoje temos somente os betas. Utilize por enquanto o MSDE.
>

>>
>>
>>Criar / Atualizar Banco de Dados
>>Para criar o banco de dados no SQL Server não seria problema... E a atualização da base dos clientes, como pode ser feita?
>

>Por scripts ou pelo E.M.
>

>
>>
>>
>>Tabelas que não mudam no cliente
>>Li um artigo que dizia ser uma boa prática manter tabelas que não mudam na máquina local. Ex: Estados.DBF - Algum comentário a respeito?
>

>Isto é uma técnica que pode ser usada com os DBFs do VFP também. É questão de arquitetura do aplicativo.
>

>
>
>>
>>
>>
>>Integridade
>>Uso o DBC "completo" - Tenho triggers, regras de registro, índices candidatos, etc. No meu sistema, quando tento gravar e existe algum erro, o próprio banco de dados retorna o que está errado. Ex: "Nome não informado" ou "Código do Produto duplicado", etc! Posso fazer algo parecido no SQL Server?
>
>

>Sempre que possível, eu atualizo as tabelas por Stored Procedures, nelas coloco as regras de Negócio.
>

>
>>
>>
>>Conexão
>>Onde eu posso gravar os dados do servidor do SQL, usuário, senha, etc? Internamente no EXE?
>

>Eu utilizo arquivos UDL.
>
>Vc cria um arquivo texto vazio com o nome Meubanco.udl, depois vc executa pelo Windows, e ele vai te pedir as configurações, do BANCO, senha etc..
>
>e através dos dados deste arquivo acesso o banco. Mas note que não gravo a senha no arquivo.
>
>

>>
>>
>>Segurança
>>Crio um usuário genérico para todos os usuários ou um usuário no SQL para cada usuário do sistema?
>>Atualmente eu tenho uma tabela de usuários com as permissões de cada um: Pesquisar Cliente, Incluir Cliente, Alterar Cliente, Excluir Cliente, etc... E também algo do tipo: Desconto máximo permitido, etc.
>>No SQL Server, vou manter esse mesmo esquema, certo?
>

>Não vejo problemas para isto.
>

>>
>>
>>
>>bom, é "só" isso... :-)
>
>
>
>
>Não sei muito, mas espero ter ajudado.