[MySQL] Vincoli su tabella

[Jamie04]

Dovendo scrivere il codice di una tabella in cui un campo deve rispettare queste specifiche:
- essere un alfanumerico di lunghezza esattamente pari a 15 caratteri che inizia sempre per "N_" e termina per "00"
- un utente non può disporre di più di un abbonamento

Per il primo punto come potrei fare? Il mio dilemma è relativo a quel _ che essendo una wildcard mi mette in difficoltà perché se metto un LIKE ('NL_%00') temo non vada bene in quanto quel _ potrebbe essere interpretato come un carattere arbitrario mentre a me serve proprio che sia _.
Il secondo punto invece si risolve con un trigger on insert?

Grazie

[optime]

- per la prima non so se si può definire la maschera di una colonna a livello di definizione di colonna
- la seconda si risolve con un semplice indice univoco

(tu dici: "dovendo scrivere il codice di una tabella": cos'è esattamente il CODICE DI UNA TABELLA?)

[Jamie04]

- un utente non può disporre di più di un abbonamento per uno stesso teatro (avevo dimenticato questa parte)

come cos'è? il codice SQL che definisce una tabella. Tipo:
create table abbonamento(id int primary key, codutente varchar(10), ....)

[optime]

sempre indice univoco, ma composto (li avrete studiati immagino)

[Jamie04]

no, non mi dice niente, e nel libro non è menzionato, quindi non è questa la soluzione che ha in mente il prof

[nman]

...... di lunghezza esattamente pari a 15 caratteri che inizia sempre per "N_" e termina per "00" .........

Io andando un pò fuori dalla richiesta lo farei cosi
...... di lunghezza esattamente pari a 11 caratteri ........
perché poi i 2 caratteri iniziali e i 2 finali sempre uguali li aggiungi da programma

...... - un utente non può disporre di più di un abbonamento .......

Se devi rispettare il compito e lavorare solo sul "create table" allora un
Indice univoco composito sui campi UtenteTeatro come consigliato da Optime

Se invece puoi proporre varianti ... e magari insegnare qualcosa al prof
da programma verifichi prima di fare INSERT che non ci sia
già la accoppiata UtenteTeatro

-- oppure ( e io sceglierei questa )

fai un INSERT condizionato (non un trigger)
INSERT bla, bla, bla ...... WHERE Utente e Teatro <> Utente e Teatro

.

[optime]

no, non mi dice niente, e nel libro non è menzionato, quindi non è questa la soluzione che ha in mente il prof

come siamo lontani dal mondo reale

[Jamie04]

Io andando un pò fuori dalla richiesta lo farei cosi
...... di lunghezza esattamente pari a 11 caratteri ........
perché poi i 2 caratteri iniziali e i 2 finali sempre uguali li aggiungi da programma

non è una cattiva idea, ma come aggiungo i caratteri iniziali e finali? sempre con un trigger on insert? mi faresti un esempio?

Se devi rispettare il compito e lavorare solo sul "create table" allora un
Indice univoco composito sui campi UtenteTeatro come consigliato da Optime
Se invece puoi proporre varianti ... e magari insegnare qualcosa al prof
da programma verifichi prima di fare INSERT che non ci sia
già la accoppiata UtenteTeatro
-- oppure ( e io sceglierei questa )
fai un INSERT condizionato (non un trigger)
INSERT bla, bla, bla ...... WHERE Utente e Teatro <> Utente e Teatro

ma che avete contro i trigger?
il compito chiede di scrivere il codice che definisce la tabella, non posso fare come mi pare, devo attenermi a quanto richiesto
grazie!

[nman]

......ma come aggiungo i caratteri iniziali e finali? sempre con un trigger on insert? .....

Aggiungere a lato programma significa che non li aggiungi con il DB
se hai un DB hai certamente anche un programma ( ASP, PHP, Access ) eccetera che legge e scrive i dati del DB
quindi nel DB resterebbero solo 11 caratteri tutto il resto è superato

ma che avete contro i trigger?

I trigger sono antipatici e costringono il DB a un notevole lavoro di intelligenza

mentre il DB è (a parer mio) solamente un magazzino di dati, robustissimo ma ignorante

mi dilungo solo un po',

La mia vecchia concezione è che:

Nel programma ( o applicazione ) scrivi, calcoli,
verifichi prima di inserire la congruità dei dati che stai INSERTANDO
verifichi prima di cancellare un record che non ci siano record relazionati su tabelle figlie
eccetera eccetera

Nel DB conservi solamente i dati


Il Trigger invece inverte questa logica e delega al DB la esecuzione di operazione intelligenti sui dati

ma certamente non può sostituire il programma, quindi resta una scarpa e una ciabatta ......

il compito chiede di scrivere il codice che definisce la tabella, non posso fare come mi pare, ........

Se il compito prevede una tabella allora il Trigger è da eliminare in quanto esterno alla tabella
direi che quello che si avvicina di più potrebbe essere:
(Su base SQLServer perché non uso MySql)

--  Usa il DB che preferisci xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
USE [Test]
GO

-- cominciamo a creare la tabella con un [Id] autoincrementale
CREATE TABLE [dbo].[T3]
(
 [Id] [int] IDENTITY(1,1) NOT NULL,
 [Abbo] [nvarchar](20) NULL,
 [Teat] [nvarchar](50) NULL,
 [Uten] [int] NULL
) ON [PRIMARY]
GO
 
--  Imposto la Kry primaria sul campo di nome [Id]
ALTER TABLE dbo.T3 ADD CONSTRAINT
 PK_T3 PRIMARY KEY CLUSTERED 
 (
 Id
 ) WITH( STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
 
-- Aggiungo un vincolo che verifica i:
-- 1°)     Primi 2 caratteri si Abbo
-- 2°)     Ultimi 2 caratteri di Abbo
-- 3°)     Lunghezza di Abbo
-- In verita se avessi definito sopra Abbo come 'nvarchar(15)' non avrei avuto bisogno
-- di verificarne la lunghezza  ( Ma facciamo le cose difficili e complete :)   ) 
ALTER TABLE dbo.T3 ADD CONSTRAINT
 ck_Abb CHECK ((left([Abbo],(2))='N_' AND right([Abbo],(2))='00' AND len([Abbo])=(15)))
GO
 
-- Aggiungo un indice Univoco composito con i campi [Teat] e [Uten]
-- in modo che ogni utente non possa avere piu di 1 abbonamento allo stesso teatro
CREATE UNIQUE NONCLUSTERED INDEX KC_Te_Ut ON dbo.T3
 (
 Teat,
 Uten
 ) WITH( STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
 
-- Finito

.

[marino51]

-- Finito

Rivedi tutto con quella "noiosissima" view ....

ps, MS SQL utilizza la stessa strategia per i 3 casi, (view, inner ... e select sulle 3 tabelle)
la strategia dipende dal motore del db