Árvore de páginas

Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.

Índice

Índice
maxLevel4
outlinetrue
exclude.*ndice
stylenone

Objetivo


O objetivo deste documento é descrever e diferenciar os tipos de armazenamento de dados de formulários na base do fluig.


Definição do Modelo de Armazenamento


O modelo de armazenamento é definido pelo desenvolvedor durante a exportação do formulário através do fluig Studio. Esta opção só é exibida ao exportar um novo formulário para o servidor.

Na imagem abaixo são exibidos os dois modelos disponíveis:

  • "Numa única tabela (para pequenas quantidades de registros)", também chamado de modelo "Registros de formulário (Tabela única)".
  • "Tabelas de Banco de Dados (recomendado)", também chamado de "Meta Lista (Tabelas múltiplas)".


Tabelas de Banco de Dados (recomendado)


Um formulário configurado para armazenar seus dados em tabelas múltiplas, quando exportado criará uma nova tabela no banco de dados cujo nome seguirá o padrão MLEEELLL, onde EEE representa o código da empresa precedido por zeros e LLL representa o código da lista (gerado de forma sequencial pela plataforma) também precedido por zeros.

Informações
titleExemplo

Se o código da empresa for "1" e já foram criados 20 formulários previamente, o próximo formulário criado (de nº 21) irá gerar a tabela ML001021.

Os registros destes formulários também serão separados em Meta Listas filhas, que seguirão o mesmo padrão de criação e serão relacionadas através da tabela META_LISTA_REL.

O modelo de tabelas múltiplas, por segmentar os dados dos formulários e tornar mais eficiente a consulta a estes registros, é o modelo recomendado e também o padrão para a exportação de novos formulários para o servidor fluig.


Numa única tabela (para pequenas quantidades de registros)


Um formulário configurado para armazenar seus dados em tabela única terá as informações de cada registro gravadas na tabela FICHA do banco de dados. Por acumular muitos registros rapidamente, dependendo do fluxo de uso dos formulários e das solicitações que os utilizam, esse modelo é pouco eficiente e não é recomendado para a construção de formulários atualmente, sendo mantido seu suporte para situações específicas e para manter formulários importados de versões anteriores. Quando se utiliza formulários pai x filho, também não é recomendado a configuração para utilização de tabela única, pois o filtro de registros (query constrains) não trará como resultado os registros do formulário filho.