Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 73 reacties
Bron: C|Net

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.

Moderatie-faq Wijzig weergave

Reacties (73)

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 :)
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?
<offtopic>XML is super voor transport van data.<offtopic>
Als je data wil transporten met XML moet je wel netjes je tags afsluiten ;)
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.
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?
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.
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.
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.
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.
@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".
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 ....
Laten we de opmerking
<quote>
Wie kent er iemand die SOURCE code heeft aangepast voor zijn aplicatie omdat de db dan beter functioneerd ?
</quota>
nou eens uit de wereld helpen.
Nee de meeste van ons tweakers heeft nog nooit source code aangepast
nee de meeste ervaren programeurs gaan ook niet zitten te rommelen in de source code
MAAR
het product is er wel, het product word ook door anderen over de hele wereld aangepast en verbeterd, en die verbetereingen kun je dan ook weer downloaden. DUS omdat jij en ik en je overbuurman niet in de sourcecode aan het rommelen is wil nog niet zeggen dat het niet gebeurd. En daar gaat het nu om , in de eeuwig durende discussie over closed en open software. Kun je het aanpassen ? Ja , dan heeft dat een aantal voordelen op closed source software.
En dat jij en ik het niet doen is niet relevant
Nee, waar het om gaat zijn al die Open Source fanatici/fantasten die beweren dat een bedrijf beter uit is met Open Source, dit wordt altijd gestaafd met dezelfde crap:
1) als de makers failliet gaan/stoppen met het project dan heb je de source - een escrow-clausule, standaard in closed source contracten, doet hetzelfde
2) iedereen kan de source aanpassen, als je het niet zelf doet, doet een ander het wel en het product wordt er beter op - hah. Ze bedoelen dat het een oerwoud van aanpassingen wordt, dat projecten rustig forken, en het belangrijkste voor een bedrijf: dat niemand verantwoordelijk gehouden kan worden. Bedrijven leveren diensten/producten en zijn daarvoor afhankelijk van software. Als die software faalt, moet er een schuldige aangewezen kunnen worden. Bij OS is dat onmogelijk. Of wil je die knurft in de kelder van zijn pa en ma die die verandering niet genoeg getest had verantwoordelijk houden? Geen van de klanten van het bedrijf waar ik voor werk peinst er ook maar over zelf serieuze uitbreidingen op de geleverde software te schrijven, al hebben ze daar alle mogelijkheden toe. In plaats daarvan krijgen we hier de ene na de andere opdracht voor uitbreidingen. Waarom? Omdat als het dŠn misgaat, wŪj de lul zijn, en niet de klant.
3) iedereen kan de source inzien, niemand is "eigenaar" van de code, dus iedereen kan het herdistribueren. Hierdoor gaat de prijs vanzelf naar 0. Leuk. Bedrijven zitten niet te wachten op gratis software, laat staan "vrije" software. Bedrijven zitten te wachten op _risicovrije_ software. ICT wordt steeds volwassener. Dat betekent dat uit falen inmiddels schadeclaims kunnen volgen. Van een kale kip valt niet te plukken, dus daar ga je met je OS software.
4) er worden vanzelf bedrijven opgericht die support leveren. Jaja, die mensen beweren zeker ook dat de wet van vraag en aanbod stelt dat als maar genoeg mensen gratis bier willen, er vanzelf een brouwerij komt die dat levert. Onzin dus. Er worden alleen support-bedrijven opgericht als ze denken dat daar een boterham mee belegd kan worden. En omdat iedereen support kan gaan leveren voor OS, waarom zou de prijs van die support dan niet ook vanzelf naar 0 gaan?
5) OS is eerlijker. Mijn reet. OS is helemaal niet eerlijk. Er zijn een paar grootmagnaten die projecten in beheer hebben. Zij mogen praatjes geven, worden aangetrokken door grote bedrijven om consultant te spelen enzovoorts. De mensen die het echte werk doen, die OS fanaten die al hun vrije tijd erin steken om code te schrijven, die verdienen geen ruk! Ohja, "erkenning" door andere OS-fanaten. Lekker. Koop je daar brood mee?
6) OS is een gezond bedrijfsmodel, anders zouden bedrijven als IBM, HP en Sun zich er niet mee bezig houden. Juist. Kinderarbeid is ook gezond, anders zou Nike zich er niet mee bezig houden. Arbeiders uitbuiten idem. Dit komt neer op bijna hetzelfde als bij 5. IBM c.s. spelen de grote OS-pusher. Kunnen ze makkelijk doen. Hun inkomsten komen toch niet uit OS. Zolang IBM nog lekker veel closed source software, consultancy, support en hardware verkoopt zal ze OS kunnen blijven steunen. Als ze daar mee stopt, is het over. OS is nu even een hype en de ooit grote moloch/monopolist IBM kan even mooi weer spelen en zal dat natuurlijk ook niet nalaten. Doen alsof je een OS-strijder tegen big evil closed source van bedrijven als big evil Microsoft bent is een mooie marketingtruc om meer closed source software, consultancy, support en hardware te kunnen verkopen. En al die OS fanaten helpen je er graag bij, zonder een cent terug te krijgen.

Begrijp me niet verkeerd. Ik denk dat OS zeker zijn plaats heeft. Maar het is gťťn gezond bedrijfsmodel. Het is ook niet de silver bullet die eindelijk een einde gaat maken aan crashende software. Het is ook niet de redder van de economische malaise. Het is ook niet de plaats waarvandaan de innovatie in de ICT de komende jaren gestuurd zal worden. Wat is het dan wel? Het is een leermodel. Eigenlijk zou iedere IT-student eens mee moeten doen met Open Source projecten. Waarom? Dan leert hij/zij werken in teamverband, doet ervaring op met software die meer doet dan die domme practica op school/universiteit en niet onbelangrijk: deze ervaring kan als werkervaring op het CV meegenomen worden. Dat is handig voor als hij/zij klaar is met studeren en een echte baan nastreeft.
1) als de makers failliet gaan/stoppen met het project dan heb je de source - een escrow-clausule, standaard in closed source contracten, doet hetzelfde
Heb jij een escrow clausule voor, pak hem beet, Windows 95 of Windows NT? Nee? Dat dacht ik al. Microsoft stopt er toch echt mee.
2) iedereen kan de source aanpassen, als je het niet zelf doet, doet een ander het wel en het product wordt er beter op - hah. Ze bedoelen dat het een oerwoud van aanpassingen wordt, dat projecten rustig forken,
Dat forken valt in de praktijk, zeker voor grote en complexe projecten, nogal mee. Hoeveel forks van de linux kernel ken jij? En hoeveel van KDE? Hoeveel alternatieve versies van Apache ben je recent tegengekomen?
en het belangrijkste voor een bedrijf: dat niemand verantwoordelijk gehouden kan worden. Bedrijven leveren diensten/producten en zijn daarvoor afhankelijk van software. Als die software faalt, moet er een schuldige aangewezen kunnen worden. Bij OS is dat onmogelijk. Of wil je die knurft in de kelder van zijn pa en ma die die verandering niet genoeg getest had verantwoordelijk houden? Geen van de klanten van het bedrijf waar ik voor werk peinst er ook maar over zelf serieuze uitbreidingen op de geleverde software te schrijven, al hebben ze daar alle mogelijkheden toe. In plaats daarvan krijgen we hier de ene na de andere opdracht voor uitbreidingen. Waarom? Omdat als het dŠn misgaat, wŪj de lul zijn, en niet de klant.
Tsja, dat is natuurlijk een opvatting van hoe je zaken kan doen. Overigens kan je ook voor OS software een leverancier verantwoordelijk stellen. En nee, dan moet je inderdaad je software niet downloaden van internet maar gewoon een contract afsluiten met, zeg, SuSE of RedHat.
3) iedereen kan de source inzien, niemand is "eigenaar" van de code, dus iedereen kan het herdistribueren. Hierdoor gaat de prijs vanzelf naar 0. 8<
Dat zei je hierboven ook al.
4) er worden vanzelf bedrijven opgericht die support leveren. Jaja, die mensen beweren zeker ook dat de wet van vraag en aanbod stelt dat als maar genoeg mensen gratis bier willen, er vanzelf een brouwerij komt die dat levert. Onzin dus. Er worden alleen support-bedrijven opgericht als ze denken dat daar een boterham mee belegd kan worden. En omdat iedereen support kan gaan leveren voor OS, waarom zou de prijs van die support dan niet ook vanzelf naar 0 gaan?
Iedereen mag ook een bakkerij, of een webdesign bureau, of een taxicentrale oprichten. Ken jij al bakkers waar je gratis brood kan halen, software bedrijven die gratis websites voor je ontwerpen en taxi's die je gratis vervoeren? Nee? Ik ook niet. Je redenering klopt van geen kanten. Natuurlijk kan "iedereen" support leveren voor een Open Source OS. Dat wil niet zeggen dat iedereen daar toe in staat is, noch dat het gratis is.
5) OS is eerlijker. Mijn reet. OS is helemaal niet eerlijk. Er zijn een paar grootmagnaten die projecten in beheer hebben. Zij mogen praatjes geven, worden aangetrokken door grote bedrijven om consultant te spelen enzovoorts. De mensen die het echte werk doen, die OS fanaten die al hun vrije tijd erin steken om code te schrijven, die verdienen geen ruk! Ohja, "erkenning" door andere OS-fanaten. Lekker. Koop je daar brood mee?
Wat houdt jou tegen om je eigen project op te zetten en daar "grootmagnaat" van te worden? Niemand! Natuurlijk zijn er duizenden anonieme ontwikkelaars die waardevolle code schrijven voor de diverse projecten. Wat ze daar mee opschieten? Je krijgen software die voor hun beter bruikbaar is. Dat is namelijk de drijvende kracht achter deze schare ontwikkelaars: ze werken aan programma's die ze zelf gebruiken. Sommigen kopen daar inderdaad hun brood mee, omdat ze er effectiever door gaan werken. Anderen doen dat niet, omdat het hobby is, en bij sommigen wordt het ineens een opstapje naar een goede baan.
6) OS is een gezond bedrijfsmodel, anders zouden bedrijven als IBM, HP en Sun zich er niet mee bezig houden.
En bedrijven als SuSE (inmiddels overgenomen), Redhat, MySQL en anderen zijn gek? Nee, aan het verkopen van OpenSource software zal je niet zo veel verdienen. Aan het verkopen van services die er mee te maken hebben wel.

Open Source software heeft een plaats, net zoals gesloten software die heeft. Die plaats wordt steeds serieuzer, omdat bedrijven en overheden zich niet langer willen binden aan een enkele leverancier. Het is leuk dat je in theorie een een schadevergoeding kan eisen van een bedrijf, maar hoe vaak is dat bij Microsoft al gedaan en gelukt als er weer eens misbruik van een lek gemaakt is?
Open Source software is niet _de_ oplossing, maar het kan wel een alternatief zijn dat het overwegen waard is.
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.
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.
En oja. Bedrijven die suport bieden voor openSource die een serieuse partner zijn voor een groot bedrijf ken ik niet
IBM, Sun, HP... :?
Over de opmerking wie er wel eens open source code aanpast:

Inderdaad, ik geloof niet dat bedrijven dit doen.
Het kost tijd&geld, en je weet zeker dat je dan uit de pas loopt met toekomstige versies van het product. Slecht idee dus!

Er wordt van OS software altijd gezegd dat dit een heel groot voordeel is, maar ik geloof er niets van.

Wel is OS software veel voordeliger dan commerciŽle software. Zeker voor een niet te grote database kun je dan eens naar MySql kijken of naar Apache, in plaats van Oracle of IIS.
Er wordt van OS software altijd gezegd dat dit een heel groot voordeel is, maar ik geloof er niets van.
De groep die het hier op de frontpage altijd het hardst staat te schreeuwen is dan ook consequent onder de 18 en heeft nog nooit bij een groter bedrijf dan de Albert Heijn waar ze bijklussen binnengekeken :)

Helaas wen je daaraan... ik mag Tweakers.net erg graag maar zou soms toch graag zien dat er hier op de frontpage een leeftijdsgrens zou zitten, of een mini-IQ-test voordat je een antwoord kunt posten.

Ja, MySQL is een hele leuke database voor websites, en zowel MySQL als PostGreSQL zijn geschikt voor kleine ondernemingen. Maar als je bedrijfskritische 24/7 software gaat draaien wil je een enterprise DBMS, niet een produkt waar "hobbyisten van over heel de wereld in hun avonduurtjes de bugs van hebben zitten fixen." Dat wordt hier overal als enorme pro van de OS-databases genoemd, maar je gaat toch als bedrijf je meest vitale en kritische processen niet toevertrouwen aan de grootste hobbyclub ter wereld?!? :?
Je kan net zo goed stellen "Je gaat je als bedrijf voor je meest vitale en kritische processen afhankelijk maken van een enkele leverancier?" Die uitspraak is net zo eenzijdig.
Je kan ook op open source software prima professionele support krijgen (ook van grote bedrijven), maar je bent nooit afhankelijk van alleen dat bedrijf.
Voor elke toepassing en voor elk bedrijf zal je apart de afweging moeten maken wat de beste oplossing is. Het artikel zegt alleen maar dat er een verschuiving te zien is richting de open source oplossingen. Vanuit mijn perspectief (ik ontwikkel onder meer mee aan KDE applicaties) is dat een positieve ontwikkeling.

* 786562 ATS
Hmm.. dan zou ik toch maar eens kijken op de websites van deze opensource db's... Zo draait Yahoo bv MySQL..

Ik weet ook dat MySQL heel wat functionaliteit moet missen, maar PostgreSQL is een geduchte tegenstander voor de commerciele pakketten...
Je moet trouwens de lijst van developers bekijken.. zitten heel wat bekende namen in de software wereld tussen,,,
Hmm.. dan zou ik toch maar eens kijken op de websites van deze opensource db's... Zo draait Yahoo bv MySQL..
Ik zou de database van Yahoo nu niet echt als 'vitale bedrijfskritische' informatie willen bestempelen. Op dit exacte moment zit ik aan de fabrieksautomatisering van een van de grootste fabrieken van Nederland te sleutelen, met daaraan een Oracle 8 cluster en SAP. 1 foutje in de database betekent hier direct tienduizenden euro's verlies.

Ik moet er niet aan denken dat ik hier achter MySQL zou zitten :X
Maar als je bedrijfskritische 24/7 software gaat draaien wil je een enterprise DBMS, niet een produkt waar "hobbyisten van over heel de wereld in hun avonduurtjes de bugs van hebben zitten fixen."
Met andere woorden, je kiest een organisatie uit (MySQL) die een professionele structuur hebben, aan QA doen, een goed Software Engineerings Proces volgen, en een strak testplan uitvoeren zodat het product van een goede kwaliteit is. Daarnaast hoop je dat ze goede gekwalificeerde engineers/programmeurs in dienst hebben, maar dit kan je helaas niet altijd makkelijk controleren.

Dit geld dus zowel voor closed-source als open-source organisaties.

Als bedrijf kies je een database+organisatie omdat deze goede support leveren en een goed product hebben. Anders had je wel een willekeurige closed-source database van "piet om de hoek" (aka thuistweaker) gekocht..! ;) De discussie of het open/closed is hier niet relevant, maar mogelijk wel voor andere eisen die op de tafel van de manager liggen.
maar je gaat toch als bedrijf je meest vitale en kritische processen niet toevertrouwen aan de grootste hobbyclub ter wereld?!?
nope, maar sommige "professionele" bedrijven zijn geen haar beter.
open source != hobby club.
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.
Ik ken een bedrijfje van +/- 50 man dat door een extern buro een tijdschijfsysteem heeft laten ontwikkelen. Het externe buro had gekozen voor een Oracle backend(!). Kijk, dit zijn nou situaties waarin je beter een open source DB kunt gebruiken. Het programma is in 2 dagen te herschrijven om gebruik te maken van MySQL en daarna zijn de onderhoudskosten een fractie van voorheen.

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

Dan moet je toch eens beter om je heen kijken. Kijk bijvoorbeeld eens op de website van MySQL http://www.mysql.com/press/partners/releases.html welke bedrijven mysql als partner zien.
IBM, ook niet de kleinste, levert al jaren serieus support op OSS.
Goh da's knap. Wie weet kunnen we dan eens zaken doen.

Laat ik nou net zo'n iemand zijn die dat soort systemen in elkaar 'knutselt'.
En MySQL is een mooie database, maar als jij daar 50 man op de vrijdagmiddag of maandagochtend hun uren in laat vullen (even overdrijven) dan ben ik benieuwd of die MySQL het nog wel gaat redden.
Gezeik met locks, een trage verbinding.
En als die database hapert dan zitten er 50 man uit hun neus te peuteren als het tegenzit.
Me dunkt dat je daar best wel wat voor over hebt om te voorkomen.
En Oracle onderhoud hoeft helemaal niet duur te zijn. Veel van onze klanten helpen we gewoon van afstand en dat bevalt ze uitstekend.

Dan zou ik eerder het voorbeeld van de MS Access 'terreur' willen noemen. Allerlei bedrijfskritische informatie die in Access applicaties of Excel sheets wordt bijgehouden en oh wee als er geen backup wordt gemaakt.
En in het begin werkt het misschien nog wel, maar net op het moment als je er op gaat vertrouwen blijkt dat het programma toch niet goed opgewassen is tegen de hoeveelheid data die je er mee wilt beheren.
Dan is zo'n 'grote' database overkill en kan het ook wel op een OSS versie.

Trouwens je kun ook heel goed OSS en closed source software combineren. Bijv een PhpBB of tig probleemloos op een Oracle DB draaien.
Wat betreft de Access 'terreur' zoals je het noemt ben ik het helemaal met je eens. Maar ik vind dat je een beetje verkeerd beeld hebt van de prestaties van MySQL. 50 gebruikers is natuurlijk peanuts en dat kan het op zijn sloffen aan. Zie voor een vergelijkende benchmark bijvoorbeeld deze grafieken van eweek:

http://www.eweek.com/slideshow/0,3670,s=1590&a=23120&po=1&i=1,00.asp

Daar komt nog bij dat het hier niet om een bedrijfskritische applicatie gaat, dus zelfs al zou de database geen 50 gebruikers tegelijk aankunnen op maandagochtend dan hoeft er heus niemand uit zijn neus te gaan eten. Tijdschrijven kan op een ander moment ook nog wel.
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.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True