Considerar os recursos de banco de dados a serem usados

Depois de conhecer o nível básico de interoperabilidade, os recursos do banco de dados usados pelo aplicativo devem ser considerados. Por exemplo, quais instruções SQL o aplicativo executará? O aplicativo usará cursores roláveis? Transações? Procedimentos? Dados Longos? Para obter ideias sobre quais recursos podem não ser compatíveis com todos os DBMSs, consulte as descrições das funções SQLGetInfo, SQLSetConnectAttr e SQLSetStmtAttr e o Apendice C: Gramática SQL. Os recursos exigidos por um aplicativo podem eliminar alguns DBMSs da lista de DBMSs de destino. Eles também podem mostrar que o aplicativo pode facilmente segmentar muitos DBMSs.

Por exemplo, se os recursos necessários são simples, eles geralmente podem ser implementados com um alto grau de interoperabilidade. Um aplicativo que executa uma simples instrução SELECT e recupera resultados com um cursor de somente avanço provavelmente será altamente interoperável por conta de sua simplicidade: quase todos os drivers e DBMSs são compatíveis com a funcionalidade de que precisam.

No entanto, se os recursos necessários forem mais complexos, como cursores roláveis, instruções de exclusão e atualização posicionadas e procedimentos, geralmente devem ser feitas compensações. Há várias possibilidades:

• Menor interoperabilidade, mais recursos. O aplicativo inclui os recursos, mas funciona apenas com DBMSs compatíveis.

• Maior interoperabilidade, menos recursos. O aplicativo descarta os recursos, mas funciona com mais DBMSs.

• Maior interoperabilidade, recursos opcionais. O aplicativo inclui os recursos, mas os torna disponíveis apenas com DBMSs compatíveis.

• Maior interoperabilidade, mais recursos. O aplicativo usa os recursos com DBMSs compatíveis e os emula para DBMSs que não são compatíveis.

Os dois primeiros casos são relativamente simples de implementar, porque os recursos são usados com todos os DBMSs compatíveis ou com nenhum. Os dois últimos casos, por outro lado, são mais complexos. Em ambos os casos, é necessário verificar se o DBMS é compatível com os recursos e, no último caso, é necessário escrever uma quantidade potencialmente grande de código para emular esses recursos. Portanto, esses esquemas provavelmente exigirão mais tempo de desenvolvimento e podem ser mais lentos em tempo de execução.

Considere um aplicativo de consulta genérico que consegue se conectar a uma única fonte de dados. O aplicativo aceita uma consulta do usuário e exibe os resultados em uma janela. Agora, suponha que este aplicativo possui um recurso que permite aos usuários exibir os resultados de várias consultas simultaneamente. Ou seja, eles podem executar uma consulta e examinar alguns dos resultados, executar uma consulta diferente e examinar alguns de seus resultados e, em seguida, retornar à primeira consulta. Isso apresenta um problema de interoperabilidade porque alguns drivers oferecem suporte a apenas uma única instrução ativa.

O aplicativo possui várias escolhas com base no que o driver retornar para a opção SQL_MAX_CONCURRENT_ACTIVITIES em SQLGetInfo:

• Sempre oferecer suporte a várias consultas. Depois de se conectar a um driver, o aplicativo verifica o número de instruções ativas. Se o driver oferece suporte a apenas uma instrução ativa, o aplicativo fechará a conexão e informará ao usuário que o driver não oferece suporte à funcionalidade necessária. O aplicativo é fácil de implementar e tem funcionalidade completa, mas tem menor interoperabilidade.

• Nunca oferecer suporte a várias consultas. O aplicativo descarta o recurso completamente. É fácil de implementar e tem alta interoperabilidade, mas tem menor funcionalidade.

• Oferecer suporte a várias consultas somente se driver permitir. Depois de se conectar a um driver, o aplicativo verifica o número de instruções ativas. O aplicativo permite que o usuário inicie uma nova instrução enquanto uma já estiver ativa somente se o driver oferecer suporte a várias instruções ativas. O aplicativo tem maior funcionalidade e interoperabilidade, mas é mais difícil de implementar.

• Sempre oferecer suporte a várias consultas e emulá-las quando necessário. Depois de se conectar a um driver, o aplicativo verifica o número de instruções ativas. O aplicativo sempre permite que o usuário inicie uma nova instrução enquanto uma já estiver ativa. Se o driver oferecer suporte a apenas uma instrução ativa, o aplicativo abrirá uma conexão adicional com esse driver e executará a nova instrução nessa conexão. O aplicativo tem funcionalidade completa e alta interoperabilidade, mas é mais difícil de implementar.