Förklaring av SQL

PHPportalen Forum Index » Databaser
Lägg ett bokmärke på hela tråden
Skapa nytt inlägg   Svara på inlägget
Visa föregående ämne :: Visa nästa ämne  
Startad av: Meddelande
webbhelp



Medlem i: 3833 dagar
Från: Sverige
Status: Offline



#735158
Inlägg Skrivet: 2013-12-07 23:38      Ämne: Förklaring av SQL Citera

Hej!

Jag har blivit mer intresserad av att fördjupa mina kunskaper i PHP, även då SQL.

När jag lärde mig php så fanns bara MySQL, enkelt att börja använda och det fanns inget annat då.
Men nu tänkte jag försöka få mer koll på vad för olika sorters SQL engines det finns.

SQL är ju själva grunden, en standard för hur SQL frågor ska byggas för att få ut rätt resultat, eller hur?

men sen finns det ju postgresql, det finns mongodb, memsql osv.

Varför använder jag just MySQL och inte något annat, vilket är bäst? är dom bra för olika ändamål, jag förstår inte riktigt vad som avgör vilket man ska ha?

Memsql, är det världens snabbaste? fungerar det liknande mysql eller?
mongodb, är det också sql, fast i objekt form på nåt sätt? vet ni så får ni gärna förklara.
postgresql, är det en variant istället för mysql?

Jag frågar här för att få en liten knuff i rätt riktning, detta området är egentligen rätt okänt för mig.

förklara gärna lite allmänt och särskilt om mongodb om ni vet vad det är, samt memsql.

Tack på förhand
 
Till toppen på sidan
Visa användarprofil Skicka privat meddelande Skicka e-post Besök användarens hemsida MSN Messenger
jeja2000



Medlem i: 2177 dagar
Från: Lyrestad
Status: Offline



#735159
Inlägg Skrivet: 2013-12-08 01:25      Ämne: Citera

Vilket man bör använda beror lite på typen av applikation man programmerar. Behöver man relationer så måste man se till att Databasen klarar det vilket mysql gör med innoDb exempelvis.

Sen kan man kanske förklara de olika databasmotorerna att de lagrar informationen på olika sätt. Vissa lagrar info i "textfiler", Andra i mer komplexa format.

Sen vissa databasmotorer kan ju lagra informationen i exempelvis ramminne för snabbare tillgång. Vilket man får använda cache till på andra motorer.

För att se skillnaden skulle jag nog jämföra dokumentationen på de olika alternativen. Hur datan lagras, finns det relationer. Man använder olika sätt för att kommunicera mellan dem.

Själva SQL är ju en förkortning av Structured Query Language.
 

_________________
Tredjepartslogistik
Till toppen på sidan
Visa användarprofil Skicka privat meddelande Besök användarens hemsida
EmilV
Ex-Moderator



Medlem i: 5344 dagar
Från: Lilla Edet
Status: Offline



#735164
Inlägget är accepterad som det rätta svaret Skrivet: 2013-12-08 13:09      Ämne: Citera

SQL är till för att ställa frågor till relationsdatabaser. Det är den databasmodell MySQL använder, med tabeller, rader, kolumner och främmande nycklar som sammanbinder rader i olika tabeller. Relationsdatabaser bygger teoretiskt på relationsalgebran som definierar hur join, select och liknande beter sig. Fördelen med detta är att relationsdatabaser fungerar mycket bra i det genrella fallet eftersom en bra databasmotor kan använda relationsalgebra för att snabba upp dina SQL-frågor (MySQL är dock synnerligen dåligt på sådana optimeringar...).

Relationsdatabaser pratar såvitt jag vet alltid SQL eftersom det är standardiserat. De flesta gör vissa avsteg från standardenmen det är mycket litet och håller man sig till enklare kommandon kommer man ofta undan utan att ändra någo alls. PDO i PHP kan ansluta till flera olika SQL-databaser så använder du SQL och PDO har du stor chans att kunna köra dittprogram i flera olika miljöer.

MySQL, MariaDB, Postgre SQL, SQL Server, SQLite, Oracle och DB2 är exempel på relationsdatabaser som pratar SQL.

Vilken databas du ska använda beror på en stor mängd faktorer. Vill man ha en fri databasmotor är nog Postgre eller MariaDB att rekommendera då MySQL köpts upp av Oracle. Risken finns att Oracle kommer göra mycket för att antingen döda MySQL eller börja ta rejält betalt för att köra det i kommersiella system. MariaDB är en fri variant av MySQL och bygger på MySQL i grunden, men har inga kopplingar till Oracle. Några av grundarna till MySQL AB startade MariaDB just för att MySQL blev uppköpt.

Postgre har funnits med länge och är på många plan mer kompetent än MySQL. Att PHP-utvecklare oftare använder MySQL än Postgre tror jag beror på att det tidigt fanns MySQL-kopplingar i just PHP. På många andra håll har Postgre större fotfäste. Förutom att det är helt skilda program så är Postgre och MySQL/MariaDB väldigt lika varandra; de försöker lösa samma problem.

SQL Server, Oracle och DB2 är också rätt lika de övriga, med den stora skillnaden att det är helt kommersiella, proprietära produkter som man får betala en hel del pengar för. Deras fördel är att de har många väldigt kompetenta utvecklare och databasteoretiker bakom sig. Eventuellt är det också lättare att skala dessa databaser till många maskiner men det har jag inte så stor erfarenhet av så kanske har jag fel.

SQLite är en mycket liten databasmotor som tagits fram för att bäddas in direkt i ditt program. De andra databasmotorerna bygger på en klient-server-modell där ditt program bara innehåller klientkoden. SQLite har istället hela databasmotorn inbyggd i ditt program och arbetar direkt mot en fil på hårddisken (det finns även stöd för att arbeta mot en bit RAM-minne, men idén är densamma). SQLite är oerhört bra på det den gör och passar bra för mindre databaser utan samtidiga användare.

MongoDB är en helt annan best. Det är inte en relationsdatabas överhuvudtaget. Istället sparar du objekt som i stort sett kan liknas vid PHP:s arrayer. Du specificerar inte något databasschema i förväg, det finns inga tabeller, rader eller kolumner. Istället för tabeller pratar man om "collections" (samlingar) av objekt. Objekt i samma samling behöver inte se likadana ut eller ha samma fält, även om det kanske är att rekommendera. Mongo har ett eget frågespråk som liknar Javascript och är helt olikt SQL. Det finns också två olika typer av frågor i Mongo. Den ena typen har vissa likheter med relationsdatabaser i det att du väljer objekt som har ett visst värde.

Den andra typen av frågor bygger på MapReduce, ett koncept som utvecklades av Google för att arbeta med stora datamängder på ett skalbart sätt. I MapReduce skickar du in två funktion: map och reduce. map-funktionen konverterar varje objekt till ett värde av en viss typ (som du väljer själv, men alla värden får samma typ och utseende). reduce-funktionen tar två sådana värden och slår ihop dem till ett. Idén är att mappa alla objekt och sedan reducera ner dem till ett enda slutresultat. Exempelvis kan du räkna ut hur många användare som heter Laban genom att mappa alla "Laban" till 1 och alla andra till 0. Du kan sedan reducera med vanlig addition. Detta är skalbart eftersom både map- och reduce-funktionerna kan köras parallellt på olika maskiner, nära det data de arbetar på.

Det finns flera databasmotorer som använder MapReduce, till exempel Riak och Hadoop. Populärast är nog just Hadoop, som fått flera populära extralager. Kolla in Cassandra och Hive.

Du har kanske hört termen NoSQL? Ofta pratar man då om nyckel-värde-databaser, där man kopplar ett värde till en nykel som i en hashtabell (jämför gärna med PHP:s arrayer igen, som gör just det). Det finns många exempel på sådana databaser som skiljer sig på lite och därför lämpar sig för olika sorters problem. Några exempel:

* Redis, som körs helt i RAM och implementerar ett fåtal datastrukturer på ett riktigt bra vis
* Memcached, körs också i RAM och agerar enbart cache. Blir databasen full slängs objekten ut. Mycket bra för att cacha resultatet av dyra beräkningar, till exempel för att slippa ställa samma SQL-fråga flera gånger.
* MongoDB som jag redan nämnt.
* Riak, en databas som lätt skalar till många maskiner och löser uppdateringskonflikter (olika servrar som uppdaterar samma värde) på ett intressant vis.
* CouchDB, som har många likheter med Mongo

Jag vill även passa på att nämna Neo4j som är en grafdatabas. Data lagras som noder och kopplingar mellan dem. Du kan till exempel lagra varje användare som en nod, och låta användare som är vänner med varandra få en koppling mellan sig i Neo4j. Du kan då till exempel räkna ut avståndet mellan användare.

Det finns många flera databasmotorer än de jag nämnt här. Vilka du ska använda beror på vilka problem du försöker lösa och vilka egenskaper du behöver hos din databas. Relationsdatabaser lämpar sig väl för väldigt många problem och är en naturlig startpunkt. Men om du skriver ett program med särskilda krav kan det vara värt att kika på de andra. Läs introduktionen i respektive manual för att försöka få ett grepp om vad databasmotorn gör och vilka problem den lämpar sig för.

Min databasprofessor sade en gång att en databasmotor som inte kan klara åtminstone 100 miljoner rader knappast förtjänar sitt namn. Tittar vi på de jag nämnt här är det flera stycken som faktiskt har problem med de datamängderna för vissa typer av frågor. MySQL riskerar till exempel horribla låsproblem vid JOIN och/eller subqueries på den sortens datamängder, särskilt om du har många samtidiga användare.

Jag jobbar numera som backendutvecklare på Bloglovin. Vi har x miljoner användare och y hundra tusen samtidigt inloggade (det finns säkert någon bra Techcrunch-artikel någonstans med mer exakta värden på x och y). Som de flesta PHP-ställen har vi i grunden MySQL, och hon har klarat skalningen förvånansvärt bra. Men vi skulle aldrig klarat det utan att fundera oerhört noga på hur våra SQL-frågor presterar, hur vi ska skala ut databasen på flera maskiner, och så cachar vi också så mycket som möjligt i Memcached för att undvika in i det sista att faktiskt ställa någon SQL-fråga. Vi håller också på att testa oss fram med lite nya databaslösningar för att se hur vi ska göra för att kunna skala upp ännu bättre. Vi har en del i Redis nu och jag är rätt imponerad av hur bra det presterar, men där får man tänka väldigt noga på hur man ska modellera sitt data på bästa sätt eftersom det inte är en relationsdatabas (och faktum är att just relationer är något Redis är oerhört dåligt på).
 

_________________
Tänk!

EmilVikström.se | Bloglovin.com
Till toppen på sidan
Visa användarprofil Skicka privat meddelande Besök användarens hemsida
webbhelp



Medlem i: 3833 dagar
Från: Sverige
Status: Offline



#735166
Inlägg Skrivet: 2013-12-08 15:01      Ämne: Tack för ett sådant bra & informativt svar! Citera

Jag uppskattar verkligen ditt informativa svar!
Det var intressant skrivet och därmed blev jag väldigt nyfiken och har en del frågor. =)

Jag trodde att allt var relationsdatabaser, men så var det inte nej.

1. Hur kan man skapa applikation som säg en webshop, produkterna i en, bilderna till varje produkt i en, alla olika språk med titel och beskrivning i en tabell.
jag ser inte riktigt hur man kan göra det utan en relationsdatabas såvida man inte ska hantera flera olika SQL frågor i PHP istället?


2. postgre sql som du säger är smartare men ändå nästan likadant, borde jag inte försöka byta till det om jag fortfarande vill hålla mig på sql spåret med relationsdatabaser osv?

3. Tyvärr förstod jag inte riktigt vad du menade med NO-SQL; det lät rätt intressant om hur man skapar en databas utan tabeller med att lägga till värde i en typ, collection varje gång, är det så att man måste namnge det samma namn varje gång för att det ska kunna lagras, så att jag sen kan hämta ut rätt data med hjälp av namnen jag givit dom? eller jämför jag för mycket med MySQL?

4. Vet du något om memsql? läste att det var snabbast, stämmer det? sen är frågan bara för att det är snabbast klarar det ändå stora databaser med miljoner rader...

Huvudfrågan

5. Hur vet jag egentligen på vad jag borde använda till vad, när du säger så att mysql kan få problem vid miljoner rader, då tänker jag; borde jag inte byta ut det till något stabilare som klarar mer hårt tryck?

 
Till toppen på sidan
Visa användarprofil Skicka privat meddelande Skicka e-post Besök användarens hemsida MSN Messenger
EmilV
Ex-Moderator



Medlem i: 5344 dagar
Från: Lilla Edet
Status: Offline



#735169
Inlägget är accepterad som det rätta svaret Skrivet: 2013-12-09 08:01      Ämne: Citera

1. Det är precis som du säger, att använder man en nosql-databas får 2man oftast lösa relationer i sin applikationskod istället. Du kan till exempel ha en funktion som returnerar en lista med alla id-nummer för produkter i en kategori och en annan funktion som lägger till produkternas namn och pris. I MongoDB och liknande dokumentorienterade databaser skulle du istället ha lagt in pris, bild och kategori i ett och samma objekt och sedan frågat efter alla objekt som tillhör en viss kategori (rätt likt SQL, men ändå inte). Använder du en relationsdatabas såsom MySQL bör du såklar tförsöka använda JOIN och liknande så långt det är möjligt, då slipper du återuppfinna hjulet på nytt.

2. Postgre och MySQL är rätt lika varandra. Har du MySQL idag och är nöjd med det finns det ingen anledning att byta. Är du orolig för MySQL:s framtid kan du byta till MariaDB som beter sig på samma sätt som MySQL; det gjorde till exempel Wikipedia.

3. Det finns flera olika sorters nosql-databaser. Det bästa sättet att lära sig är nog att testa dem. Alla har lite olika beteenden och följer olika idéer. Det enda de uttryckligen har gemensamt är att de inte är relationsdatabaser Smile

4. Har aldrig testat mmemsql. Det verkar vara en relationsdatabas enbart i RAM. Det har sina fördelar att inte behöva tänka på hur långsamma hårddiskar är. Det verkar lösa lite samma problem som Redis, fast med relationsdatabaser. Jag gillar idén då relationsdatabaser och SQL har mycket som talar för sig i form av prestandaoptimeringar, men hårddiskar har en tendens att försvåra all form av skalning till flera maskiner. Memsql själva hävdar att det skalar till flera terabyte data, och om det skalar horisontellt (till flera maskiner) så bör det bara vara en fråga om hur mycket du kan betala för dina servrar Smile

5. Det bästa sättet är egentligen att pröva själv och se om det verkar lösa det problem du tycker dig ha. Har du inget problem med MySQL/Postgre/MariaDB så tycker jag att du ska stanna där. Optimera inte förrän du behöver det. Ett fel som många gör är att de bygger för massiv skalning tidigt istället för att bygga sådant som användarna faktiskt ser, och så blir det aldrig att det tar fart så då har man lagt allt jobb på skalning i onödan. Skala kan man alltid göra i efterhand genom att skriva om de bitar som faktiskt är flaskhalsar. Bloglovin har kört i sex år på MySQL + memcached.

Om du å andra sidan bara är ute efter att lära dig något nytt så för all del, ladda ner en databasmotor och börja läs manualen! Det är det allra bästa sättet att lära sig på. Skriv ett skript som skapar testdata åt dig och sätt igång att ställa frågor till databasen!
 

_________________
Tänk!

EmilVikström.se | Bloglovin.com
Till toppen på sidan
Visa användarprofil Skicka privat meddelande Besök användarens hemsida
Tarre



Medlem i: 4401 dagar

Status: Offline



#735170
Inlägg Skrivet: 2013-12-09 12:27      Ämne: Citera

EmilV skrev:
SQL är till.......

Denna bör spikas tycker jag :) väldigt informativ
 
Till toppen på sidan
Visa användarprofil Skicka privat meddelande
webbhelp



Medlem i: 3833 dagar
Från: Sverige
Status: Offline



#735181
Inlägg Skrivet: 2013-12-09 18:56      Ämne: Citera

Tack för sådana bra svar!
Lärorikt, jag ska ta dina råd till mig för det du sa var väldigt bra och hade sin mening =)

Tack!
och ja klistra den =)
 
Till toppen på sidan
Visa användarprofil Skicka privat meddelande Skicka e-post Besök användarens hemsida MSN Messenger
Wedge
Administratör



Medlem i: 5469 dagar
Från: Järfälla
Status: Offline



#735194
Inlägg Skrivet: 2013-12-10 14:26      Ämne: Citera

Limmet är nu tillsatt!
 

_________________
I am Groot
Till toppen på sidan
Visa användarprofil Skicka privat meddelande MSN Messenger
Visa tidigare inlägg:   
Skapa nytt inlägg   Svara på inlägget
PHPportalen Forum Index » Databaser
Hoppa till:  
Du kan inte skapa nya inlägg i det här forumet
Du kan inte svara på inlägg i det här forumet
Du kan inte ändra dina inlägg i det här forumet
Du kan inte ta bort dina inlägg i det här forumet
Du kan inte rösta i det här forumet
Du kan inte bifoga filer i detta forum
Du kan inte ladda ner filer från detta forum
Kontakta oss på adressen: info@phpportalen.net
Webbplatsen bygger i grunden på phpBB © 2001, 2002 phpBB Group

Modifieringar har senare gjorts i systemet av PHPportalen
Sid och logotypdesign skapad av Daren Jularic