Exchange-roadmap vervolgt zijn bochtige weg

Ik geloof er niets van dat er zo'n stammenstrijd is bij MS.

ESE en SQL hebben gewoon allebei hun sterke punten, en daardoor is het een beter geschikt voor Exchange en het andere beter voor algemene databases.

Dat SQL ook voor bestandsopslag gebruikt gaat worden is nogal logisch. Het type load dat je bij bestandsopslag krijgt sluit keurig aan bij de sterke punten van SQL.

Sharepoint had daarom ook van het begin af aan op SQL gebouwd moeten worden. Een ESE database is gewoon ontzettend onlogisch daarvoor.
Maar Sharepoint komt uiteindelijk voort uit public folders met digital dashboard. En die developers waren dus gewend aan ESE.

Zelfs als je straks wel Exchange krijgt op een SQL database, dan ben ik er van overtuigd dat Microsoft zal aanraden daar een dedicated SQL Server voor te gebruiken aangezien de load op die databases zo totaal anders zal zijn dan alle andere SQL databases.

Dat is eigenlijk niet uit te leggen zonder heel diep in de techniek te duiken. Maar ik zal toch een poging wagen zonder dat te doen.

Het probleem tussen SQL en ESE is dat die databases op een totaal andere wijze worden aangesproken.

Bij SQL zul je bv een database hebben met relatief statische data waar veel zoek opdrachten op worden gedaan.

Bij Exchange (ESE) komt dat bijna niet voor. De data is gigantisch dynamisch en je zoekt zelden de hele database door. Verder zit er weinig structuur in de data.
Bv: een mailtje komt binnen. Het wordt door een gebruiker geopend. Er wordt een reply gemaakt waarbij die data opnieuw ingelezen moet worden. Het wordt verplaats naar een andere folder, en een uurtje later gewist. En dat moet bovendien allemaal supersnel gebeuren.

Vanwege dat grote verschil bleek al snel dat SQL niet genoeg prestatie zou kunnen leveren voor een Exchange database. Vandaar dat er dus voor Exchange een nieuwe database ontworpen is die optimaal geschikt is voor het soort load dat je in Exchange krijgt. (En die database heeft in zijn oorsprong banden met de access database, maar is inmiddels zodanig aangepast dat het niet meer te vergelijken is)

Nu kun je wel een SQL server ontwikkelen die ook goed geschikt is voor het soort databases dat Exchange nodig heeft, maar de vraag is of dat nuttig is. Want naast Exchange ken ik geen andere applicaties die een zelfde database belasting opleveren. Dus heeft het dan zin al die extra code in SQL te schrijven of kun je net zo goed die code in een apart programma houden?

Ik zou niet echt verbaasd zijn als ze inderdaad nog niet met SQL integreren.

De hele manier waarop een Exchange database noodzakelijkerwijs opgezet moet worden, en de soort load die zo'n database krijgt, is totaal verschillend van een normale sql database.
Uiteraard kun je het integreren, maar dan krijg je bij het aanmaken van een nieuwe database in SQL waarschijnlijk eerst de vraag of je een klassieke database wilt aanmaken, of een exchange compatible sql database.
Je moet je dan afvragen of je niet beter twee verschillende databases kunt houden, zodat beide producten optimaal op hun eigen type database zijn afgesteld.

Als Exchange admin zat ik niet echt op die SQL database te wachten. Het levert mij geen voordeel op. Die 64bit support zou wel mooi zijn want al dat geklooi met 3GB, userva switches en de geheugen fragmentatie zou dan een stuk minder worden.

Ik snap alleen niet waarom ze nog steeds met die public folders bezig blijven. Het concept lijkt aardig, maar in de praktijk werkt het gewoon niet in grote omgevingen. Ook bij Microsoft zelf worden die dingen bijna niet gebruikt.

In de plaats daarvan zou het de JET-technologie, die sinds versie 5.5 door het leven gaat als ESE en niet verward mag worden met de technologie uit Access, blijven gebruiken.

Juist niet dus.