Visão geral

O sistema foi desenvolvido em duas partes: código na forma de stored procedures 6.1.5 e scripts PHP.
Não foi utilizada orientação a objetos. Ao invés disso, foi criada uma estrutura de diretórios e um conjunto de scripts que realizavam ações bem simples.
Estrutura de diretórios:

ajuda:

Contém as páginas de ajuda.

alterar:

Contém scripts que executam ações como: salvar, alterar, remover dados, além de ações que alteram o estado de uma solicitação: aceitar, rejeitar, etc.

documentação:

Documentação do sistema, incluindo o código que está no banco de dados.

buscas:

As telas personalizadas de busca. Cada listagem possui uma tela de busca.

detalhes

Telas com informações detalhadas sobre pessoas, solicitações e projetos.

imagens

Figuras do sistema.

listagens

Telas de listagens de pessoas, solicitações e projetos.

misc

Tela de login, controle de acessos, além do javascript de ordenação.

novos

Telas de cadastro de novas pessoas e solicitações.

relatórios

Telas com os relatórios.

utils

Alguns scripts com funções de apoio.

É possível notar que esta divisão hierárquica facilitava bastante a localização dos scripts que compunham o sistema. Por exemplo: o script que apaga uma solicitação está localizado no diretório alterar, o que exibe uma lista com as solicitações, por sua vez, deve estar no diretório listagens, e assim por diante.
Além dos scripts php temos uma série de stored procedures, triggers e views que estão no Sybase.
As justificativas para o uso de stored procedures foram:

Transações

Permitem a criação de transações. Assim, ações que envolvem vários passos podem ser desfeitas caso um erro ocorra em algum deles.

Concorrência

Utilizando um esquema de ``locks''³ corretos, chamadas concorrentes às stored procedures são gerenciadas pelo Sybase.

Isolamento

O cliente não executa ações diretamente sobre as tabelas, ao invés disso, executa stored procedures que fazem este serviço.
Desta maneira, as tabelas podem ser alteradas sem que o cliente altere seu código. Além disso, como o cliente não pode alterar as
tabelas diretamente, podemos garantir maior consistência dos dados bastando, para isso, codificar corretamente as stored procedures.

A validação dos dados foi feita totalmente no Sybase utilizando constraints e triggers.
Esta abordagem foi utilizada por exigir menos codificação no cliente⁴ e para permitir que mesmo outros sistemas usem as stored procedures do MetaNaeg, sem que os dados sejam corrompidos.

... ``locks''³

Os ``locks'' são feitos nas tabelas que as stored procedures manipulam.

... cliente⁴

Aplicação que interage com as stored procedures.