/ Forside / Teknologi / Udvikling / SQL / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
SQL
#NavnPoint
pmbruun 1704
niller 962
fehaar 730
Interkril.. 701
ellebye 510
pawel 510
rpje 405
pete 350
gibson 320
10  smorch 260
Forskel MySQL vs. MsSQL - Fuldstændig list~
Fra : Johan Holst Nielsen


Dato : 17-09-03 15:36

Hej,

Jeg har diskuteret en del idag omkring hvilke forskelle der reelt er
mellem MsSQL og MySQL (4)... hvilke forskelle er der efterhånden
tilbage? Jeg tænker primært på features osv...

Er der en fuldstændig liste - gerne med flere databaser inkluderet :(
Google ser ikke ud til at være min ven i dette tilfælde.

mvh
Johan


 
 
Morten Wulff (17-09-2003)
Kommentar
Fra : Morten Wulff


Dato : 17-09-03 20:15

On Wed, 17 Sep 2003 16:36:10 +0200, Johan Holst Nielsen
<johan@weknowthewayout.com> wrote:
> Jeg har diskuteret en del idag omkring hvilke forskelle der reelt er
> mellem MsSQL og MySQL (4)... hvilke forskelle er der efterhånden tilbage?
> Jeg tænker primært på features osv...
> Er der en fuldstændig liste - gerne med flere databaser inkluderet :(

Du kan muligvis bruge denne sammenligning af features:

http://www.mysql.com/information/features.html

Der kan du sammenligne en lang række forskellige systemer.


hth,

Morten Wulff



--
Self Injury Information and Support: www.psyke.org

"I have a school book with my name on it."
"Your parents must be so proud." (http://www.actsofgord.com/)

Peter Lykkegaard (17-09-2003)
Kommentar
Fra : Peter Lykkegaard


Dato : 17-09-03 21:01

Morten Wulff wrote:
>
> Du kan muligvis bruge denne sammenligning af features:
>
> http://www.mysql.com/information/features.html
>
> Der kan du sammenligne en lang række forskellige systemer.
>
Ja, om ikke andet så kan man se at implementering af SQL sproget er noget
forskellig
Btw så er der testet på en mssql 2000 RTM Desktop Edition (8.00.194) eller
muligvis en Developer Ed
Det kunne være interessant at se hvordan det ser ud i forhold til den nyeste
version 8.00.760 (sp3)
Der var/er en del bugs i RTM versionen

mvh/Peter Lykkegaard



Lars Dybdahl (19-09-2003)
Kommentar
Fra : Lars Dybdahl


Dato : 19-09-03 08:27

Morten Wulff wrote:
> Du kan muligvis bruge denne sammenligning af features:
> http://www.mysql.com/information/features.html

Denne sammenligningstabel er ikke fair - der er i hvert fald utrolig mange
fejl på Interbase-delen.

Jeg kan bl.a. nævne:
- bigint. Interbase/Firebird bruger nu 64-bit integers som default, hvorimod
en bigint på Microsoft SQL Server er en 64-bit integer.
- current_user. Selvflg. har den det.
- Limit. Denne er i modsætning til MSSQL ikke nødvendig i Interbase pga. den
måde, den arbejder på.

Den siger desuden at MySQL 4.x ikke supporterer transaktioner. Og så mangler
tabellen et par meget vigtige ting:

1) Generator (Firebird), kaldes Sequence i PostgreSQL. Jeg ved ikke om MySQL
har det nu, men Microsoft SQL Server har ikke (møgirriterende).
2) Syntaksen NEW.feltnavn=2; i en trigger. Jeg kan ikke leve uden, men
f.eks. Microsoft SQL server har ikke denne syntax, hvilket medfører
gigantiske stored procedures i sammenligning med f.eks. Firebird/Interbase.
3) Syntaksen "for select * from tabel do begin ... end". Denne syntax bruger
man jo altid i en stored procedure, men mangler i MIcrosoft SQL Server.
4) Transaktionsmetode. I firebird kører alt i transaktioner, og pga.
multigenerationsarkitekturen fungerer det perfekt i en enkelt fil på en
enkelt harddisk og med daglange transaktioner åbne. Microsoft SQL Server
kører med to filer, som helst skal ligge på hvert deres harddisk system,
den bruger låsninger (suk), og transaktioner bør holdes korte. MySQL har
traditionelt været meget web-egnet, fordi den afvikler SQL statements meget
hurtigt (low latency), på bekostning af visse flerbrugeregenskaber.
Firebird leverer første record meget hurtigt, men bruger lidt længere tid
på alle records. Til gengæld klarer den sig godt under pres med mange
brugere. Microsoft SQL Server klarer sig... skidt. Den er god til
benchmarks og dårlige database programmører, men ikke velegnet til f.eks.
web.

Tabellen virker, som om den er skrevet til netop MySQL sammenligning, og en
sammenligning, der er fair overfor Microsoft SQL Server ville se anderledes
ud.

Lars.

--
Freelance programmør


Thomas Due (25-09-2003)
Kommentar
Fra : Thomas Due


Dato : 25-09-03 12:48

Lars Dybdahl wrote:

> 1) Generator (Firebird), kaldes Sequence i PostgreSQL. Jeg ved ikke
> om MySQL har det nu, men Microsoft SQL Server har ikke
> (møgirriterende).

Mjah, det er nu ikke rigtig. I MSSQL kan du definere en Identity for et
felt, og dermed få en autonummering.

E.g.

create table test1 (
ID integer identity(1,1),
...
)

Hvis jeg har misforstået så se bort fra denne post.



--
Thomas Due
Software Developer
Scanvaegt Nordic A/S

Troels Arvin (25-09-2003)
Kommentar
Fra : Troels Arvin


Dato : 25-09-03 13:43

On Thu, 25 Sep 2003 11:47:41 +0000, Thomas Due wrote:

> >> 1) Generator (Firebird), kaldes Sequence i PostgreSQL. Jeg ved ikke
>> om MySQL har det nu, men Microsoft SQL Server har ikke
>> (møgirriterende).
>
> Mjah, det er nu ikke rigtig. I MSSQL kan du definere en Identity for et
> felt, og dermed få en autonummering.

Jeg læser Lars' indlæg som at det er irriterende, at MSSQL ikke har
sekvenser (SEQUENCEs).

Både sekvenser og IDENTITY-kolonner bliver først del af SQL:2003, men
mange DBMSer har allerede implementeret mindst én af dem; særligt finder
man sekvenser på de fleste "større" DBMSer.

Følgende DB2-dokumentation beskriver forskelle mellem sekvenser og
IDENTITY-kolonner:
http://publib.boulder.ibm.com/infocenter/db2help/index.jsp?topic=/com.ibm.db2.doc/admin/c0004994.htm
Bemærk dog, at IBMs IDENTITY-implementation er noget anderledes end
MSSQL's (IBMs implementation match'er den foreslåede standard).

En væsentlig forskel mellem sekvenser og IDENTITY-kolonner er, at en
sekvens ikke er knyttet til en bestemt tabel, og man kan derfor oprette
lige så mange sekvenser, som man måtte have lyst til. En tabel kan
derimod kun have én kolonne af IDENTITY-typen.

--
Greetings from Troels Arvin, Copenhagen, Denmark


Lars Dybdahl (27-09-2003)
Kommentar
Fra : Lars Dybdahl


Dato : 27-09-03 22:59

Troels Arvin wrote:
> Både sekvenser og IDENTITY-kolonner bliver først del af SQL:2003, men

Nej - Microsoft SQL Server 2000 har IDENTITY kolonner - men den mangler
sequence, og selv om jeg har snakket med mange MSSQL eksperter, har ingen
kunne vise mig en løsning, som kan give samme opførsel med fuld performance
uden ekstra vedligeholdesarbejde. Microsoft SQL Server 2000 mangler
simpelthen features, men det glæder mig, at de gør noget ved det i SQL
Server 2003. MSSQL server 2000 er efter min mening en database med så
seriøse mangler (= højere udviklings og driftsomkostninger end
alternativerne), at man skal tænke sig grundigt om, inden man anvender det.

> En væsentlig forskel mellem sekvenser og IDENTITY-kolonner er, at en
> sekvens ikke er knyttet til en bestemt tabel, og man kan derfor oprette
> lige så mange sekvenser, som man måtte have lyst til. En tabel kan
> derimod kun have én kolonne af IDENTITY-typen.

Det er måske den nemmeste måde at forstå det på, hvis man ikke kender
forskellen, men hvis man fokuserer på anvendeligheden, så vil jeg mene, at
den største forskel ligger i, at sequences ikke kræver oprettelse af
records for at levere tal, og den største mangel i MSSQL Server er, at man
f.eks. ikke kan lave et SQL statement som dette rimeligt nemt:

update deltagere
set startraekkefoelge=gen_id(MinSekvens)
where startraekkefoelge is null

Denne her er også dybt besværlig i MSSQL:

create trigger on mintabel for update as
begin
new.TIDSSTEMPEL=current_timestamp;
end

Denne sætter current_timestamp i tidsstempel feltet, hver gang en record
ændres (i Firebird/Interbase). Hvor svært kan det være?

Lars.

--
Freelance programmør


Peter Lykkegaard (27-09-2003)
Kommentar
Fra : Peter Lykkegaard


Dato : 27-09-03 23:17

Lars Dybdahl wrote:

> Denne her er også dybt besværlig i MSSQL:
>
> create trigger on mintabel for update as
> begin
> new.TIDSSTEMPEL=current_timestamp;
> end
>
> Denne sætter current_timestamp i tidsstempel feltet, hver gang en
> record ændres (i Firebird/Interbase). Hvor svært kan det være?

Øhh, du laver da bare et felt af typen TimeStamp så klarer MSSQL resten?´
Ingen triggers etc er nødvendig

mvh/Peter Lykkegaard



Lars Dybdahl (28-09-2003)
Kommentar
Fra : Lars Dybdahl


Dato : 28-09-03 08:35

Peter Lykkegaard wrote:
>> Denne sætter current_timestamp i tidsstempel feltet, hver gang en
>> record ændres (i Firebird/Interbase). Hvor svært kan det være?
> Øhh, du laver da bare et felt af typen TimeStamp så klarer MSSQL resten?´
> Ingen triggers etc er nødvendig

TIDSSTEMPEL feltet skal angive, hvornår et af de andre felter i en record
sidst er blevet ændret. Hvis der kopieres data ind i tabellen med et
værktøj, der overskriver alle felter, inkl. TIDSSTEMPEL feltet, skal
systemet stadigvæk overskrive denne TIDSSTEMPEL værdi med
current_timestamp.

Du må gerne forklare nærmere, hvordan du vil lave dette med MSSQL Server.

Lars.

--
Freelance programmør


Peter Lykkegaard (28-09-2003)
Kommentar
Fra : Peter Lykkegaard


Dato : 28-09-03 11:20

Lars Dybdahl wrote:
> Peter Lykkegaard wrote:
>>> Denne sætter current_timestamp i tidsstempel feltet, hver gang en
>>> record ændres (i Firebird/Interbase). Hvor svært kan det være?
>> Øhh, du laver da bare et felt af typen TimeStamp så klarer MSSQL
>> resten?´ Ingen triggers etc er nødvendig
>
> TIDSSTEMPEL feltet skal angive, hvornår et af de andre felter i en
> record sidst er blevet ændret. Hvis der kopieres data ind i tabellen
> med et værktøj, der overskriver alle felter, inkl. TIDSSTEMPEL
> feltet, skal systemet stadigvæk overskrive denne TIDSSTEMPEL værdi med
> current_timestamp.

Jeg bruger primært Timestamp for at gøre det nemmere for MSSQL at lave
updates
I stedet at checke alle felter checker den Timestamp (fremover RowVersion)
Skal jeg lave track'n'trace på sidste ændring bruger et alm DateTime felt
>
> Du må gerne forklare nærmere, hvordan du vil lave dette med MSSQL
> Server.
>
Man kan evt lave en INSTEAD OF Trigger

mvh/Peter Lykkegaard



Lars Dybdahl (01-10-2003)
Kommentar
Fra : Lars Dybdahl


Dato : 01-10-03 20:51

Peter Lykkegaard wrote:
> Man kan evt lave en INSTEAD OF Trigger

Det er da netop besværligt?!? Især hvis du vil tilføje felter til tabellen
senere, så skal du opdatere din instead of trigger...

Lars.

--
Freelance programmør


Troels Arvin (28-09-2003)
Kommentar
Fra : Troels Arvin


Dato : 28-09-03 08:51

On Sun, 28 Sep 2003 00:16:45 +0200, Peter Lykkegaard wrote:

> Øhh, du laver da bare et felt af typen TimeStamp så klarer MSSQL resten?´

Jeg læser
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tsqlref/ts_ta-tz_6fn4.asp
som at MSSQLs nuværende timestamp datatype - forstået som en
"automatisk" type - er under udfasning, og at det derfor er en datatype
man bør holde sig fra, hvis det overhovedet kan lade sig gøre.

--
Greetings from Troels Arvin, Copenhagen, Denmark


Peter Lykkegaard (28-09-2003)
Kommentar
Fra : Peter Lykkegaard


Dato : 28-09-03 10:55

Troels Arvin wrote:
>
> Jeg læser
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tsqlref/ts_ta-tz_6fn4.asp
> som at MSSQLs nuværende timestamp datatype - forstået som en
> "automatisk" type - er under udfasning,

Ahh, takker - man skal bruge rowversion fremover

mvh/Peter Lykkegaard



Peter Brodersen (27-09-2003)
Kommentar
Fra : Peter Brodersen


Dato : 27-09-03 23:28

On Sat, 27 Sep 2003 23:58:41 +0200, Lars Dybdahl <lars@dybdahl.dk>
wrote:

>> Både sekvenser og IDENTITY-kolonner bliver først del af SQL:2003, men
>Nej - Microsoft SQL Server 2000 har IDENTITY kolonner

Snakker Troels ikke her overordnet om SQL-standarden (jf. "mange
DBMSer har allerede implementeret mindst én af dem"), og ikke
produktet MS SQL Server 2003?

--
- Peter Brodersen

Ugens sprogtip: i dag (og ikke idag)

Lars Dybdahl (28-09-2003)
Kommentar
Fra : Lars Dybdahl


Dato : 28-09-03 08:36

Peter Brodersen wrote:
> Snakker Troels ikke her overordnet om SQL-standarden (jf. "mange

Hmm... Jeg tror, at du har ret - i det her forum er der bare mange, der
underforstår "Microsoft SQL Server", når de ikke angiver en bestemt
database, så jeg må indrømme, at jeg regnede med at han omtalte Microsoft
SQL Server 2003.

Lars.

--
Freelance programmør


Søg
Reklame
Statistik
Spørgsmål : 177558
Tips : 31968
Nyheder : 719565
Indlæg : 6408925
Brugere : 218888

Månedens bedste
Årets bedste
Sidste års bedste