Hva er bedre med MSSQL contra MYSQL?

[Lurifaksen]

Jeg har tidligere brukt MySQL databaser, men etter å ha lest mye positivt om MSSQL, og fordi det ville være lettere å jobbe med visual studio (C#) valgte jeg å gå fra MySQL til MS SQL (på den tiden fantes det ikke MySQL plugin til visual studio med støtte for "drag and drop").

 

Nå etter ca et år bruk angrer jeg ganske mye på dette. Så vidt jeg vet er det nå kommet .NET connector for MySQL til visual studio som gjør det mulig å jobbe med MySQL nesten likt som MSSQL, så akkurat nå kommer jeg ikke på en eneste fordel med MS SQL contra MySQL.

 

Jeg har imidlertid funnet en rekke ulemper:

1. Ingen web-verktøy tilsvarende phpmyadmin
   
2. Har jo ingen funksjoner - MySQL har derimot haugevis av praktiske funksjoner som kan brukes i spørringene for å gjøre ting lettere. Savner spesielt "LIMIT 20,40" f.eks - håpløst!
   
3. Oppleves treg, dvs spesielt nye oppkoblinger.
   
4. Fungerer dårlig med PHP? Hver dag feiler denne ca 1-2 ganger (ikke noe kjempeproblem altså) uten at noe er feil på serveren: "mssql_connect($host,$username,$password)". Er tydeligvis heller ikke mulig å hente ut mer info om feilen med PHP (i motsetning til MySQL).
   
5. Bruker SQL Server express, og føler jeg hater Microsoft litt når de fant ut at automatisk backup mulighet, det fjerner vi fra express-utgaven!
   

Er det noen som har en god grunn til at jeg skal fortsette med MSSQL?

 

Det må presiseres at jeg ikke bruker noen av de avanserte databasefunksjonene - kun enkle tabeller og spørringer og så vidt litt Views.

[laaknor]

Nå er det vel normalt fullversjonen av SQL-server som anbefales, og ikke Express-utgaven. Det er der bare for at du skal kunne gjøre litt enkel testing....

[roac]

Tja, hvor skal vi begynne? Nei du har ikke limmit, men i motsetning til MySQL som velger å bruke kode som ikke inngår i SQL Standarden, så er MSSQL en av de databasene som ligger tettes opp til SQL Standarden, og du har row_number. Kanskje du da burde se på denne? Webgrensesnitt for administrering av database er jo ærlig talt en minor issue, og jeg kan ikke engang se at det er hensiktsmessig. Du har vel uansett tilgang til databaseserveren og kan kjøre en native applikasjon? SSMS (SQL Server Management Studio) er vanvittig mye bedre enn et webgrensesnitt. At MSSQL kan virke tregere i småapplikasjoner er jeg helt med på, men jobber du med .NET så setter du opp Application Pools, og i så fall trenger ikke applikasjonen å koble seg opp for hver gang. Det MSSQL er bedre på er jo concurrency, å gjøre mange ting på en gang, og god transaksjonshåndtering, noe som ikke akkurat er styrken til MySQL. PHP bruker jeg ikke, så den biten kan jeg ikke si noe om. SQL Server Agent er vel ikke ikke med i SQL Server Express nei, men det er strengt tatt ikke verre enn å ha en liten stored procedure for å ta backup (det lager jeg meg uansett) og bruke en at-kommando på OSet (Task Scheduler tjenesten må gå) og bruke sqlcmd til å starte prosedyren. Dette er jo nesten i beste Linux-ånd

 

Fordeler med MSSQL: God Query Optimizer, skalerer bra, god håndtering av samtidige spørringer, .NET integrasjon kan i NOEN tilfeller være bra, det samme med XML håndtering. Og kommer vi opp i større utgaver, så har vi: Online Restore, Partitioned Tables og annet snacks.

[Lurifaksen]

Tja, hvor skal vi begynne? Nei du har ikke limmit, men i motsetning til MySQL som velger å bruke kode som ikke inngår i SQL Standarden, så er MSSQL en av de databasene som ligger tettes opp til SQL Standarden, og du har row_number. Kanskje du da burde se på denne? Webgrensesnitt for administrering av database er jo ærlig talt en minor issue, og jeg kan ikke engang se at det er hensiktsmessig. Du har vel uansett tilgang til databaseserveren og kan kjøre en native applikasjon? SSMS (SQL Server Management Studio) er vanvittig mye bedre enn et webgrensesnitt. At MSSQL kan virke tregere i småapplikasjoner er jeg helt med på, men jobber du med .NET så setter du opp Application Pools, og i så fall trenger ikke applikasjonen å koble seg opp for hver gang. Det MSSQL er bedre på er jo concurrency, å gjøre mange ting på en gang, og god transaksjonshåndtering, noe som ikke akkurat er styrken til MySQL. PHP bruker jeg ikke, så den biten kan jeg ikke si noe om. SQL Server Agent er vel ikke ikke med i SQL Server Express nei, men det er strengt tatt ikke verre enn å ha en liten stored procedure for å ta backup (det lager jeg meg uansett) og bruke en at-kommando på OSet (Task Scheduler tjenesten må gå) og bruke sqlcmd til å starte prosedyren. Dette er jo nesten i beste Linux-ånd

 

Fordeler med MSSQL: God Query Optimizer, skalerer bra, god håndtering av samtidige spørringer, .NET integrasjon kan i NOEN tilfeller være bra, det samme med XML håndtering. Og kommer vi opp i større utgaver, så har vi: Online Restore, Partitioned Tables og annet snacks.

 

Når det gjelder at MySQL ikke følger SQL standarden så ser jeg ikke helt problemet med det. Så vidt jeg vet følger den jo standarden, men i tillegg har den en rekke andre funksjoner som gjør den "bedre enn standarden".

 

Ang web-administrasjon så er dette praktisk i tilfeller hvor jeg ikke er på mine egne PC-er. Er ikke spesielt populært å laste ned og installere programmer på andres PC-er, dessuten har alle MSSQL administrasjonsprogrammene jeg har prøvd vært veldig trege. Og mangelen på "limit" gjør jo det enda tregere - jeg er visst nødt å laste ned ALLE radene i tabellene for i det hele tatt få gjort noe? Pleier å være mulig å sette "TOP x", men problemet da er jo at den kun tar de x første uten mulighet for å ta top x DESC - jeg er jo alltid interessert i de siste.

 

Av fordelene du nevner er det vel heller ingenting som er aktuelt for meg, så det er vel antagelig feil database jeg bruker?

[Manfred]

SELECT TOP 10 * FROM Tabell ORDER BY pk_id DESC

Sånn gjør du det du mener er "umulig", nemlig å hente de siste radene og ikke de første.

[kaffenils]

Er det noen som kan forklare hvordan MySQL internt utfører LIMIT x,y? Jeg klarer ikke å skjønne hvordan det kan være effektivt hvis du har ti millioner av rader og f.eks. kjører LIMIT 100,1000000. MySQL må jo på en eller annen måte lese alle rader frem til offset 1000000, og det må da være utrolig tregt. Eller inneholder nodene i indextreet en eller annen informasjon om hvilke radnumre som en finner i en node?

 

Roac eller blackbrrd, dere kan sikkert forklare dette.

[Lurifaksen]

SELECT TOP 10 * FROM Tabell ORDER BY pk_id DESC

Sånn gjør du det du mener er "umulig", nemlig å hente de siste radene og ikke de første.

Selvfølgelig er det mulig å gjøre det manuelt, men ingen av programmene jeg har brukt har hatt skikkelig funksjoner for å gjøre slikt automatisk - åpner jeg en tabell henter den alt. F.eks. Visual Studio 2005 og SQL server management studio.

 

En annen ting som irriterer meg voldsomt er at ingen av db-admin programmene til MSSQL lar meg kjøre en select spørring, og gjøre endringer på noen av radene i resultatet. Dette er jo svært enkelt i phpmyadmin. Er bare å hake av de radene som skal endres, og klikke på rediger-knappen.

Endret 9. desember 2007 av Lurifaksen

[roac]

Og hvorfor skal du sitte å gjøre endringer manuelt i databasen? Hvis det er noe du gjør ofte, så er det vel noe som er feil et annet sted da, eller at det er applikasjonen/løsnignen det er noe galt med, som ikke har rutiner for å gjøre det du skal ha gjort. Jeg føler at du legger skylden helt feil sted. Manuelle operasjoner er faktisk en enorm sikkerhetsrisiko, og manuelle endringer i databaser er en enorm kilde til nedetid på løsninger, kanksje ikke i så stor grad i forbindelse med oppdateringer, men definitivt i forbindelse med slettinger.

 

Jeg vil også påstå at en web basert admin-grensesnitt mot en database er et potensielt sikerhetsproblem.

 

Og ellers må jeg si at det er første gangen jeg har hørt en person rose noe som er OpenSource for å gjøre ting på egen måte i steden for å følge standarden. Noen må gjerne rette meg hvis jeg tar feil, men jeg mener at limit ikke har vært en del av sql standarden, mens row_number har vært det (og faktisk er LANGT mer fleksibel enn limit). Du kan f eks ta følgende spørring:

 

select varenummer, varenavn, pris, antall, kategori, row_number(order by pris*verdi desc partition by kategori) as rad from varelager where rad >= 10 order by varenummer

 

Som henter ut informasjon om de ti varene innen hver kategori som samlet har størst verdi på lageret, dateene sortert etter varenummer.

Endret 9. desember 2007 av roac

[blackbrrd]

http://www.postgresql.org/docs/8.2/interac...ries-limit.html

 

Postgres bruker limit og offset...

"The rows skipped by an OFFSET clause still have to be computed inside the server; therefore a large OFFSET can be inefficient."

 

Limit har jeg ikke noe problem med å forstå hvorfor en vil ha, offset/limit, limit x,y, e.l. derimot er nok ikke spesiellt effektivt, man må jo vite hva de første x radene er før man kan hoppe over dem. Mao, du kan slippe å lese innholdet av radene, men du må gå igjennom alt av indekser osv...

 

Funky spørring roac Brukt den typen mye?

 

Personlig bruker jeg limit relativt ofte, men hittil har jeg ikke brukt offset.

 

Litt interessant lesing kanskje?

http://troels.arvin.dk/db/rdbms/#select-limit

Endret 11. desember 2007 av blackbrrd

[Lurifaksen]

Og hvorfor skal du sitte å gjøre endringer manuelt i databasen? Hvis det er noe du gjør ofte, så er det vel noe som er feil et annet sted da, eller at det er applikasjonen/løsnignen det er noe galt med, som ikke har rutiner for å gjøre det du skal ha gjort. Jeg føler at du legger skylden helt feil sted. Manuelle operasjoner er faktisk en enorm sikkerhetsrisiko, og manuelle endringer i databaser er en enorm kilde til nedetid på løsninger, kanksje ikke i så stor grad i forbindelse med oppdateringer, men definitivt i forbindelse med slettinger.

 

Jeg vil også påstå at en web basert admin-grensesnitt mot en database er et potensielt sikerhetsproblem.

 

Og ellers må jeg si at det er første gangen jeg har hørt en person rose noe som er OpenSource for å gjøre ting på egen måte i steden for å følge standarden. Noen må gjerne rette meg hvis jeg tar feil, men jeg mener at limit ikke har vært en del av sql standarden, mens row_number har vært det (og faktisk er LANGT mer fleksibel enn limit). Du kan f eks ta følgende spørring:

 

select varenummer, varenavn, pris, antall, kategori, row_number(order by pris*verdi desc partition by kategori) as rad from varelager where rad >= 10 order by varenummer

 

Som henter ut informasjon om de ti varene innen hver kategori som samlet har størst verdi på lageret, dateene sortert etter varenummer.

Manuelle endringer skjer ikke spesielt ofte nei, men pleier å skje i forbindelse med oppgraderinger av databasen etc (for å oppdatere gammel data f.eks, eller som en midlertidig løsning hvis applikasjonen ikke er helt ferdig).

 

Ang. standarder og open source - jeg gir temmelig blaffen i begge deler så lenge det ikke berører sluttbruker. Derfor bryr jeg meg om at HTML følger standarden, men SQL-spørringer er det kun jeg som jobber med så at det i det hele tatt er en standard er lite interessant. Men det er jo klart at det er en fordel at flere databasesystemer bruker samme syntaks siden det gjør det lettere å switche - men siden hovedsyntaksen er lik ser jeg ikke det som noe problem at mysql ikke følger standarden.

 

Hovedbruken min av limit er jo en enkel måte å hente ut en del av radene, og så veldig enkelt kunne hente ut neste x antall rader - i stedet for å hente ut alt på en gang slik alle MSSQL administrasjons-programmene jeg har prøvd gjør. Her finner jeg kun mulighet for å sette antall - ikke et utdrag, med knapper for "neste 100 rader" f.eks.

Endret 11. desember 2007 av Lurifaksen

[kaffenils]

offset/limit, limit x,y, e.l. derimot er nok ikke spesiellt effektivt, man må jo vite hva de første x radene er før man kan hoppe over dem. Mao, du kan slippe å lese innholdet av radene, men du må gå igjennom alt av indekser osv...

 

Det var egentlig det jeg trodde. Dermed vil f.eks. LIMIT 1000000,100 måtte lese en million rader før de hundre radene kan returneres til klient.

 

SQL Server har nemlig også tilsvarende muligheter ved å bruke med row_number(), OVER() og Common Table Expressions, men det er uhyre ineffektivt hvis du henter høye radnumre, som f.eks. rad nr. 1000000 til 1000100.

[serverside]

En annen ting som irriterer meg voldsomt er at ingen av db-admin programmene til MSSQL lar meg kjøre en select spørring, og gjøre endringer på noen av radene i resultatet. Dette er jo svært enkelt i phpmyadmin. Er bare å hake av de radene som skal endres, og klikke på rediger-knappen.

Dette er rett og slett feil. I Enterprise Manager kan man endre data rett i tabellen etter å ha kjørt en spørring.

 

Når det gjelder LIMIT i MySql kan dette enkelt gjøres med ROW_NUMBER() i MSSQL

 

MSSQL har meget god støtte for xml! Man kan kjøre xpath-spørringer på kolonnenivå. I tillegg har MSSQL kommet et godt stykke lengre på brukerdefinerte funksjoner og stored procedures.

 

Microsoft slipper nå MSSQL2008 som har en rekke nye features. Bl.a. datatype for hiearkiske data.

 

Svar på dine spørsmål:

1) Hva i all verden skal man med et web-grensesnitt mot en databaseserver? Dersom du virkelig trenger det så er det et kjapt søk på google så finner du dette til MSSQL også. (gratis til og med)

2) MSSQL inneholder nok funksjoner til å gjøre de spørringene du trenger. Det gjelder bare å bruke de riktig.

3) Hvis din MSSQL-server oppleves treg ville jeg tatt en kikk på oppsettet. Jeg har selv utviklet databaser på MSSQL som fint håndterte over 1000 spørringer pr sekund uten spesielt bra hardware. Det er sjelden databasen det er noe feil med, som regel er det koden.

4) Hvor godt MSSQL fungerer med PHP vet jeg lite om. Bruker stort sett .NET selv og det fungerer meget bra :-)

5) SQL Server Express er ikke beregnet på produksjonsmiljøer i stor skala. Der har MySQL et stort fortrinn. pris! Men det har dukket opp en del webhotelltilbydere som har MSSQL til en overraskende billig penge.. (bla. webhuset.no og fastname.no)

[kaffenils]

Når det gjelder LIMIT i MySql kan dette enkelt gjøres med ROW_NUMBER() i MSSQL

 

Hvis du har lyst til å ta livet av SQL Serveren så må du gjerne bruker row_number() får å simulere LIMIT x,y til MySQL.

Regner med du tenker på denne metoden?

 

with mycte as
(
select row_number() over (order by LastName) as row, FirstName, LastName from Contacts
)
select FirstName,LastName from mycte where row between 100 and 110

 

Vil hente ut rad 100 til 110 sortert på LastName fra Contacts. Men er det effektivt? Nei. Hvorfor? Fordi SQL Server må lese alle rader fra 1 til 110. Denne leseoperasjonen vil selvfølgelig ikke forårsake problemer fordi det tross alt er få pages som leses, men tenk deg at tabellen har 10.000.000 rader og du sier between 9.999.900 and 9.999.910. Spørringen vil returnere 10 rader, men for å finne disse 10 radene må SQL Server lese så og si alle data for hele index/heapen. På grunn av mengden med data vil SQL Server sette en Shared Lock på tabellnivå hvilket resulterer i at ingen får oppdatert noe data. Er det bra? Nei.

 

Derfor lurer jeg veldig på hvordan MySQL eller PostgreSQL håndterer dette og hvordan det påvirker concurrency nå du ber om data fra "slutten" av indexen som i f.eks LIMIT 9999900 and 9999910. Hvilke låser vil MySQL og PostgreSQL sette på tabell/index?

[blackbrrd]

Postgres bruker MVCC som vil si at SELECT aldri låser en rad med mindre du har spesifisert "FOR UPDATE", hvor du eksplisitt sier at du skal låse raden.

 

Med andre ord, ingen concurrency problemer der

Endret 11. desember 2007 av blackbrrd

[serverside]

Hvis du har lyst til å ta livet av SQL Serveren så må du gjerne bruker row_number() får å simulere LIMIT x,y til MySQL.

Regner med du tenker på denne metoden?

 

with mycte as
(
select row_number() over (order by LastName) as row, FirstName, LastName from Contacts
)
select FirstName,LastName from mycte where row between 100 and 110

Trenger ikke å bruke with (bør helst aldri brukes av flere årsaker)

En av mange artikler på nett som forklarer dette:

http://www.asp101.com/articles/gal/effecti...ing/default.asp

[kaffenils]

Postgres bruker MVCC som vil si at SELECT aldri låser en rad med mindre du har spesifisert "FOR UPDATE", hvor du eksplisitt sier at du skal låse raden.

 

Med andre ord, ingen concurrency problemer der

 

Joda, row-versioning vil selvfølgelig løse concurrency-problemet og kan selvfølgelig brukes i SQL Server også. Allikevel ser jeg for meg at det vil være både cpu, minne og I/O intensivt hvis MySQL og PostgreSQL må lese alle rader som tilfredsstiller spørringen før LIMIT x,y utføres. Eksempelet mitt med LIMIT 10000000,100 vil slik jeg har forstått det medføre at 10000100 rader må leses. Sikkert et veldig søkt eksempel, men allikevel.

 

Det hadde vært interessant om du kunne testet en slik spørring på PostgreSQL og sett hvor mye data som faktisk leses for en LIMIT 100 med OFFSET 10000000.

 

Hvis noen har lyst til å gjøre samme test i MySQL så hadde det vært artig om dere hadde postet info om hva MySQL må lese for å få ut resultatet.

 

Trenger ikke å bruke with (bør helst aldri brukes av flere årsaker)

En av mange artikler på nett som forklarer dette:

http://www.asp101.com/articles/gal/effecti...ing/default.asp

 

Jeg har heller aldri sagt at CTE sammen med row_number() er effektivt til paging. Artikkelen nevner ikke CTE med et eneste ord. Det den derimot sier er at web serveren ikke bør cache tabellen.

 

Men eksempelet du linker til er faktisk enda dårligere. Der må jo ALLE radene leses hver ENESTE gang du bytter til ny page i gridviewet pga. at den temporære tabellen må fylles opp. Verre sløsing med minne har jeg vel sjelden sett. Eksempelet med CTE (selv om det også suger) vil i alle fall avbryte lesing når radene er returnert. Det betyr å hente lave sidenumre er myyyye raskere enn i eksempelet du viser til. De siste sidene vil selvfølgelig være like trege som i ditt eksempel, men total sett så er mitt forslag mye bedre.

[j000rn]

Trenger ikke å bruke with (bør helst aldri brukes av flere årsaker)

En av mange artikler på nett som forklarer dette:

http://www.asp101.com/articles/gal/effecti...ing/default.asp

 

I den artikkelen henter han ut ALLE dataene, og så lager en clustret index på dem. At dette er effektivt syntes jeg hørtes veldig snodig ut. KANSKJE dette kan være raskere hvis man har veeeldig store "pages"?

 

Dette tror jeg er mest effektivt om man skal hente ut mye data fra tabellen / kolonner som ikke er med i index'n. For ytelse har jeg her puttet en index på DatabaseName med included column DatabaseID.

WITH rows AS
(
SELECT row_number() OVER (ORDER BY DatabaseName) as row, DatabaseID FROM Databases 
)
SELECT Databases.* FROM rows INNER JOIN Databases ON Databases.DatabaseID = rows.DatabaseID
WHERE row BETWEEN 100 and 200

[kaffenils]

Helt enig med deg Jørn, men CTE-metodenfår også "problemer" når offset er et høyt tall. Artikkelen det henvises til har derimot dette problemet uansett hvilken page man vil lese.

 

Det er derfor jeg lurer på om MySQL og PostgreSQL har løst problemet med høy offset på en effektiv måte, eller om en støter på samme problemene som ved bruk av ROW_NUMBER() OVER() på SQL Server.

 

Roac, her har du en god ide til neste artikkel på mssql.no. Finn ut hvordan dette håndtere i de nevnte DBMS.

[roac]

SQL Server har alltid en låsing på dataene når du henter dem ut, uansett hvordan du gjør dette. Det som er interessant er HVORDAN radene låses, noe som bestemmes med transaksjonsnivået. Dersom transaksjonsnivået er read uncommitted, så får fortsatt andre gjøre oppdateringer mot rader selv om du bruker row_number(). Så det som jeg synes hadde vært interessant å finne ut er hvordan mysql/postgres låser, for så å mappe det mot transaksjonsnivå i SQL Server, evt hvilke muligheter du har.

 

Roac, her har du en god ide til neste artikkel på mssql.no. Finn ut hvordan dette håndtere i de nevnte DBMS.

Helt klart. Og jeg har jo så lite å gjøre om dagen, he he. Jeg skal ha det i bakhodet, men først er det eksamen i MAT1000 på torsdag.

[kaffenils]

Helt klart. Og jeg har jo så lite å gjøre om dagen, he he. Jeg skal ha det i bakhodet, men først er det eksamen i MAT1000 på torsdag.

 

ÅÅÅÅÅÅÅ jeg er såååå glad jeg er ferdig meg eksamener. Har fortsatt mareritt om at jeg møter opp på eksamen helt uforberedt.