Apache/MySQL app omzetten naar IIS/MSSQL

[m33p]

Beste,

Ik heb een webapp ontwikkeld op Apache in PHP welke de gegevens als XML data en in een MySQL database opslaat. Nou is mijn vraag aardig kort.

Hoe 'makkelijk' is het omzetten van een MySQL app naar een MSSQL app voor iemand die weet hoe de mssql enterprise manger werkt, en.. that's about it Mijn MySQL kennis is aardig hoog, maar aangezien we hier binnen het bedrijf zo'n 20 MSSQL servers hebben, en 1 MYSQL server is het misschien handig om maar eens MSSQL te gaan leren.

Ik heb al lopen zoeken, en op het eerste gezicht lijkt het ernstig veel op MySQL. Kan iemand mij vertellen in hoeverre MySQL verschilt van MSSQL? Dan doel ik niet op de extra functies ofzo, maar puur de query-compatibiliteit tussen MySQL en MSSQL.

Afhankelijk van bovenstaand wil ik ook een versie van de app maken voor IIS. Opzich geen probleem afgezien dat mijn app gebruik maakt van multiviews (Apache). Ik kan niet vinden of er ook zoiets als multiviews / mod_rewrite is voor IIS. Iemand die daar een alternatief voor heeft?

Alvast bedankt

[ZroBioNe]

Ik weet dat LIMIT van MySQL niet werkt in MSSQL

[Gerco]

Er is een rewrite module voor IIS en die heet IISRewrite. Er zijn er vast nog wel een paar. Als je scripting taal ook onder IIS draait en je een nette DAL in je app hebt, is het een kwestie van de connectie URL veranderen en het draait.

In het slechtste geval zit je met een complete rewrite. Ergens halverwege kun je je app omzetten door overal 'mysql' te vervangen door 'mssql'.

Kortom, er is te weinig info in je startpost om hier iets zinnigs over te zeggen.

[ Voor 18% gewijzigd door Gerco op 06-04-2006 14:17 ]

[giMoz]

ok, je haalt volgens mij een aantal zeken door elkaar:
Je maakt geen app voor Apache of voor IIS: maar in PHP of in ASP(.net) ...
EN MySQL is geen taal, en MSSQL ook niet, maar zijn Database Management Systemen (DBMS'en)... Met beide als belangrijkste functionaliteiten dat ze te bevragen zijn met SQL (of een variant hierop)

Vraag is nu: waar is je applicatie in gemaakt???

[m33p]

Het staat toch aardig duidelijk in de eerste zin (welke ik nog wat aangepast heb) maar om het te verduidelijken:

Het is gescript in PHP.
Het draait op Apache
De data staat in een MySQL database

Wat wil ik:
Scripting in PHP
Draaiend op IIS
De data in een MSSQL database

Gerco:
De term DAL zegt mij niks, en google kan me er ook niet veel over vertellen. Enige uitleg wat 'DAL' betekend a.u.b?

[ Voor 6% gewijzigd door m33p op 06-04-2006 14:27 ]

[Thekk]

DAL = Database Abstraction Layer, dus een laag tussen je programma en je database. Die zorgt ervoor dat je programma zo weinig mogelijk (eigenlijk alleen de connectiestring) weet van de database, en je die database dus ook makkelijk kan uitwisselen.

[ Voor 78% gewijzigd door Thekk op 06-04-2006 14:32 ]

[Gerco]

m33p schreef op donderdag 06 april 2006 @ 14:26:
Het staat toch aardig duidelijk in de eerste zin (welke ik nog wat aangepast heb) maar om het te verduidelijken:

Dat stukje over PHP ontbrak dus

De term DAL zegt mij niks, en google kan me er ook niet veel over vertellen. Enige uitleg wat 'DAL' betekend a.u.b?

DAL staat voor "Data Access/Abstraction Layer", dat is een laag functies of objecten die je app gebruikt om gegevens te manipuleren en op te vragen. Als je een DAL hebt, staan daar al je queries en DBMS specifieke functionaliteit in. Vervang die MySQL-DAL door een MSSQL-DAL en het werkt.

Uit je reaktie begrijp ik dat je geen DAL hebt, dus ik ga er vanuit dat je overal in je app "mysql_" calls gebruikt. Je zal je hele app moeten doorlopen en alle mysl_ calls moeten vervangen door het mssql equivalent (hoe je dat ook vanuit PHP gebruikt, geen idee).

Volgende keer iets als PEAR:DB gebruiken en je zult hier minder moeite mee hebben. Je moet natuurlijk nog steeds je queries aanpassen als je MySQL only features gebruikt.

[ Voor 6% gewijzigd door Gerco op 06-04-2006 14:34 ]

[qless]

Wel van mySQL naar msSQL valt opzich mee, echter mySQL is voor (simpele) queries (dus geen joins e.d.) veel sneller dan msSQL...
Ook is de performance van PHP beter in Apache dan in IIS.

Dus waarom ombouwen? laat de rest maar omgaan.

[giMoz]

@qless: duidelijk niet....

voor MSSQL zijn er de stored procs die ervoor zorgen dat het performance verschil weer snel wordt ingelopen...
de performance van PHP onder apache is idd beter dan bij IIS maar daar is dus ASP.Net voro uitgevonden. Mits goed gebruik gemaakt van caching e.d. is die combi dan nogal wat sneller dan PHP/MySql

[TeeDee]

qless schreef op donderdag 06 april 2006 @ 14:35:
Dus waarom ombouwen? laat de rest maar omgaan.

Wat een onzin. Als je leest, zie je dat er in zijn omgeving 20 MSSQL servers staan. Nofi aan de TS, maar op dit moment is hij juist diegene die afwijkend gedrag vertoont

Wat je evt. zou kunnen doen is gewoon op Apache/PHP blijven draaien, alleen je databank naar MS-SQL omtoveren.

[Gerco]

@giMoz:

PHP en ASP.NET zijn dan ook niet vergelijkbaar. ASP.NET is een gecompileerde omgeving en PHP scripts worden steeds opnieuw geparsed. Je kunt beter Zend Encoded PHP vergelijken met ASP.NET. Het performance verschil zal dan een stuk kleiner zijn.

Blijft natuurlijk wel dat MSSQL een beter en, mits goed ingezet, sneller DBMS kan zijn dan MySQL. Vooral als je ingewikkelde dingen doet. Bij recht-toe-recht-aan data selecteren zal MySQL waarschijnlijk nog wel wat vlotter blijven.

[whoami]

giMoz schreef op donderdag 06 april 2006 @ 15:14:
@qless: duidelijk niet....

voor MSSQL zijn er de stored procs die ervoor zorgen dat het performance verschil weer snel wordt ingelopen...

Stored procedures zijn niet per definitie sneller / beter dan parametrized queries.
Er zijn natuurlijk wel bepaalde dingen die je sneller kan doen met een SP, maar het is niet zo dat een SP per definitie beter / sneller is dan een embedded parametrized query.

[Janoz]

maar in php heb je geen parametrized queries

[GX]

Janoz schreef op donderdag 06 april 2006 @ 15:34:
maar in php heb je geen parametrized queries

Nee, en in txt ook niet. Je punt? _{Zucht: nuance.} Prepared statements zijn er niet voor niets, Oracle, pgsql en mysql kennen deze. Wat Mssql er mee doet weet ik niet, maar ik neem gewoon aan dat ook die ze kent.

Overigens dat MySQL alleen maar simpele queries is moet me nog even uitgelegd worden. Ongenuanceerd tegen MySQL flamen kan iedereen wel.

_{Ja, de vraag van de TS is al beantwoord, maar ik stoor me nogal aan misconceptie van een heleboel onderwerpen in deze draad}

[ Voor 18% gewijzigd door GX op 06-04-2006 15:43 ]

[gorgi_19]

GX schreef op donderdag 06 april 2006 @ 15:39:
Nee, en in txt ook niet. Je punt?

Dat je niet per se stored procedures hoeft te gebruiken in SQL Server voor performance winst, maar ook parametrized queries kan gebruiken. Echter, PHP kent dit niet.

[whoami]

GX schreef op donderdag 06 april 2006 @ 15:39:
[...]


Nee, en in txt ook niet. Je punt?

En wat is jouw punt dan ? Hoe ga je dit probleem dan oplossen met de combo php/mysql als je in php geen parametrized queries hebt ?

Overigens dat MySQL alleen maar simpele queries is moet me nog even uitgelegd worden. Ongenuanceerd tegen MySQL flamen kan iedereen wel.

Ik denk dat je even beter moet lezen; er werd gezegd dat MySQL waarschijnlijk sneller is dan MS-SQL als het gaat om het uitvoeren van eenvoudige / simpele queries.
Echter, ook hier heb ik nog geen onderbouwing voor gezien.

[GX]

whoami schreef op donderdag 06 april 2006 @ 15:43:
En wat is jouw punt dan ? Hoe ga je dit probleem dan oplossen met de combo php/mysql als je in php geen parametrized queries hebt ?

Met prepared statements.

Ik denk dat je even beter moet lezen; er werd gezegd dat MySQL waarschijnlijk sneller is dan MS-SQL als het gaat om het uitvoeren van eenvoudige / simpele queries.

Oeps.

Echter, ook hier heb ik nog geen onderbouwing voor gezien.

Ik wacht mee.

edit:
Na wat googlen heb ik niet echt een MySQL 5.0 vs MS SQL vergelijking kunnen vinden. Misschien iemand hier die beschikking heeft tot MS SQL en tijd/zin/machtigingen/vrijheid heeft om te benchmarken?

[ Voor 17% gewijzigd door GX op 06-04-2006 16:06 ]

[Gerco]

quote: http://swik.net/MySQL/MySQL+vs+MS+SQL+Server

At the moment this was written, SQL Server 2000 held the second position in the OLTP Test in price by performance results. MySQL does not participate in these tests and they have their own benchmark tests, so it is difficult to make a head on comparison. In some benchmarks, MySQL has proven to be faster in its table format, MyISAM. MyISAM databases are very compact on disk and place little demand on CPU cycles and memory.

Er is dus geen duidelijke en onafhankelijke bechmark die MySQL boven MSSQL plaatst kwa performance. Ook niet eronder trouwens. Wel zijn er hier en daar reports dat MySQL's MyISAM tables bijzonder lightweight en snel zijn.

Overal gezien is er dus niet echt een winnaar aan te wijzen tot MySQL aan de onafhankelijke benchmarks mee gaat doen.

[m33p]

Ik heb wel een DAL in mn app gebouwed (een MySQL class) dus dat moet opzich geen probleem zijn. De performance van MySQL maakt ook niet denderend veel uit. Het zijn voornamelijk inserts en op het moment barweinig selects en de performance is nu zeer hoog en ik verwacht ook niet dat het merkbaar zal zijn.

Ook stelt men voor om het om te bouwen naar ASP maar dat is me net wat té.

De reden dat ik afwijk is dat in het bedrijf waar ik werk een 30-tal programmeurs zitten welke in C en .NET (dacht ik) applicaties ontwikkelen welke op MSSQL draaien. Ik ben 'maar' de systeembeheerder, en ben voor mezelf bezig een monitoring app te ontwikkelen die aan mijn eisen voldoet. Opzich kan ik het zo laten draaien, het werk, en goed ook maar het is niet erg efficient, vandaar het idee om te kijken of het mogelijk is het om te zetten naar iets wat op IIS draait en kan werken met een MSSQL database. Voor zover ik heb kunnen vinden ga ik wel wat probleempjes krijgen, maar geen problemen welke niet op te lossen zijn

[whoami]

Gerco schreef op donderdag 06 april 2006 @ 15:59:
[...]


Er is dus geen duidelijke en onafhankelijke bechmark die MySQL boven MSSQL plaatst kwa performance. Ook niet eronder trouwens. Wel zijn er hier en daar reports dat MySQL's MyISAM tables bijzonder lightweight en snel zijn.

Overal gezien is er dus niet echt een winnaar aan te wijzen tot MySQL aan de onafhankelijke benchmarks mee gaat doen.

Trouwens, het hangt er dan ook nog eens van af hoe die databases getuned zijn. Een MySQL database kan het misschien halen van een MS SQL Server DB, als die Sql Server DB tabellen sterk gefragmenteerd zijn (door bv veel page-splits die recentelijk zijn gedaan), of verkeerde (of geen) clustered indexes hebben.
Als je die DB dan defragmenteerd, en een goede clustered index hebt gedefinieert, dan kan het resultaat plots heel anders zijn.

[Janoz]

Waarom heeft iedereen het over de snelheid van db's? Voor een database lijkt mij snelheid niet het belangrijkste. Misschien wel voor hobby projecten, maar in een iets proffesionelere omgeving lijkt mij data integriteit toch wel prio nummer 1.

[Gabberhead]

Janoz schreef op vrijdag 07 april 2006 @ 09:49:
Waarom heeft iedereen het over de snelheid van db's? Voor een database lijkt mij snelheid niet het belangrijkste. Misschien wel voor hobby projecten, maar in een iets proffesionelere omgeving lijkt mij data integriteit toch wel prio nummer 1.

In een professionele omgeving is performance minstens even belangrijk als integriteit. Bij een factuurrun voor 1,5 miljoen klanten wil je allebei goed hebben.
Als de integriteit goed is, maar je queries hebben 2 weken nodig om alle data te verzamelen, ligt je bedrijf dus 2 weken stil. (en omgekeerd, een run in 1 nacht die verkeerde facturen oplevert is net zo desastreus).

[whoami]

m33p schreef op vrijdag 07 april 2006 @ 09:28:
Ik ben 'maar' de systeembeheerder, en ben voor mezelf bezig een monitoring app te ontwikkelen die aan mijn eisen voldoet.

Voldoet de Sql Profiler dan niet aan jouw eisen ?

Janoz schreef op vrijdag 07 april 2006 @ 09:49:
Waarom heeft iedereen het over de snelheid van db's? Voor een database lijkt mij snelheid niet het belangrijkste. Misschien wel voor hobby projecten, maar in een iets proffesionelere omgeving lijkt mij data integriteit toch wel prio nummer 1.

Daar ben ik het niet 100% mee eens. Integriteit is idd wel het belangrijkste, maar performance is toch zeker even belangrijk.

[ Voor 48% gewijzigd door whoami op 07-04-2006 10:04 ]

[m33p]

whoami schreef op vrijdag 07 april 2006 @ 10:03:
[...]

Voldoet de Sql Profiler dan niet aan jouw eisen ?

Niet performance-wise, maar feature-wise bedoel ik. Er zijn tal van apps welke ook netwerk kunnen monitoren, maar die voldoen niet aan mijn eisen Uiteraard

kan ik de SQL profiler goed gebruiken om de query's om te zetten van MySQL naar MSSQL

Edit:
Nu ik het nalees snap ik je bericht. Er moest netwerk - monitoring app staan, mijn fout...

[ Voor 12% gewijzigd door m33p op 07-04-2006 10:19 ]

[Janoz]

Gabberhead schreef op vrijdag 07 april 2006 @ 09:54:
[...]


In een professionele omgeving is performance minstens even belangrijk als integriteit. Bij een factuurrun voor 1,5 miljoen klanten wil je allebei goed hebben.
Als de integriteit goed is, maar je queries hebben 2 weken nodig om alle data te verzamelen, ligt je bedrijf dus 2 weken stil. (en omgekeerd, een run in 1 nacht die verkeerde facturen oplevert is net zo desastreus).

Ik zeg niet dat performance onbelangrijk is. Het lijkt mij echter eerder prio nummertje 2. Als ik echter kan kiezen tussen een iets tragere oplossing met een betere integriteit dan zou ik daar voor kiezen. De traagheid los ik dan wel op door een extra of grotere server neer te zetten. Daarnaast vermoed ik niet dat de verschillen zo groot zijn dat een run van 2 weken wordt terug gebracht naar enkele uren enkel en alleen door het gekozen pakket . Dit soort verschillen zijn alleen te behalen door je database ontwerp te optimaliseren.

[Gabberhead]

Janoz schreef op vrijdag 07 april 2006 @ 11:01:
[...]


Ik zeg niet dat performance onbelangrijk is. Het lijkt mij echter eerder prio nummertje 2. Als ik echter kan kiezen tussen een iets tragere oplossing met een betere integriteit dan zou ik daar voor kiezen. De traagheid los ik dan wel op door een extra of grotere server neer te zetten. Daarnaast vermoed ik niet dat de verschillen zo groot zijn dat een run van 2 weken wordt terug gebracht naar enkele uren enkel en alleen door het gekozen pakket . Dit soort verschillen zijn alleen te behalen door je database ontwerp te optimaliseren.

Geloof me, er zijn veel meer oorzaken voor performance problemen dan alleen de keuze voor een pakket
En een oplossing wordt heus niet alleen behaald door meer ijzer neer te zetten. Welkom in de wondere wereld van Oracle en de grootverbruikers

Op het gevoel zou ik ook zeggen dat integriteit een hogere prio heeft dan performance, maar in de praktijk wordt er op beide snoeihard afgerekend. Voor veel IT-managers is er voor beide een even hoge prio.

Ik begrijp je stelling wel hoor. Op het niveau waar we het hier in dit topic over hebben is performance natuurlijk geen issue. Misschien is een ander topic beter geschikt om het over de principes van prio keuzes te hebben

[killercow]

ik heb nog nooit zoveel mods zo ongeloofenlijk off-topic zien gaan.

php kun je net zo gemakkelijk op windows/iss als op linux/apache draaien.

sommige php modules moet je iets anders aanspreken, en ook de bestands paden zijn natuurlijk anders, maar voor de rest (op backticks enzo na) werkt alles het zelfde.
Ik heb net in een uurtje of wat zo'n 50mb aan windows/iis .php scripts overgegooid naar een linux/apache omgeving.

zaken als schrijfrechten enzo zul je ongetwijfeld onder de knie hebben, dus tjah wat let je.

Waarom stap je niet rustig in stapjes over? eerst van apache naar iis, (met error-logging tot file aan)

en daarna als dat allemaal lekker soepel en error vrji draait, stap je over naar MSSQL, wat eenongeveer net zo grote stap moet zijn gok ik.

Performance is echt een bullshit verhaal, als je namelijk miljoenen hits gehad, had je dit in de eerste post wel gezegt, en aangezien jij de sysadmin bent, gok ik er op dat de echte apps die het zware werk moeten doen wel door de programmeurs gemaakt worden, niet?

Of MSSQL en MySQL nu even snel zijn of niet vindt je niet uit met discussies, dat vindt je uit met benchmarks, en eventueel 2 doorgewinterde programmeurs die allebij een app 100% volgens de strakke specs (keys/functies/etc) bouwen, en eventueel een app 100% geoptimaliseerd naar hun platform.

edit:

Ik ben zelf van iis+php+mysql afgestapt naar linux(lvs)+apache+mysql omdat onder hoge "load", windows meer op een bokkende ezel leek dan op een OS, dit in combinatie met fast-cgi en turck mmcache.

[ Voor 8% gewijzigd door killercow op 07-04-2006 21:16 ]