Hoofdcategorieën
Device Settings

Interesse bedrijfsleven voor open-sourcedatabases groeit

Door Jeroen P Hira, dinsdag 9 maart 2004 12:45
Bron: C|Net, views: 9.838

Een onderzoek van AMR Research onder 140 technologiemanagers heeft uitgewezen dat de interesse voor open-sourcedatabases aan het groeien is. Momenteel is de markt hiervoor in een experimentele fase, maar in 2006 zal er een wijdverbreide acceptatie ontstaan zijn. Een van de belangrijkste redenen waarom open-sourcedatabases zich op deze interesse kunnen verheugen, is natuurlijk de vrijheid om de programmacode van de open-sourcedatabases aan te passen.

Dit in tegenstelling tot de databases van Oracle, IBM en Microsoft. Verwachting is ook dat de grootste concurrentie van MySQL, MaxDB en PostgreSQL zal gaan komen. Hierbij zullen de laatstgenoemden sneller kunnen inspringen op de veranderingen binnen de markt, terwijl het voor de drie databasegiganten moeilijker zal worden om nieuwe klanten te werven en de klanten ook nog op een winstgevende manier diensten te verlenen. Zeker omdat aan de open-sourcedatabases in vergelijking nauwelijks nog kosten zijn verbonden. Het verschil bij aanschaf is momenteel groot, er wordt 40 duizend dollar betaald voor een commerciële database, tegen 1500 dollar per processor bij een open-sourcedatabase zoals die van MaxDB. Hierbij geldt dat onder GPL-voorwaarden de open-sourcedatabases natuurlijk helemaal gratis zijn, wat het verschil alleen maar groter maakt.

Database server logo's (MySQL, SQL Server, DB2, Sybase & Oracle)

Voorlopig kunnen de commerciële bedrijven nog prat gaan op hun dienstverlening - het grootste nadeel voor open-sourcedatabases - maar dit gaat snel veranderen. De serviceondersteuning voor open-sourcedatabases wordt in steeds grotere mate verleend door onafhankelijke softwarebedrijven. Zo heeft bijvoorbeeld een softwaregigant als SAP een overeenkomst met MySQL gesloten. Uit deze overeenkomst is MaxDB voortgekomen, welke in de loop van de tijd steeds meer MySQL-kenmerken zal gaan vertonen en bevatten. Rest de open-sourcebedrijven nog één obstakel om uit de weg te ruimen, namelijk de mogelijkheid om grote datastromen te beheersen en te behandelen. Zolang dit alleen door de commerciële bedrijven goed kan worden uitgevoerd, blijven deze een pluspunt hebben. Dit zal echter slechts een kwestie van tijd zijn, voordat de open-sourcebedrijven hun achterstand hebben ingehaald en ook op dat gebied kunnen concurreren met de commerciële bedrijven.

Volgende 13:43 IDC: West-Europese servermarkt blijft groeien
Vorige 12:37 Soltek releast SL-865Pro 775-moederbord
Advertentie

Reacties

«  1  2  »

Dit doet mij altijd deugd. Ik probeer zelf ook altijd zoveel mogelijk OSS te draaien. Een goed open source alternatief voor Mathematica/Maple heb ik helaas nog niet kunnen vinden. Voor de rest draait bij mij alles op OSS. Behalve de games natuurlijk.

Maxima, de moeder van alle computer-algebra-programma's:

http://maxima.sourceforge.net/

Enige nadeel is dat de interface minder gerafineerd is als die van Mathematica bijvoorbeeld.


Is het niet 'word" en "self-fulfilling"? En is voor een discussie niet een valide openingsstatement nodig?

Ontopic: Ik juich deze verschuiving van waarde voor software naar waarde voor service van harte toe. Het verplaatst afhankelijkheid en als leverancier blijf je op je hoede om service naar tevredenheid te houden.

Toevallig is er op 17 maart een seminar over open source DBs waar MySQL ook aanwezig is... misschien een idee om ze zelf te vragen hoe ze jouw "self fulfilling prophecy" view zien? ;) http://www.mysql-event.nl

Waarom is het voor commerciele databases moeilijker om in te springen op de markt? Volgens mij zijn de nieuwste commerciele databases juist degenen die hypermoderne technieken ondersteunen (alles wat met XML te maken heeft om maar wat te noemen), terwijl MySQL of Postgres nog steeds "klassiek" aanvoelen...

Mogelijk wordt het voor de groten moeilijker om dat die vooral gespecialiseerd zijn in grote hoeveelheden data. Mijn ervaring is dat de meeste bedrijven aan de internet toepassingen kleine databases hebben die ook prima in de open source databases passen. Ik denk dat maar weinig echt grote databases nodig zijn (> 10GB).
De extra moderne features rond de database als XML wordt door de open source gebruikers waarschijnlijk snel ingelopen.

Echt grote DBs 'beginnen' volgens mij bij tbytes, niet bij 10 gbytes.

Het vervelende is dat de meerdeheid van de applicaties geen zware databasesystemen nodig hebben, postgresql is meestal zwaar genoeg en binnenkort kan mysql met versie 5 ook de wat zwaardere toepassingen gaan verzorgen.

De échte zware dingen zoals op luchthavens of in grote bedrijven kunnen natuurlijk wel het beste door Oracle of Sybase worden bediend, maar dan speelt het geld ook geen rol.

Je moet de commerciële systemen ook zien als luxe auto's, ze zijn sneller, hebben meer features en zijn comfortabel, maar vaak onnodig.

Je moet de commerciële systemen ook zien als luxe auto's, ze zijn sneller, hebben meer features en zijn comfortabel, maar vaak onnodig.
Je vergeet robuuster en veiliger. Het hangt er maar net vanaf watvoor systeem er op moet draaien. Is de database niet zo groot of is het systeem niet kritisch wat betreft beschikbaarheid, schaalbaarheid en veiligheid (en/of) is een OS DB misschien een goed alternatief. Ook onderhuidse features zijn belangrijk, ofwel de technische implementatie. Oracle is jarenlang de enige geweest die bijvoorbeeld row-level locking deed. Zelfs SQL Server en Sybase deden tot voor kort nog page of table level lock. Ook het read-consistency model (nu wordt het wel erg technisch...) van Oracle is erg geavanceerd. Er zijn omgevingen waar dat soort dingen heel belangrijk zijn.

Ik zeg dit niet om MySQL e.a. af te kraken, maar om aan te geven hoe moeilijk de keuze vaak is. Het is niet alleen een kwestie van de BMW die lekerdere stoelen heeft als een Lada. Ook hoe het ding in elkaar zit is belangrijk. Maar dat is ook weer onlosmakelijk verbonden met je doel, je eisen en je budget. In meer dan de helft van de gevallen kun je gewoon met een lekker simpel OS DB'tje af.

Ik denk dat we in de toekomst combinaties gaan zien. En dan zal Oracle e.a. wel weer het licentiemodel aan gaan passen. Uiteindelijk wint de gebruiker door deze gezonde concurrentie.

Op zich klopt het wat je zegt, maar het grote voordeel van oracle is met name dat het alles kan. Als je alleen maar goede transacties en triggers wilt maar snelheid is minder belangrijk is PostgreSQL prima. Wil je alleen snelheid dan is MySQL vrijwel net zo goed als Oracle. Maar wil je alles, dan zal je toch moeten betalen

XML is zo overrated als iets. Het heeft zijn nut - ok, maar nu zit men opeens iedereen te pushen om naar XML over te schakelen, terwijl dit nog steeds 1 enorm nadeel heeft - performantie. Het is zo erg dat men tegenwoordig al hardware accelerators heeft voor XML parsing te doen op servers-side, gewoon omdat het anders te traag gaat en de server door de knieen zakt. Al die "moderne" technieken zijn allemaal mooi enzo, en hebben zeker hun nut, maar sommigen ervan, zoals XML worden opgeblazen alsof ze het van het zijn.

Ik denk niet echt dat die nieuwe technieken enzo belangrijk zijn op database gebied, eerder customizing, scalability en het deployen van veel en kleine databases in een beperkte omgeving (waardoor mysql een enorme userbase heeft, met 8mb ram draait een kleine mysql database supervlot, waardoor bijna alle hosters dit draaien)

<offtopic>XML is super voor transport van data.</offtopic> :*)

okee, netjes afsluiten :)

<offtopic>XML is super voor transport van data.<offtopic>
Als je data wil transporten met XML moet je wel netjes je tags afsluiten ;)

Dat is inderdaad een van de gebruiken van XML, maar effe een dataset van 100.000 records omzetten naar XML en dan over een connectie pompen heeft een gigantische overhead, zowel op CPU als op bandwidth gebied.

Voor databases is dit vrij nutteloos, er zijn toch geen afgesproken standaarden, en de features van de databases verschillen teveel om zomaar opeens te zeggen dat alles moet omgeswitcht worden naar XML. Ik zeg niet dat het niet mogelijk is, maar praktisch is dit onbruikbaar voor real world applicaties.

Als ik hier af zou komen bij mijn baas en zeggen dat er een nieuwe fantastische database is die volledig XML dit, zus en zo is dan gaat die dat mischien overwegen - tot hij hoort dat daardoor het hele severpark 4x zo groot moet worden voor dezelfde load aan te kunnen of dat anders de performantie niet om over naar huis te spreken is. Een nice-to-have moet ook haalbaar zijn in real world applicaties.

Men heeft hier een jaartje geleden juist hele grote delen naar een dedicated protocol verhuist omdat de overhead te groot was, het kwam van SOAP en een eigen XML-specified protocol tussen client/server en server/server.. De servers konden door deze wijziging plots een 6 keer hogere load aan (door dit voorval moet ik het woordje XML eigenlijk zelfs niet meer vernoemen bij mijn baas btw - dus bovenstaand voorbeeld riskeer ik mij niet :D ) Het heeft inderdaad massa's meer gekost aan ontwikkeling (5-6 manmaand) - maar dat heeft men er makkelijk uit doordat men opeens het serverpark niet meer zo hard moest upgraden.

XML heeft een mooie rol in markup languages, portable transport tussen verschillende platformen van relatief kleine dataframes, en parsable data die human-readable/editable moet zijn, maar daar beperkt het zich dan ook toe.

Voor databases is dit vrij nutteloos
Niet echt. Als je bijvoorbeeld kijkt wat voor dingen Oracle 9i (rel 2) kan doen met XML, zitten daar echt nuttige dingen bij.

Domweg een XML document in je db stoppen om 'm er later weer uit te kunnen halen voegt weinig toe inderdaad. Maar Oracle kan bijvoorbeeld aan de hand van een XSchema definitie een efficiente storage structuur opzetten voor XML data die aan die definitie voldoet, en waar je vervolgens niet alleen met SQL queries dingen mee kunt doen, maar ook met XPath specifieke nodes kunt selecten/updaten. Dat is *heel* erg handig voor data die niet makkelijk in een tabel in te passen is, denk aan allerlei soorten (al dan niet recursieve) boomstructuren.

Natuurlijk voegt het niet voor alle soorten data wat toe, maar voor sommige dingen waar ik mee werk is het echt een enorme vooruitgang t.o.v. de oude tabellen.

Je omschrijft meteen het grootste probleem met XML: de combinatie met SQL. Jij hebt 1 of meer veldjes met XML met neem ik aan content, waarover je gaat Xpath-en. Nu heb jij geen relationale database meer. Waar bepaal je nu trouwens de grens tussen wat een SQL veldje wordt of in de XML wordt gepropt? Stop je het in de XML en wil je later voor een X aantal tabelentries die data achterhalen, moet je het XML veldje voor al die entries leeghalen en parsen. In de realiteit is dat retetraag. XML alleen is helemaal geen optie. Komen ze meestal met im- en exportfuncties aanzetten. Resultaat: rijstebrei.
Dit en het probleem wat jij beschrijft heb je niet bij een goed genormaliseerde database. Op te merken valt slechts nog dat SQL 15 jaar geleden met hetzelfde probleem te maken had ("leuk maar praktisch te langzaam als je 5 seconden op je simpele test query moet wachten") en binnen 5 tot 10 jaar draaiden commerciele websites voor een massapubliek erop.

Waarom zou ik voor hierarchisch georganiseerde data niet gewoon een LDAP directory gebruiken dan? Is supersnel en hiervan zijn ook gratis te gebruiken opensource implementaties, bv. openldap.

Ondersteunen 'light directories' ook SQL-like queries inclusief joins, etc, dan?

Ik gaf met XML ook maar een voorbeeld. Er zijn nog veel meer handige dingen in commerciele databases terug te vinden, die je in OSS databases er maar bij moet fantaseren.

In dit verhaaltje mis ik nog Firebird, voorheen Borland/Interbase.
Zelf geen ervaring mee hoor.

Firebird is toch juist de gratis SQL database server compatible met Interbase?

Eigenlijk niet. Een tijd geleden is de source code van interbase vrijgegeven door Borland (de makers van o.a. Delphi en JBuilder). Daarop hebben een aantal enthousiastelingen ingesprongen door met de ontwikkeling door te gaan. Dit alles heeft geleid tot firebird waar onlangs versie 1.5 van uitgekomen is. Mijn persoonlijke ervaring is dat het aanmaken van nieuwe databases nogal lastig gaat, in ieder geval niet via de mysql manier. Anyways, Firebird 1.5; Stored procedures; referential integrety etc etc... Zeker geen kleine speler op de open source markt, kan tevens met 3 (sql) dialecten overweg...

Firebird is een zeer fijn open source alternatief en onderhand schieten de eenvoudige beheertools ook wel aardig de grond uit. Kijk maar naar IboConsole ( http://www.mengoni.it/downloads.html )

Ons bedrijf heeft onlangs zelfs MySQL georienteerde applicaties vervangen door Firebird georienteerde applicaties vanwege de schappelijkere licentie. Firebird zou wel eens een grote rol kunnen gaan spelen.

IBExpert, IBLogging, IBReplicator, IBPLANalyzer (voor optimizen van querys) etc etc

Echt heerlijk veel tools voor beschikbaar, al dan niet niet gratis, en kwalitatief zeer goed.

Voor onze projecten (maatwerk+detachering) gebruiken we
altijd als het kan IB, vooral door goede componenten voor Delphi.

Binnen mijn stage bedrijf gebruiken we MSSQL en SyBase, sinds kort ook MySQL, en men is zeer tevreden over vooral de snelheid va n My tegenover MS

Mja, hebben ze ook in de gaten dat kwa betrouwbaarheid de grote databases zoals MS SQL, Oracle en Sybase mijlenver op MySQL voorlopen? MySQL is leuk als je geen geavanceerde fall-back mogelijkheden nodig hebt, want die kent MySQL amper of helemaal niet.

Ik begrijp niet waarom een bedrijf MySQL zou gebruiken, er zijn zat gratis alternatieven die beter zijn. Kijk alleen maar naar PostgreSQL, die heeft wel geavanceerde fall-bak mogelijkheden en andere zaken die andere "echte" SQL databases ook hebben.

MySQL is leuk als je geen geavanceerde fall-back mogelijkheden nodig hebt, want die kent MySQL amper of helemaal niet.
Jij hebt InnoDB van MySQL zeker nog nooit gezien?

Of MaxDB van MySQL?
The following is a list of features supported by MaxDB by MySQL beyond those currently available in the MySQL database server:
Views
Server-side cursors
Stored procedures and triggers
Automatic failover (to a standby server)
Scheduling and automatic messaging on alerts
Snapshots
Archive tables
Synonyms

Wat ik mij afvraag is of MySQL nog zo snel is wanneer alle data integriteits features zijn enabled zoals ondersteuning van transacties en foreign keys. Zonder die checks zal MySQL wel sneller zijn, dat geloof ik wel.

Zeker omdat aan de open-sourcedatabases in vergelijking nauwelijks nog kosten zijn verbonden. Het verschil bij aanschaf is momenteel groot, er wordt 40 duizend dollar betaald voor een commerciële database, tegen 1500 dollar per processor bij een open-sourcedatabase zoals die van MaxDB.
Bij dit soort investeringen is de belangrijkste kostenpost het onderhoud. Hoe verhouden zich dan de kosten tot elkaar?

Zodra MySQL stored procedures aankan word het pas echt interessant voor serieuze toepassingen.

Hopelijk gaan we dat snel zien.

Zodra MySQL stored procedures aankan word het pas echt interessant voor serieuze toepassingen.
Je bedoelt: zodra MySQL een fatsoenlijke featureset gaat ondersteunen zal de snelheid ook eindelijke dermate lijden dat je een eerlijk vergelijk kunt trekken met de professionele databases.

MySQL is een webserver-DB, geen enterprise DBMS. Zolang er geen true DRI, nested transactions, clustering, SMP-execution plan optimalization oid inzit zal het dat ook niet worden.

hahaha vivala Open- source.......


ik ben wel benieuwd wat M$ en de rest gaan doen
tegen open source

want jah lets face it

er komen steed meer ervaren gebruikers die de code kunnen aanpassen en dus zijn die programma's van M$ enz..... niet meer nodig
want een bedrijf, die laat gewoon zn programma maken/aanpassen door een stagair die stage loopt of zo.....

dus misscihen zal het wel een vast vak op de ICT accademie worden nog beter

i can't wait
maarja dat zal nog wle eff duren voor dat dat bij ons school is (en dan ben ik al weg :'( )

ik ben wel benieuwd wat M$ en de rest gaan doen
tegen open source

want jah lets face it

er komen steed meer ervaren gebruikers die de code kunnen aanpassen en dus zijn die programma's van M$ enz..... niet meer nodig
want een bedrijf, die laten ze gewoon maken/aanpassen door een stagair die stage loopt of zo.....

dus misscihen zal het wel een vast vak op de ICT accademie worden nog beter

i can't wait
maarja dat zal nog wle eff duren voor dat dat bij ons school is (en dan ben ik al weg )

Jezus, want een achterlijke reply zeg.

Ik denk dat ik mezelf een redelijk ervaring programmeur kan noemen, maar ik zou het niet in mijn kop halen om een beetje aan de sourcecode van een database te prutsen omdat ik hier gewoon geen fuck verstand van heb. Ik heb verstand van het aansluiten en toepassen van databases (zoals de meeste developers), maar schrijven is echt andere koek.

En ik zou het zeker niet laten doen doe een stagiair want die weten eigelijk gene ene fuck. En wat voor school doe jij trouwens??

Heel juist gesproken!!!
Wanneer je een stagiair een database laat maken/aanpassen, dan moet je wel zorgen voor een verdraaid goede documentatie! Want wat als de stagiair weg is?
Dit heb ik helaas in de praktijk iets te vaak meegemaakt. Ook door het vertrekken van vaste medewerkers die een database op hadden gezet, maar slecht gedocumenteerd.

Wat SAP betreft, die komt nu wel positief uit het verhaal, maar men vergeet te vermelden dat je bij een SAP implementatie je bedrijf aan de SAP database aan moet passen i.p.v. andersom. Ik hoop dat dit met MaxDB wat minder erg is (?), want hier heb ik geen ervaring mee.

Ik zou een stagiair zowiezo niet aan de database-source laten prutsen. Voor het geval dat hij een aantal bugs introduceert (en ga het dan maar uitzoeken wat er misgegaan is). Een stagiair mag hier hoogstens iets coderen tegen een test database, maar nooit iets met live data er in.

Wat SAP betreft, die komt nu wel positief uit het verhaal, maar men vergeet te vermelden dat je bij een SAP implementatie je bedrijf aan de SAP database aan moet passen i.p.v. andersom
:)
Dat komt omdat bedrijven gestructureerd moeten gaan werken. En dat is niet alleen met SAP, ook met Navision en soort gelijke ERP pakketten. Zelf ervaar ik juist als uiterst positief omdat grijze gebieden naar boven komen in de bedrijfsvoering. Dus waarom he SAP nu negatief beoordeeld weet ik niet maar typerend vond ik het wel. Tijdens de implemenatie van Navision (en vooral tijdens de voorbereiding) heb ik dit soort argumenten vaak mogen aanhoren. "wat is dit voor k*t programma, vroeger ging dat wel". Tja, nu men er aan gewend is wel men niet anders :)
edit:
ach eigenlijk best wel offtopic :z

Misschien is je reactie off-topic. Hij is wel heel erg herkenbaar, ook Navision :):
Dus als ik een boeking heb gemaakt kan ik die alleen corrigeren met een tegenboeking. Wat een k*tsysteem!
Automatiseren is reorganiseren en heeft meestal meer met mensen dan met computers te maken....En mensen houden er niet van als anderen inzicht krijgen in hun fouten.

Je moet natuurlijk niet SAP DB gelijk stellen aan SAP (het ERP-pakket). Ik kan me voorstellen dat het ERP-pakket als achterliggende DB misschien wel SAP DB gebruikt, maar een database is een database, en daar hoef je natuurlijk niet je hele bedrijf voor te reorganiseren.

dat dnek jij maar maar dat valt nog heel vies tegen als je weet wat ze kunnen (ik niet hoor )


maar tegen woordig hoef je ook niet kei verbaast te kijken als asp of php of java sript kennen,

en in de toekomst zal dat alleeem maar meer worden als open source maar door gaat dus...


jij onderschat de kracht van de thuistweaker....
M$ doet dat niet en daarom is de window.. bron code nog niet openbaar... omdat er misscihen (ik weet wel zaker van wel) er mensen kunnen zijn die dat kunnen uitbuiten...

de thuis gebruiker niet per se een stagair hoor maar die kunnen echt wel veel tegen woordig hun kennis is een kennis om niet te onderschatten....

en juist mensen zoals jij zouden de teokomst kunnen worden ...
mensen met programeer kennis stel je maar eens voor dat er nu open source was nou dan weet ik zeker dat jij echt iets geprobeerd zou hebben met een open source code.... gewoon om te testen dan he.......

niet om serius en kei goed programma te schrijven ...

maar dat is maar een redenering hoor het zou ook ander kunnen lopen

zoals dat M$ geen open source doet en geen de markt blijf geregen met an iron fist.......

en wij uiteindelijk big bugs moetne neer tellen

dat zou ook kunnen (hoeft niet linux)

Je bent een dikke koekebakker en fantast ;)

noem het wat je wilt en misschein ben ik dat ook wel

maar dat neemt niet weg dat de thuis tweaker steeds meer kan en wil .....


oke missichen is dit wel iets te ....

@The_Krizzle:
dat dnek jij maar maar dat valt nog heel vies tegen als je weet wat ze kunnen (ik niet hoor )

maar tegen woordig hoef je ook niet kei verbaast te kijken als asp of php of java sript kennen,

en in de toekomst zal dat alleeem maar meer worden als open source maar door gaat dus...

jij onderschat de kracht van de thuistweaker....
...ik denk dat jij de professionele kant van een organisatie onderschat. Begrijp me niet verkeert, ik houd van open source, draai *nix thuis, maar ik ben me heel goed bewust hoe een organisatie bijvoorbeeld op commerciele software kan bouwen. Tijdens mijn stageperiode heb ik hier veel van geleerd.

(p.s. tis een lichte flame, maar FYI: uit je zinsbouw/verwoording krijg ik niet de indruk dat je echt strakke professionele richtlijnen volgt, of strakke verslagen/documentatie opleverd) Die professionaliteit hebben bedrijven nodig, en deze zitten dus echt niet te wachten op free software van de "thuistweaker".

de belangrijkste redenen waarom open-sourcedatabases zich op een grote interesse kunnen verheugen, is natuurlijk de vrijheid om de programmacode van de open-sourcedatabases aan te passen.
dat is natuurlijk de grootste onzin die er gezecht kan worden.
De enige reden is dat het gratis is en voldoet voor web-db backend.
Maar een levenverzekerings bank zal er nooit op gaan draaien (mits er geen goede transactions en SP inzitten).

En op de quote terug te komen.
Wie kent er iemand die SOURCE code heeft aangepast voor zijn aplicatie omdat de db dan beter functioneerd?

En oja. Bedrijven die suport bieden voor openSource die een serieuse partner zijn voor een groot bedrijf ken ik niet

Ik hoop dat je je beseft dat het midden en kleinbedrijf een veel grotere sector is dan het grootbedrijf waar jij over spreekt? Voor heel veel toepassingen is zo'n simpele database gewoon prima. Waarom denk je dat Access zo populair is, ondanks dat het de geest geeft zodra je wat hogere eisen gaat stellen aan aantallen gebruikers of hoeveelheden data?
Of een database geschikt is voor een bank is geen criterium om te bepalen of het geschikt is voor, zeg, een klein ingenieurs bureautje.

Volgens mij gaat het hier om iets grotere databases dan een desktopdatabeesje als MSAccess, het gaat om "Oracle, IBM MySQL, MaxDB en PostgreSQL" Volgens mij geen van allen desktop spul zoals MSAccess. Ook dit midden en kleinbedrijf zullen gebruik maken van boekhoud/logistieke systemen die gebaseerd zijn op grotere databases dan MSAccess.
Ook ik ben een redelijk ervaren programmeur en zou het niet in mijn kop halen om de sourcecode van een databasesysteem aan te gaan passen, als het al zou kunnen aangezien ik met databases werk (SQL/Oracle) waarbij de sourcecode (en maar goed ook) niet is vrijgegeven.

En oja. Bedrijven die suport bieden voor openSource die een serieuse partner zijn voor een groot bedrijf ken ik niet
IBM, Sun, HP... :?

Wel - op dit ogenblik zit er een collega naast mij die toch rustig postgres een beetje heeft aangepast om er voor een bepaalde toepassing wat meer performantie uit te persen. Ook als je plugins wil schrijven als bepaalde stored procedures te traag zijn is het heel handig dat je de source-code eens kan naslagen.
Voor vele ontwikkelaars is een database idd een black-box waar men niet in durft kijken, maar zo heel ingewikkeld is dit nu ook weer niet eens je de basisstructuur en werking doorhebt. Eens je die doorhebt heb je meestal ook een veel beter zicht op performance-impact van bepaalde dingen, ga je bepaalde technieken vermijden of juist meer gebruiken, omdat deze traag of juist erg geoptimaliseerd zijn.

En serieuze "partners" voor opensource databases, in eerste vraag stel ik mij de vraag als ontwikkelaar welk voordeel ik erbij heb dat ik een "partner" zou hebben. Support? Er bestaat zoiets als mailinglists waar je in vele gevallen snellere en deftigere hulp hebt dan van "officiele" supportafdelingen gewoon omdat daar nog veel ervaren ontwikkelaars mee opzitten. Als je dan echt een partner wilt - je vind ze heus wel hoor. Het bedrijf "Mysql" verdient trouwens met niets anders zijn brood.

Oracle als "partner" hebben, reseller worden of eender wat stelt trouwens niets voor, in 3 dagen ben je dat zonder al teveel moeite. Wat stelt dat dan voor? Je mag het Oracle logotje gebruiken voor marketting doeleinden |:(

En serieuze "partners" voor opensource databases, in eerste vraag stel ik mij de vraag als ontwikkelaar welk voordeel ik erbij heb dat ik een "partner" zou hebben. Support? Er bestaat zoiets als mailinglists waar je in vele gevallen snellere en deftigere hulp hebt dan van "officiele" supportafdelingen gewoon omdat daar nog veel ervaren ontwikkelaars mee opzitten.
ik denk dat je met het worden van partner het voortbestaan kan verzekeren... Iets waar open source organisaties best behoefte aan hebben. Ook een community heeft support nodig, en een drijfveer.
«  1  2  »

Op dit item kan niet meer gereageerd worden.

Volgende 13:43 IDC: West-Europese servermarkt blijft groeien
Vorige 12:37 Soltek releast SL-865Pro 775-moederbord
VNU Media logo Hosted by True

© 1998 - 2012 Tweakers.net B.V. - Alle rechten voorbehouden - Contact - Jouw privacy - Algemene Voorwaarden

Uitgever van:

Website van het jaar 2011