Spørsmål om mysql, lage tabell

[Inc]

Hvis vi tar denne tabellen f.eks

create table person(alder int not null, fornavn char(30), etternavn char(30), fnr int primary key);

 

Så er det lagt inn "ikke tillat med tomt felt" i alder, men gjelder den kommandoen videre bak i rekken?

[roac]

Hvis vi tar denne tabellen f.eks

create table person(alder int not null, fornavn char(30), etternavn char(30), fnr int primary key);

 

Så er det lagt inn "ikke tillat med tomt felt" i alder, men gjelder den kommandoen videre bak i rekken?

5561797[/snapback]

Nei, den må spesifiseres for hver enkelt kolonne

[ofredstie]

Du må definere hvor stor INT'en skal være og en skikkelig primær nøkkel,

f.eks. person_id.

 

Tenker meg at fnr står for fødselsnummer (personnummer) og er perfekt å bruke

som primær nøkkel siden alle nordmenn/kvinner har unike nummer, MEN du har

ikke lov (med mindre du har fått godkjenning fra Datatilsynet) å lagre denne informasjonen. Derfor foreslår jeg at du bruker auto increment (hvis det er MySQL

du bruker).

 

Foreslår at du bytter ut alder med fødselsdato fordi man bør/skal ikke bruke kalkulerte felt i relasjons-databaser.. fører bare til mye ekstra hodebry.

Ved å lagre fødselsdatoen så kan du kalkulere alderen "on the fly".

 

 

Eksempel:

CREATE TABLE person (

person_id INT(6) AUTO_INCREMENT,

fornavn VARCHAR(30) NOT NULL,

etternavn VARCHAR(40) NOT NULL,

fødselsdato DATE NOT NULL,

--

CONSTRAINT PERSON_PK PRIMARY KEY (person_id)

);

[roac]

Du må definere hvor stor INT'en skal være og en skikkelig primær nøkkel,

f.eks. person_id.

 

Tenker meg at fnr står for fødselsnummer (personnummer) og er perfekt å bruke

som primær nøkkel siden alle nordmenn/kvinner har unike nummer, MEN du har

ikke lov (med mindre du har fått godkjenning fra Datatilsynet) å lagre denne informasjonen. Derfor foreslår jeg at du bruker auto increment (hvis det er MySQL

du bruker).

 

Foreslår at du bytter ut alder med fødselsdato fordi man bør/skal ikke bruke kalkulerte felt i relasjons-databaser.. fører bare til mye ekstra hodebry.

Ved å lagre fødselsdatoen så kan du kalkulere alderen "on the fly".

 

 

Eksempel:

CREATE TABLE person (

  person_id INT(6) AUTO_INCREMENT,

  fornavn VARCHAR(30) NOT NULL,

  etternavn VARCHAR(40) NOT NULL,

  fødselsdato DATE NOT NULL,

  --

  CONSTRAINT PERSON_PK PRIMARY KEY (person_id)

);

5565294[/snapback]

 

For det første er vel ikke personnummer karakterisert som fortrolig informasjon lenger, så jeg tror du skal ha lov til å lagre den informasjonen (Jeg ville dog selv ha dobbeltsjekket med datatilsynet). Men, det er verdt å merke seg at Personnummer (og D-nummer) ikke er en god idé av helt andre årsaker, det nemlig ikke gitt at en person beholder det livet ut, og i så tilfelle får du litt av en oppdateringsjobb.

 

Ofte kan det være anbefalingsverdig med en surrogatnøkkel, som du selv poengterer. Altså en primærnøkkel som ikke har noen betydning bortsett fra å identifisere en rad i tabellen.

 

Dersom du tenker fremover, på slike ting som sammenslåing av databaser fra to firma, bør nøkkelen være unik på tvers av installasjoner. Hvilke mekanismer MySQL har her vet jeg ikke, men i MSSQL har vi GUID (uniqueidentifier) som kan brukes til slikt.

[ofredstie]

And I quote:

"Fødselsnummer kan bare brukes når det er saklig behov, og når det er umulig å oppnå tilfredstillende identifikasjon ved bruk av andre metoder, som for eksempel navn, adresse, fødselsdato, medlems- eller kundenummer. (Personopplysningsloven § 12)"

ref: http://www.datatilsynet.no/templates/article____903.aspx

 

Ang at det ikke gitt at en person beholder det livet ut, det er tull og tøys.. hver person får ett personnummer når de blir født (basert på fødselsdatoen (som er umulig å bytte) og fem andre tall) og det beholder du hele livet.

 

Ang å slå sammen to databaser så går det greit også:

la oss si at to bedrifter har hver sin kundedatabase, DB1 og DB2.

DB1 har 2 500 registrerte kunder og kundenummerne går fra 0 001 til 2 500.

DB2 har 12 500 reg kunder og kundenummerne går fra 000 001 til 012 500.

Som du sa så vil vi nå ett problem, nemlig at de første 2500 kundene i DB2 har samme

id som i DB1..

 

En enkel måte å løse dette på er å legge til f.eks. 100 000 for hver kunde i DB1

(f.eks. 100 000 + 2 500) og 200 000 for hver kunde i DB2. Nå vet man at alle eksisterende kunder fra DB1 har id'er fra 100 001 til 102 500 mens kundene

fra DB2 har id'er fra 200 001 og 212 500.

 

Alle fremtidige kunder får id fra 300 000 og oppover (man kan definere hva slags tall man vil auto_increment skal starte på).

 

Eksempel:

CREATE TABLE db1_kunde (
kunde_nr INT(4) AUTO_INCREMENT,
fornavn VARCHAR(20) NOT NULL,
etternavn VARCHAR(30) NOT NULL, 
--
CONSTRAINT DB1_KUNDE_PK PRIMARY KEY (kunde_nr)
);


CREATE TABLE db2_kunde (
kunde_nr INT(5) AUTO_INCREMENT,
fornavn VARCHAR(25) NOT NULL,
etternavn VARCHAR(50) NOT NULL, 
--
CONSTRAINT DB2_KUNDE_PK PRIMARY KEY (kunde_nr)
);


CREATE TABLE nydb_kunde (
kunde_nr INT(8) AUTO_INCREMENT = 300000,
fornavn VARCHAR(30) NOT NULL,
etternavn VARCHAR(50) NOT NULL, 
--
CONSTRAINT NYDB_KUNDE_PK PRIMARY KEY (kunde_nr)
);


INSERT INTO nydb_kunde (kunde_nr, fornavn, etternavn)
SELECT db1.kunde_nr + 100000, db1.fornavn, db1.etternavn 
FROM db1_kunde db1;

INSERT INTO nydb_kunde (kunde_nr, fornavn, etternavn)
SELECT db2.kunde_nr + 200000, db2.fornavn, db2.etternavn 
FROM db2_kunde db2;

[Inc]

Mange flotte tips, takker:)

Tabellen var bare ett eksempel tatt i fra en guid for nybegynner, ikke tenkt mer på det.

 

Fødselsdato og personnummer i samme kolonne? eller personnummer for seg selv?

 

En enkel måte å løse dette på er å legge til f.eks. 100 000 for hver kunde i DB1

(f.eks. 100 000 + 2 500) og 200 000 for hver kunde i DB2. Nå vet man at alle eksisterende kunder fra DB1 har id'er fra 100 001 til 102 500 mens kundene

fra DB2 har id'er fra 200 001 og 212 500.

Hvis en gjør det slik (se litt fremover), så burde en vel passe på at marginene er rikelig i tilfelle det "utenkelige " skjer ved at du får f.eks mer en 100.000 e. 200.00 kunder i DB.1 før evt. sammenslåing av databaser? eller tar jeg feil nå...

Endret 7. februar 2006 av regga

[roac]

Ang at det ikke gitt at en person beholder det livet ut, det er tull og tøys..  hver person får ett personnummer når de blir født (basert på fødselsdatoen (som er umulig å bytte) og fem andre tall) og det beholder du hele livet.

5566280[/snapback]

En person får nytt personnummer dersom han foretar kjønsskifte, og slik jeg forstår det vil en person som har D-nummer senere kunne få et personnummer, men jeg er ikke helt sikker på dette.

Endret 7. februar 2006 av roac

[ofredstie]

Mange flotte tips, takker:)

Tabellen var bare ett eksempel tatt i fra en guid for nybegynner, ikke tenkt mer på det.

 

Fødselsdato og personnummer i samme kolonne? eller personnummer for seg selv?

 

Hvis en gjør det slik (se litt fremover), så burde en vel passe på at marginene er rikelig i tilfelle det "utenkelige " skjer ved at du får f.eks mer en 100.000 e. 200.00 kunder i DB.1 før evt. sammenslåing av databaser? eller tar jeg feil nå...

5566726[/snapback]

 

Fødselsdato for seg selv (som blir brukt til å kalkulere rett alder),

personnummer ville nå ikke jeg brydd meg om å legge inn (hvis databasen

skulle blitt brukt kommersiellt så hadde du nok kanskje fått problemer med

f.eks. Datatilsynet senere, ville nok ført til at du måtte endre databasen din

som igjen fører til mye ekstra hodebry for deg som utvikler).

Anyway, hvis du absolutt vil lagre personnummeret så ville jeg satt opp en egen

attributt med datatype INT(11), f.eks. "personnr INT(11) NOT NULL,".

 

Det stemmer det, men hvis du tar en nærmere titt på tabellen "nydb_kunde" så vil du se at attributen kunde_nr bruker datatypen INT(8).

Siden AUTO_INCREMENT begynner på 300 000 så betyr det at nye kunder kan ha kunde nummer fra 300 000 til og med 99 999 999, med andre ord så kan man legge inn .. hmm.. skavise... 99 600 000 nye kunder.. :o)

 

Med mindre du har STOOOORE planer for databasen din så vil dette sannsynligvis holde en god stund frem i tid.

[ofredstie]

En person får nytt personnummer dersom han foretar kjønsskifte, og slik jeg forstår det vil en person som har D-nummer senere kunne få et personnummer, men jeg er ikke helt sikker på dette.

5567374[/snapback]

 

Ok, kjønnskifte problemstillingen har jeg ikke tenkt over :o)

[Inc]

En person får nytt personnummer dersom han foretar kjønsskifte, og slik jeg forstår det vil en person som har D-nummer senere kunne få et personnummer, men jeg er ikke helt sikker på dette.

5567374[/snapback]

 

Ok, kjønnskifte problemstillingen har jeg ikke tenkt over :o)

5568119[/snapback]

Er det lov å skifte kjønn i norge da? hehe, jeg mener om du skifter kjønn blir en da "lovlig" omregistrert til det motsatte kjønn?

edit:

 

Det stemmer det, men hvis du tar en nærmere titt på tabellen "nydb_kunde" så vil du se at attributen kunde_nr bruker datatypen INT(8).

Siden AUTO_INCREMENT begynner på 300 000 så betyr det at nye kunder kan ha kunde nummer fra 300 000 til og med 99 999 999, med andre ord så kan man legge inn .. hmm.. skavise... 99 600 000 nye kunder.. :o)

Klart, men det er jo for nye kunder etter at de to .DB er lagt sammen.

Hvis du HAR de 2500 kundene i DB1, kan du da legge til 100.00 for hver kundenr men FØR du slår sammen to DB?

hehe, sorry vist dette virker teit, men jeg begynte med sql for to dager siden

Endret 7. februar 2006 av regga

[roac]

Er det lov å skifte kjønn i norge da? hehe, jeg mener om du skifter kjønn blir en da "lovlig" omregistrert til det motsatte kjønn?

5568212[/snapback]

Ja da, det er fullt lovlig, og du får nytt personnummer.

[ofredstie]

Nå er det ikke sånn at man legger til 100 000 i DB1, i steden så endrer man kunde_id'en fra f.eks. 2 345

til 102 345 (I DB2 så blir kunden med kunde_id 2345 endret til 202 345.. dermed har man løst problemet med to kunder i to forskjellige databaser som hadde samme kunde_id.)

 

INSERT INTO nydb_kunde (kunde_nr, fornavn, etternavn)
SELECT db1.kunde_nr + 100000, db1.fornavn, db1.etternavn
FROM db1_kunde db1;

INSERT INTO nydb_kunde (kunde_nr, fornavn, etternavn)
SELECT db2.kunde_nr + 200000, db2.fornavn, db2.etternavn
FROM db2_kunde db2;

 

Endringen av kunde_id'ene skjer når du legger inn dataene fra de to gamle databasene inn i

den nye (samlede) databasen.

[roac]

En person får nytt personnummer dersom han foretar kjønsskifte, og slik jeg forstår det vil en person som har D-nummer senere kunne få et personnummer, men jeg er ikke helt sikker på dette.

5567374[/snapback]

Ok, kjønnskifte problemstillingen har jeg ikke tenkt over :o)

5568119[/snapback]

Forsto det Før man velger en primærnøkkel så er det ekstremt viktig at man ser på alle sider ved denne, spesielt om det er noen som helst mulighet for at den skal endres, eller om det er noen som helst mulighet for at den ikke er unik. I dette tilfellet er det det første som er tilfellet.

 

Ellers kan jeg nevne at surrogatnøkler i aller høyeste grad kan anbefales, da man slipper unna slike problemstillinger. Typiske ting som jeg er skeptisk til å bruke som primærnøkkel er:

 

1. Kundenummer

2. Personnummer

3. Organisasjonsnummer

4. Telefonnummer

5. Epost-adresse

(Blant annet)

[Inc]

Nå er det ikke sånn at man legger til 100 000 i DB1, i steden så endrer man kunde_id'en fra f.eks. 2 345

til 102 345 (I DB2 så blir kunden med kunde_id 2345 endret til 202 345.. dermed har man løst problemet med to kunder i to forskjellige databaser som hadde samme kunde_id.)

Ok, et steg i riktig retning for min del

 

Ellers kan jeg nevne at surrogatnøkler i aller høyeste grad kan anbefales, da man slipper unna slike problemstillinger. Typiske ting som jeg er skeptisk til å bruke som primærnøkkel er:

 

5. Epost-adresse

(Blant annet)

Det har jeg faktisk lurt på og. At to mail adresser kan være like i samme firma. Da må vel feilen ligge hos dem?

Endret 7. februar 2006 av regga

[roac]

Ellers kan jeg nevne at surrogatnøkler i aller høyeste grad kan anbefales, da man slipper unna slike problemstillinger. Typiske ting som jeg er skeptisk til å bruke som primærnøkkel er:

 

5. Epost-adresse

(Blant annet)

Det har jeg faktisk lurt på og. At to mail adresser kan være like i samme firma. Da må vel feilen ligge hos dem?

5569077[/snapback]

Det er ikke nødvendigvis en feil. Gitt at du f eks selger noe hardware eller software, kan det være at flere firma ikke har egen it-avdeling men bruker en ekstern person. Som selvfølgelig er kontaktperson for _flere_ av dine kunder, og dermed står den samme epost-adressen flere ganger, selv om det er forskjellige kunder.

[Inc]

Men er det på samme måte som at det er en som har samme e-post adresse som min, ett sted der ute i verden?

Der hadde jeg faktisk ett tilfelle, en stund etter at mail adr. var opprettet så kom det en del feil mld og feil post til min mail som var tiltenkt en annen.

[roac]

Men er det på samme måte som at det er en som har samme e-post adresse som min, ett sted der ute i verden?

Der hadde jeg faktisk ett tilfelle, en stund etter at mail adr. var opprettet så kom det en del feil mld og feil post til min mail som var tiltenkt en annen.

5569277[/snapback]

Ikke to på en gang. Men, det kan (i tilfeller som når du har epost fra ISPen din, f eks NextGenTel) være at epost-adressen har vært i bruk tidligere.