Hej V5.

Det sådan at jeg også snart skal har en slags medlemskab hjemmeside hvor mine kunder betaler for undervisning.

Derfor vil jeg høre om i havde nogle forslag til database opsætning.

Jeg er derfor helt sikker på at databasen godt kan blive forbedret.

Membership bliver sat samme med min brugere table.

Membership bruges til:

fk_brugerid -> Hvilke brugere har købt.

fk_oplysninger -> Hvad er kundens adresse, postnr mv.

opsagt -> er det opsagt ja eller nej?.

opsagtdato -> hvornår blev det opsagt.

betaltdato -> Hvornår har brugeren købt medlemskabet.

fk_prisid -> Hvilke pakke har brugeren købt.

Tilbagebetalt -> vil kunde ha penge tilbage eller ej?.

Tilbagebetaltdato -> Hvornår er det gjort.

Betalingid -> Hvilket abn nr få kunden?

Oplysninger

- Ja, der er ikke så meget at sig. den giver lidt sig selv.

Pris bruges til:

navn -> hvad kalder jeg pakken.

fk_prisid -> hvilke pakke har kunden købt

PrisValue

pristal -> det er prisen på pakken.

mdr -> er hvor mange måneder kunden har købt.

abnValue -> er hvilke værdi Epay eller Quickpay bruger til Abn for at det køre osv.

(Måske har du nogle forslag Daniel til hvad jeg kan lave om?)

Der er mange måder at opbygge en database på, og det er naturligvis vigtigt at få struktureret data godt fra starten, således de er fleksible og nemt kan udbygges. 

Personligt ville jeg starte med at omdøbe alle feltnavnene til engelsk, jeg kan se du også selv at støt på at tabelnavnet "by" kan give problemer, hvorfor den nu hedder "byen". Udover det så har vi et karaktersæt i Danmark med æøå som ikke gør sig godt i kode.

Ydermere kan jeg se du ikke har meget konsekvens i din navngivning, bruger du camelCase? bruger du UpperCase eller bruger du lowercase? Sæt en standard og hold dig til den, ellers er du nød til at slå op i databasen, hver gang du vil kode noget, fordi du ikke kan huske om det var BetaltDato, betaltDato eller betaltdato.

Selve strukturen på databasen er fint nok, de data du oftest bruger, altså din core user-data som username, hashed password, e-mail mm. samles i éen tabel. Andre data der ikke bruges ofte samles i en anden tabel som kan JOINs når behovet er der, og kundens abonnementer samles i en tredje tabel.

Held og lykke med dit projekt.

~ Daniel

Jeg er enig om at det skal være nemt at udbygges til hvis den senere med tiden skulle kun noget mere f.eks.

Jeg har ikke haft problemer tidligere med at bruge "byen". Jeg har dermed også opbygge min egen hjemmeside i MVC, Linq :).

Jeg bruger Microsft SQL Server management studio til at opdater database, tilpasse database og samt ret i den.. Da jeg bruger C# har jeg letter ved at tilpasse navne på de forskellig områder.

Dermed hjælper LINQ dig også med at huske navne på de forskellig områder. Som du kan se et lille billede af her.

Der er jeg enig med at jeg laver en INNER join til brugere tablen.

 #2  Der findes mange værktøjer til at hjælpe og lave autocompelte på database-felter mm. - det ændre dog ikke på at struktur, ensartedhed og konsekvens igennem hele forløbet er værdsat in my humble opinion, især hvis det nu skulle blive et større foretagende og der kommer andre udviklere indover, eller du skal integrere data med andre systemer.

BY er en SQL-query kommando som bruge bl.a. efter ORDER eller GROUP, du kan godt bruge "By" som et feltnavn i de fleste database ved at enclosure feltnavnet i f.eks. '-tegn, du vælger som alternativ at bruge feltnavnet "byen", med det bedste ville være; City. Så støder du ikke på feltnavne med æøå eller By :-)

Du spurgte om min feedback :-) Den er hermed givet.

Der er vi enig om at der findes. Den kan sikkert godt laves på mange andre måder men jeg vil bare del min bruger table op og min kunde medlemskab op i en anden table.

Det ved jeg godt ang "BY" som f.eks her

SELECT column_name, aggregate_function(column_name)
FROM table_name
WHERE column_name operator value
GROUP BY column_name;

Det kun muligvis godt være at jeg skulle lave den om til "City" så jeg sikker mig at jeg ikke kommer ind i problemet, hvis det nu skulle komme på et tidspunkt :) 

- Takker mange gange for feedback. Det er altid skønt at se tingene med ændre øjne :)

Jeg laver alt på engelsk, nu da kodesproget også er engelsk. Det skaber ensartethed og jeg bliver aldrig forvirret. Plus, at hvis jeg skal finde noget specifikt hjælp - jeg ikke lige kan huske. Så kan jeg tage det dirkete fra koden. Så er chancen for at jeg for et hit på Google hundrede gange større, end hvis jeg skulle oversætte/visse en anden person end lige dansk min kode/søge på keywords.

Opdelingen ser fin ud i min verden. Men jeg ville personligt aldrig bygge noget som kræver at jeg skal bevare kodeord i min egen database. Det gør mange andre meget bedre - og så er sikkerheden allerede meget højere. Hvorfor opfinde den dybe tallerken to gange?

Dog med det sagt, så er det selvfølgelig sådan noget som abbonomenter og datoer - som jeg så fint selv ville gemme hvis absolut nødvendigt.

Det var så lige mine to "cent" jeg ville komme med. Som jeg personligt gør det i dag, efter 10+ år på bagen.

 #5  Enig, normalt vil jeg også opbygge det på engelsk. men jeg arbejder lige pt på at gøre hjemmesiden endnu bedre med databasen og de andre små ting.

Det lyder godt. 

Okay ;)

Hvad er det for nogle  du vil tag med?

 #6  Jeg er ikke helt med, ang. hvad du mener med at "tage med". Da jeg jo ikke ved præcist hvad du laver videoer om osv.

Ang. oplysninger, så ville jeg have adresser i en table for sig selv. (Perosnlig præference.) Og så ellers "JOINE" med user_id felt. Evt. også brug tredjeparts scripts for at undgå at folk skriver en adresse ind som faktisk ikke eksistere. (Ligesom Stofa eksempelvis gør det, når man søger på ders driftstatuser.)

Der er millioner af måder at gøre det på og man kan altid finjustere. Først og fremmest ville jeg have en prototype op og stå med de data jeg tror at jeg for brug for, for derefter at gå det igennem med en "kam" og se hvad jeg kan undlade. Eksmepelvis hvis jeg nu benytter mig af Facebook login eller en anden/andre tjenester til at logge ind med. Så kan jeg jo egentlig undgå at have mail adresser i min database. (Medmindre hvis folk jo så har muligheden for, at lave en bruger i selve systemet.)

Mit største tip, er at gå langsomt fremad - byg og byg. Især når det har med personlige data at gøre. Vi har jo love og regler her hjemme omkring personlige data også. Det skal gennemtænkes for alt i verden. (Både for din og kundens skyld.)

Især hvis du bruger PHP skal du være ekstra opmærksom. PHP er et dejligt sprog, men det har sine mange svagheder. Især ang. sikkerhed. (Det er nemt at lave fejl i.) Men det kan jo så måske også diskuteres i sidste ende. Det handler vel også lidt om smag. (Personligt rør jeg aldrig PHP, medminre at det er til prototyper.)

 #7  Jeg vil helt klart tag nogle af de ting med som du fortæller og siger til mig, og jeg er enig om at man må starte et sted og så gå videre der fra.

Jeg vil lige prøv at søg rundt på nettet og se om jeg kan find en løsning som jeg måske kan kig på eller arbejder videre fra.

- Jeg arbejder ikke med PHP. Dermed arbejder jeg med C#

 #8  C#? Så er hvad du laver vel en native App? (Altså ikke en desideret hjemmeside.) Der skal du jo bruge nogen andre teknologier.
Jeg vil med glæde komme med input hvis du senere skulle være i tvivl. Fire øjne er trods alt bedre end to. Om ikke andet, så bare for input.

 #9  C# det er programmering-sprog, Der er forklaring her.

Det er jeg også glad for :) og jeg er enig med at det er langt bedre.

Jeg vil prøv at gå videre med det.

Besvar#11 @psto kommenterede for 2 år siden

@DHH: Hvordan gør du i forhold til opbevaring af kodeord?

 #10  Jeg ved skam godt hvad C# er. Jeg rodede lidt med det. Men som hjemmeside sprog, kan jeg ikke se idéen med det. Jeg er selv gået helt oldschool fordi jeg vil lave til Linux kernen. (C.) Så det er hvad jeg leger med lige pt. Er ved at se en masse Universitets matriale igennem en lære jeg kender i Australien. (Det gavner at have sine kontakter. Så jeg kan se hans lektioner han har lavet før.)

 #11  Det lader jeg så vidt som muligt andre tjenester om. Så jeg aldrig skal have det i en database. Facebook, Twitter osv.
Hvis det dog ikke er muligt, kender jeg nogen gode kryptografer og nørder inde for feltet i U.S.A som giver mig tips og tricks - og som jeg kan spørge hvis jeg bliver helt i tvivl. Jeg kan dog hurtigt sige at du skal holde dig fra at gemme det i en database med samme navn som din hjemmeside. (Brugeren der logger ind.) Og meget mere i den dur. Din MySQL eller hvad for en server du benytter skal jo være sikker. Der findes tonsvis af god information til netop dette ude på nettet. Tjek evt. rundt på hacker forums, eller sågar StackOverflow.

Og når du så gemmer selve din hash + salt, så for alt i verden ikke benyt dig af MD5 eller SHA1. Find noget bedre. Det emne her, kunne i sig selv give en bog alene. Så det er hvad jeg lige kan skrive, imens at jeg sidder i et tog som hopper og danser imellem Odense og Århus lige pt. Fortsat god Søndag. :)

Besvar#13 @psto kommenterede for 2 år siden

 #12  interressant :)

Hvad gør du @daniel i forhold til brugerdata?