Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Applicaties voor meerdere RDBMS'en verspilling

 

Nogal wat leveranciers van softwarepakketten adverteren met hun ondersteuning van meerdere merken databases. En het zijn niet de minsten. Onder hen: SAP, Opentext, en Topdesk, om er maar een paar te noemen. Als enige eis stellen deze applicaties dat er een SQL-compliant database wordt gebruikt. Elke serieuze relationele database spreekt dit protocol.

Oppervlakkig beschouwd klinkt dat aanlokkelijk: welk merk database in je organisatie al aanwezig is, Oracle, IBM DB/2, MS SQLServer of MySQL: het gaat werken. Dat scheelt installeren, het opleiden van je beheerders en het onderhandelen met een databaseleverancier.

Toch is het gewoon een slecht idee en moet je dit niet willen. Waarom niet? Er zijn argumenten van technische en architectonische aard. Daarover graag een volgende keer. Hieronder een simpeler reden: geld. Je betaalt bij zo’n applicatie teveel licentiekosten voor de database en voor de licentiekosten van het pakket zelf.

Licentiekosten database

De afgelopen decennia hebben leveranciers van databases enorm veel functionaliteit toegevoegd aan hun producten. Waar databanken in het (verre) verleden uitsluitend de opslag van gegevens regelden in tabellen, zijn deze in de loop van de tijd geëvolueerd tot geavanceerde platforms met de introductie van autorisatielagen, integriteitscontroles, stored procedures, triggering mechanismen en zelfs embedded fileservers, webservers en jobschedulers. Voor al die mooie functies wordt dan wel stevig betaald door de afnemers. Zelfs de instaplicentie van een database van één van de grote merken kost al snel duizenden euro’s per jaar.

In tegenstelling tot de standaardtaal SQL, (die overigens vele dialecten kent) zijn al die extra opties leverancierspecifiek en daardoor niet (zomaar) uitwisselbaar. Pakketten die meerdere SQL-databases ondersteunen gebruiken daarom alleen die opties van een database die altijd aanwezig en universeel zijn: het verbinden met de database en de opslag van data. Dat is natuurlijk doodzonde: al die mooie opties van jouw database worden niet gebruikt. Maar je betaalt er wel voor.

Licentiekosten pakket

Om meerdere databasemerken te kunnen ondersteunen moet een pakketleverancier flink investeren. Tenslotte moet hij minimaal testen of zijn applicatie ook echt werkt met al die SQL-databases. Dat betekent kosten voor de licenties van al die gegevensbanken, het inhuren of in dienst nemen van personeel met de benodigde kennis, testen, extra infrastructuur, et cetera.

Jij, als afnemer van zo’n pakket kiest echter (meestal) maar één optie: SAP met Oracle of Opentext eDocs met SQLServer. Je betaalt dan echter eveneens voor de ontwikkelkosten van SAP met SQLServer, DB/2 of SAP-DB. De licentiekosten van de applicatie zijn dus (aanmerkelijk) hoger voor functionaliteit waar je als afnemer niets aan heeft.

Niet doen dus, die applicaties die meerdere databases ondersteunen. Dat is het weggooien van (veel) geld. Kun je echt niet om een pakket heen, omdat het de standaard in jouw branche is of de functionaliteit precies aansluit bij jouw behoefte: kies dan voor de goedkoopste database, al is deze nieuw voor je organisatie. Je beheerders zullen er weinig werk aan hebben want van al die geavanceerde functies wordt toch geen gebruik gemaakt. In alle andere gevallen: kies een pakketleverancier die keuzes durft te maken en optimaal gebruik maakt van de opties van jouw dure database.

Jurrie Zaat, managing consultant Orcado

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/5001398). © Jaarbeurs IT Media.

?


Lees meer over


 

Reacties

Klinkt als een logisch verhaal, maar het gaat te kort door de bocht.

Vanuit een software leverancier perspectief is het inderdaad duur om je applicatie te laten landen op veel verschillende database systemen. Het kost immers ontwikkelkracht en tijd om te testen en ingewikkelder om te onderhouden. Het is echter een feit dat als je het niet doet, je klanten dus zult mislopen. Als je pakket dus groot is, kun je de keuze voor 1 database niet makkelijk meer maken.

En ja, door geschikt te zijn voor veel databases mis je alle functionaliteit die de verschillende systemen bieden en is de database eigenlijk het sluitstuk van de applicatie geworden. Daarnaast speelt er ook het performance issue. Met generieke code bereik je geen grote performance.

Een mogelijkheid om de propositie naar klanten slimmer te maken is door je software als een dienst aan te bieden met daarnaast API's om integratie mogelijk te maken. Daarmee kun je als software leverancier WEL profiteren van de voordelen van een specifieke database EN ontzorg je de klant EN los je het probleem van de extra licenties op.


Het argument "Niet doen dus, die applicaties die meerdere databases ondersteunen" vind ik echter slecht onderbouwd. Of je een pakket aan wilt schaffen hangt in mijn ogen niet af van dit database verhaal, maar van andere eigenschappen, namelijk welke waarde het biedt ten opzichte van de investering en operationele kosten.

"kies dan voor de goedkoopste database, al is deze nieuw voor je organisatie" vind ik ronduit een gevaarlijk advies. Je zegt tegen een bedrijf technologie op te nemen waarover het zelf geen kennis en dus controle op heeft. Dan zit je dus vaak aan *nog* een partij vast die dat deel voor je moet beheren. Maar ook qua veiligheid, misschien doe je wel dingen die de veiligheid van je hele infrastructuur op het spel zetten.

Laatst zag ik nog een bedrijf die zelf een Wiki in de lucht takelde op basis van Linux en open source terwijl het bedrijf daar nauwelijks kennis over had. Maarja, het was zo goedkoop... Een levensgevaarlijke keuze.

Slecht verhaal..

Je hoeft vaak niet de meest uitgebreide (dure) versie van een RDBMS aan te schaffen, juist omdat niet alles gebruikt wordt door de applicatie.

Maar de auteur gaat compleet voorbij aan de eisen die een klant stelt aan de complete stack (applicatie + infrastructuur). Bijvoorbeeld beschikbaarheid, performance, backups, monitoring, kwaliteit support, etc.

Dan kan domweg de (qua licentie) goedkoopste database ineens heel erg duur uitpakken.
'Je beheerders zullen er weinig werk aan hebben want van al die geavanceerde functies wordt toch geen gebruik gemaakt.'
Haha.. Ja, want een compleet onbekend RDBMS, die installeer je even op een vrijdagmiddag. Kan meteen in productie..
Die extra DB features heeft een beheerder vaak sowieso geen werk aan, maar heeft impact op de eigen ontwikkelaars (rapportages bouwen of stukje maatwerk).

Hetzelfde kun je dan zeker generieker doortrekken naar platforms. Kies geen MS Office, want dat draait naast Windows ook op MacOS!
Gebruik geen apps! Want die worden zowel voor iOS als Android ontwikkeld, dus duur..
Enzovoorts..

Juist hierom hebben veel (grote) bedrijven de voorkeur voor zo min mogelijk verschillende platforms. Bijv. alles Linux-Oracle, AIX-DB2 of Windows-SQLServer. Omdat die specialisten zo duur zijn en je niet voor elk pakket weer de "goedkoopste" database wilt kiezen die afwijkt van de standaard.
Grote pakketleveranciers spelen hier op in, vraag-aanbod vanuit de klant dus.

Beste Henri,

Dank voor je uitgebreide reactie.
Mijn stuk(je) was nu juist niet vanuit het perspectief van de leverancier geschreven, maar vanuit de klant. Je merkt terecht op dat er nog veel meer nadelen zijn bij universele applicaties, performance is er daar inderdaad één van.

Mijn punt is dat de ondersteuning van meerdere databases vaak wordt gezien als een voordeel en dus koopargument terwijl ik dat om meerdere redenen juist als een nadeel zie. Je opmerking dat je als leverancier geen keuze zou hebben vind ik onjuist. Er zijn genoeg voorbeelden waarbij die keuze wel is gemaakt en het pakket erg succesvol is. Denk bijvoorbeeld aan Microsoft Dynamics, Oracle Applications of Exact.

Bij het aanbieden van een applicatie als dienst is de keuze voor de onderliggende database inderdaad minder van belang, maar dat lijkt me een andere discussie; namelijk die over de voor- en nadelen van het in huis hebben van systemen of het inkopen van diensten.

En tja, een gevaarlijk advies. Dat valt maar te bezien. Er is, lijkt me, nog wel een verschil tussen ergens totaal geen kennis van hebben en genoeg om het in de lucht te houden zonder specifiek getrainde databasebeheerders te hebben rondlopen. Bovendien zijn de gegevens in de onderliggende database (waarvan ik het belang juist erg groot acht) meestal slecht afgeschermd bij generieke applicaties. De data is te muteren zonder (goede) integriteitscontroles en vaak is er maar 1 gebruiker die "alles mag". De veiligheid is dus sowieso een issue. Dat je door te kiezen voor een nieuwe database je totale infrastructuur in gevaar brengt waag ik daarom nogal te betwijfelen.

Beste JW,

Jammer dat je het een 'slecht verhaal' vindt. Wel leuk dat ook jij uitgebreid reageert.

Dat klanten voor 1 platform kiezen komt, zeker bij grotere organisaties, volgens mij maar weinig voor. Mijn punt is overigens ook niet dat klanten 'zo maar' nieuwe besturingssystemen of smaken databases moeten installeren maar wel dat ze applicaties moeten kiezen die zijn geoptimaliseerd voor hun (bestaande) omgeving en niet degenen die pretenderen alles te ondersteunen .

Je voorbeeld van het doortrekken van de gedachte naar officepakketten is onbedoeld een aardige. Zoals je ongetwijfeld weet is de ondersteuning van MS Office op het OSX-platform heel veel slechter dan op Windows. Het is eigenlijk zelfs een ander pakket en niet alle onderdelen (zoals Access of Outlook) worden voor OSX geleverd. In feite heeft Microsoft hier dus wel degelijk een keuze gemaakt. Aan de andere kant gaat die vergelijking wel een beetje mank: er is bij dat pakket geen directe andere relatie met andere software zoals een database. Daar ging het mij nu juist om.

En ja: een standaardinstallatie van een database installeer ik prima in een vrijdagmiddag. Je mag me bellen! ;-)

Er is gewoon een markt voor Applicaties voor meerdere rdbms'en.

Veel opensource pakketten werken overigens ook gewoon met mysql/mariadb/postgresql/mssql/oracle. Dan heb je nog frameworks als PearPHP waarmee je nog meer (DB)backend onafhankelijk kan ontwikkelen.
Volgens mij is porten naar meerdere databases eenvoudig als je beetje ervaren bent.

Het argument "Oppervlakkig beschouwd klinkt dat aanlokkelijk" is waar. Maar is net zo goed waar als het gaat om een andere database kiezen dan dat je standaard hebt. Tja. Weinig spectaculaire conclusie maar het ligt dus helemaal aan de omstandigheden wat wijsheid is. Het advies om niet altijd blind te kiezen voor wat je ooit als standaard hebt benoemd vind ik trouwens wel goed. De enige standaard die wat mij betreft altijd gevolgd moet worden is 'gezond verstand'.

Slecht verhaal.

Mijn perceptie : de auteur werkt waarschijnlijk in de MKB context.

Een pakket als SAP levert ook MaxDB dat 5% van de SAP licentieprjs kost.
Bovendien spelen hele andere redenen mee voor de DB keuze zoals JW al aangaf.

Verder leveren sommige van die "dure" opties zoals Oracle Advanced Db Compression en Automatic Storage Management wel degelijk substantiele voordelen op, waardoor er toch een business case voor zou kunnen bestaan.

Jurrie,

Advies om de goedkoopste database te kiezen is nogal betrekkelijk als non-functionele aspecten zoals beschikbaarheid en prestatie meegenomen worden in de overweging. Dat er bezuinigd kan worden op de licenties zal ik niet ontkennen maar beter in dat geval om vanuit business vereisten te rekenen in plaats van weer als de gebruikelijke 'supermarkt manager' op de kleintjes te letten en daardoor het grotere geheel missen.

Betreffende je in reactie gegeven veiligheidsaspecten gelden deze m.i. ook voor de vele oplossingen waar iedere applicatie zijn eigen database heeft, inrichtingsfouten zijn naast SQL injectie nog altijd de meeste voorkomende oorzaak van digitale inbraken. En ja, dit kan impact hebben voor de hele infrastructuur.

Opmerkelijk vaak worden de databases die meekomen met (non-Enterprise) applicaties niet consistent onderhouden, veel legacy hier doordat sommige al lang niet meer ondersteund worden door database leverancier maar nog wel gebruikt worden door de applicatiebouwer.

Hallo Ewout,

Dank voor je reactie.
Punt is dat bij universele applicaties de beschikbaarheid en prestaties van het geheel niet afhankelijk zijn van de zaken die jij noemt. Dat is althans de bewering van de leverancier, anders zou deze wel degelijk een voorkeur voor een database uitspreken. Overigens ben ik dat inmiddels in de meeste gevallen ook wel eens met deze leveranciers. De performanceverschillen van de grote databases zijn inmiddels (als je geen gebruik maakt van onderscheidende kwaliteiten) erg gelijk. (Voor ik hier een nieuwe discussie mee ontlok: hierover graag een andere keer...)
Dat is juist de reden dat ik in voorkomende gevallen inderdaad op de kleintjes (nou ja) adviseer te letten. (Komt misschien ook omdat wij veel werken voor (grote) Food retailers ;-), dus @kj: nee, de auteur werkt (voornamelijk) niet in de "MKB context" maar voor grote ondernemingen en (rijks)overheden.))

Je hebt gelijk dat die veiligheidsaspecten die ik noem (in een eerdere reactie) niet voorbehouden zijn aan dit onderwerp. Daarom vind ik ze als zodanig dus ook geen sterk argument tegen mijn betoog.

Met je laatste opmerking ben ik het volledig eens. Reden te meer om de onderliggende database bij (standaard-) applicaties erg serieus te nemen, lijkt me.

Jurrie,

Ik denk dat ik me bij KJ aan ga sluiten, het advies van leveranciers lijkt me niet de meeste objectieve bron.

Grappig dat je (rijks)overheid noemt want daar zie ik inderdaad nog weleens houtje-touwtje combinaties die niet alleen slecht presteren op de database maar ook op de opslag, opmerkelijk vaak hebben deze trouwens een blinde voorkeur voor Oracle net als bepaalde retailers.

Leuk om wat te besparen op licenties maar als je dan het dubbele kwijt bent aan hardware dan lijkt me dat niet echt slim, veel databases zonder DBA zijn tenslotte verre van optimaal ingericht. Leuk voor de leveranciers maar naar mijn opinie gewoon weer 'penny wise and pound foolish' en wat je dan ook nog weleens ziet is dat er voor die afwijkende databases geen back-up of monitoring agents zijn, het blijven vreemde eenden.

Het artikel is helder geschreven maar de concludering is nogal kortzichtig omdat het simpelweg vendor lock-in voorstelt. Maar ook wordt achteloos decennia aan innovatie over de schutting gekieperd en toont het een strategisch inzicht van een pakje boter.

Iedere IT architect kan je helder en duidelijk uitleggen waarom je een generieke database ontsluiting nodig hebt. En ja dat kost extra geld, tijd en soms ook wat performance. Maar wat krijg je er voor terug?
Dat je applicatie makkelijker kan migreren vanwege diverse redenen zoals het groeien naar een grotere, snellere en redundante omgeving. Een gunstigere en goedkopere partij. En als een leverancier stopt met het product wat je gebruikt of zelfs failliet gaat dan kan je op alternatieven overstappen.

Wat de praktijk betreft heb je wel degelijk een punt want vaak wordt beweert dat men generieke ondersteuning heeft voor databases maar kan dat niet worden aangetoond omdat het simpelweg niet werkt. De reden is omdat er diverse SQL dialecten zijn en dat er soms oplossingen gebruikt zijn die niet werken op een bepaalde database technologie.

En vaak wordt er mettertijd maatwerk uitgevoerd vanwege onderhoud en/of performance issues die wel database afhankelijk is. Dit wordt overigens met liefde door consultants gedaan omdat ze weten dat ze hiermee zichzelf onmisbaar maken voor de rest van de tijd van het gebruik van het product en toekomstige ontwikkelingen. In dat opzicht is elk stukje maatwerk vaak een klinknagel tussen je product en de gebruikte database.
Het is dan de kunst om er een bout en moer van te maken. Dat kan door gebruik te maken van een database API die database onafhankelijk is en daarmee de scheiding is tussen de twee onderdelen.
Een software product die hier geen gebruik van maakt is feitelijk achterhaald want software ontwikkeling is mede dankzij de cloud in het modulaire tijdperk beland.

Jurrie,
Als we in de hele keten kijken dan zou het gebruiken van een onbekende db een risico vormen in het geval dat je een probleem krijgt.

Stel je voor:
- Je hebt performanceproblemen binnen de applicatie die gebruik maakt van die (onbekende)db.

- Of je hebt performanceproblemen binnen andere applicaties die op hetzelfde deel van je storage zitten als die onbekende db,

- Of je hebt performanceproblemen binnen andere applicaties die door dezelfde host-server aangeboden worden als de host-server van die onbekende db.

Alle leveranciers (van andere applicaties, van je netwerk, van je hypervisor, van je storage) gaan eerst met de vinger wijzen naar je onbekende db! Hun advies: Tja, we ondersteunen die database niet en je zou eerst moeten proberen die database te isoleren (op andere hardware zetten). Terecht of onterecht, dit is de eerste wat je zou MOETEN doen om verder door de leveranciers geholpen te worden.
Maak je gebruik van een bekende database dan ben je heel verder in je oplossingsproces.
Na veel tijd en geld besteed te hebben aan onderzoek en consultancy kom je er achter dat je:
1) een hardware moet aanschaffen voor hosten van die db en applicatie + migratiekosten
2)of een andere database gebruiken dus weg met je beoogde besparing,
3)of een andere applicatie aanschaffen want de betreffende applicatie ondersteunt geen andere databases.

Maw, je investering zal desinvestering worden :-(

P.s. wat ik je hierboven verteld heb, heb ik al eerder bij een klant meegemaakt.


@Reza en @Ewout,

Allereerst ging mijn betoog er om dat je moet proberen om applicaties die meerdere database-smaken ondersteunen te mijden. De discussie (waarvoor dank overigens) lijkt zich nu toe te spitsen op mijn advies voor een keuze voor een afwijkende (goedkopere) database.

Ik weet niet waar dat idee vandaan komt, maar ik suggereer nergens dat je dan maar een onbekende database moet nemen en zeker niet één die niet wordt ondersteund door de leverancier. Mijn advies is (en blijft) dat je in zulke gevallen zeker naar de goedkoopste variant moet kijken die wél wordt ondersteund. Als de leverancier geen voorkeur uitspreekt, waarom zou ik dan een duurdere nemen?

Tweede misverstand: een goedkope(re) database wil niet automatisch zeggen dat dit een obscuur iets is. Zoals Ewout hierboven aangeeft, wordt er in Oracle-bolwerken in dit soort gevallen automatisch een dure Oracle Db onder een standaardapplicatie gezet. Hoewel ik een groot fan van Oracle RDBMSen ben vind ik die oplossing in de meeste gevallen absurd, zelfs als het de standaardeditie betreft. Je zou in zo'n geval ook kunnen kiezen voor een Mysql, PostgreSQL of SQlServer variant. Allemaal prima (goed gesupporte) databases voor minder geld.

Mijn conclusie na jaren overwegen of je wel of niet meerdere databases moet ondersteunen is nu: doe het niet.
Redenen:
- Je maakt je applicatie nodeloos complexer
- Je gebruikt de betere features niet van de database
- Er zijn weinig omgevingen waar nog maar 1 smaak wordt gebruikt

Er zullen best nog voordelen voor zijn te noemen, maar voor mij wegen die niet tegen de nadelen.

@Leen,
In je profielbeschrijving lees ik dat Cloudcomputing and Interoperabiliteit je speciale interesse hebben.

Maar niet in een tiered/frontend/backend omgeving ?
:-P

@Leen
Als eerste hangt natuurlijk veel af van je applicatie, als database niet meer is dan een 'emmer' dan kun je portabiliteit overwegen. Nadeel is wel dat alle logica dan vaak in de applicatie zit wat prestatie niet altijd ten goede komt. Zeker niet als deze van elkaar gescheiden zijn en alle queries over het netwerk gaan, soms flinke hoeveelheden packets die door de TCP/IP stack en over het draadje moeten.

Aan de andere kant zie ik ook nog weleens dat niet alleen een duur RDBMS gebruikt wordt doordat alle cores gelicenseerd moeten worden terwijl dat voor de prestatie helemaal niet nodig is, zeker bij Oracle gebeurt dit nog weleens of je moet hard partitioning gaan gebruiken.

Laten we nu - heel toevallig - een oplossing hebben waarbij de interconnect (in-memory of infiniband) voor een prestatie verbetering zorgt in communicatie tussen applicatie en database en hard partitioning voor lagere licentiekosten. Oja, doordat data-in-motion en data-in-rest volledig gecompartimeerd is - gecertificeerd tot EAL-4+ - worden ook nog veel beveiligingsproblemen met legacy databases en applicaties opgelost en kan één machine multitenant gebruikt worden met gegarandeerde prestaties.

Nieuwsgierig? http://www.slideshare.net/edekkinga/forward-unisys

@Ewout
Een wat commercieel getinte reactie van je.

De end-to-end response time van een applicatie hangt af van vele factoren. De RDBMS response tijd is daar maar een onderdeel van. Voor SAP is de RDBMS response time idealiter 40% van de totale RT. De RT van het RDBMS hangt verder af van de beschikbare resources en de snelheid daarvan en het storage subsysteem. (SAN of NAS). In de praktijk zie ik met 10GbE niet erg veel netwerk-related bottlenecks.

De bottlenecks die ik in de praktijk tegen kom hebben meestal te maken met simpelweg onjuiste parameter instellingen, bijvoorbeeld een database cache van 1 GB op een server met 60 GB RAM.

Oracle werkt met een variabele (CPU_COUNT) die de waarde krijgt van het aantal cores dat wordt aangetroffen. Vanuit deze variabele worden weer andere waarden afgeleid die bijvoorbeeld van belang zijn voor een andere belangrijke feature van Oracle : parallel query.

Een applicatie als SAP gebruikt Oracle als een "byte container", maar dat maakt dit RDBMS nog niet meteen uitwisselbaar met een ander merk. Een volwassen RDBMS als Oracle heeft in de loop van de tijd heel wat zaken ontwikkeld die niet meer zijn weg te denken : het genoemde parallel query, een hele serie van compressie opties die werkelijk geld kunnen besparen, Automatic Storage management, maar ook build-in zaken als de file system cache bypass (direct en concurrent I/O), Write-protect, snapshots etc. etc. geven dit RDBMS een zekere robuustheid en betrouwbaarheid die je niet bij overige RDBMS-en ziet.

Als je perse geld wil besparen, vervang dan eerst je dure OS (AIX, HP, Solaris, MS) met Linux bijvoorbeeld of beter nog, gebruik een Linux Guest om je applicatie een virtueel onderkomen te geven. Gebruik verder een modern file system type (WAFL) met build-in snapshots bijvoorbeeld zodat je de ouderwetse tapes de deur uit kan doen.

Beste Jurrie,

Als software-ontwikkelaar bij TOPdesk kan ik je wel iets vertellen over hoe het is om een applicatie voor meerdere typen database te ontwikkelen.

Zelfs als je maar één merk database ondersteunt moet je al verschillende versies van dat merk ondersteunen, aangezien niet alle klanten tegelijkertijd nieuwe versies van de database installeren. Dus je hebt sowieso al een systeem nodig dat met meerdere versies van één merk database overweg kan. Daarmee wordt de stap naar verschillende RDBMS'en een stuk kleiner.

Verder zijn de kosten van het testen op verschillende databases, ongeacht of ze van hetzelfde merk zijn, slechts een fractie van de totale kosten van het hele ontwikkelproces. En de database is maar één van de variabelen. We kunnen als standaard-applicatie ook overweg met de diverse andere systemen die bij de klant aanwezig zijn. Denk aan verschillende typen en versies operating systems, mailservers en protocollen, proxies, authenticatiesystemen, koppelingen met diverse gegevensbronnen, browsers, etc. We zijn dit gewend.

Daarnaast zijn er ook andere voordelen voor de klant. We hebben al een aantal klanten gehad die eerst op één merk database wilde draaien, aangezien andere software dat vereiste, maar later die software had vervangen en een goedkoper RDBMS kon gebruiken. TOPdesk kan niet alleen met verschillende RDBMS'en overweg, maar kan ook probleemloos zijn database van het ene merk naar het andere merk converteren.

Tenslotte bieden we TOPdesk ook aan als SaaS-oplossing. In zo'n cloud-scenario is het merk van de database voor de klant niet of minder belangrijk. Doordat we meerdere RDBMS'en ondersteunen kunnen we daarbij dus voortdurend de beste oplossing kiezen.

Ik hoop dat ik hiermee een aantal misverstanden heb kunnen oplossen.

@KJ
Ik stel nergens dat een DBA of systeembeheerder vervangen kan worden, ik geef zelfs aan dat deze functies essentieel zijn en ik het een slecht idee vindt om te kiezen voor een database waarover geen kennis aanwezig is. Betreffende de genoemde prestatie problemen heb ik al meerdere opinies geschreven want inderdaad zijn de 'next-next-finish' inrichtingen niet altijd optimaal.

Aangaande je voorstel om dure platformen te vervangen geef ik je ook gelijk mede ook omdat hier nog vaak een 'hands-off' strategie gehanteerd wordt, niet zelden omdat DBA en systeembeheerder dus weg zijn bezuinigd. Oja, MS SQL draait naar mijn weten niet op Linux en ik denk dat je met legacy juist wilt voorkomen dat je alles in één keer moet wijzigen want olifanten eet je nu eenmaal hapje voor hapje.

@Ewout
Sorry, alleen de eerste zin was voor jou bedoeld, gezien je verwijzing naar de Unisys-link. De rest was een verdere verduidelijking gericht aan de auteur van het artikel.

Duidelijk iemand die totaal geen verstand van de techniek heeft ! Over de rol van DBA wordt zelfs wat disrespectvol gesproken, alsof het een soort van junior specialisatie is. Vergeet ook niet dat de verschillende RDBMS meestal op andere platformen draaien, wat het er niet makkelijker op maakt om je in alle producten te specialiseren.

In Enterprise omgevingen worden de "dure opties" wel degelijk gebruikt, anders hadden de gratis RDBMS systemen die de leveranciers aanbieden ook volstaan.

Ik vind nergens in het verhaal een onderbouwing van de conclusie. De grote van het bedrijf, de huidige expertise, kosten voor omscholing en uitbreiding personeel, licentie kosten en vele andere factoren spelen een rol.

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×