Vad är skillnaden mellan MYSQL och SQL Server 2014 Express?


Svar 1:

Som någon som arbetar med både MySQL och SQL Server 2014 dagligen, kan jag berätta vad jag tror är de viktigaste skillnaderna (plus mina egna gillar och ogillar inte var och en)

SQL SPRÅK IMPLEMENTATION

SQL Server har en enorm historia med sig själv, de byggde en motor baserad på förutsättningen att varje fråga behöver en exekveringsplan, du har bättre verktyg i SQL Server för att optimera din fråga genom att visuellt analysera kostnaderna för din fråga. MySQL saknar den här typen av analysverktyg, eller så måste du betala för det.

I MySQL kan du göra detta: Välj a, b, c + y, räkna (d) som räknare från ztable-gruppen med 1,2 3. I SQL Server MÅSTE du göra detta: Välj a, b, c + y, count ( d) som räknare från ztable-gruppen med a, b, c + y.

I MySQL begränsar du dina frågor med användning av LIMIT-klausulen. Till exempel:

VÄLJ * FRÅN SomeTable Limit 50, 10. Det ger dig från resultaten från frågan, bara raderna, 50 till 59. Det är användbart för ett antal saker.

SQL Server använder denna VÄLJ * FRÅN dbo.SomeTable OFFSET 50 ROW FETCH NÄSTA 10 ROWS.

Du kan göra samma sak, men du måste skriva mycket mer på SQL Server.

I MySQL kan du använda om (some_condition = true, useThisValueIfTrue, useThisValueIfFalse), du också kan använda CASE: CASE WANN a = true THEN 1 ELSE 0 END som SomeValue. I SQL Server har du ENDAST CASE. Vilket ger dig mycket mer att skriva på varje fråga.

På den andra sidan har SQL Server mycket fler alternativ när det gäller komplexa frågor, det finns PIVOT för att skapa CROSSTAB-frågor, det finns CROSSJOIN och en hel del andra funktioner som gör SQL Server verkligen cool för avancerade frågor.

När du sätter in data i MySQL kan du göra detta:

infoga i mytable-set a = värde, b = anothervalue.

I SQL Server kan du ENDAST använda klassikern:

infoga i mytable (a, b) värden (värde, anothervue)

eller

infoga i mytable-värden (värde, anothervalue)

Nu i 2, 3, 4 kolumner är detta förmodligen inte i det minsta besvärliga, men när du trycker på 40, 50 kolumner, är det ont att göra en insats utan att göra misstag, speciellt när det är komplexa beräknade värden involverade.

Så för mig slår MySQL SQL Server enkelt på enkla frågor, till och med 2-3 tabellfrågor. Men på långa, komplexa frågor är SQL Server King.

SÄKERHETSKOPIERING

Återigen byggdes SQL Server med tanke på komplexa situationer, det finns minst 3 sätt att göra en fullständig säkerhetskopiering, och det finns komplexa, inkrementella säkerhetskopior, binär, filsystem och skript. Du borde förmodligen hålla dig till binärt, men det finns en massa säkerhetsproblem som du måste vara VÄLLIGA när du återställer en SQL SERVER. Återställning av en säkerhetskopia i SQL Server är INTE-FÖR-UNDTAGAD Du måste veta vad du gör, eller så kan du krossa din databas. Också om inte din databas är riktigt liten, skulle jag aldrig, aldrig rekommendera att använda en SQL File Restore på SQL SERVER, ta det för alltid, och ibland misslyckas dumpningen och du får veta den, 45 minuter till 1 timme senare om du har tur .

Å andra sidan handlar MySQL bara om att dumpa SQL i en fil och återställa den SQL. Det fungerar, det är enkelt och du kan enkelt utbilda alla medier till kraftanvändare att arbeta med säkerhetskopior och gör det enkelt utan besvär. MEN du måste också hålla och säkerställa säkerheten själv, vilket ibland kan vara besvärligt beroende på din miljö.

DISK ANVÄNDNING

Jag läste någonstans här på Quora när en kille sa att diskanvändning inte är viktigt eftersom lagring är billig. Tja, det kan vara så, men är fortfarande ganska dumt att slösa det bara för.

Tja, MySQL är väldigt kompakt, jag har några installationer på små företag som går tillbaka från 2003, och data har aldrig nått 10 GB, och de har tabeller med miljoner rader, och ändå har uppgifterna inte vuxit ut.

I SQL Server hade jag en annan installation som åt upp 2 GB efter bara 2 månader! SQL Server måste upprätthållas, du måste rensa dina loggar, du måste säkerhetskopiera frecuently binärt för att din SQL Server ska låta dig underhålla din databas och ha en person som vet hur man hanterar dataarbetet med varje fall beroende på antalet användare, installationens komplexitet, vilken typ av data som hanteras, varför DBA är ett måste på vissa platser. MySQL kan underhållas med en medeltränad elanvändare och det kommer att gå bra.

Det finns också några saker som inte kan göras i SQL Server utan att ha SQL Profiler OCH SQL Agent. MySQL kan göra allt på egen hand utan mycket mer än en tjänst.

Beroende på företagets storlek och komplexitet kan SQL Server vara vägen att gå igen. Men MySQL är en bra utmanare om du inte behöver dessa komplexiteter.

LAGRADA FÖRFARANDEN, FUNKTIONER OCH UDFS

Detta är landet för de djärva i RDBMS, jag producerar till och med en Udemy-kurs om SPs på MySQL. Men så mycket som jag älskar SP, Triggers, Functions och allt MySQL, du måste ge det till SQL SERVER, De har det bäst.

Nu innan du halshuggar mig för att jag säger detta, låt mig bara lägga till, SP: erna på SQL Server är snabba, kan vara komplexa, har en massa verktyg för att göra ditt liv enklare, de kan sammanställas på andra språk som c # och visual basic, du kan till och med skapa TABELL-variabler som kan fungera snabbare och enklare än tillfälliga tabeller på MySQL. De har mycket att gå.

MySQL kan ha användardefinierade funktioner också, men du måste vara kompetent i C. Om du är det har du inget att oroa dig för. Många av oss är det inte.

Det finns fler naturligtvis, men jag hoppas att du får idén.

Lycka till!


Svar 2:

SQL Server Express som sträcker sig från val av stora företag, om du använder SQL i ditt arbete har du några alternativ tillgängliga. Att kontrollera SQL-förfrågningar är bara en av de många saker du kan skärma med Prefix.

SQL Server Express erbjuder olika intressanta platser. Det första och till synes viktigaste är den totala mångsidigheten och samordningen med SQL Server.

Läs mer: SQL Server Express | SQL Server Express-versioner