Domande da neofita

lunedì 22 settembre 2008 - 16.30

supremeprogrammer Profilo | Newbie

Ciao,
lo so il titolo è tutto un programma,ma nn sapevo come spiegarmi differentemente.
Sono ai miei primi approcci con SQL Server 2005,anche se questo più che una domanda specifica su SQL Server è una domanda generica sui db.
Allora ho una tabella TdatiTransazione con dei dati realitivi ad una operazione bancaria.
In essa ho tra gli altri, i dati del rapporto dell'intestatario e dati del rapporto del beneficiario.
In particolare mi ritrovo con un id_tipo_rapporto_intestat e un id_tipo_rapporto_benefic. Entrambe sono fk di un campo id della tabella TtipoRapporto che secondo me nn è il caso di sdoppiare in TtipoRapportoIntest e TtipoRapportoBenefic in quanto praticamente l'unica cosa che le distinguerebbe è l'appartenenza ad un intestatario piuttosto che ad un beneficiario.Credo di aver ottenuto lo stesso risultato aggiungendo un campo inerente all'appartenenza. E' corretto secondo voi? Facendo il diagramma del DB mi trovo di fatto che dalla tabella TdatiTransazione partono due relazioni verso TtipoRapporto che puntano allo stesso id.
Scusate per la domanda banale,ma il dubbio atroce mi assale.
Un altra cosa inerente la nomenclatura, secondo voi è vantaggioso o scomodo chiamare i campi descrivendone per esteso la natura intervallando con un "_" ?Per esempio: num_rapporto_sottoscritt è troppo lungo o può andare?

Grazie infinite anticipatamente per l'aiuto.

Brainkiller Profilo | Guru

>Un altra cosa inerente la nomenclatura, secondo voi è vantaggioso
>o scomodo chiamare i campi descrivendone per esteso la natura
>intervallando con un "_" ?Per esempio: num_rapporto_sottoscritt
>è troppo lungo o può andare?

Bella domanda, ti rispondo su questo, Lorenzo ti risponderà anche sul resto.
Tutte queste domande vanno sotto l'area chiamata "naming conventions" ossia delle regole che ti indicano come chiamare i nomi delle variabili, delle tabelle, ecc.ecc. Nessuno ti vieta di usare una naming convention tua, ma se lavori in team è sempre meglio osservare delle regole standard. Prova a leggere per esempio questa FAQ e magari già ti fai un'idea:
http://databases.aspfaq.com/database/what-naming-convention-should-i-use-in-my-database.html
Ciao

David De Giacomi | Microsoft MVP
http://blogs.dotnethell.it/david/

lbenaglia Profilo | Guru

>Allora ho una tabella TdatiTransazione con dei dati realitivi
>ad una operazione bancaria.
>In essa ho tra gli altri, i dati del rapporto dell'intestatario
>e dati del rapporto del beneficiario.
>In particolare mi ritrovo con un id_tipo_rapporto_intestat e
>un id_tipo_rapporto_benefic. Entrambe sono fk di un campo id
>della tabella TtipoRapporto

Puoi postare i comandi di CREATE TABLE di entrambe le tabelle completi di CONSTRAINT?

>Grazie infinite anticipatamente per l'aiuto.
Prego.

Ciao!
--
Lorenzo Benaglia
Microsoft MVP - SQL Server
http://blogs.dotnethell.it/lorenzo/
http://italy.mvps.org

supremeprogrammer Profilo | Newbie

Inanzitutto grazie per la risposta.Ecco uno screenshot del diagramma del DB:

519x557 57Kb


Ecco invece il create:

USE [PAC]
GO
/****** Oggetto: Table [dbo].[Tpac] Data script: 09/23/2008 09:35:10 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TABLE [dbo].[Tpac](
[id] [int] IDENTITY(1,1) NOT NULL,
[id_tipo_rapporto_sottoscritt] [int] NOT NULL,
[num_rapporto_sottoscritt] [int] NOT NULL,
[intestazione_sottoscritt] [nvarchar](50) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL,
[id_tipo_rapporto_benefic] [int] NOT NULL,
[num_rapporto_benefic] [int] NOT NULL,
[intestazione_benefic] [nvarchar](50) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL,
[id_periodicita] [int] NOT NULL,
[importo] [int] NOT NULL,
[data_sottoscrizione] [datetime] NOT NULL,
[rata_ingresso] [int] NOT NULL,
[frazionario] [int] NOT NULL,
[id_user] [int] NOT NULL,
[timestamp] [datetime] NOT NULL,
[id_stato_pac] [int] NOT NULL,
[data_addebbito] [datetime] NOT NULL,
[data_iniziativa] [datetime] NOT NULL,
CONSTRAINT [PK_Tpac] PRIMARY KEY CLUSTERED
(
[id] ASC
)WITH (IGNORE_DUP_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY]

GO
USE [PAC]
GO
ALTER TABLE [dbo].[Tpac] WITH CHECK ADD CONSTRAINT [FK_Tpac_TstatoPac] FOREIGN KEY([id_stato_pac])
REFERENCES [dbo].[TstatoPac] ([id])
GO
ALTER TABLE [dbo].[Tpac] WITH CHECK ADD CONSTRAINT [FK_Tpac_TtipoRapporto] FOREIGN KEY([id_tipo_rapporto_sottoscritt])
REFERENCES [dbo].[TtipoRapporto] ([id])
GO
ALTER TABLE [dbo].[Tpac] WITH CHECK ADD CONSTRAINT [FK_Tpac_TtipoRapporto1] FOREIGN KEY([id_tipo_rapporto_benefic])
REFERENCES [dbo].[TtipoRapporto] ([id])

lbenaglia Profilo | Guru

>Ecco uno screenshot del diagramma del DB:
Non vedo particolari problemi se non il fatto che per ogni riga delle tabelle Tpac e Tiniziativa puoi avere solo 2 valori di tipi rapporto. Se volessi normalizzare ulteriormente la struttura, potresti definire due tabelle di giunzione (una tra Tpac e TtipoRapporto e una seconda tra Tiniziativa e TtipoRapporto) la cui PK è data dalle PK delle tabelle relazionate tra loro, definendo in questo modo due relazioni molti-a-molti.

Ciao!
--
Lorenzo Benaglia
Microsoft MVP - SQL Server
http://blogs.dotnethell.it/lorenzo/
http://italy.mvps.org

supremeprogrammer Profilo | Newbie

Ciao,
grazie per la risposta.
Potresti spiegarti un po meglio.Che intendi per "solo 2 valori di tipi rapporto" ? Potenzialmente potrei avere n valori nel campo id_tipo_rapporto relativo al sottoscrittore ed altrettanti per il beneficiario in ciascun record delle due tabelle Tiniziativa e Tpac o no? Scusa ma sono proprio un profano.
Potresti farmi un esempio di campi presenti nelle due tabelle di giunzione che mi suggerisci?

Grazie

lbenaglia Profilo | Guru

>Ciao,
>grazie per la risposta.
>Potresti spiegarti un po meglio.Che intendi per "solo 2 valori
>di tipi rapporto" ?
Eh, hai definito solo due colonne id_tipo_rapporto* in Tpac e Tiniziativa, quindi PER OGNI RIGA potrai avere al più 2 tipi rapporto

>Potresti farmi un esempio di campi presenti nelle due tabelle
>di giunzione che mi suggerisci?
Le PK delle tabelle che vuoi mettere in relazione molti-a-molti, definendo su di essere un constraint di PRIMARY KEY.
http://www.mml.cam.ac.uk/call/cert/11/many_to_many.html

>Grazie
Prego.

Ciao!
--
Lorenzo Benaglia
Microsoft MVP - SQL Server
http://blogs.dotnethell.it/lorenzo/
http://italy.mvps.org

supremeprogrammer Profilo | Newbie

Ok credo di aver capito che intendi quando scrivi:
>Eh, hai definito solo due colonne id_tipo_rapporto* in Tpac e
>Tiniziativa, quindi PER OGNI RIGA potrai avere al più 2 tipi
>rapporto
>

Guarda,il motivo per cui ho messo due soli campi id_tipo_rapporto è che ce ne saranno al massimo 2.
Questo perchè le parti in ballo sono 2:sottoscrittore e beneficiario.Quindi due sole parti e un solo id_tipo_rapporto per ogni parte coinvolta nella transazione.
In teoria nn ce ne dovrebbe essere una terza parte,pèr questo facevo fatica a capire,ma questo tu giustamente nn lo sapevi perchè i stupidamente non ho precisato.Scusa.

Va bene allora procedo così come stavo facendo.
Ti sono grato.
Partecipa anche tu! Registrati!
Hai bisogno di aiuto ?
Perchè non ti registri subito?

Dopo esserti registrato potrai chiedere
aiuto sul nostro Forum oppure aiutare gli altri

Consulta le Stanze disponibili.

Registrati ora !
Copyright © dotNetHell.it 2002-2023
Running on Windows Server 2008 R2 Standard, SQL Server 2012 & ASP.NET 3.5