Projeto de arquitetura 4D: um guia completo

O projeto arquitetônico 4D é o processo de estruturação de um banco de dados 4D (suas tabelas, campos, relacionamentos, índices e níveis de acesso) para que a aplicação permaneça rápida, sustentável e segura à medida que cresce. Um esquema 4D bem planejado normalmente envolve cinco decisões principais: granularidade da tabela, estratégia de relacionamento, tipo de chave primária, localização do índice e separação de dados da lógica de interface. Fazer isso direito desde o início ajudará você a evitar migrações dispendiosas no futuro.

Principais conclusões

• O desenho da arquitetura 4D separa três preocupações: o modelo de dados (tabelas, campos, relações), a camada de lógica de negócios (métodos, classes, gatilhos) e a camada de apresentação (formulários, caixas de listagem, diálogos).
• O tipo de relação é mais importante do que a contagem de tabelas: um link muitos para muitos precisa de uma tabela de junção, enquanto um link um para muitos usa um campo de chave estrangeira mais uma relação.
• Índices aceleram leituras, mas tornam as gravações mais lentas — indexe chaves estrangeiras e qualquer campo usado na cláusula WHERE de uma consulta, não todos os campos.
• A camada ORDA (Object Relational Data Access) de 4D muda a maneira como você pensa sobre o esquema: tabelas e campos bem nomeados tornam-se classes de dados e nomes de atributos legíveis no código.
• A implantação cliente-servidor versus implantação de usuário único é uma decisão arquitetônica, não uma reflexão tardia da implantação — ela afeta o bloqueio, o armazenamento em cache e o modo como você escreve consultas.
• As convenções de nomenclatura aplicadas consistentemente desde o primeiro dia economizam mais tempo de refatoração do que qualquer outro hábito único.

O que significa “arquitetura 4D” em um contexto de banco de dados

O desenho da arquitetura 4D refere-se ao desenho estrutural de uma aplicação construída na plataforma 4D (4th Dimension), o banco de dados relacional e ambiente de desenvolvimento low-code originalmente lançado pela equipe de Laurent Ribardière em 1984 e agora mantido por 4D SAS. Ao contrário de um banco de dados SQL puro, 4D agrupa o motor de dados, uma linguagem de programação, um designer de formulários e um servidor web/REST em um único produto — portanto a “arquitetura” aqui abrange tanto o esquema quanto as camadas de aplicação que estão sobre ele.

O termo é por vezes confundido com visualização arquitetônica (BIM 4D, tempo como quarta dimensão no projeto de edifícios). Este guia aborda o sentido do software: como organizar um banco de dados 4D e suas camadas de aplicação. Se você chegou em busca de projeto de construção, os conceitos abaixo não se aplicam.

As três camadas de uma aplicação 4D

Os projetos de design de arquitetura 4D se beneficiam de um modelo explícito em camadas. A divisão de responsabilidades evita que um aplicativo em crescimento se transforme em um emaranhado de scripts de formulário.

Camada 1 — O modelo de dados

O modelo de dados é o conjunto de tabelas, campos, relações e índices armazenados no arquivo de estrutura 4D. Essa camada não deve conter nenhum código de interface do usuário e nenhuma regra de negócios que possa existir em outro lugar. Os tipos de campo (texto, inteiro, real, data, hora, booleano, blob, objeto, imagem) e comprimentos de campo são fixos aqui, e alterá-los posteriormente em um banco de dados ativo requer cuidado.

Camada 2 — Lógica de Negócios

A lógica de negócios reside em métodos de projeto, classes e gatilhos de tabela. Em 4D moderno, as classes (introduzidas com 4D v18 R3 e expandidas desde então) permitem escrever código reutilizável e testável em vez de espalhar a lógica pelos métodos de formulário. Um gatilho em uma tabela é acionado ao criar, salvar e excluir — útil para trilhas de auditoria, mas um gatilho que chama a interface do usuário falhará em contextos de servidor headless.

Relacionado: Airtable — Uma interface simples de planilha baseada em um banco de dados relacional real, com automações, visualizações e interfaces compartilháveis..

Camada 3 — Apresentação

A apresentação abrange formulários, caixas de listagem, caixas de diálogo de entrada e qualquer saída web ou REST. Formulários 4D vinculam-se diretamente a campos e variáveis, o que é conveniente, mas incentiva a colocação de lógica no formulário. Manter os métodos de formulário enxutos - chamar um método de classe e exibir o resultado - é a maior vitória em termos de manutenção na maioria dos projetos 4D.

Projetando o modelo de dados: tabelas, relações e chaves

As decisões de modelagem de dados no projeto de arquitetura 4D seguem princípios relacionais, com mecânicas específicas de 4D em camadas.

Escolhendo a granularidade da tabela

Uma tabela deve representar um tipo de entidade. Dividir uma tabela “cliente” em “cliente” e “endereço_cliente” faz sentido quando um cliente pode ter vários endereços; mesclá-los faz sentido quando há exatamente um endereço por cliente e não há reutilização. A normalização excessiva em muitas tabelas pequenas aumenta o número de relações e junções, o que prejudica o desempenho nas visualizações de lista.

Se você estiver comprando: Zoho Creator — Um construtor de aplicativos de baixo código que se conecta ao conjunto Zoho mais amplo e tem preços por usuário, e não por aplicativo..

Tipos de relacionamento

4D suporta relações automáticas definidas no editor de estrutura e relações manuais criadas em código. Os padrões comuns:

Relação	Implementação 4D	Uso típico
Um para muitos	Campo de chave estrangeira no lado “muitos” mais uma relação	Fatura → Linhas de fatura
Muitos para muitos	Tabela de junção com duas chaves estrangeiras	Produtos ↔ Fornecedores
Um para um	Chave primária compartilhada ou chave estrangeira única	Usuário → Perfil do usuário
Auto-referência	Chave estrangeira apontando de volta para a mesma tabela	Funcionário → Gerente

Estratégia de chave primária

4D oferece chaves primárias de inteiro longo com incremento automático e chaves primárias UUID (texto). As chaves Longint são compactas e rápidas de indexar; Os UUIDs são globalmente únicos, o que é importante ao mesclar dados de vários sites ou sincronizar com sistemas externos. Um compromisso comum é uma chave interna de inteiro longo mais um campo de texto de “referência externa” exclusivo e separado.

Indexação e desempenho de consulta

Os índices são a alavanca de desempenho de maior aproveitamento no projeto de arquitetura 4D e também os mais fáceis de aplicar em excesso.

O que indexar

Indexe qualquer campo usado como chave estrangeira de uma relação, qualquer campo usado frequentemente nos critérios de pesquisa de uma consulta e qualquer campo usado para classificação em caixas de listagem grandes. 4D suporta índices de árvore B padrão, índices de palavras-chave para pesquisa de texto baseada em palavras e índices compostos que cobrem múltiplos campos.

O que não indexar

Cada índice adiciona custo de gravação e armazenamento. Indexar um campo booleano com dois valores possíveis raramente ajuda. A indexação de um campo que só é lido como parte de uma exibição de registro completo adiciona sobrecarga sem nenhum ganho. Revise os índices depois que o aplicativo tiver padrões de uso reais, em vez de adivinhar antecipadamente.

Estratégia de consulta

Consultas ORDA (ds.Invoice.query("Status = :1"; "Open")) são geralmente preferíveis aos comandos QUERY clássicos para novo código porque retornam seleções de entidades que podem ser classificadas, filtradas e passadas entre métodos sem nova consulta. Para tabelas muito grandes, restringir a consulta com critérios indexados antes de aplicar filtros não indexados mantém os tempos de resposta previsíveis.

Relacionado: Knack — Um construtor de banco de dados sem código voltado para portais, diretórios e ferramentas internas — com preços fixos em vez de taxas por usuário..

ORDA e arquitetura 4D moderna

ORDA (Object Relational Data Access) é a camada de acesso a dados orientada a objetos de 4D, introduzida em 4D v17. Ele expõe tabelas como classes de dados e registros como entidades, então uma tabela chamada Invoice se torna ds.Invoice e um campo chamado TotalNet se torna $invoice.TotalNet.

Isto tem uma consequência arquitetônica para o projeto de arquitetura 4D: nomes de tabelas e campos agora fazem parte de sua API pública. Renomear um campo quebra o código de uma forma que fica visível em tempo de compilação, mas a nomenclatura inconsistente torna o código ORDA difícil de ler. Adotar uma convenção – nomes de tabelas singulares, campos PascalCase, sem abreviações – compensa imediatamente.

ORDA também oferece suporte a seleções de entidades do lado do cliente que são carregadas apenas parcialmente, o que altera o perfil de desempenho das telas de lista. Uma caixa de listagem vinculada a uma seleção de entidade pode exibir milhares de linhas sem carregar todos os registros, assumindo que a consulta por trás dela esteja indexada.

Nossa escolha: Claris FileMaker Pro — A plataforma de banco de dados relacional de longa duração para equipes que precisam de aplicativos personalizados em desktop, web e dispositivos móveis a partir de um único arquivo..

Cliente-servidor, usuário único e implantação na Web

A topologia de implantação molda o design da arquitetura 4D mais do que muitos desenvolvedores esperam.

Aplicativos de usuário único executam o mecanismo de dados e a interface em um processo. O bloqueio é trivial; o ajuste de desempenho envolve principalmente a velocidade do disco local.

Cliente-servidor separa o 4D Server (motor de dados) do 4D Client (interface). Os registros são bloqueados no servidor e o custo de ida e volta da rede de cada consulta torna-se significativo. Arquiteturas que emitem muitas consultas pequenas por tela apresentam desempenho ruim aqui; agrupar consultas em lote e usar seleções de entidade reduz as viagens de ida e volta.

A implantação Web e REST expõe o mesmo modelo de dados através do servidor REST de 4D ou através de métodos web compilados. A segurança passa para o primeiro plano: o acesso a tabelas e campos deve ser restrito por meio de funções e privilégios, e qualquer regra de negócios aplicada apenas em um método de formulário é efetivamente não aplicada para clientes da Web.

Convenções de nomenclatura e documentação

A nomenclatura consistente não é glamorosa, mas é decisiva para o projeto de arquitetura 4D. Uma convenção viável para 4D:

• Tabelas: Substantivos singulares, PascalCase (“Cliente”, “InvoiceLine”).
• Campos: PascalCase, sem prefixos de tipo (“InvoiceDate”, não “dInvDate”).
• Relacionamentos: nomeados de acordo com a tabela de destino (“Customer_Invoices”).
• Métodos: verbo primeiro (“CreateInvoice”, “RecalculateTotals”).
• Classes: Substantivo primeiro (“InvoiceService”, “TaxCalculator”).

Documentar o esquema – mesmo como um único arquivo Markdown listando cada tabela, sua finalidade e suas principais relações – facilita muito a integração e as migrações futuras. O editor de estrutura de 4D mostra as relações graficamente, mas não explica por que existe uma tabela.

Erros comuns de design de arquitetura 4D

Colocando lógica de negócios em métodos de formulário. Os métodos de formulário não podem ser chamados de contextos da web ou tarefas agendadas, portanto, a lógica presa lá deve ser duplicada.

Uso de comandos clássicos baseados em seleção em todo o novo código. As seleções clássicas são vinculadas ao processo e não transitam bem entre os processos; As seleções de entidades ORDA são mais flexíveis.

Ignorando a tabela de junção. Armazenar vários valores em um único campo de texto (IDs separados por vírgula) anula a indexação e torna os relatórios complicados.

Indexando tudo. O desempenho de gravação diminui e o benefício raramente é percebido.

Ignorar privilégios até a implantação. Adaptar um modelo de segurança em um aplicativo finalizado é significativamente mais difícil do que projetá-lo junto com o esquema.

Como decidir: uma lista de verificação prática

Antes de construir seu projeto de arquitetura 4D, resolva estas questões:

1. Quantos usuários simultâneos e eles se conectarão através de uma LAN, WAN ou web?
2. Quais entidades têm um relacionamento natural um-para-muitos e quais precisam de tabelas de junção?
3. Quais campos aparecerão nos critérios de pesquisa ou nas ordens de classificação em tabelas grandes?
4. Quais regras de negócios devem ser válidas independentemente do ponto de entrada (formulário, web, importação)?
5. Os dados serão mesclados com outro sistema, exigindo chaves UUID?
6. Quem manterá isso daqui a dois anos e a nomenclatura fará sentido para eles?

As respostas a estas seis perguntas determinam a maioria das decisões estruturais em um projeto 4D.

Leitura Adicional

A documentação oficial 4D em developer.4d.com cobre detalhadamente ORDA, classes, privilégios e implantação. Para conhecer os fundamentos da modelagem relacional que se aplicam independentemente da plataforma, consulte o artigo da Wikipédia sobre normalização de banco de dados. Para o contexto mais amplo de plataformas de desenvolvimento rápido e de baixo código, a entrada da Wikipedia sobre plataformas de desenvolvimento de baixo código é um ponto de partida razoável. 4D SAS também publica notas de lançamento e guias de migração que descrevem quando ORDA, classes e outros recursos de design de arquitetura 4d foram introduzidos.

Perguntas frequentes

O que é projeto de arquitetura 4D?

O desenho da arquitetura 4D é o processo de planejamento da estrutura de uma aplicação 4D (4ª Dimensão): suas tabelas, campos, relações, índices, camada de lógica de negócio e camada de apresentação. Ele determina o desempenho do aplicativo, a facilidade com que pode ser alterado e o grau de segurança com que pode ser implantado em desktops, cliente-servidor ou clientes da Web.

A arquitetura 4D é igual ao BIM 4D?

Não. O 4D BIM adiciona o tempo como uma quarta dimensão à modelagem de informações de construção para o planejamento da construção. A arquitetura 4D no sentido de software refere-se ao design de aplicações na plataforma de banco de dados 4D. Os dois campos compartilham uma abreviatura, mas nada mais.

Devo usar comandos ORDA ou 4D clássicos?

ORDA é a melhor opção para novos desenvolvimentos. Ele retorna seleções de entidades que podem ser passadas entre métodos, classificadas e filtradas sem a necessidade de serem consultadas novamente e expõe tabelas e campos como propriedades de objetos legíveis. Os comandos clássicos baseados em seleção ainda são úteis em código legado e em alguns casos especiais.

Quantos índices deve ter uma tabela 4D?

Não existe um número fixo. Indexe chaves estrangeiras, campos usados ​​em critérios de pesquisa comuns e campos usados ​​para classificar listas grandes. Evite indexar campos com baixa cardinalidade, como valores booleanos ou campos de status com dois ou três valores, pois o custo de gravação geralmente supera o benefício de leitura.

Que tipo de chave primária devo escolher em 4D?

As chaves longint com incremento automático são compactas e rápidas e atendem a aplicações em um único local. As chaves de texto UUID são maiores, mas globalmente exclusivas, o que é importante ao mesclar dados de vários sites ou integrar com sistemas externos. Muitos projetos usam uma chave longint internamente, além de um campo de referência externo exclusivo.

Posso mudar o modelo de dados 4D após a implantação?

Sim, mas com cuidado. Adicionar tabelas, campos e índices geralmente é simples. Alterar tipos de campos, renomear campos usados ​​pelo código ORDA ou reestruturar relações em um banco de dados ativo requer uma migração planejada, idealmente testada primeiro em uma cópia dos dados de produção.