REGRA PARA DEFINI?ÃO DE NOMES DE CONSTRAINT FK
Olá a todos!
Estou com uma grande dúvida em relação aos nomes de constraints para chave estrangeira. Sempre que criei um banco de dados usando interface gráfica, a própria ferramente gerava estes nomes pra mim. Sugiu a dúvida agora que estou criando manualmente um banco de dados via script. Pesquisei no Google e vi que outras pessoas também têm essa mesma dúvida. Então adotei um padrão para a nomenclatura de constraints para chave estrangeira da seguinte forma FK_NomeTabelaSecundária_NomeTabelaPrimária_NomeChaveEstrangeira.
Não sei se a forma correta, mas segue o código utilizando a regra na prática para vocês me auxiliarem. Grata!
Estou com uma grande dúvida em relação aos nomes de constraints para chave estrangeira. Sempre que criei um banco de dados usando interface gráfica, a própria ferramente gerava estes nomes pra mim. Sugiu a dúvida agora que estou criando manualmente um banco de dados via script. Pesquisei no Google e vi que outras pessoas também têm essa mesma dúvida. Então adotei um padrão para a nomenclatura de constraints para chave estrangeira da seguinte forma FK_NomeTabelaSecundária_NomeTabelaPrimária_NomeChaveEstrangeira.
Não sei se a forma correta, mas segue o código utilizando a regra na prática para vocês me auxiliarem. Grata!
-- PEDIDOS
IF OBJECT_ID([ô]dbo.PEDIDOS[ô], [ô]U[ô]) IS NOT NULL
DROP TABLE dbo.PEDIDOS
GO
-- VENDEDORES
IF OBJECT_ID([ô]dbo.VENDEDORES[ô], [ô]U[ô]) IS NOT NULL
DROP TABLE dbo.VENDEDORES
GO
-- VENDEDORES
CREATE TABLE VENDEDORES
(
IdVendedor INT NOT NULL IDENTITY(1,1),
IdGerenteVendas INT,
NomeVendedor VARCHAR(60),
QuotaVendas DECIMAL(12,2),
BonusVenda DECIMAL(6,2)
)
GO
ALTER TABLE VENDEDORES
ADD CONSTRAINT PK_IdVendedor PRIMARY KEY CLUSTERED (IdVendedor)
GO
-- CLIENTES
IF OBJECT_ID([ô]dbo.CLIENTES[ô], [ô]U[ô]) IS NOT NULL
DROP TABLE dbo.CLIENTES
GO
CREATE TABLE CLIENTES
(
IdCliente INT NOT NULL IDENTITY(1,1),
NomeCliente VARCHAR(60),
EndCliente VARCHAR(50)
)
GO
ALTER TABLE CLIENTES
ADD CONSTRAINT PK_IdCliente PRIMARY KEY CLUSTERED (IdCliente)
GO
-- TRANSPORTADORAS
IF OBJECT_ID([ô]dbo.TRANSPORTADORAS[ô], [ô]U[ô]) IS NOT NULL
DROP TABLE dbo.TRANSPORTADORAS
GO
CREATE TABLE TRANSPORTADORAS
(
IdTransportadora INT NOT NULL,
NomeTransportadora VARCHAR(60),
MeioTransporte VARCHAR(50),
PrcFrete DECIMAL(12,2),
PrazoMaximoDias INT
)
GO
ALTER TABLE TRANSPORTADORAS
ADD CONSTRAINT PK_IdTransportadora PRIMARY KEY CLUSTERED (IdTransportadora)
GO
-- PEDIDOS
CREATE TABLE PEDIDOS
(
IdPedido INT NOT NULL,
IdCliente INT NOT NULL,
IdTransportadora INT NOT NULL,
IdVendedor INT NOT NULL,
DataPedido SMALLDATETIME,
QtdItensPedido INT
)
GO
ALTER TABLE PEDIDOS
ADD CONSTRAINT PK_IdPedido PRIMARY KEY CLUSTERED (IdPedido)
GO
-- ITENS_PEDIDO
IF OBJECT_ID([ô]dbo.ITENS_PEDIDO[ô], [ô]U[ô]) IS NOT NULL
DROP TABLE dbo.ITENS_PEDIDO
GO
CREATE TABLE ITENS_PEDIDO
(
IdPedido INT NOT NULL,
IdProduto INT NOT NULL,
ValDesconto DECIMAL(12,2),
QtdPedida INT
)
GO
ALTER TABLE ITENS_PEDIDO
ADD CONSTRAINT PK_PedidodProduto PRIMARY KEY CLUSTERED (IDPEDIDO, IDPRODUTO)
GO
-- PRODUTOS
IF OBJECT_ID([ô]dbo.PRODUTOS[ô], [ô]U[ô]) IS NOT NULL
DROP TABLE dbo.PRODUTOS
GO
CREATE TABLE PRODUTOS
(
IdProduto INT NOT NULL,
NomeProduto VARCHAR(60),
UnidMedidaProduto VARCHAR(40),
IdCategoria INT,
PrecoProduto DECIMAL(12,2)
)
GO
ALTER TABLE PRODUTOS
ADD CONSTRAINT PK_IdProduto PRIMARY KEY CLUSTERED (IdProduto)
GO
-- CATEGORIAS
IF OBJECT_ID([ô]dbo.CATEGORIAS[ô], [ô]U[ô]) IS NOT NULL
DROP TABLE dbo.CATEGORIAS
GO
CREATE TABLE CATEGORIAS
(
IdCategoria INT NOT NULL,
NomeCategoria VARCHAR(60),
CategoriaPerecivel VARCHAR(60),
VendeOnLine BIT
)
ALTER TABLE CATEGORIAS
ADD CONSTRAINT PK_IdCategoria PRIMARY KEY CLUSTERED (IdCategoria)
GO
-- VENDEDORES
ALTER TABLE VENDEDORES
ADD CONSTRAINT FK_VENDEDORES_VENDEDORES_IdVendedor FOREIGN KEY(IdGerenteVendas) REFERENCES VENDEDORES(IdVendedor)
--ON UPDATE CASCADE
GO
-- PEDIDOS
ALTER TABLE PEDIDOS
ADD CONSTRAINT FK_PEDIDOS_VENDEDORES_IdVendedor FOREIGN KEY(IdVendedor) REFERENCES VENDEDORES(IdVendedor)
--ON UPDATE CASCADE
--ON DELETE CASCADE
GO
ALTER TABLE PEDIDOS
ADD CONSTRAINT FK_PEDIDOS_CLIENTES_IdCliente FOREIGN KEY(IdCliente) REFERENCES CLIENTES(IdCliente)
--ON UPDATE CASCADE
--ON DELETE CASCADE
GO
ALTER TABLE PEDIDOS
ADD CONSTRAINT FK_PEDIDOS_TRANSPORTADORAS_IdTransportadora FOREIGN KEY(IdTransportadora) REFERENCES TRANSPORTADORAS(IdTransportadora)
--ON UPDATE CASCADE
--ON DELETE CASCADE
GO
-- ITENS_PEDIDO
ALTER TABLE ITENS_PEDIDO
ADD CONSTRAINT FK_ITENS_PEDIDO_PEDIDOS_IdPedido FOREIGN KEY(IdPedido) REFERENCES PEDIDOS(IdPedido)
--ON UPDATE CASCADE
--ON DELETE CASCADE
GO
ALTER TABLE ITENS_PEDIDO
ADD CONSTRAINT FK_PRODUTOS_IdProduto FOREIGN KEY(IdProduto) REFERENCES PRODUTOS(IdProduto)
--ON UPDATE CASCADE
--ON DELETE CASCADE
GO
-- PRODUTOS
ALTER TABLE PRODUTOS
ADD CONSTRAINT FK_PRODUTOS_CATEGORIAS_IdCategoria FOREIGN KEY(IdCategoria) REFERENCES CATEGORIAS(IdCategoria)
ON UPDATE CASCADE
ON DELETE CASCADE
GO
Uma das regras de ouro quanto à nomenclatura é ser sucinto, mas ao mesmo tempo passar a idéia do que o objeto é de forma mais completa possÃvel. Não tem exatamente uma regra rÃgida, é meio que pessoal, mas como esses nomes de constraints são raramente usados, faz muito pouca diferença na verdade.
Olá Kerplunk!!
O que você sugere desse padrão que estou adotando, está claro para quem for analisar o script e o banco de dados?
O que você sugere desse padrão que estou adotando, está claro para quem for analisar o script e o banco de dados?
Colega Kelly,
No equilÃbrio entre sucinto e informativo, acho que teu padrão ficou bom.
Dificilmente vais ter que lidar com estes nomes, contudo, se outro programador precisar te substituir em tuas férias, por exemplo (se é que programador tem férias), será fácil entender.
Tudo de bom.
No equilÃbrio entre sucinto e informativo, acho que teu padrão ficou bom.
Dificilmente vais ter que lidar com estes nomes, contudo, se outro programador precisar te substituir em tuas férias, por exemplo (se é que programador tem férias), será fácil entender.
Tudo de bom.
KELLY,
Acredito que o padrão adotado está legal, bem legÃvel e de fácil interpretação.
E como os outros colegas disseram, é uma questão pessoal, mas é importante seguir uma padronização, mesmo que alguém tenha que mexer com isto no futuro.
O que você deve se atentar, é o tamanho do nome, pois em alguns bancos de dados existem limitações do tamanho, não sei se é o caso do SQL Server, pois nunca atingi este limite.
Acredito que o padrão adotado está legal, bem legÃvel e de fácil interpretação.
E como os outros colegas disseram, é uma questão pessoal, mas é importante seguir uma padronização, mesmo que alguém tenha que mexer com isto no futuro.
O que você deve se atentar, é o tamanho do nome, pois em alguns bancos de dados existem limitações do tamanho, não sei se é o caso do SQL Server, pois nunca atingi este limite.
Tópico encerrado , respostas não são mais permitidas