"Dé grootste en gratis computerhelpdesk van Nederland"
Wat is het verschil tussen MySQL en Access
- Onderwerp starter XERJRB17
- Startdatum
- Status
Je kunt Access niet echt vergelijken met MySQL, net zoals je MySQL eigenlijk niet kunt vergelijken met echte relationele databases.
MS-Access is vooral bedoeld voor het bewaren van niet al te grote datasets die worden opgevraagd vannuit rapportage tools. Je kunt er niet eenvoudig complexe queries op draaien en het is uberhaupt niet bedoeld om bijvoorbeeld een website mee te voeren. Eigenlijk moet je je daar niet mee bezichhouden als je niet diep in de MS-office zit.
MySQL is een poging tot een relationele database, die *veel* meer data aan kan met veel complexere queries en veel meer gelijktijdige gebruikers, maar het kan bijna niets en is niet bijzonder betrouwbaar.
Als je nog moet beginnen met relationele databases dan zou ik absoluut aanraden om eerst te kijken naar PostgreSQL. Waarom: PostgreSQL is gratis, open source, veel uigebreider dan MySQL en vooral: het houdt zich aan de standaard. Met PostgreSQL leer je *correct* SQL, en leer je hoe je bepaalde taken in een database aan hoort te pakken, in plaats van de eingeloze berg workarounds die MySQL gebruikers blijven verzinnen om de tekortkomingen van MySQL te omzijlen.
MS-Access is vooral bedoeld voor het bewaren van niet al te grote datasets die worden opgevraagd vannuit rapportage tools. Je kunt er niet eenvoudig complexe queries op draaien en het is uberhaupt niet bedoeld om bijvoorbeeld een website mee te voeren. Eigenlijk moet je je daar niet mee bezichhouden als je niet diep in de MS-office zit.
MySQL is een poging tot een relationele database, die *veel* meer data aan kan met veel complexere queries en veel meer gelijktijdige gebruikers, maar het kan bijna niets en is niet bijzonder betrouwbaar.
Als je nog moet beginnen met relationele databases dan zou ik absoluut aanraden om eerst te kijken naar PostgreSQL. Waarom: PostgreSQL is gratis, open source, veel uigebreider dan MySQL en vooral: het houdt zich aan de standaard. Met PostgreSQL leer je *correct* SQL, en leer je hoe je bepaalde taken in een database aan hoort te pakken, in plaats van de eingeloze berg workarounds die MySQL gebruikers blijven verzinnen om de tekortkomingen van MySQL te omzijlen.
Ben het niet eens met je analyse van MS-Access, je kan er HELE krachtige dingen mee doen, maar op de schaal waarvoor het bedoeld is, dus een (zeer) gelimiteerd aantal gebruikers tegelijkertijd en bij een totaal aan minder dan 2 gig aan data per database.
Correcte SQL? standaard? de S in SQL staat voor Stuctured niet Standaard, om een reden.... Goed SQL schrijven is wel een kunst die met de vele query tools in de wereld tegenwoordig (Cognos/BO/SSIS en in mindere maten Access) wel een steeds schaarsere "kunst" aan het worden.... Goed begrip van SQL is wel belangrijker dan meniggeen denkt.
Wat versta jij onder heel krachtig? Ik denk aan WITH queries, recursie, triggers, stored functions in java of C, defineerbare datatype en aggregaten, range-types, replicatie, XML en JSON support, fulltext search, index-only search, functionele indexes en partiele indexes.
Ja, de standaard: http://en.wikipedia.org/wiki/SQL (zeg met niet dat je die niet even gegoogled hebt
)En die bestaat ook om een reden; zodat alle databases *die* functionaliteit op dezelfde manier kunnen implementeren.
Geen enkele databases implementeert de hele standaard, maar wat ze wel implementeren doen ze op de standaard manier. Behalve MySQL dan, want die wijkt af wanneer de originele makers ervan vonden dat het handiger was om het anders te doen. Zo betekent || in MySQL niet concattenatie maar OR, en zo kun je in MySQL ook GROUP BY volledig onmogelijk definieren en toch een antwoord krijgen.
Kortom; als je eerste ervaring met databases op MySQL is gebaseerd dan wordt je tweede database een heel aparte, want queries die in MySQL al jaren leken te werken ineens vol fouten blijken te zitten.
Helemaal mee eens, men grijpt tegenwoordig dolgraag naar een tool die queries genereert. Men gebruikt liever een ORM setup dan dat men even iets langer nadenkt over hoe het datamodel in elkaar zit en hoe je het met SQL kunt benaderen. Gevolg: lage performance door inefficiente queries, en de enige oplossing daarvoor is snellere hardware.
Afijn, en daarom is het dus van groot belang dat begint met een database die zich gedraagt zoals het hoort.
Er bestaat dus GEEN standaard, Structured Query Language, SQL, niet Standard Query Language....
Concatineren in SQL Server doe je met + niet met ||, dit is juist een van de dingen die per database verschillen, net zoals je bij sommige programmeer talen I++ kan doen ipv I = I + 1
Het verschil van MySQL tov Oracle tov DB2, alle databases hebben hun eigen "Dialect"... Meestal redelijk beperkt in de strikte Select ... from ... where syntax...
Maar als je aan specifieke dingen gaat denken, en dat kan al zo simpel zijn als concatineren, ZLS en Null verwerking, doen veel databases dat op hun eigen manier. Als je aan functies gaat denken zoals de oracle TO_DATE of TO_CHAR, dan gaat de vergelijking helemaal mank want daar heeft echt elke database zijn eigen functies in denk bijvoorbeeld aan Cast in SQL Server, of wil je ook gaan zeggen dat Oracle, DB2 of SQL Server geen serieuze databases zijn omdat hun "standaard" afwijkt?
Als je dan nog verder kijkt naar de 3GL programmeer talen die bij de verschillende databases horen, dan wordt je helemaal hopeloos.
Feit is dat een database een database is, maar als je die gaat ontsluiten met SQL dan kan het nog wel eens van belang zijn of je Oracle SQL of SQL Server SQL of DB2 SQL of nog andere SQL gewent bent... De basis lukt je altijd wel, maar specifieke dingen ga je moeten googlen.
Concatineren in SQL Server doe je met + niet met ||, dit is juist een van de dingen die per database verschillen, net zoals je bij sommige programmeer talen I++ kan doen ipv I = I + 1
Het verschil van MySQL tov Oracle tov DB2, alle databases hebben hun eigen "Dialect"... Meestal redelijk beperkt in de strikte Select ... from ... where syntax...
Maar als je aan specifieke dingen gaat denken, en dat kan al zo simpel zijn als concatineren, ZLS en Null verwerking, doen veel databases dat op hun eigen manier. Als je aan functies gaat denken zoals de oracle TO_DATE of TO_CHAR, dan gaat de vergelijking helemaal mank want daar heeft echt elke database zijn eigen functies in denk bijvoorbeeld aan Cast in SQL Server, of wil je ook gaan zeggen dat Oracle, DB2 of SQL Server geen serieuze databases zijn omdat hun "standaard" afwijkt?
Als je dan nog verder kijkt naar de 3GL programmeer talen die bij de verschillende databases horen, dan wordt je helemaal hopeloos.
Feit is dat een database een database is, maar als je die gaat ontsluiten met SQL dan kan het nog wel eens van belang zijn of je Oracle SQL of SQL Server SQL of DB2 SQL of nog andere SQL gewent bent... De basis lukt je altijd wel, maar specifieke dingen ga je moeten googlen.
Right... Weet je wat, ik laat het hierbij. De TS heeft niets aan deze discussie en volgens mij hebben wij dusdanig andere meningen dat we nog dagen ruzie kunnen maken.
Als je nog iets kunt vertellen over de verschillen tussen Access en MySQL dan heeft de TS niet helemaal voor niets gepost
Als je nog iets kunt vertellen over de verschillen tussen Access en MySQL dan heeft de TS niet helemaal voor niets gepost
Ruzie, hmz, S is Structured, staat zelfs op je "heilige" Wiki pagina, heeft altijd al zo geheten sinds dat ik geloof IBM het opschreef.
Over een inhoudelijke vergelijking van MySQL en Access zou ik me niet kunnen wagen, maar jou statement "Je kunt Access niet echt vergelijken met MySQL, net zoals je MySQL eigenlijk niet kunt vergelijken met echte relationele databases."
MySQL is net zo goed een volwaardige relationele database als Oracle, SQL Server, Access, Progress, DB2, Sybase, SQLite, Filemaker ieder daarvan heeft wel zijn eigen nukken en zijn eigen ding.
Met name Access weet ik van dat je bijvoorbeeld geen triggers kan hebben wat ik bijvoorbeel Oracle,SQL Server wel kan. Verder heeft Access (nog altijd) een uitdaging met de 2 gig limiet. Kan een database prima werken zonder triggers? Ja, Kan een database kleiner dan 2 gig blijven... heel veel databases zijn kleiner dan 2 gig
Het hangt af van je eigen perspectief, ervaring, doelstellingen en budget af wat je gebruikt, je wil niet weten hoeveel respectabele bedrijven en websites er op MySQL drijven
Over een inhoudelijke vergelijking van MySQL en Access zou ik me niet kunnen wagen, maar jou statement "Je kunt Access niet echt vergelijken met MySQL, net zoals je MySQL eigenlijk niet kunt vergelijken met echte relationele databases."
MySQL is net zo goed een volwaardige relationele database als Oracle, SQL Server, Access, Progress, DB2, Sybase, SQLite, Filemaker ieder daarvan heeft wel zijn eigen nukken en zijn eigen ding.
Met name Access weet ik van dat je bijvoorbeeld geen triggers kan hebben wat ik bijvoorbeel Oracle,SQL Server wel kan. Verder heeft Access (nog altijd) een uitdaging met de 2 gig limiet. Kan een database prima werken zonder triggers? Ja, Kan een database kleiner dan 2 gig blijven... heel veel databases zijn kleiner dan 2 gig
Het hangt af van je eigen perspectief, ervaring, doelstellingen en budget af wat je gebruikt, je wil niet weten hoeveel respectabele bedrijven en websites er op MySQL drijven
Nou nog even dan, omdat ik gelijk wil hebben Oh, en het laatste woord ook graag.
Je hebt nu al drie keer gezegd dat het voor Structured staat, maar niemand beweert het tegendeel.
De wiki is mij niet heilig, het is alleen een verwijzing naar waar de SQL standaard gevonden kan worden.
Als je de standaard leest (en dat is niet makkelijk) dan zie je dat 99.9% van de zaken waarin de grote databases anders gaan niet eens worden genoemd in de standaard.
MySQL is helaas feitelijk nog niet eens een RDBMS, laat staan een volwaardige. Reden: alles waar de R in RDBMS voor staat kun je in MySQL uit schakelen. (behalve triggers, die kun je dan weer niet deferren, wat nu juist weer erg handig is)
Daarnaast rammelt MySQL aan alle kanten; je kunt in een ENUM dubbele waarden defineren, je kunt een transactie committen met BEGIN (een bijzonder gevaarlijke "feature"), je kunt een kolom als
NOT NULL definieren en vervolgens vullen met NULL door de NULL te kopieren uit een andere tabel, als je een backup maakt moet je aangeven dat je de stored functions ook mee wilt dumpen, anders komen die botweg niet in je backup, en zo gaat het nog een tijdje door.
Dus nee, MySQL is geen volwaardige RDBMS en als DMBS in het algemeen is het een van de slechtere, het rammelt en loopt qua functionaliteit ver achter op de rest.
Nu is jouw volgende vraag waarschijnlijk iets als "als het zo slecht is, waarom gebruiken dan zoveel mensen toch MySQL?" Dat is omdat er ook tegenwoordig nog een idee leeft dat MySQL veel eenvoudiger en sneller is dan de rest. Dat het vervolgens niet goed werkt valt niet op want men is niets anders gewend. Het is ook niet voor niets dat je wel regelmatig topics ziet over migraties van MySQL naar iets anders, en vrijwel nooit van iets anders naar MySQL.
Klopt, en de vraag is dan: heeft de dataabse geen triggers nodig omdat er geen triggers nodig zijn, of denkt de ontwikkelaar dat hij de functionaliteit van triggers in de applicatie kan oplossen?
Vooral bij MySQL wordt er heel wat code geschreven om het gebrek aan features in MySQL op te lossen, en dat is gewoon zonde van de tijd.
Oh, en het laatste woord ook graag.Je hebt nu al drie keer gezegd dat het voor Structured staat, maar niemand beweert het tegendeel.
De wiki is mij niet heilig, het is alleen een verwijzing naar waar de SQL standaard gevonden kan worden.
Als je de standaard leest (en dat is niet makkelijk) dan zie je dat 99.9% van de zaken waarin de grote databases anders gaan niet eens worden genoemd in de standaard.
MySQL is helaas feitelijk nog niet eens een RDBMS, laat staan een volwaardige. Reden: alles waar de R in RDBMS voor staat kun je in MySQL uit schakelen. (behalve triggers, die kun je dan weer niet deferren, wat nu juist weer erg handig is)
Daarnaast rammelt MySQL aan alle kanten; je kunt in een ENUM dubbele waarden defineren, je kunt een transactie committen met BEGIN (een bijzonder gevaarlijke "feature"), je kunt een kolom als
NOT NULL definieren en vervolgens vullen met NULL door de NULL te kopieren uit een andere tabel, als je een backup maakt moet je aangeven dat je de stored functions ook mee wilt dumpen, anders komen die botweg niet in je backup, en zo gaat het nog een tijdje door.
Dus nee, MySQL is geen volwaardige RDBMS en als DMBS in het algemeen is het een van de slechtere, het rammelt en loopt qua functionaliteit ver achter op de rest.
Nu is jouw volgende vraag waarschijnlijk iets als "als het zo slecht is, waarom gebruiken dan zoveel mensen toch MySQL?" Dat is omdat er ook tegenwoordig nog een idee leeft dat MySQL veel eenvoudiger en sneller is dan de rest. Dat het vervolgens niet goed werkt valt niet op want men is niets anders gewend. Het is ook niet voor niets dat je wel regelmatig topics ziet over migraties van MySQL naar iets anders, en vrijwel nooit van iets anders naar MySQL.
Klopt, en de vraag is dan: heeft de dataabse geen triggers nodig omdat er geen triggers nodig zijn, of denkt de ontwikkelaar dat hij de functionaliteit van triggers in de applicatie kan oplossen?
Vooral bij MySQL wordt er heel wat code geschreven om het gebrek aan features in MySQL op te lossen, en dat is gewoon zonde van de tijd.
- Status
