Intrebari

Re: Insert

ignatandrei — Wed, 13 Aug 2008 06:38:02 GMT

tebbaerty:

Cu alte cuvinte in ritmul de 500 job-uri / zi ar trebui să treacă mai mult de 100 de ani pentru a se putea ajunge la limita maxima de două miliarde şi ceva. Pănă atunci vom fi de mult oale şi ulcele .

Si dvs cand faceti un program il faceti ca atunci cand ve ti fi oale si ulcele sa nu mai poata fi folosit ? :D daca faci ceva sa nu se treazeasca stra stra stra nepotii nostri ca nu pot folosi ce a scrit bunicutzul lor mult iubit.:P

bine imi dau seama ca suna aberant dar nu m-am putut abtine :D .. scz daca provoc inconveniente

Atunci un GUID iti rezolva problema ...

Re: Insert

ignatandrei — Wed, 13 Aug 2008 06:33:54 GMT

tebbaerty:
Dar motivul pentru care am pus o cheie compusa este ca nu imi trebuia un id ci o cheie compusa pentru a nu permite 2 inregistrari identice cum a dat exemplu persoana de mai sus (acela cu facturile) . Probabil era si alta metoda dar pe moment asa mi s-a parut firesc :D

Metoda se numeste index unique , citeste aici
http://www.odetocode.com/Articles/70.aspx

Re: Insert

B_gd_n[ ]Sahlean — Tue, 12 Aug 2008 21:49:12 GMT

tebbaerty:
Dap cred ca aveti dreptate. Dar motivul pentru care am pus o cheie compusa este ca nu imi trebuia un id ci o cheie compusa pentru a nu permite 2 inregistrari identice cum a dat exemplu persoana de mai sus (acela cu facturile) . Probabil era si alta metoda dar pe moment asa mi s-a parut firesc :D

si int nu are 65.000 ? .. bine normal ca puteam sa folosesc bigint. :D

Ok.
Exemplul cu acea factura nu este bine ales deoarece:
[1] dacă tabela Factura are cheia primară compusă din Serie+Nr factură atunci
[2] tabela ProduseFacturate va avea o cheie externă compusă Serie+Nr factură problemă urâtă (cel puţin de mine dmmpdv) ...

Soluţia pe care o prefer în această situaţie este cea a unei chei primare artificiale în tabela Factură de forma CodFactura
(de tip INT cu IDENTITY(1,1) sau de tip GUID) plus o cheie candidat (conceptual vb.) implementabilă sub forma unui index cu valori unice compus din Serie si Nr factura:

CREATE TABLE Factura
(
CodFactura INT IDENTITY(1,1) PRIMARY KEY,
Serie VARCHAR(10) NOT NULL,
Nr INT NOT NULL,
Data DATETIME NOT NULL
);
GO

CREATE UNIQUE NONCLUSTERED INDEX Factura_SerieNr ON Factura (Nr,Serie);
GO

INSERT INTO Factura (Serie,Nr,Data) VALUES ('A',1,'2008-01-01');
INSERT INTO Factura (Serie,Nr,Data) VALUES ('A',1,'2008-02-02');
GO

Chiar si combinatia Serie + Nr are anumite probleme.

Re: Insert

B_gd_n[ ]Sahlean — Tue, 12 Aug 2008 21:30:27 GMT

tebbaerty:

Cu alte cuvinte in ritmul de 500 job-uri / zi ar trebui să treacă mai mult de 100 de ani pentru a se putea ajunge la limita maxima de două miliarde şi ceva. Pănă atunci vom fi de mult oale şi ulcele .

Si dvs cand faceti un program il faceti ca atunci cand ve ti fi oale si ulcele sa nu mai poata fi folosit ? :D daca faci ceva sa nu se treazeasca stra stra stra nepotii nostri ca nu pot folosi ce a scrit bunicutzul lor mult iubit.:P

bine imi dau seama ca suna aberant dar nu m-am putut abtine :D .. scz daca provoc inconveniente

Nu e bine să te abţii ... cum ar zice cineva.

Re: Insert

tebbaerty — Tue, 12 Aug 2008 21:22:10 GMT

Cu alte cuvinte in ritmul de 500 job-uri / zi ar trebui să treacă mai mult de 100 de ani pentru a se putea ajunge la limita maxima de două miliarde şi ceva. Pănă atunci vom fi de mult oale şi ulcele .

Si dvs cand faceti un program il faceti ca atunci cand ve ti fi oale si ulcele sa nu mai poata fi folosit ? :D daca faci ceva sa nu se treazeasca stra stra stra nepotii nostri ca nu pot folosi ce a scrit bunicutzul lor mult iubit.:P

bine imi dau seama ca suna aberant dar nu m-am putut abtine :D .. scz daca provoc inconveniente

Re: Insert

tebbaerty — Tue, 12 Aug 2008 21:16:43 GMT

Dap cred ca aveti dreptate. Dar motivul pentru care am pus o cheie compusa este ca nu imi trebuia un id ci o cheie compusa pentru a nu permite 2 inregistrari identice cum a dat exemplu persoana de mai sus (acela cu facturile) . Probabil era si alta metoda dar pe moment asa mi s-a parut firesc :D

si int nu are 65.000 ? .. bine normal ca puteam sa folosesc bigint. :D

Re: Insert

B_gd_n[ ]Sahlean — Tue, 12 Aug 2008 20:43:01 GMT

ggciubuc:
O cheie compusa de obicei mareste dimensiunea indexului care duce la probleme de performanta;

Discutabil.

insa daca se fac cautari dupa cheie sau componente ale ei merita cantarit.

Dacă selectivitatea condiţiei(ţiilor) este scăzută.

Cât despre int/bigint cred că autorul a facut nişte calcule greşite.
Un calcul simplu indica urmatoarele (calculul pleacă de la ce se scrie aici: ejobs se lauda cu 350 job-uri zilnice noi ): 500 job-uri/zi x 356 zile/an = 178.000 job-uri / an x 10 ani = 1.780.000 job-uri / 10 an.i Cu mult sub limita de 2.147.483.647 de la tipul int (nu bigint). Cu alte cuvinte in ritmul de 500 job-uri / zi ar trebui să treacă mai mult de 100 de ani pentru a se putea ajunge la limita maxima de două miliarde şi ceva. Pănă atunci vom fi de mult oale şi ulcele .

Re: Insert

ignatandrei — Tue, 12 Aug 2008 20:06:29 GMT

tebbaerty:

Problema e ca daca folosesc un identity atunci acesta in scurt timp va ajunge la o valoare imensa.
Imagineazati o baza de data in care se sterg si se adauga elemente de foarte multe ori.
cel putin asa gandesc eu :-?

bigint ( 2^63-1 (9,223,372,036,854,775,807) * 2, daca pornesti de la minim ...) ?
Daca nu, poate guid ...

Re: Insert

ggciubuc — Tue, 12 Aug 2008 18:38:08 GMT

O cheie compusa de obicei mareste dimensiunea indexului care duce la probleme de performanta; insa daca se fac cautari dupa cheie sau componente ale ei merita cantarit.

Re: Insert

Diana — Tue, 12 Aug 2008 15:27:03 GMT

Vezi BOL ---> Data Types (int, bigint).

Re: Insert

tebbaerty — Tue, 12 Aug 2008 13:24:10 GMT

ignatandrei:
tebbaerty:
"
Asta cu nume prenume era doar de exemplu eu pun cheie primara compusa pe altceva.

Nu am avut nevoie in general de PK compusa, ci de fiecare data adaugarea unui surogat ( identity, guid) s-a dovedit de folos ( in BD si in aplicatie ...)
Poti sa faci index pe coloane daca vrei sa iti ajute cautarea ...

Problema e ca daca folosesc un identity atunci acesta in scurt timp va ajunge la o valoare imensa.
Imagineazati o baza de data in care se sterg si se adauga elemente de foarte multe ori.
cel putin asa gandesc eu :-?

Re: Insert

Diana — Tue, 12 Aug 2008 12:19:52 GMT

B_gd_n[ ]Sahlean:
Diana:

Cu CNP sau SSN pe post de cheie primara poti avea probleme, vezi

http://sqlserver.ro/forums/post/5106.aspx

Mai precis, la ce probleme te referi ?

Prefer sa evit situatiile prezentate in link-ul de mai sus.

Re: Insert

ignatandrei — Tue, 12 Aug 2008 10:04:17 GMT

tebbaerty:
"
Asta cu nume prenume era doar de exemplu eu pun cheie primara compusa pe altceva.

Nu am avut nevoie in general de PK compusa, ci de fiecare data adaugarea unui surogat ( identity, guid) s-a dovedit de folos ( in BD si in aplicatie ...)
Poti sa faci index pe coloane daca vrei sa iti ajute cautarea ...

Re: Insert

B_gd_n[ ]Sahlean — Tue, 12 Aug 2008 10:03:25 GMT

Diana:
Cu CNP sau SSN pe post de cheie primara poti avea probleme, vezi

http://sqlserver.ro/forums/post/5106.aspx

Mai precis, la ce probleme te referi ?

Re: Insert

Diana — Tue, 12 Aug 2008 09:54:45 GMT

Cu CNP sau SSN pe post de cheie primara poti avea probleme, vezi

http://sqlserver.ro/forums/post/5106.aspx