Bra sätt att editera i MySQL-databas?

JimmyAndersson · Inlägg av **JimmyAndersson** » 6 september 2007, 20:32:41

Jo, det är jag igen som frågar massa grejjer..

Jag har kört fast lite i hur strukturen av en edit-del ska se ut.
Tanken är att man först söker efter en användare och får upp alla dess uppgifter. T.ex:

Kod: Markera allt

Användare    Lösenord     Status    Hemkatalog
-----------+-----------+----------+------------
  abc         4v8fhhvn       1      någon/katalog
  def         u6vnficv       1      annan/mapp

Lösenorden sparas i databasen i MD5-format och visas ju därför också i detta format.
För att göra visningen och ändringen smidigt så tänkte jag att uppgifterna visas i formulär-inmatningsfält.

Låt säga att jag vill ändra användare abc's status. Sparar jag hela raden (användarnamn, lösenord osv) så blir ju lösenordet helt tokigt. Att ha en liten kryssruta eller liknande för de fält som ska sparas känns oöverskådligt och blir inte så snyggt, men det är iallafall en möjlig lösning.

Eller finns det någon som har en bättre idé?

Micke_s · Inlägg av **Micke_s** » 6 september 2007, 20:43:09

Vad vill du uppnå med Status?

Annars så kanske en stored procedure som tar användarnamn och ny status vettigt så du skiljer vilka som kommer åt lösenorden.

Du kan t.ex. se till att anv inte har acess till tabellerna men kan köra stored procedures för ändra saker i tabellerna.
Edit: så kan du validera datan du får in också.

JimmyAndersson · Inlägg av **JimmyAndersson** » 6 september 2007, 20:52:51

Status betyder om kontot är aktivt. 1 = aktivt. 0 = inaktivt.
En etta indikerar alltså att användaren kan logga in på sitt konto.

Glömde skriva att koden/sidan inte är tillgänglig för användarna. Det är alltså min admin-sida.

cykze · Inlägg av **cykze** » 6 september 2007, 21:02:00

Du kan väl låta lösenordsfälten vara tomma som standard. För att ändra lösenordet för ett visst konto så fyller man helt enkelt i ett lösenord i det fältet.

Sen kollar du i PHP-koden vilka lösenordsfält som är icke-tomma och uppdaterar bara dom i databasen.

JimmyAndersson · Inlägg av **JimmyAndersson** » 6 september 2007, 21:53:37

Det var en bra och enkel idé!

Tänk vad det kan ge mycket när man lägger ut problem på entreprenad i en tråd.

sodjan · Inlägg av **sodjan** » 6 september 2007, 22:24:29

Om du måste blanda in lösenord alls på denna sida, så väl tanken med
blanka pw-fält (= ingen ändring) det bästa som går att åstakomma.

Annars skulle man kunna lägga ut en så pass känslig operation
som att sätta pw på en separat sida.

MD5-hashas pw automatisk av databasen när PHP uppdaterar det ?
Du hade ju problem tidigare med att du fick in klartext-pw i databasen...

Status skulle jag göra till radiobuttons eller dropdown.

För övrigt så känns det lite konstigt (för mig) att ha ett lösenord
*inne* i databasen. Jag är van vid att användaren får sina rättigheter
via inloggningen till OS'et...

JimmyAndersson · Inlägg av **JimmyAndersson** » 6 september 2007, 22:38:06

Blanka pw-fält = ingen ändring var en bra idé.

MD5-hashas pw automatisk av databasen när PHP uppdaterar det ?
Du hade ju problem tidigare med att du fick in klartext-pw i databasen...

Jo, jag tidigare hade jag missat att lägga till MD5 i "INSERT INTO"-delen. Det var därför det blev knasigt.

Status regleras egentligen med radiobuttons. Det var bara svårt att få det
snyggt med ascii-tecken, så det fick bli en etta eller nolla, vilket är precis
det som sparas i det tabellfältet.

För övrigt så känns det lite konstigt (för mig) att ha ett lösenord
*inne* i databasen. Jag är van vid att användaren får sina rättigheter
via inloggningen till OS'et...

Du har helt klart en poäng där.

I det här fallet så gäller däremot
lösenorden inloggningen till en ftp-server, så då mailar jag istället uppgifterna.
Det mailet skulle iofs kunna genereras automatiskt, men det får komma i nästa version.

sodjan · Inlägg av **sodjan** » 6 september 2007, 22:42:41

Nu är jag inte med...

Är FTP-servers pw inte samma som OS'ets ??
Är det inte en vanlig "user" som man loggar in till ?

Intressant...

speakman · Inlägg av **speakman** » 6 september 2007, 23:05:09

Menar du att du bara vill uppdatera "status"-fältet för användaren "abc"?
Isåfall äre UPDATE usertable SET status = 1 WHERE Användare = "abc";
Du bör dock lägga till ett indexfält med primärnyckel och autoräknare, som ALTER TABLE usertable ADD COLUMN id INT PRIMARY KEY AUTOINCREMENT FIRST;.
Och sedan göra alla ändringar mot id: WHERE id = $userid osv...

sodjan · Inlägg av **sodjan** » 7 september 2007, 10:45:26

På vilket sätt är det bättre att lägga dit en egen "id" än att bara indexera
"Användare" ? Jag kan tänka mig för att underlätta RI mot andra tabeller,
men så länge som det (som i detta fall) bara är en tabell ?

JimmyAndersson · Inlägg av **JimmyAndersson** » 7 september 2007, 13:38:54

sodjan:

Är FTP-servers pw inte samma som OS'ets ??
Är det inte en vanlig "user" som man loggar in till ?

Jasså, du menar så.

Jo det stämmer.
Men lösenordet och deras övriga uppgifter lagras i både OS'et och databasen.

Såhär fungerar det när jag lägger till en användare:

1) Jag (som admin) skriver in användarens namn, lösen, hemkatalog,
grupp-id, bandbredd, utrymme (max antal MB), osv.

2) Användarnamnet skapas i OS'et och läggs till i rätt grupp.

3) Första gången användaren loggar in så skapas dess hemkatalog och
ges rätt rättigheter. Det går så fort att användaren upplever att katalogen
redan fanns där från början.

Det kan hända att jag missförstod dig igen, men det lär jag snart få veta isåfall.

Mycket bra idé att indexera "Användare". Men jag hittar inte hur koden ska se ut för att söka efter index. Dvs vad heter kolumnen index? Att söka efter php mysql index gav nästan 13 miljoner träffar eftersom sökningen även hittar .index-filer...

sodjan · Inlägg av **sodjan** » 7 september 2007, 13:58:40

Index används automatisk om de finns. Det avgör query-optimizern själv.

Notera att index inte alltid används, om det är väldigt få poster i tabellen
eller om optimizern gissar att det är en rellativt stor andel av posterna
som du vill ha, så är det snabbare att läsa tabellen direkt.

Det är här kardinalitetsvärderna kommer in i bilden. D.v.s det antal poster
som detabasen *tror* att det ligger i tabellen. Om man alltså har en stor
tabell men ett felaktigt kardinalitetsvärde (för lågt) så kommer optimizern
att tro att tabellen är liten, och köra en table-scan istället för en index-lookup.
Det var just det som hände med forumet när det var slött någon gång i våras.
En uppdatering av kardinaliteterna hjälpte i det fallet...

> Men jag hittar inte hur koden ska se ut

Som vanligt...

JimmyAndersson · Inlägg av **JimmyAndersson** » 7 september 2007, 14:34:58

Aha. Tänka sig, man blir lite klokare för varje dag som går..

> Men jag hittar inte hur koden ska se ut

Som vanligt...

Ja..

Nåväl, jag får fortsätta leta. Svaret brukar finnas, det gäller bara att hitta det.

sodjan · Inlägg av **sodjan** » 7 september 2007, 14:38:17

>Nåväl, jag får fortsätta leta.

Leta efter vadå ?
Du ska inte ändra någonting i din SQL kod.
Eller menar du syntaxen för att *skapa* ett index ??

JimmyAndersson · Inlägg av **JimmyAndersson** » 7 september 2007, 14:54:55

Äh, nu förstår jag. Du menade att *koden* ska se ut "som vanligt".

Jag trodde du menade att jag inte hittar något "som vanligt".

Svårt att veta, ibland får man "RTFM" som svar, så jag är beredd på allt...

Nädå, syntaxen för att skapa index kan jag.
Men då behöver jag alltså inte blanda in index i koden för att söka i tabellen?