marzo 2007 - Posts
venerdì scorso ho avuto il piacere di partecipare al "
Ready For A New Day" tenutosi a Bari e organizzato da "
.NetSide", in previsione del quale avevo già parlato in
questo post.
E' stato veramente un piacevolissimo pomeriggio, come
sottolineato dal presidente dell'associazione Michele Locuratolo.
Tra i tanti premi sorteggiati a fine workshop, ho avuto la fortuna sfacciata di beccarmi un voucher per sostenere un esame Microsoft, senza contare che il premio più prestigioso - licenza di Windows Vista - è andato a Francesco R., un programmatore "in fasce" (ha solo 18 anni) che ho invogliato personalmente a venire al workshop.
L'appuntamento è al prossimo evento del 20 Aprile "
.NET Data Management".
comunico che da oggi sono entrato "ufficialmente" a far parte della vasta comunità di utenti windows che hanno come sfondo del proprio desktop una foto del proprio figlio :P
Inoltre, per chi cominciasse a nutrire dubbi sulla mia salute mentale, tengo a precisare che, nelle mie tante password di accesso a questo e a quel sistema, prometto di NON includere mai la sua data di nascita nè il suo nome :)
USE AdventureWorks
GO
CREATE TABLE [Person].[Child] (
[ChildID] [int] IDENTITY(1,1) NOT FOR REPLICATION NOT NULL,
[FirstName] [dbo].[Name] NOT
NULL,
[LastName] [dbo].[Name]
NOT NULL,
[BirthDate] [datetime] NOT NULL,
[rowguid] [uniqueidentifier] ROWGUIDCOL NOT NULL CONSTRAINT [DF_Child_rowguid] DEFAULT (newid()),
[ModifiedDate] [datetime] NOT NULL CONSTRAINT [DF_Child_ModifiedDate]
DEFAULT (getdate()),
CONSTRAINT
[PK_Contact_ChildID] PRIMARY KEY CLUSTERED
(
[ChildID] ASC
)WITH (PAD_INDEX = OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY]
GO
ALTER TABLE [Person].[Child]
WITH CHECK ADD CONSTRAINT [CK_BirthDate] CHECK (([BirthDate]<=GetDate()))
GO
INSERT [Person].[Child] ( [FirstName], [LastName], [BirthDate] )
VALUES ('Ivan', 'Quaratino', '20070315')
GO
/*
Per la precisione si è trattato delle 16:40 di un giovedì diverso da tutti gli altri...
*/
E' risaputo che l'utilizzo degli alias (sia per le colonne che per le
tabelle) renda il codice T-SQL più leggibile - anche se preferisco dire "più
scrivibile", perchè la lunghezza dei nomi di tabella rende talvolta
eccessivamente prolissa e snervante la scrittura di condizioni di JOIN.
Personalmente ne faccio largo uso, ma unicamente per le tabelle.
Raramente, infatti, li utilizzo per i nomi di colonna.
La convenzione che
uso per nominare le tabelle è questa: una lettera per ogni prima lettera delle
parole che compongono il nome di tabella/colonna - ad es. la tabella
"TesteDocumenti" diventa TD, "AnagraficaArticoliCommerciali" diventa AAC.
Ma come funzionano esattamente gli alias? Il concetto di alias nel linguaggio
SQL è spesso frainteso e le questioni di sintassi, indipendentemente dal
linguaggio, sono noiosissime tanto che taluni le considerano assolutamente
inutili da sollevare.
Come non convenirne? Di fatto, però, poichè si rischia
di impazzirci sopra parecchio tempo, è meglio tenere a mente che, in una query:
- se specifichi un alias per una tabella o vista inclusa nella clausola
FROM, allora sei costretto a usare esclusivamente l'alias definito
- discorso opposto per gli alias di colonna o espressione, che attribuisci
solo ed esclusivamente per dare alla tua query dei nomi di colonna diversi da
quelli di origine, ma che non puoi "riusare" nella query (per es. nella
condizione WHERE o ORDER BY)
Non passa corso di "SQL Server 2000 Programming" che non faccio notare ai
partecipanti il brutto scherzo in cui si può incorrere col
Query Analyzer, commentando un frammento di uno script che includa il comando GO. Invece, il tool di amministrazione/sviluppo
"Sql Server Management Studio (SSMS)" (introdotto con Sql
Server 2005) evita lo spiacevole errore ignorando il GO incluso nella sezione
commentata.
Vediamo un esempio:
01
USE tempdb
02 GO
03
04
DROP TABLE T1
05
06
CREATE TABLE T1 (
07 C1
INT,
08 C2
VARCHAR(10)
09
)
10 GO
11
12
INSERT T1
VALUES (1, 'uno')
13
/*
14 INSERT T1 VALUES (2, 'due')
15 GO
16
17 INSERT T1 VALUES (3, 'tre')
18 */
19
20
SELECT * FROM T1
21 GO
Il messaggio restituito da Query Analyzer è un tantino ambiguo, ma allusivo
quanto basta per intuirne il motivo:
Server: messaggio 113, livello 15, stato 1, riga 3
Carattere di fine
commento '*/' mancante.
Server: messaggio 170, livello 15, stato 1, riga
1
Riga 1: sintassi non corretta in prossimità di '*'.
Di fatto, il GO non è un comando SQL, bensì del client, e determina l'invio del batch che comprende le istruzioni
dalla riga 11 alla 14. Ecco dunque spiegato il messaggio di errore che denuncia
la mancanza del carattere di fine commento '*/'.
Insomma, un'altro buon motivo per mettere in cantina il vecchio Query
Analyzer.
Se eseguiamo lo script di sopra con il SSMS, otteniamo la risposta
attesa:
(Righe interessate:
1)
C1 C2
-----------
----------
1
uno
(Righe interessate: 1)