Como Adicionar uma Base de Dados à Sua App (Sem Perder Dados Mais Tarde)

Para adicionar uma base de dados à sua app, escolha uma base de dados relacional gerida (o Postgres é a predefinição habitual), guarde a sua string de ligação num segredo do lado do servidor, crie uma tabela por cada tipo de coisa que a app guarda, e faça com que o seu backend — nunca o navegador — leia e escreva nela. Se criar com um construtor de apps com IA, normalmente basta dizer "guarda isto numa base de dados" e o agente configura as tabelas e o código; o seu papel é descrever bem os dados e verificar que ficam de facto guardados.

Este guia explica quando precisa de uma base de dados, as principais opções, como descrever os seus dados e os erros que causam perda ou fuga de dados.

Quando a sua app precisa de uma base de dados

Precisa de uma base de dados quando a sua app tem de lembrar algo depois de a página ser fechada, ou partilhar dados entre pessoas. Sinais típicos:

• Os visitantes enviam algo: um formulário, um registo, uma marcação, uma encomenda
• Os utilizadores têm contas com conteúdo guardado próprio
• Um administrador precisa de ver ou editar o que os outros criaram
• Quer relatórios ou contagens ao longo do tempo

Não precisa de uma para um site estático onde todos veem o mesmo conteúdo, como um portefólio ou uma página de destino simples. Se não tiver certeza do que é uma base de dados, leia primeiro o que é uma base de dados.

As suas opções

Para a maioria das pequenas e médias apps web, uma base de dados relacional como o Postgres é a escolha certa por defeito. É boa em relações (um cliente tem várias encomendas), mantém os dados consistentes e permite responder a perguntas mais tarde com SQL. Veja o que é o Postgres para uma visão geral em linguagem simples.

Descreva os seus dados antes de construir

O mais útil que pode fazer é escrever as coisas que a sua app guarda e como se ligam. Não precisa de jargão de bases de dados. Numa app de marcações:

• Clientes: nome, email, telefone
• Serviços: nome, duração, preço
• Marcações: qual cliente, qual serviço, hora de início, estado (pendente, confirmada, cancelada)

São três tabelas. "Qual cliente" e "qual serviço" tornam-se ligações (chaves estrangeiras) entre elas. Acertar nisto cedo importa muito mais do que qualquer escolha tecnológica, porque mudar a forma de dados que já têm linhas reais é mais difícil do que mudar o layout de uma página.

Algumas regras práticas:

• Uma tabela por tipo de coisa. Não meta encomendas numa coluna de texto do cliente.
• Dê a cada linha um ID e uma data de criação. Vai precisar de ambos mais tarde.
• Use tipos adequados. Datas como datas, valores monetários como cêntimos inteiros ou tipo decimal, não como texto.
• Marque os campos obrigatórios como obrigatórios. Deixe a base de dados rejeitar dados errados, e não apenas o formulário.

Prompts de exemplo

Comece com uma funcionalidade de cada vez, em vez de despejar um esquema completo:

Adicione uma base de dados a esta app. Crie uma tabela de marcações com nome do cliente, email, serviço, hora de início e estado (pendente, confirmada, cancelada; por defeito pendente). Guarde nela os envios do formulário de marcação, mostre uma mensagem de sucesso e adicione uma página de administração que liste as marcações da mais recente para a mais antiga.

Depois alargue-a:

Adicione uma tabela de serviços (nome, duração em minutos, preço em cêntimos). Substitua o campo de texto livre do serviço nas marcações por uma ligação à tabela de serviços, e migre as marcações existentes sem apagar nenhuma.

E depois aperte-a:

Certifique-se de que todas as leituras e escritas na base de dados acontecem no servidor. O navegador nunca deve receber a string de ligação à base de dados. Valide o email e a hora de início no servidor antes de inserir.

Passo a passo

1. Liste os seus dados como acima: coisas, campos, ligações entre elas.
2. Crie a base de dados. Num construtor de IA, peça-a no chat. Noutro sítio, crie uma instância Postgres gerida e copie a sua string de ligação.
3. Guarde a string de ligação como segredo (uma variável de ambiente no servidor), nunca no código. Veja variáveis de ambiente e segredos.
4. Crie as tabelas. Use migrações — scripts versionados que alteram o esquema — para que as mudanças sejam repetíveis e reversíveis.
5. Construa as rotas do servidor que criam, leem, atualizam e apagam linhas (CRUD). O navegador chama estas rotas; nunca fala diretamente com a base de dados.
6. Ligue a interface a essas rotas: formulários que guardam, listas que carregam, estados vazios quando ainda não há nada.
7. Teste a persistência. Envie algo, recarregue a página, abra num navegador diferente. Se os dados não estiverem lá, não foram guardados na base de dados.
8. Verifique o acesso. Inicie sessão com um segundo utilizador e confirme que não consegue ver nem editar os dados do primeiro.
9. Publique e teste de novo no URL em produção, porque a app publicada pode usar uma ligação diferente da de pré-visualização.

Erros comuns

• Guardar no navegador e achar que está guardado. O localStorage parece funcionar até alguém abrir a app noutro dispositivo. Teste sempre num segundo navegador.
• Pôr a string de ligação no código do front-end. Qualquer pessoa pode ler o código do front-end. Isso dá-lhe acesso a toda a sua base de dados.
• Sem verificações de acesso. "Mostrar as minhas encomendas" tem de filtrar pelo utilizador com sessão iniciada no servidor, e não na interface. É a falha de segurança mais comum em apps criadas com IA; a nossa lista de verificação de segurança cobre-a.
• Alterações destrutivas ao esquema. Pedir para "mudar o nome da tabela" ou "alterar a estrutura" pode apagá-la e recriá-la. Quando existem dados reais, diga "migre as linhas existentes, não apague nada".
• Guardar ficheiros na base de dados. Imagens e PDFs pertencem ao armazenamento de ficheiros, com apenas o URL ou a chave numa tabela. Veja como adicionar carregamento de ficheiros.
• Sem cópias de segurança. Saiba como a sua plataforma faz cópias de segurança e como as restaurar antes de ter clientes.

Lista de verificação

• Cada tipo de coisa tem a sua tabela com ID e data de criação
• Campos obrigatórios e tipos são impostos pela base de dados
• A string de ligação vive apenas em segredos do servidor
• Todas as leituras e escritas passam por rotas do servidor
• Cada utilizador só consegue ler e alterar as suas próprias linhas
• Os dados sobrevivem a um recarregamento e aparecem noutro navegador
• As alterações ao esquema usam migrações e mantêm as linhas existentes
• Sabe como funcionam as cópias de segurança e as restaurações
• A app em produção foi testada depois de publicada

Adicionar uma base de dados no Mythex

No Mythex, cada projeto pode ter a sua base de dados Postgres dedicada, tanto no Free como no Pro. Normalmente não precisa de clicar num botão separado de "ligar": peça no chat ("guarda os emails da lista de espera numa base de dados") ou escreva /database, e os dados de ligação são injetados no espaço de trabalho e na sua app publicada. As definições do projeto mostram se há uma base de dados ativa.

A base de dados adormece após 5 minutos de inatividade e acorda no próximo pedido. A utilização publicada é cobrada pelo tempo em que esteve efetivamente acordada, a partir do mesmo saldo de créditos que usa para construir. Se adicionar uma base de dados depois de já ter publicado, publique de novo para que a app em produção a apanhe.

Veja Base de dados e a receita Criar uma app CRUD na documentação. Para o lado do início de sessão nos dados por utilizador, leia como adicionar início de sessão à sua app.

Perguntas