Avand in vedere experienta voastra as vrea sa-mi explicati cum a-ti fi realizat voi urmatorul tabel si sa-mi subliniati si explicati diferenta.Multumesc.

create table Clienti

(ID             int primary key not null,

NumeClient      varchar(20) not null unique nonclustered,

AdresaClient    varchar(40)  not null,

Oras            varchar(15)   not null default 'Bucuresti',

PersoanaContact varchar(20) not null,

Telefon         int         not null,

Observatii      varchar(100) null)

---

Sorin Titu
MCITP Database Administrator
MCITP Enterprise Administrator

In primul rand ID se preteaza a fi definit Identity cu index cluster (pentru usurinta la inserare)

Apoi mai umblati la dimensiunile varchar de la NumeClient si PersoanaContact pentru ca sigur gasiti denumiri de firme si persoane cu mai mult de 20  caractere

Telefenoul nicidecum nu poate fi intreg : e vorba de exemplu de nr. 021777777, aici trebuie un varchar dimensionat dupa felul de introducere,

de exemplu : +40744-100.535.

Iar la observatii poate trebuie marita dimensiunea lui varchar pana la varchar(max) (vezi si http://sqlserver.ro/forums/thread/359.aspx )

De asemenea mai trebuie analizat la constrangerea not nul: s-ar putea sa trebuiasca null la anumite campuri cand nu se cunoaste informatia (de exemplu Persoana de contact si telefonul - pot sa nu stiu o persoana exact, sau sa nu-i stiu telefonul)

---

Gheorghe Ciubuc,SQL Server Influencer, MCP(SQL 2000), MCTS (SQL Server 2005) , OCA(Oracle 9i), Sybase(Brainbench)

Si inca ceva: folositi interfata mai intai daca aveti nevoie de scriptul de creare tabel. Iata cum

1.Construiti tabelul prin interfata apoi

2.Right-Click pe tabelul dorit -->Script Table As-->Create to -->Clipboard  si Paste unde vreti(asta la SQL 2005, la 2000 intrati in Query Analyzer si e cam similar)

---

Gheorghe Ciubuc,SQL Server Influencer, MCP(SQL 2000), MCTS (SQL Server 2005) , OCA(Oracle 9i), Sybase(Brainbench)

Eu as normaliza un pic tabela adaugand o tabela pentru persoanele de contact si una pentru adrese.

Ca sa va faceti o idee de tabela normalizata redau un fragment din baza de date demo AdventureWorks:

---

Cristian Andrei Lefter, SQL Server MVP
MCT, MCSA, MCDBA, MCAD, MCSD .NET,
MCTS, MCITP - Database Administrator SQL Server 2005
http://sqlserver.ro

Cam asa ceva e mai obisnuit.

BTW: Exista database patterns? Si si tool de a le verifica?

Ca database patterns eu personal folosesc regulile de normalizare (pt OLTP).

---

Cristian Andrei Lefter, SQL Server MVP
MCT, MCSA, MCDBA, MCAD, MCSD .NET,
MCTS, MCITP - Database Administrator SQL Server 2005
http://sqlserver.ro

As avea si eu cateva idei, poate nu f bune.

In primul rand campul AdresaClient tinand cont ca nu este impartit pe strada, numar , bloc, et etc eu zic ca este declarat cam mic de 40.. Oricum daca la nivelul rapoartelor trebuie anumite date mai detaliate despre adresa, ar fi o buna chestie sa impartiti campul.

Aceeasi observatie o am si pentru campul NumeClient. Poate este prea mic.

 

A doua idee, asta in functie pentru ce vrerti sa fol tabelul, ati putea ca in campul PersoanaContact sa fie o referinta catre o anumita tabela de persoane sau cine stie chiar si catre un alt client. Asa acel camp nu o sa il puteti folosi numai pentru raporturi.

 La telefon parerea mea este ca mai bine sa fie de tip varchar de maxim 15 pentru ca unii dintre utilizatori ar putea introduce numarul separat cu "-" si atunci .... trebuie mai multe verificari din layerul de interfata, adica ceva de genu 0040-722-122345. Oricum poate ar fi bine chiar impartirea numarului in 3 parti sau se poate sa aveti un tabel cu tari si cu prefix si atunci numarul sa fie format numai din 722-122345.

 

Daniel

---

MCP (C Sharp)
Software Engineer,
Cluj Napoca

Ca resurse pentru invatarea normalizarii:

"Description of the database normalization basics" http://support.microsoft.com/default.aspx?scid=kb;en-us;283878

"ACC: Database Normalization Basics" http://support.microsoft.com/default.aspx?scid=kb;en-us;100139

"Support WebCast: Database Normalization Basics" http://support.microsoft.com/default.aspx?scid=kb;en-us;324613 (poate fi si download-at pentru vizualizare offline)

---

Cristian Andrei Lefter, SQL Server MVP
MCT, MCSA, MCDBA, MCAD, MCSD .NET,
MCTS, MCITP - Database Administrator SQL Server 2005
http://sqlserver.ro

Eu as tine cont de exemplul lui Cristi si asi introduce si campul e-mail. Iar la telefon.... eu de exemplu am 3 telefoane (acasa, servici, mobil - 2 sunt fixe) dintre care pot fi gasit pe 2 (unul fix si unul mobil)... deci asi tine cont de teoria bazelor de date relationale si asi face o tabela cu date mai putin utilizate....

 

Cand spun asta ma refer la faptul in in multe interogari o sa fie folosit ID-ul si numele clientului si mai putin adresa de e-mail, adresa si telefoane asa ca le-asi separa

 Ca dimensiune a coloanelor sunt de parere cu ce este scris mai sus

 

---

Cătălin D.

 Sorine nu trebuie sa faci decat ce ti se cere ! Plus ca mai poti da un ALTER dupa .. !

 

 Off topic :: Ti am trimis si mail si PM ! As vrea sa te intreb ceva , imi poti da un nr de tel ? 

---

MCSE;MCITP

Ce-ati zice daca in loc de adresa tabele alea doua sa fac o coloana adresa de tip xml in clienti:)?

---

Secolul XXI ori va fi religios ori nu va fi deloc

crestinul:

Ce-ati zice daca in loc de adresa tabele alea doua sa fac o coloana adresa de tip xml in clienti:)?

Sună interesant, dar o să fie mai greu de făcut un "GROUP BY Judet, Sector" sau chiar si un "WHERE Localitate='Bucuresti'". Sigur, există XQuery, dar:

1) e un limbaj în plus de învăţat

2) e important să se definească o schemă pentru XML-ul respectiv (şi acea coloană să fie Typed XML, ca să se verifice să fie conform schemei)

3) cred că performanţa pentru un XML index e mai slabă decât cea pentru un index obişnuit

4) s-ar putea ca unii să scrie "Bucureşti", alţii "Bucuresti", alţii "Buc" (sau la judeţ "Caraş Severin" în loc de "Caraş-Severin").

Dacă ai tabele separate ([Judete], [Localitati], [Adrese], etc) atunci poţi să eviţi astfel de probleme. Totuşi, astfel de design trebuie să ţină cont de ce fel de adrese trebuie ţinute în baza de date (dintr-un singur oraş / din România / de oriunde).

În final, design-ul depinde de scopul pentru care sunt stocate aceste informaţii (altfel spus: care sunt rapoartele care trebuie obţinute?) şi de importanţa relativă a unor aspecte faţă de altele (performanţă, finalizare mai rapidă a proiectului, acurateţea datelor, flexibilitatea).

Răzvan

Cam pana la a cata forma normala aduceti tabelele din cate tin eu minte erau vreo sapte ,am impresia ca sunt si softuri care ajuta la normalizarea tabelelor?

---

Secolul XXI ori va fi religios ori nu va fi deloc

Sunt 5 (+1) forme de normalizare.

Pentru OLTP primele 3 sunt folosite.

---

Cristian Andrei Lefter, SQL Server MVP
MCT, MCSA, MCDBA, MCAD, MCSD .NET,
MCTS, MCITP - Database Administrator SQL Server 2005
http://sqlserver.ro

Din cate stiu eu sunt 5 dar cea folosita este cea de-a 3-a...

vezi aici mai multe detalii...sigur este vorba de ceva introductiv pentru ca discutia poate continua mult mai mult si chiar sunt carti destinate explicatiei acestor forme normale

---

Cătălin D.