Komponent-databas och SQL

[sodjan]

Helt rätt maha. Bara en liten sak.

Notera att mySQL på *Windows* inte är case-sensitive för
tabell- och fält-namn. Det följer det underliggande OS'et
(varför det nu ska göra det !?) så på unix/linux blir det det.
Däremot är SQL i sig *aldrig* case-sensitive.

Personligen föredrar jag om allt är case-insensitive. Det finns
ingen som helst anledning att "PHONE" och "phone" ska vara
två olika saker.

Såg förresten nyss att mySQL inte stöder vyer ("views"). Så synd !
Lite konstigt med tanke på den ställning mySQL har fått. Men en
gratis produkt kan väll få hur stor spridning som helst hur
dåligt den än är.

Jag såg också att man inte kan ta en transaktions konsistent
backup *online* (d.v.s med aktiva användare på databasen).Det
trodde jag också var standard på databashanterare. (Om man inte
kör speglade databaser, men det är ju lite fusk...)

[oJsan]

Såg förresten nyss att mySQL inte stöder vyer ("views").
...ja om man använder en äldre version än 5.0 så är det så.

http://dev.mysql.com/doc/refman/5.0/en/views.html

[JimmyAndersson]

sodjan:
"Klarar mySQL av object med svenska tecken ?"

Troligen inte. För att vara säker så brukar jag aldrig använda svenska tecken när det rör object, filnamn, sökvägar mm. I inlägget skrev jag sådär bara för att göra texten så tydlig som möjligt.

"Så här ser det ut efter uppsnyggning och borttagning av onödiga fält (specielt i "hemmalager" !)"

Var lite rädd för att hemmalager-tabellen skulle innehålla massa onödigt, men jag provade för att se hur fel jag hade tänkt.


Tack för korrigeringarna, sodjan & maha!

Kopplingen mellan "levlager.värde" och "komptyp.beskrivning" kan bli ett frågetecken, men annars känns allt logiskt och begripligt.


Nu ska jag släpa hem min nya digitalmixer från posten. Kommer säkert bli några timmars testande om jag känner mig själv rätt, men ikväll ska jag börja lägga upp databasen och börja skissa på ett nytt GUI för sidorna. Jag tror att det finns en risk för att det blir för många dropdown-menyer, men det märker man nog när man börjar skissa.


edit:

Såg oJsan's inlägg nu och kollade på länken:
"Views are available in binary releases from 5.0.1 and up."

Jag har PHP 5.1.2-1 så alltså kan jag använda view's. Någon får gärna berätta lite mer om fördelarna med views.

[sodjan]

>> Såg förresten nyss att mySQL inte stöder vyer ("views").
> ...ja om man använder en äldre version än 5.0 så är det så.

Perfekt. I den bok jag lånade förra veckan på biblioteket
(som kom ut under V4-tiden) står det att views "antagligen"
skulle komma i en "senare V5 version". Skulle ha kollat
med mySQL sidan också...

Men då så, då kan du använde det, Jimmy, för att förenkla
interfacet från databaseb mot din PHP kod. Och "priset" i
mer komplex programmering därför att man normaliserar
databasen hårdare blir inte lika högt. Notera bara problemet
med ORDER BY som nämns på sidan som oJsan länkade till !

> för många dropdown-menyer,

Vad är "för många" och vad är det som begränsar ?

[oJsan]

Kopplingen mellan "levlager.värde" och "komptyp.beskrivning" kan bli ett frågetecken[...]
Kopplingen sker med "levlager.komptyp_nr" mot "komptyp.komptyp_nr"
...eller förstod jag inte frågan riktigt?

[JimmyAndersson]

sodjan:

> för många dropdown-menyer,

Vad är "för många" och vad är det som begränsar ?

Det som begränsar är ifall användargränsnittet ser för rörigt ut, dvs om det är så pass många dropdown-menyer att menyn hamnar framför en annan när den "fälls ner". Har sett det fenomenet på några bank-sidor och det ser så rörigt ut. Men det ger sig nog när jag skissar upp användargränssnittets utseende. Har inte kollat hur många ställen det behöver vara menyer på, men det känns som om det är ganska många.

oJsan:
Det löser sig nog när jag börjar koda.

edit: sodjan beskrev precis vad jag menade i inlägget nedan.

[sodjan]

> Någon får gärna berätta lite mer om fördelarna med views.

Antag att du vill lista ditt "hemmalager", utan views skulle det kunna se
ut ungefär så här (otestad kod !) :

Kod: Markera allt

  select 
    hemlager.hemlager_nr,
    hemlager.antal,
    levlager.levlager_nr,
    levlager.value,
    levlager.artnr,
    komptyp.beskrivning,
    lev.namn
  from
    hemnlager, levlager, komptyp, lev
  where
    hemlager.levlager_nr = levlager.levlager_nr AND
    levlager.komptyp_nr = komptyp.komptyp_nr AND
    levlager.lev_nr = lev.lev_nr
  order by <någonting>

Detta får du alltså skriva i din PHP kod *varje gång* du
söker från ditt "hemlager" !!

Om du istället först gör (i databasen, i förväg) :

Kod: Markera allt

create view hemlager_view as
  select 
    hemlager.hemlager_nr,
    hemlager.antal,
    levlager.levlager_nr,
    levlager.value,
    levlager.artnr,
    komptyp.beskrivning,
    lev.namn
  from
    hemnlager, levlager, komptyp, lev
  where
    hemlager.levlager_nr = levlager.levlager_nr AND
    levlager.komptyp_nr = komptyp.komptyp_nr AND
    levlager.lev_nr = lev.lev_nr
  order by <någonting>

så räcker det med att från PHP göra :

Kod: Markera allt

 select * from hemlager_view

Finessen är alltså att "Create view" gör du *EN* gång, medan
"select ... from hemlager_view" gör du så mycket du vill...

Blev det klart ?

Som du ser kan du (inom rimliga gränser) även ändra den fysiska
tabell designen t.ex lägga till något mer, justera "hemlager_view" och
(i bästa fall) inte behöva göra några (större) ändringar i koden.

Notera också att mitt exempel inte är helt bra, man ska nornalt aldrig
använda "select stjärna" i kod, det blir latenta buggar och det försvårar
framtida underhåll av databasen. Om det är en view man kör mot,
kan det dock vara OK, man kan ju lägga till fält i tabellerna utan att
ändra vyn och på så sätt ger "select *" från vyn fortfarande samma resultat...



oJsan:
> Kopplingen mellan "levlager.värde" och "komptyp.beskrivning" kan bli ett frågetecken[...]
> Kopplingen sker med "levlager.komptyp_nr" mot "komptyp.komptyp_nr"
> ...eller förstod jag inte frågan riktigt?

Nja, det var mer frågan om vad som ska in i fältet "värde" resp "beskrivning".
Det är inte solklart för alla komptyper vad som är vad...
*Kopplingen* mellan tabellerna är dock inget problem...

[JimmyAndersson]

"Finessen är alltså att "Create view" gör du *EN* gång, medan
"select ... from hemlager_view" gör du så mycket du vill...

Blev det klart ?"

Jajjamensan. Glasklart.
Mycket smidigt!

[sodjan]

Perfekt

*Nästa* arbetsbesparande finness att "dyka ner i" är "stored procedures" och
"stored functions". Alltså där man lägger standard SQL som man använder
ofta som en proc/func i databasen som sedan bara anropas från SQL med CALL.

Men det är kanske en liten bit dit än...

[kimmi]

hi,
från CIRCUITCELLAR ,

Build a PHP Components Database
by Keith Brown
Keith introduces you to the LAMP software suite and walks you through your first PHP project: a program for logging and tracking your parts. Now you can use your favorite browser to access your programs without having to generate a GUI for new applications.

Keywords: PHP, database, LAMP, MySQL

link Zip file
vet inte om det er noget men ser bra ut .

[speakman]

Notera att mySQL på *Windows* inte är case-sensitive för
tabell- och fält-namn. Det följer det underliggande OS'et
(varför det nu ska göra det !?) så på unix/linux blir det det.
Däremot är SQL i sig *aldrig* case-sensitive.

Det går att konfigurera MySQL att vara case insensitivt även på *IX.

Såg förresten nyss att mySQL inte stöder vyer ("views"). Så synd !
Lite konstigt med tanke på den ställning mySQL har fått. Men en
gratis produkt kan väll få hur stor spridning som helst hur
dåligt den än är.

Nu fanns ju views som sagt, men jag skulle definitvt framhålla PostgreSQL som "the one" free software SQL-server. MySQL ligger *många* år efter, och jag kan heller inte förstå hur den kan framstå som den gör idag. Bra PR?

Jag såg också att man inte kan ta en transaktions konsistent
backup *online* (d.v.s med aktiva användare på databasen).Det
trodde jag också var standard på databashanterare. (Om man inte
kör speglade databaser, men det är ju lite fusk...)

Vet inte vad du menar riktigt, men replikering fungerar ju i MySQL, om än j-vligt pissigt då binärloggen bara växer och växer (fixas dock efter lite scriptande, men ska det verkligen vara nödvändigt?).
Sedan har du ju mysqlhotcopy som jag antar gör ungefär det du pratar om.

[sodjan]

Vad jag menar med vadå ?

mysqlhotcopy ? Ett PERL script som någon har slängt ihop ?
Självklart ska funktioner för så centrala funktioner som backup
ingå i databas distributionen och vara "rock-solid". Backup får
*ALDRIG* klicka. Jag skulle inte lita på något så svajigt
som mysqlhotcopy verkar vara. Bara att kolla kommentarerna
på sidan...

Men som sagt, vad var det som var oklart ?

[speakman]

Nej, mysqlhotcopy ingår som en del av administrationsverktygen i MySQL och därför även skrivet *av* MySQL (och även i samma "klass" då givetvis).
Och mig veterligen är den lika solid som databasen i sig, och det den gör är att traversera alla tabeller; gör en skrivlåsning på en tabell, dumpar ut den på valfritt vis, låser upp den igen, och tillsist vidare till nästa tabell.
All skrivning till den låsta tabellen "haltar" klienterna (men inget fel returneras), så i de flesta fallen med snabb server och disk så går förfarandet väldigt fort.

Som sagt, tillvägagångssättet är väl kanske lite primitivt men det funkar säkert till drygt 99% av vad MySQL används till.
För säkrare backup är det replikering som gäller, och backuptagning av slavservern. Då blir inte klienter lidande heller.

Det jag inte var säker på var vad du menade med online backup vilket det finns många tillvägagångssätt för, bl.a. mysqlhotcopy (alt. med replikering).

Jag tror det är väl hårt att jämföra MySQL med Oracle, men samtidigt tror jag inte Jimmy vill köpa en Oracle-licens (eller flera för att kunna göra egna strukturer, och utan begränsningar på tabellmängd och datamängd) för sitt lilla komponentprojekt.

Nu är jag dåligt uppdaterad på PostgreSQL eftersom jag (tyvärr) hållit på mest med MySQL, men vad jag kom ihåg när jag jämförde dom så hade PostgreSQL allt + ännu mer för länge sedan, än vad MySQL har idag.
Och med högsta sannolikhet finns betydligt bättre backuprutiner implementerad där också.
Detta kanske är något?

[sodjan]

Att den är "online" betyder att det körs samtidigt som det ligger
användare mot databasen.

Att den är "konsistent" betyder att det inte finns data i olika delar
(tabeller, filer, tablespaces, whatever) av databasen som kommer
från olika "point in time" eller att det inte finns några "split transactions".

> gör en skrivlåsning på en tabell, dumpar ut den på valfritt vis, låser
> upp den igen, och tillsist vidare till nästa tabell.

Betyder inte det att en tabell *senare* i backupen kan ha uppdatteringar
som ligger efter i tid än en av de tidigare tabellerna ? Alltså att tabell-2
i exemplet ovan inte är låst (för uppdatering) medan tabell-1 backas upp ?
I så fall är backupen inte konsistent.

Det framgår inte heller hur mysqlhotcopy jobbar ihop med transaktioner
på databasen. Vem som väntar på vem, o.s.v

Replikering är OK men ger dubbla lagringsvolymen (och eventuella
prestanda problem i själva replikeringen i sig).

PostgreSQL löser detta genom recover från transaktionsloggarna, vilket
också "fungerar", men men en jäkla massa hand-jagande av filer
kors och tvärs. Och själva backupen *i sig* är inte konsistent.

Spelar inte så stor roll, men man är lite intresserad av att se hur de hypade
produkterna löser detta när man själv har jobbat med databaser 15 år.
Jag är van vid att bara göra :

$ RMU /BACKUP /ONLINE <databas> <backup-fil>

Man får en backupfil som är helt konsistent och som kan återställas med :

$ RMU /RESTORE <backup> <databas>

Databasen låses bara under ett ögonblick i starten av backupen, märks
normalt inte för användarna (väntar bara ut alla R/W transaktioner). Sedan,
medan backupen kör, så kör alla uppdateringar mot databasen som vanligt.

Denna databas är helt transaktionskonsisten, och kan naturlitsvis "rullas
fram" genom en /RECOVER av transaktionsloggarna (normalt).

[speakman]

Det mesta borde du själv kunna räkna ut svaren på.
Vad gäller transaktioner så är dessa atomic även för mysqlhotcopy.
Frågan är om du *vet* att RMU *verkligen* ger exakt det du beskriver, eller om du bara förutsätter det?
Varför jag undrar är hur det kan vara så tokenkelt och bli så fantastiskt bra och inte ger ett märkbart avbrott för användarna och är fullständigt konsistent och ger en exakt spegling vid en viss tidpunkt utan att röra transaktionsloggarna, men inga andra har lyckats göra det på det viset?
PostgreSQL har det ju som sagt lagts ner lite mer jobb på än MySQL och är byggd på helt andra premisser, men gör ändå inget bra jobb på det mest väsentliga delarna.