Newsgroup: it.comp.software.database
Titolo: SQLServer 2k - Relazioni

Secondo voi dopo aver creato una relazione tra due tabelle (diciamo
primary/clienti foreign/fatture sul codice cliente) devo poi creare io
degli indici (nell'esempio sul codice cliente) nell'apposita tab oppure
si arrangia sqlserver?
Il dubbio mi ha sempre "attanagliato" e chiedo lumi.
buona giornata a tutti

 si arrangia sqlserver?
SQL Server automaticamente crea un indice unique per garantire l'univocità
del constraint PRIMARY KEY. Se un indice clustered non è già presente sulla
tabella, oppure non è stato eplicitamente dichiarato di volere un indice non
clustered, sarà creato un indice cliustered.
Le foreign keys vanno indicizzate manualmente in quanto SQL Server non
genera alcun indice con il constraint FOREIGN KEY.
Ciao!
--
Lorenzo Benaglia
UGIdotNET - 
http://www.ugidotnet.org
UGISS - 
http://www.ugiss.org

 genera alcun indice con il constraint FOREIGN KEY.
grazie millissime
posso insistere? ;) Mi sono accorto di una cosa; usavo TRUNCATE TABLE
per fare pulizia iniziale su una tabella alla quale adesso ho aggiunto
un relationship. purtroppo adesso la truncate non e' piu' accettata
"being referenced by a FOREIGN KEY constraint" :(
Non ho proprio modi? Io _devo_ cancellare!

Paolo Fiore wrote:

una delete...
o meglio, una stored procedure che cancella prima i figli, poi tutti i padri
o smargiasso, disable del constraint, truncate di padre e figli, enable.
ciao
-- 
Punkarruso
mail:punkarruso chiocchiolona despammed punto com
pubblicità progresso:
http://www.gnu.org/press/2002-04-11-ms-patent.html

 o smargiasso, disable del constraint, truncate di padre e figli,
enable.
questa non l'avevo considerata xche' probabilmente sbaglio col concetto
di relationship :(
Mi chiedo se tolgo la relazione e mi limito a creare gli indici a mano
(primary e foreign) mi cambia qualcosa in prestazioni?
Prima ignIorantone pensavo di si, ma alla luce di quanto mi scrivete tu
e Lorenzo sopra mi viene da dire: proprio nulla!
sbaglio?
un grazie a tutti voi

 (primary e foreign) mi cambia qualcosa in prestazioni?
Dal punto di vista delle prestazioni non cambierebbe nulla ma perderesti in
integrità dei dati.
Senza relazioni FOREIGN KEY poresti inserire figli senza il corrispettivo
padre oppure eliminare il padre laciando i figli orfani.
I database *relazionali* sevono appunto ad evitare questo genere di cose...
;-)


 integrità dei dati.
sono con te, ma in questo momento mi interessavano le prestazioni! ;)
Grazie per il prontissimo l'aiuto all'area
e buon natale

 wrote in message 
news:atsmdk$29ndp$1...@ID-65620.news.dfncis.de...

Ciao Paolo,
dato che stai usando SQL 2000 puoi anche dichiarare
l'integrita' referenziale di tipo ON DELETE CASCADE
vedi books online createdb.chm::/cm_8_des_04_92ib.htm
(Copy, Menu GO->URL..., Paste)
Rispetto alla TRUNCATE TABLE sappi che comunque
l'operazione e' piu' onerosa (tecnicamente nel
Transaction Log devono essere tracciate le righe che
vengono cancellate, mentre nel caso della "truncate"
vengono tracciate solo le informazioni legate alla
deallocazione delle pagine).
Un'altra soluzione potrebbe essere quella di
eliminare la foreign key, eseguire la
truncate e dichiarare nuovamente la foreign key.
Detto questo, se non si tratta di un ambiente
di test o di sviluppo, preferisco di gran lunga
la soluzione che ha proposto Punkarruso: cancellare
le fatture e poi i clienti.
Ti allego un esempio.
Ciao,
-- 
Gianluca Hotz
Backoffice MVP (SQL Server) MCP SQL Server and MCP Windows
Vice-President of the Italian User Group for SQL Server
Founding Member of the Italian User Group for .NET
http://www.ghotz.com
http://www.ugiss.org
--
/*
** Cancellazione record correlati
*/
USE tempdb
GO
IF OBJECT_ID('dbo.Fatture') IS NOT NULL
 DROP TABLE dbo.Fatture
GO
IF OBJECT_ID('dbo.Clienti') IS NOT NULL
 DROP TABLE dbo.Clienti
GO
CREATE TABLE dbo.Clienti(
 IDCliente int   NOT NULL,
 NomeCLiente varchar(20) NOT NULL,
 CONSTRAINT pk_Clienti
 PRIMARY KEY (IDCLiente)
)
GO
CREATE TABLE dbo.Fatture(
 NumeroFattura int   NOT NULL,
 IDCliente  int   NOT NULL,
 DataFattura  datetime NOT NULL,
 CONSTRAINT pk_Fatture
 PRIMARY KEY (NumeroFattura),
 CONSTRAINT fk_Fatture_isof_Clienti
 FOREIGN KEY (IDCliente)
 REFERENCES dbo.Clienti(IDCLiente)
)
GO
CREATE INDEX Fatture_fk_Clienti
ON dbo.Fatture(IDCliente)
GO
SET NOCOUNT ON
INSERT dbo.Clienti VALUES (1, 'paperino')
INSERT dbo.Clienti VALUES (2, 'paperoga')
INSERT dbo.Fatture VALUES (1, 1, GETDATE())
INSERT dbo.Fatture VALUES (2, 2, GETDATE())
INSERT dbo.Fatture VALUES (3, 1, GETDATE())
INSERT dbo.Fatture VALUES (4, 1, GETDATE())
INSERT dbo.Fatture VALUES (5, 2, GETDATE())
INSERT dbo.Fatture VALUES (6, 2, GETDATE())
INSERT dbo.Fatture VALUES (7, 1, GETDATE())
SET NOCOUNT OFF
GO
/*
** Tecnica 1: (tradizionale) elimino le fatture, poi i clienti
*/
BEGIN TRANSACTION
 DELETE dbo.Fatture
 DELETE dbo.Clienti
COMMIT TRANSACTION
GO
/*
** Tecnica 2: elimino la foreign key, eseguo la truncate
** e riabilito la foreign key
*/
ALTER TABLE dbo.Fatture
DROP CONSTRAINT fk_Fatture_isof_Clienti
GO
TRUNCATE TABLE dbo.Fatture
TRUNCATE TABLE dbo.Clienti
GO
ALTER TABLE dbo.Fatture
ADD CONSTRAINT fk_Fatture_isof_Clienti
FOREIGN KEY (IDCliente)
REFERENCES dbo.Clienti(IDCliente)
GO
/*
** Tecnica 3: utilizzo ON DELETE CASCADE
*/
-- elimino il vecchio constraint...
ALTER TABLE dbo.Fatture
DROP CONSTRAINT fk_Fatture_isof_Clienti
GO
--... e creo quello nuovo
ALTER TABLE dbo.Fatture
ADD CONSTRAINT fk_Fatture_isof_Clienti
FOREIGN KEY (IDCliente)
REFERENCES dbo.Clienti(IDCliente)
ON DELETE CASCADE
GO
-- a questo punto l'eliminazione delle fatture
-- e' automatica (attenzione ritorna solo il
-- row count della tabella clienti)
DELETE dbo.Clienti