[Løst] Bruke foreign key til betalingsløsning ?

[pedero]

Hei, holder på å designe et system der brukere kan legge til flere typer betalingsløsninger(paypal, visa, mastercard osv.).

 

Så da lurte jeg på hvilken av disse to løsningene er best:

 

1.database map betaling og brukere løsning 1.bmp

 

2.database map betaling og brukere løsning 2.bmp

 

(De blå boksene representere en tabell hver.)

 

Jeg har lest at man skal bruke foreign key til felt der det er mulig med forskjellige versoner av samme data(f.eks 5th standard elelr fifth standard). men siden brukeren er nødt til å velge en av betalingsløsningene vil det antageli vis ikke bli noen forkjellige versoner. Men det ville selvsagt igjen vært snedig med en egen tabell med hver tabelløsning.

 

Så hva synes dere er den beste løsningen ?

Endret 1. februar 2015 av pedero

[ahw_]

Du bør absolutt dele opp tabellene slik at systemet blir mer modulært. Du kan tenke på hver tabell som en klasse, og har ikke nødvendigvis noe med versjon å gjøre. Bruk av foreign keys gir deg gratis beskyttelse mot korrupsjon som følge av at data endrer i bare én tabell. Bruker du foreign keys blir endringer i én tabell (kolonner som er satt om med foreign key) nektet med mindre du vil at data i andre tabeller også skal endres samtidig (automatisk). Har du f.eks. en løsning som heter "paypal" kan man være sikker på at navnet på denne ikke bare kan byttes om til noe annet i kun én tabell, fordi det bryter med restriksjonene satt opp med foreign key'en.

 

Sannsynligvis vil du uansett få bruk for mer detaljer om en Betalingsløsning senere; dette har ingenting med selve betalingen å gjøre, og bør derfor ikke blandes inn i tabellen Betaling.

Endret 1. februar 2015 av ahw_

[pedero]

Du bør absolutt dele opp tabellene slik at systemet blir mer modulært. Du kan tenke på hver tabell som en klasse, og har ikke nødvendigvis noe med versjon å gjøre. Bruk av foreign keys gir deg gratis beskyttelse mot at data endrer seg uten at det enten endrer seg i andre tabeller, eller at endringen blir nektet.

 

Sannsynligvis vil du få bruk for mer detaljer om en Betalingsløsning senere; dette har ingenting med selve betalingen å gjøre, og skal derfor ikke i tabellen Betaling.

okei, og bare for å presisere så er betaling en database over paypal eposter, kortnummer osv. ikke selve transaksjonene, de vil bli lagret i en annen tabell.

[ahw_]

 

okei, og bare for å presisere så er betaling en database over paypal eposter, kortnummer osv. ikke selve transaksjonene, de vil bli lagret i en annen tabell.

 

Jeg redigerte innlegget mitt før du svarte meg. E-post bør du egentlig ikke ha under betaling heller. Det bør du ha sammen med andre bruker/addresse/kontakt-detaljer som kan være i en egen tabell som du setter opp med foreign key fra Betaling. Kortnummer har du ikke bruk for dersom folk betaler med PayPal.

Endret 1. februar 2015 av ahw_

[pedero]

 

 

okei, og bare for å presisere så er betaling en database over paypal eposter, kortnummer osv. ikke selve transaksjonene, de vil bli lagret i en annen tabell.

 

Jeg redigerte innlegget mitt før du svarte meg. E-post bør du egentlig ikke ha under betaling heller. Det bør du ha sammen med andre bruker/addresse/kontakt-detaljer som kan være i en egen tabell som du setter opp med foreign key fra Betaling. Kortnummer har du ikke bruk for dersom folk betaler med PayPal.

 

tingen er at jeg skal ha mange forskjellige betalingsmuligheter, paypal, visa osv. så da lagrer jeg alt i samme tabell. Da vil epost i betalings tabellen være eposten til paypal. Jeg har tenkt litt og funnet ut at denne løsningen er best, hvis jeg skulle ha separet paypal, visa osv. ville det ført til en veldig komplisert database, derfor tror jeg det er lurere og ha en del rader som står som null.

[quantum]

Det er nok ikke best å lagre alt i én tabell. Det er faktisk værst. Du er på rett spor i figur 1, bortsett fra at epost-adresse ligger i feil tabell, som noen allerede har påpekt.

[pedero]

Det er nok ikke best å lagre alt i én tabell. Det er faktisk værst. Du er på rett spor i figur 1, bortsett fra at epost-adresse ligger i feil tabell, som noen allerede har påpekt.

Skulle vel ha skrevet paypalepost isteden siden paypal jobber med eposter(tror ihvertfall det)

[quantum]

De fleste jobber med epost. Hva skal epost-adressen brukes til?

[pedero]

De fleste jobber med epost. Hva skal epost-adressen brukes til?

JEG TROR PAYPAL BRUKER EPOST SLIK VISA BRUKER KORTNUMMER

[ahw_]

JEG TROR PAYPAL BRUKER EPOST SLIK VISA BRUKER KORTNUMMER

Det du vanligvis skal forholde deg til er den unike transaksjons-ID'en du får fra PayPal og andre tjenester.

 

Jeg kan ikke se at e-post-adressen til personen som betalte er brukbar til noe dersom personen allerede har registrert sin e-post-addresse hos deg på forhånd. Man kan også ha flere e-post-adresser registrert hos PayPal, så hva skjer når kunden sletter den du fikk da kunden betalte?

 

Å lage et godt og sikkert system for å prosessere betalinger og ordrer er ikke lett. Hva skjer hvis noe går galt i prosessen? Hvordan kan du på pålitelig vis håndtere at prosessen ikke fullføres helt eller delvis?

[quantum]

Da er det vel isolert sett greit nok slik du har modellert det. Dersom du får flere varianter enn kortnummer og epost kan du vurdere å legge det i samme felt, og la den tilknyttede betalingsløsningen avgjøre hvordan det skal tolkes. Det er uansett mest praktisk å ha kredittkortnummeret som en streng når det skal valideres.

Endret 2. februar 2015 av quantum

[pedero]

 

JEG TROR PAYPAL BRUKER EPOST SLIK VISA BRUKER KORTNUMMER

Det du vanligvis skal forholde deg til er den unike transaksjons-ID'en du får fra PayPal og andre tjenester.

 

Jeg kan ikke se at e-post-adressen til personen som betalte er brukbar til noe dersom personen allerede har registrert sin e-post-addresse hos deg på forhånd. Man kan også ha flere e-post-adresser registrert hos PayPal, så hva skjer når kunden sletter den du fikk da kunden betalte?

 

Å lage et godt og sikkert system for å prosessere betalinger og ordrer er ikke lett. Hva skjer hvis noe går galt i prosessen? Hvordan kan du på pålitelig vis håndtere at prosessen ikke fullføres helt eller delvis?

 

Takk for tipset, har ikke vunnet å se på alle detaljer rundt betaling ennå.