Svenska ElektronikForumet

> Ja man kan ha sammansatta nycklar, bestående av flera fält.

Det kan vara :
- Ett helt fält av valfri datatyp (sannolikt vanligast).
- Del av ett fält (t.ex första 10 tecken av ett 30 teckens fält, om det är unikt).
- Sammansatt av flera fält, även blandade datatyper.
- Beräknat från ett fält (t.ex veckodag beräknad från ett datumfält).

Och, självklart, att nyckeln är unik är inget *tekniskt* krav, det är ett
designkrav enligt normaliseringskraven. Man vill helst ha det så. Sedan
kan en tabell ha en eller flera extra nycklar/index som normalt inte
är unika (men kan vara det).

> räknas alltså kombinationer av fält som en egen nyckel?

Räknas och räknas. Inte per automatik, men om *du* anger att det är så.

Jo men jag menade att i databasen kan man ju sätta fält som "unique" och då protesterar databasmotorn om man försöker lägga in nåt som redan finns (man får felmeddelande att index inte är unikt).

Går det att göra med såna kombinerade nycklar?

Verkar enklast om jag har ett heltal som ID som räknas upp automatiskt vid nyinmatning. Annars blir det många faktorer som ska stämma om jag inte ska blanda ihop t.ex. olika resistorer:

resistor, 10k, 1% , 0.25w, 0805
resistor, 10k, 5% , 0,25w, 0805

Att ha ett enda fält här som "unik" blir ju knepigt.... inget av fälten ovan är ju unika!

för IC så anger jag tillverkarens hela beteckning, för det är enklast så. Men för motstånd och kondingar tycker jag det är bökigt med beteckning, då jag köper in olika fast med samma egenskaper. De kan ju heta konstiga saker så som PNP300AB4R7AUX-100ND. Vissa har inte ens någon beteckning (t.ex. inköpt via tradera).

Jag antar att om ID räknar upp automatiskt så kan jag maska bort det i formulären sedan. Problemet är kanske att det blir lättare att råka mata in två "likadana" poster... alltså med alla data lika förutom numret.

Andra alternativet är kanske att summan av ALLA fält blir unikt ID.

Men om jag av någon anledning vill dela upp mina "74HC14, soic-14" så att jag har 125 st "cut tape" och 47 st i "tube" ... det är samma komponent, fast i olika förpackningar. Det kanske jag bäst lägger upp som olika ställen i lagret, istället för att lägga upp två liknande komponenter....

Liknande problem med 10k motstånden ovan.... om 5% tar slut ska jag kunna ha en koppling som ser att jag kan ersätta dessa med 1%... fast 1%-resistorerna får ej ersättas med 5%....

> Jo men jag menade att i databasen kan man ju sätta fält som "unique"...

Jo, men det är en lite annan sak. Det kallas ett "constraint" (ungefär "begränsning")
på ett fält. Förrutom "unique" kan det vara t.ex ett intervall, vissa specificerade värden
eller att det ska finnas som nyckel i en annan tabell (kallas också "foreign key").

Och visst, databasen kommer vid en INSERT eller UPDATE att se till att denna constraint
upprätthålls. Vissa databaser kommer automatiskt att skapa ett (unikt) index för att underlätta
detta, andra databaser överlåter till administratören att besluta om det ska finnas ett
index för det eller om man kan ta overheaden att läsa alla poster varje gång. Om det
är några hundra poster så går det nästan lika snabbt. Databasen väljer automatiskt att
göra en "sequential scan" av hela tabellen (om index saknas) eller att kolla mot indexet.

> Går det att göra med såna kombinerade nycklar?

Absolut ! Det är ingen som helst skillnad. Säg att du har ett unikt index med
nyckel = bil+ägare. Då kommer det inte att gå att göra INSERT på en post med
bil+ägare som redan finns. Var det det som du menade ?

En nyckel är en nyckel. Det spelar i princip ingen roll hur nyckel-värdet är definierat.

Jesse, ja, som du ser så är det inte gjort i en handvänding att få till det.

Jag får väl pyssla lite.
Kanske bäst att experimentera ett tag innan jag börjar fylla databasen med "skarpa" komponenter. Mitt kalkylblad fungerar fortfarande utmärkt

jesse skrev: Att ha ett enda fält här som "unik" blir ju knepigt.... inget av fälten ovan är ju unika!

Ja, alltså, i vissa har man just ett "dolt" fält som är en unik ID. Det används bara för "relationer" mellan tabellerna och är inget som användaren ser. Databasen ser till att det är unikt. Oftast är det en simpel räknare, gäller bara att längden på den är tillräcklig för alla framtida behov (men behöver t.ex. fundera över hur ID för gamla borttagna poster ska hanteras, ska de räknas som "upptagna" eller kunna återanvändas?).


Det är tankearbetet bakom databasdesignen som är viktigast. Det mesta annat går att justera i efterhand.

> i vissa har man just ett "dolt" fält som är en unik ID.

Med "dolt" avses alltså att det inte syns på de vanliga formulär
(eller i alla fall inte behöver synas) som användaren normalt ser.
För övrigt är de inte mer dolda än något annat i databasen/tabellen.

Det är ett vanligt färt, normalt numeriskt och eventuellt AUTOMATIC
och kanske kopplat till en SEQUENCE. En "sequence" är ett eget objekt
(skillt från tabeller o.s.v) som funegrar som en nummergenerator.
Man kan vid t.ex en INSERT av en ny post begära nästa värde från
sekvensen. Varje sekvens identifieras med ett eget namn, så man kan
ha valfritt antal sekvenser samtidigt.

Om däremot tabellen redan har ett lämpligt fält som är kort och unikt
så kanske man inte behöver lägga till ett extra ID-fält.

Hittade för övrtigt just detta : http://wiki.services.openoffice.org/wiki/Database.
Vet inte om det är bra. Dokumentationen håller väl den vanliga OSS nivån...

Jo, nu efter din förklaring , så förstår jag ju nästan vad de menar i den tutorialen.

Annars tycker jag det är väl mycket facktermer staplade på varandra för att man ska kunna göra sig en bild av vad de egentligen vill säga. Men jag tror jag har grunden nu. Det och att jag läser lite mer tutorials så ska det nog ordna sig. Återkommer väl om jag fastnar (tar nog inte lång tid, misstänker jag )