Normas do Banco de Dados AMADIS

Da AMADIS

Índice

Tabelas

Nomenclatura

Todos nomes, tanto de tabelas deverão ser escritos em Inglês, para que possa facilitar a compreensão por desenvolvedores de outros países que, eventualmente, podem vir a colaborar com o projeto. Os comentários inseridos para descrever as tabelas também deverão ser em inglês.

Nomes de tabelas devem conter apenas caracteres alfanuméricos. Underscores e espaços não são permitidos. Números são permitidos, mas são desencorajados.

Nomes de tabela devem sempre começar com uma letra maiúscula. Quando um nome for composto por mais de uma palavra, apenas a primeira letra de cada uma delas deve ser maiúscula.

Nomes de tabelas que representem uma entidade devem estar no singular.

Ex.: Chat, Project, Archive, State


Nomes de tabelas que representem relações, devem estar no plural ou no singular dependo do tipo de relação existente (cf. Um pouco sobre relacionamentos em um banco de dados).

Ex.: Um para Um(ou 1 → 1) : CourseAdmin (observer que relações 1 → 1 usualmente não são representadas por tabelas)

Ex.: Um para Vários (1 → n): CouseStudents
Ex.:Vários para Vários (n → n): UsersFriends


Formato das Tabelas

Todas as tabelas no AMADIS deverão utilizar o tipo InnoDB. Outros tipos de tabelas são permitidas para circunstâncias especiais mas desencorajadas.

Todas as tabelas deverão ter como collation utf8_swedish_ci para fins de internacionalização. Outros collations do tipo utf8 são permitidos dependendo do contexto, mas desencorajados.

Campos

Nomenclatura

Nomes de campo devem ser escritos em inglês para aumentar a possibilidade de internacionalização do sistema.

Nomes de campo devem conter apenas caracteres alfanuméricos. Underscores ou espaços não são permitidos. Números são permitidos, mas são desencorajados.

Nomes de campo devem sempre começar com uma letra minúscula. Quando um nome de função for composto por mais de uma palavra, a primeira letra de cada uma delas deve ser maiúscula. Esse médoto é usualmente denominado de studlyCaps ou camelCaps.

Expressividade é encorajada. Nomes de campo devem ser tão ilustrativas quando possível para aumentar a sua clareza.

Nomes de campo que são chaves estrangeiras, devem ter o nome do campo que está sendo referenciado, seguido do nome da TABELA a qual esta se referenciando. Ex:

  • codeUser : referencia o campo code da tabela User


Prefixos que designam a função do campo são permitidos mas desencorajados. Utilizar o prefixo que identifica a função como um flag é um exemplo aceitável.

Estes são exemplo de nomes de função aceitáveis:

  • code
  • name
  • flagOnline
  • startTime
  • finishDate

Formato dos Campos

Não existe uma determinação sobre o tipo de dados a ser utilizado em cada campo. Entretanto existem recomendações que são descritas na tabela abaixo:

Campo Tipagem do campo
code Int ou bigint
date bigint
flag boolean
image bigblob
IP int
name varchar(100)
password varchar(100)
text text
title varchar(100)
time bigint


Os tipos para esses campos são uma recomendação, não uma regra. Existem ocasiões onde outros tipos de dados podem requerer tipos alternativos. Por exemplo, o uso do um ENUM ou SET em um campo do tipo flag pode contribuir para a legibilidade da tabela e do sistema. Outro ponto está na recomendação do uso de campos inteiros para os campos to tipo “code”. Em tabelas com poucas entradas, os tipos int ou smallint(até 256 códigos) pode ser suficientes. Entretanto, tabelas com muitas entradas, como mensagens de um fórum, pode exigir campos do tipo bigint.

O collation de cada campo deve ser utf8_swedish_ci. Para campos do tipo blob que contenham dados binários, deve-se utilizar utf8_bin.


Links Relacionados

Ferramentas pessoais
Parceiros
















SourceForge.net Logo

Supported by Cenqua