|
| 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 |
| | |
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
| |
|
|