Multi kolom Primairy key

[eatualive]

Ik ben bezig met een nieuwe database te ontwerpen voor mijn applicatie.
Onze applicatie voor het loggen van machine gegevens wil ik naar een hoger niveau brengen.

Voorheen hadden we alleen de totale tijd dat een machine stil had gestaan of draaiden.
Ik wil het zo maken dat elk tijdstip van een stop of start terug te halen is. De totale duur kan ik vervolgens weer berekenen uit de gelogde stops.

Nu probeer ik mijn database efficient op te bouwen en nu had ik het een en ander gelezen over een multi kolom Primairy key. In mijn ogen een leuke oplossing want dan scheelt me dat per tabel 1 complete kolom dus minder data.
Echter zie ik ook veel reacties dat het een negatieve impact kan hebben op je performance.

Omdat ik zelden een database opzet en deze niet heel spectaculair zijn heb ik niet genoeg kennis wat het beste zou zijn in mijn situatie. En ik hoop dat jullie mij op weg kunnen helpen wat het verstandigste is in mijn situatie.

Ik heb een paar van deze tabellen:

t_Counter
- EventTime (PK)
- Machine_id (PK)
- Countername_id (PK)
- CounterValue
- CounterDifference

&

t_MachineState
- EventTime (PK)
- Machine_id (PK)
- State


De machine state kan zich altijd maar in 1 situatie verkeren. Of start, of stop, of manual.
Een record zal geschreven worden als de machine status veranderd. Ofwel de combinatie van EventTime en Machine_id is ten alle tijde uniek. Ik zou zeggen dan is dit is een multi kolom PK. Dit sheelt me 1 kolom MachineState_id.

Voor counters precies hetzelfde alleen 1 machine kan meerdere counters hebben. Alle counter van alle machine's worden elke 15 seconden gelogd. Ofwel de combinaite van EventTime, Machine_id & CounterName_id is uniek en multi kolom PK. Dus ook hier weer dit scheelt mij 1 kolom.

Is dit aan te raden om, of zouden jullie dit toch oplossen met een id kolom?

**note: Uiteindelijk zal ik een multi order moeten uitvoeren op de tabel t_machineState. Ik zal moeten orderen op tijd. Als ik een ID colomn heb dan kan ik ook orderen op ID aangezien dit direct gerelateerd is aan tijd. Misschien kan orderen op deze manier sneller kunnen...

[ Voor 6% gewijzigd door eatualive op 02-08-2013 11:21 ]

[BikkelZ]

Het hangt er van af of je weer heel vaak naar t_Counter probeert te refereren in andere tabellen. Als je andere tabellen hebt die t_Counter als foreign key hebben kun je heel onnatuurlijke situaties gaan krijgen. Al vanaf één refererende tabel gaat je totale column count al omlaag als je van een 3 column compound key gaat naar een 1 column primary id met een unique op die drie foreign keys in t_Counter en dan een 1 column foreign key in de refererende tabel. Dus 4-1 ipv 3-3.

Ik zou voor de compound key gaan als dit niet het geval is.

Je houdt bij een goed ontwerp sowieso een index bij over die kolommen, die moet je namelijk UNIQUE maken op het moment dat ze geen primary meer zijn. Dus bij een insert met een extra primary key kolom wordt er twee keer gecheckt op keys en iets meer data toegevoegd.

[The Eagle]

Ik vraag me af of je dit uberhaupt nodig hebt.

Als jij een tabel maakt met Machine_ID, dttm_on en dttm_off ben je er al. De rest moet je in je applicatoilogica afvangen
Initiele status is OFF, dus bij het aanzetten (status wordt ON) wordt een nieuwe rij ingevoegd waarbij machine_id en dttm_on gevuld zijn, en dttm_off NULL is.
Als je een state OFF doorkrijgt, vul je het DTTM_off veld van de rij met de max(dttm_on) <=sysdate

Voor wat betreft die counters: alleen machine_id, dttmstamp en counter ID loggen, samen met de countervalue. Het berekenen van een verschil kost tijd, dat kun je ook bij het opvragen met een view afvangen. Als er iedere 15 sec tig rijen toegevoegd worden wil je daar niet eerst nog een berekening op los hoeven te laten, dat kan achteraf ook prima bij het opvragen

[epic007]

Lijkt me prima om meerdere kolommen PK te hebben, is heel gebruikelijk in DB land volgens mij. Dat tegenwoordig overal een ID veld toegevoegd wordt is alleen voor het gemak (en idd handig bij foreign keys).

De TS heeft het over 3 states (on, off en manual) dus dttm_on en dttm_off gaan niet werken denk ik.

Verder kost het verschil berekenen (CounterDifference) idd tijd, maar bij een view wordt het verschil bij elke query uitgerekend en in dit geval maar een keer. Misschien is de difference al bekend bij het inserten.

[eatualive]

Bedankt al voor jullie reacties.

Ik heb het inderdaad over 3 states, in werkelijkheid een stuk op 10 states dus die oplossing is niet van toepassing.

De difference kan ik bereken in het programma dat het loged. In houd dit in een geheugenadres bij dus ik hoef niet eerst de oude waarde op te zoeken. Kortom ik schrijf deze direct met de orginele counter waarde. Met deze waarde kan ik wat andere leuke dingetjes doen zonder dat ik na de rand alles moet vergelijken.
Het zou zonder kunnen maar dan krijg ik bij best veel script extra calculaties terwij het nu een eenvoudige insert is. Ik verwacht dat er elke 15seconden een 20 tal rijen ingevoerd zullen worden. Dus ik denk dat ik met valuedifference weinig tijd verlies bij mijn insert maar veel tijd bespaark met mijn berekeningen. Maar ik kan het mis hebben.

Deze PK's worden zeg maar niet 3-3 doorgelinkt naar een andere tabel. Beetje lastig te omschrijven maar wat ik doe visueel:


(Negeer kolom info uit de twee tabellen aangezien dit al een oude versie is. Maar het idee met relaties kloppen wel)
Ofwel als ik een counter weg gooi of een machine dan ben wordt alle data uit deze table ook netjes verwijderd. Maar er is dus niet echt een 3-3 relatie. Met counters precies hetzelfde.

Dus als ik jullie reacties goed begrijp dan zou multi kolom PK in mijn situatie wel het beste zijn.

[ Voor 8% gewijzigd door eatualive op 02-08-2013 13:27 ]

[BikkelZ]

Volgens mij is dit goed. Hou er rekening mee dat je het meettijdstip moet meegeven en niet een automatische waarde van de database, alleen dan kun je meetgegevens van één moment queryen.

Maar wat doet CounterValue en CounterDifference precies? Is dat een VARCHAR met een parameternaam en een INT met een value? Ik neem aan dat je dit in je definitieve versie hebt omgezet naar een een foreign key naar je CounterTypes en dat je dit bedoelde met negeer de andere kolommen?

[eatualive]

Op het moment dat ik een record schrijf pak ik de PC tijd en die log ik. Nu zit ik mij wel te bedenken het zou fout kunnen gaan als de systeem tijd ik keer verzet wordt. Maarja die kans is natuurlijk ook weer heeeel klein dat alle variable dan hetzelfde zijn.

CounterValue zijn getelde flessen van de machine.
Counter difference is het verschil tussen mijn vorige CounterValue en de nieuwe.
Beide voor diverse berekeningen in mijn programma & data checks.

Ik bedoelde the kolommen uit t_Machine & t_Countername. Deze kloppen totaal niet meer omdat het veel beter, makkelijker kan en zonder spelfouten .