Considerando os recursos de banco de dados a serem usados

Depois que o nível básico de interoperabilidade for conhecido, os recursos de banco de dados usados pelo aplicativo deverão 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 suportados por todos os DBMSs, consulte as descrições da função SQLGetInfo, SQLSetConnectAttr e SQLSetStmtAttr e Apêndice 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 alcançar muitos sistemas de gerenciamento de banco de dados.

Por exemplo, se os recursos necessários forem simples, eles geralmente poderão ser implementados com um alto grau de interoperabilidade. Um aplicativo que executa uma instrução SELECT simples e recupera resultados com um cursor somente de encaminhamento provavelmente será altamente interoperável em virtude de sua simplicidade: quase todos os drivers e DBMSs dão suporte à funcionalidade necessária.

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

• Menor interoperabilidade, mais recursos. O aplicativo inclui os recursos, mas funciona apenas com DBMSs que dão suporte a eles.

• 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 disponibiliza apenas com os DBMSs que dão suporte a eles.

• Maior interoperabilidade, mais recursos. O aplicativo utiliza os recursos em SGDBs que os suportam e os emula em SGDBs que não o fazem.

Os dois primeiros casos são relativamente simples de implementar, pois os recursos são usados com todos os DBMSs compatíveis ou sem nenhum. Os dois últimos casos, por outro lado, são mais complexos. Em ambos os casos, é necessário verificar se o DBMS dá suporte aos recursos e, no último caso, gravar 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 pode 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 tenha um recurso que permite que os usuários exibam 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 dão suporte apenas a uma única instrução ativa.

O aplicativo tem várias opções, com base no que o driver retorna para a opção SQL_MAX_CONCURRENT_ACTIVITIES no SQLGetInfo:

• Sempre dê 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 der suporte a apenas uma instrução ativa, o aplicativo fechará a conexão e informará ao usuário que o driver não dá suporte à funcionalidade necessária. O aplicativo é fácil de implementar e tem funcionalidade completa, mas tem menor interoperabilidade.

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

• Dê suporte a várias consultas somente se o driver fizer isso. 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 quando uma já estiver ativa somente se o driver der suporte a várias instruções ativas. O aplicativo tem maior funcionalidade e interoperabilidade, mas é mais difícil de implementar.

• Sempre dê suporte a várias consultas e emule-as 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 quando uma já estiver ativa. Se o driver der 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.