codez Posted September 30, 2010 Report Share Posted September 30, 2010 (edited) Ir Tabula1 ar laukiem A,B,C,DATI, kur A,B,C ir primary keys Tabula1 ------- A (primary key) B (primary key) C (primary key) DATI un ir Tabula2, kurā arī ir lauki A,B,C, kuri norāda uz Tabula1 A,B,C laukiem. Tabulā2 var būt vairāki ieraksti, kuri pēc A,B,C norāda uz vienu ierakstu iekš Tabula1 Tabula2 -------- A B C DATI2 Vēl ir vairākas tabulas, kurās ir tādi pašas norādes ar A,B,C Tas ir kā ir pašlaik. Doma ir, ka varētu taisīt tā Tabula1 -------- ID (primary key) A B C DATI Tabula2 --------- T2_ID (norāda uz Tabula1 ID) DATI Tabulas1 A,B,C kombinācija unikāli raksturo ierakstu, tāpēc no tāda apsvēruma liktos, ka vajadzētu šīs trīs kolonnas kā primary keys, bet tai paša laika 1 primary key liekas efektīvāka. Kurš no variantiem jūsuprāt būtu pareizāks vai labāks un kāpēc? Edited September 30, 2010 by codez Quote Link to comment Share on other sites More sharing options...
Леший Posted September 30, 2010 Report Share Posted September 30, 2010 (edited) Varbūt šai gadījumā labāk taisīt unique(A, B, C)? Edited September 30, 2010 by Леший Quote Link to comment Share on other sites More sharing options...
marrtins Posted September 30, 2010 Report Share Posted September 30, 2010 Nu turēt vienu integeru RAMā, protams, prasa mazāk atmiņas. Ja datu ir daudz, tad ir vērts pārtaisīt PK apr integeru. Sevišķi, ja vēl A,B,C ir kādi (var)chari. Mazāk aizkakāts key buffer/innodb pool. Ja datu nav daudz, domāju neatmaksājas pārtaisīt - kas labi strādā, lai strādā :D Quote Link to comment Share on other sites More sharing options...
codez Posted September 30, 2010 Author Report Share Posted September 30, 2010 Tu domā, taisīt ID kā primary key un ielikt indeksu unique uz A,B,C, lai izvairītos no kļūdainas db? Quote Link to comment Share on other sites More sharing options...
codez Posted September 30, 2010 Author Report Share Posted September 30, 2010 Nu turēt vienu integeru RAMā, protams, prasa mazāk atmiņas. Ja datu ir daudz, tad ir vērts pārtaisīt PK apr integeru. Sevišķi, ja vēl A,B,C ir kādi (var)chari. Mazāk aizkakāts key buffer/innodb pool. Ja datu nav daudz, domāju neatmaksājas pārtaisīt - kas labi strādā, lai strādā :D Jā, A ir varchars, B,C INT Bet ieraksti Tabulā1 ir daži miljoni, savukārt tabulā 2,3,4 vairāki desmiti miljoni. Quote Link to comment Share on other sites More sharing options...
marrtins Posted September 30, 2010 Report Share Posted September 30, 2010 Ja taisīs vēl UNIQ/INDEX, tad no tā papildus ID nav jēgas. Ja būs jāatlasa dati pēc A; A,B vai A,B,C, tad tik definē PK un aizmirsti papildus ID priekš PK. Quote Link to comment Share on other sites More sharing options...
Gints Plivna Posted September 30, 2010 Report Share Posted September 30, 2010 Pirmkārt tabulai nevar būt vairākas primārās atslēgas, bet tikai viena. Visas pārējās ir jāveido kā unikālās atslēgas. Attiecībā uz "pareizāks un labāks" nav vienota akmenī iecirsta veida tāpat kā vienam patīk māte, otram meita, trešajam kleita. Viss atkarīgs no kāda skatu punkta skatās, piemēram: - ja raksta savienojumus (join) starp šādām tabulām, tad jo vairāk kolonas, jo savienojuma nosacījums kļūst neērtāks un lielākas iespējas ielaist kļūdas - ja bērna tabulā ļoti bieži vajag dabūt vecāka tabulas kolonas A, B, C un citu neko nē, tad savukārt ir izdevīgi, jo tās kolonas jau ir iekšā bērna tabulā un nav jātaisa lieks savienojums izmantojot ģenerēto ID lauku. - ja kādreiz pastāv iespēja, ka lauki A, B, C var mainīties, tad PK gadījumā no 3 kolonām, jārēķinās, ka tās būs jāmaina visur. Īsāk sakot tas ir mūžīgais jautājums naturālās atslēgas vai surogātatslēgas (ģenerētās atslēgas). Īsumā, ja neskaita ļoti speciālus gadījumus, es balsoju par surogātatslēgām (tātad ģenerētiem id laukiem), bet esmu pārliecināts, ka ir cilvēki, kas domā pretēji :) Gints Plivna http://datubazes.wordpress.com Quote Link to comment Share on other sites More sharing options...
marrtins Posted September 30, 2010 Report Share Posted September 30, 2010 Vēl variants, A aizvietot ar INT atsevišķā tabulā (A_ID INT, A VARCHAR(ciktanugarš)). Bet tad nāk klāt papildus JOIN... Quote Link to comment Share on other sites More sharing options...
codez Posted September 30, 2010 Author Report Share Posted September 30, 2010 Dati jātlasa tā: ir dots A,B,C atlasam atbilstošo ierakstu Tabulā1 un visus atbilstošos ierakstus Tabulā 2,3,4, kuri norāda un šo ierakstu Tabulā1. Index Tabulā1 uz A,B,C būs jāliek tā vai tā. Taču izvēloties vēl likt ID, iegūst to, ka Tabulās 2,3,4 n-tās reizes neatkārtojas vētības A,B,C, bet tikai ID, kurš norāda uz atbilstošo ierakstu Tabulā1. Un vēl arī tās references uz to ierakstu Tabulā1 iet caur klienta aplikāciju, respektīvi 1. gadījumā man jāsūta A,B,C kombinācijas, otrajā tikai ID. Meklēju net-ā, bet īsti neviens nav aprakstījis labāko praksi un iespējamos akmeņus šādām situācijām. Quote Link to comment Share on other sites More sharing options...
Gints Plivna Posted September 30, 2010 Report Share Posted September 30, 2010 Ja taisīs vēl UNIQ/INDEX, tad no tā papildus ID nav jēgas. Ja būs jāatlasa dati pēc A; A,B vai A,B,C, tad tik definē PK un aizmirsti papildus ID priekš PK. Nu es tā neteiktu. Tātad pirmkārt arī dabiskā veidā vienu objektu var unikāli identificēt vairākos veidos, piemēram, personu 1) pēc personas koda, 2) vārda, uzvārda, dzimšanas datuma un dzīvesvietas. Tātad ja kādā sistēmā veidos personu tabulu ar ģenerētu id, tad UK uz personas kodu neveidos? Tad pastāv risks, ka kāds ieplēsīs divus tādus. Atceramies, ka ierobežojumiem un tiem atbilstošiem indeksiem ir 2 veidu funkcijas: 1) nodrošināt potenciāli labāku ātrdarbību 2) nodrošināt datu integritāti, piemēram, to, ka noteiktā(-s) kolonā(-s) dati ir unikāli. Un dažkārt var gadīties, ka šim gadījumam no ātrdarbības viedokļa nav jēgas, bet datu pareizības ir. Un tad lielajā vairumā gadījumu, tā ir svarīgāka. Quote Link to comment Share on other sites More sharing options...
marrtins Posted September 30, 2010 Report Share Posted September 30, 2010 (edited) Cik garš, tas "A" (vidējais LENGTH(A)?)? Ieguvums, A aizvietojot ar INT, uz vairākiem 10milj ierakstu pa vairākām tabulām varētu būt vērā ņemams. Edit: Gints Plivna: jā, ja tas key velkās līdz pa vairākām tabulām, tad ir jēga. P.S. Personas kodu datubāzē nevar likt unikālu, kamēr tas dabā nav unikāls :D Edited September 30, 2010 by marrtins Quote Link to comment Share on other sites More sharing options...
Gints Plivna Posted September 30, 2010 Report Share Posted September 30, 2010 Meklēju net-ā, bet īsti neviens nav aprakstījis labāko praksi un iespējamos akmeņus šādām situācijām. Nu nu... http://www.google.lv/search?sourceid=chrome&ie=UTF-8&q=natural+vs+surrogate+keys Quote Link to comment Share on other sites More sharing options...
codez Posted September 30, 2010 Author Report Share Posted September 30, 2010 A garums ap 10-15 simboli. Quote Link to comment Share on other sites More sharing options...
codez Posted September 30, 2010 Author Report Share Posted September 30, 2010 Nu nu... http://www.google.lv/search?sourceid=chrome&ie=UTF-8&q=natural+vs+surrogate+keys Jep tev taisnība, jāzin pareizie atslēgas vārdi. Quote Link to comment Share on other sites More sharing options...
codez Posted September 30, 2010 Author Report Share Posted September 30, 2010 (edited) Pašlaik izveidoju tā: Tabula1 ------- ID A B C DATI ------- primary_key(ID) unique(A,B,C) šķiet, ka tas būs man labākais risinājums, tikai uzreiz novēroju interesantu parādību. Ja es insertoju kādu A,B,C kombināciju, tad ID piešķir sākumā 1. Tad, ja mēģinu to insertot 10x atkārtoti, man protams izmet "duplicate entry". Tad mēģinot insertot citu unikālu A,B,C, ID jau tiek piešķirts 12. Respektīvi, katrs neveiksmīgais inserts arī palielināja autoincrement vērtību. Mistiskā autoincrement palielināšana notiek pat, ja izmantoju INSERT ... ON DUPLICATE KEY UPDATE Edited September 30, 2010 by codez Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.