"Nikolaj Hansen" <barnabasdk@gmail.com> skrev i en meddelelse
news:QGDAe.59389$Fe7.194538@news000.worldonline.dk...
> Jimmy wrote:
>> Jeg har altid fokuseret på nogle gode index og så stored procedures for
>> at
>> optimere performance.
>
> Stored procedures behøver ikke altid at gøre dine queries hurtigere -
> tværtimod.
>
> Hvis det er et råt select, der henter data ud til en ekstern app, hvor
> du arbejder med dem vil et alm. query tit være hurtigere.
Jamen belastningen på netværket vil være en lille smule mindre til gengæld,
men det er selvfølgelig rigtigt at det ikke altid berettiger. :)
> Stored procs. giver mening, hvis du har noget, der bedst behandles
> internt i databasen, før et ResultSet sendes til clienten.
>
>> Nu er jeg blevet bekendt med at man i MS SQL Server kan lave relationerne
>> på
>> tabellerne med det samme mellem PK og FK når man designer og opretter
>> tabellerne, således at cascading deletes og alt sådan noget følges ad.
>
> Du kan relatere data i alle relationelle DBMS systemer - deraf navnet
>
> Pas på med cascading deletes!!!! Du kan hurtigt ende med med en tom
> database
. Igen der skal være en grund til at bruge det.
Det skal jeg huske :)
>> Men er der noget performance at hente ved at gøre dette?
>
> Nej, tværtimod. Relationer går imod performance. Hver gang du eks. laver
> en insert i en Foreign key column skal den checkes i master tabellen.
>
> Til gengæld giver det bedre datakvalitet, i det du enforcer dine
> constraints.
>
> Du bør altid relatere dine data, det er hele ideen i et relationelt DBMS.
Jo selvfølgelig, men måden jeg plejer at gøre det på er at lave primary keys
i de forskellige tabeller og så bruge joins i mine sql kald til at koble
FKerne sammen med PKerne. Dvs. der står ingen steder at denne attr. er en
foreign key. Det definerer jeg først i mit sql kald.
>> Slipper jeg så får at lave joins i mine sql kald?
>
> Nej. Jeg tror ikke du forstår ideen bag relational constraints (foreign
> /primary keys) helt.
>
>
http://www.utexas.edu/its/windows/database/datamodeling/dm/keys.html
Alt det har jeg styr på, det jeg var lidt ud efter var om det var en ide at
definere alle tingene up front i min database eller om jeg ikke vil vinde
noget synderligt ved det. Jeg kan vel ligeså godt fortsætte med at definere
det i mine sql kalds joins hvis jeg alligevel ikke vinder noget ved at
definere det up front i selve databasen.
Kan du følge mig?
Hvis der er fordele ved det, kan jeg så ikke få dig til at fortælle hvad de
er, for lige nu er jeg bare blevet overbevist om at jeg skal gøre som jeg
plejer, men et eller andet siger mig at det måske ikke er så smart. Jeg ved
bare ikke helt hvad, hehe... ;)
Jimmy