[Database] Welk gratis DBMS?*

[Verwijderd]

Beste heren en dames,

Ik sta aan de vooravond van een project dat in ASP een webquestionaire moet opleveren. Met deze app moeten 250 gebruikers een mail krijgen en een vragenlijst in gaan vullen. Dit zal meedere malen gebeuren op het systeem, omdat er meerdere projecten gaan lopen.

Ik zie het gebeuren dat er straks veel mensen tegelijk in gaan loggen en de zaak in gaan vullen en dan loop ik met een Access database tegen de lamp.

Echter kan een MSDE database geen uitkomst bieden vanwege de max aantal users van 25.

Omdat ik niet bekend ben met php maar alleen ervaring heb met asp, wordt een connectie met MySQL al lastig, wellicht dat 1 van jullie hiermee ervaring heeft??? (ASP EN PHP combi)

Tenslotte zijn de kosten van een MSSQL database erg hoog, iets wat het project niet rendabel zou maken.

Ik zie zo snel geen oplossing, en heb al zitten speuren maar in andere gelijksoortige topics is het aantal users niet zo'n iussue als bij mij.

Kunnen jullie helpen ?? ik weet het zo niet en ben een beetje de wanhoop nabij haha

thanks all !

[rb338]

Kan je met ASP niet gewoon naar een MySQL databeest verbinden dan?
Ik vind je topic titel trouwens niet echt duidelijk, misschien iets als:

"ASP app: welke database >25 users"

Kan je niet wat op Google vinden over je mogelijkheden? Je zegt dat je al hebt zitten speuren, ben je er wijzer van geworden? Heb je zelf al wat geprobeerd behalve zoeken?

[whoami]

MSDE heeft een maximum aantal concurrent connections.... Niet max. users...
Dat is dus heel wat anders....
Als jij een beetje netjes progged, dan moet MSDE dat wel aankunnen...

[ Voor 39% gewijzigd door whoami op 18-05-2005 12:36 ]

[NMe]

Verwijderd schreef op woensdag 18 mei 2005 @ 12:29:
Omdat ik niet bekend ben met php maar alleen ervaring heb met asp, wordt een connectie met MySQL al lastig, wellicht dat 1 van jullie hiermee ervaring heeft??? (ASP EN PHP combi)

ASP en PHP combineren? Waarom? Omdat je MySQL wil gebruiken? Lees dit eens.

Verder zijn er nog genoeg andere gratis database-varianten, waaronder PostgreSQL en volgens mij ook een gratis versie van Oracle.

[rb338]

-NMe- schreef op woensdag 18 mei 2005 @ 12:32:
[...]

ASP en PHP combineren? Waarom? Omdat je MySQL wil gebruiken? Lees dit eens.

Verder zijn er nog genoeg andere gratis database-varianten, waaronder PostgreSQL en volgens mij ook een gratis versie van Oracle.

Oracle heeft geen gratis versie

_{Wel goedkope}

[Noork]

access kan dit ook wel aan hoor.

[NMe]

rb338 schreef op woensdag 18 mei 2005 @ 12:33:
[...]

Oracle heeft geen gratis versie

_{Wel goedkope}

Wat is dit dan?

[Verwijderd]

-NMe- schreef op woensdag 18 mei 2005 @ 12:32:
[...]

ASP en PHP combineren? Waarom? Omdat je MySQL wil gebruiken? Lees dit eens.

Hmm ga ik eens testen ! top ! en jah das wel de opzet, ASP en MySQL combineren om gebruik te maken van die database variant .... het is de enige variant waar ik niet meer dan lof over hoor .... MSDE en PostgreSQL hoor ik mensen niet eg heel blij mee zijn ....

en voor zover ik weet heeft oracle geen vrije versie .... maar durf ik nie 100% zeker te zegge

[Cyphax]

Verwijderd schreef op woensdag 18 mei 2005 @ 12:37:
[...]


Hmm ga ik eens testen ! top ! en jah das wel de opzet, ASP en MySQL combineren om gebruik te maken van die database variant .... het is de enige variant waar ik niet meer dan lof over hoor .... MSDE en PostgreSQL hoor ik mensen niet eg heel blij mee zijn ....

en voor zover ik weet heeft oracle geen vrije versie .... maar durf ik nie 100% zeker te zegge

Hoor je mensen "niet eg heel blij mee" zijn? Nahja.
http://www.oracle.com/technology/software/index.html
Check de eerste zin al: "All software downloads are free". Ik weet niet wat je onder vrije versie bestaat overigens maar Oracle kan je voor home use gewoon gebruiken, geen enkel punt. Wil je Oracle commercieel gaan gebruiken, wordt het een ander verhaal. Daar vind je wel meer over op de site van Oracle.

[Verwijderd]

rb338 schreef op woensdag 18 mei 2005 @ 12:31:
Kan je met ASP niet gewoon naar een MySQL databeest verbinden dan?
Ik vind je topic titel trouwens niet echt duidelijk, misschien iets als:

"ASP app: welke database >25 users"

Kan je niet wat op Google vinden over je mogelijkheden? Je zegt dat je al hebt zitten speuren, ben je er wijzer van geworden? Heb je zelf al wat geprobeerd behalve zoeken?

Ik heb vooral gekeken naar de beperkingen van bijv MSDE en mensen met dezelfde vraag als de mijne ... veelal zelfde vraag maar andere prioriteit ... Google heeft me niet veel wijzer gemaak dan het verwijzen naar fora waar ik met het probleem heen kan en waar mensen soortgelijke vragen stellen ...

[whoami]

Verwijderd schreef op woensdag 18 mei 2005 @ 12:37:
[...]


MSDE en PostgreSQL hoor ik mensen niet eg heel blij mee zijn ....

Vreemd, MSDE is een 'uitgekleede' versie van sql server, en die is gewoon goed.
Ik zou eerder geloven dat er mensen zijn die niet tevreden zijn van mySQL dan van MSDE

[Spidey]

Dan is er nog het niet bekende Ingres dat nog niet zo labg gelden ook een opensource versie heeft. Een zeer krachtig DBMS. Alle documentatie is in PDF-formaat beschikbaar op de site.

http://opensource.ca.com/projects/ingres/files

[party42]

whoami schreef op woensdag 18 mei 2005 @ 12:42:
[...]

Vreemd, MSDE is een 'uitgekleede' versie van sql server, en die is gewoon goed.
Ik zou eerder geloven dat er mensen zijn die niet tevreden zijn van mySQL dan van MSDE

Dat lijkt mij idd ook. Ik wil ook nogmaals even wijzen op de max 25 concurrent users. Volgens mij is MSDE gewoon een prima database applicatie die het in het geval van de TS zeker genoeg moet zijn.

Overigens:

Ik zie het gebeuren dat er straks veel mensen tegelijk in gaan loggen en de zaak in gaan vullen en dan loop ik met een Access database tegen de lamp.

Volgens mij als je je database afhandeling netjes programmeert en recordsets z.s.m. weer loslaat dan volstaat Acces ook wel. Ik vind dat Acces onterecht geschoffeerd wordt als waardeloze database app.

[ Voor 20% gewijzigd door party42 op 18-05-2005 12:46 ]

[NMe]

Verwijderd schreef op woensdag 18 mei 2005 @ 12:37:
Hmm ga ik eens testen ! top ! en jah das wel de opzet, ASP en MySQL combineren om gebruik te maken van die database variant .... het is de enige variant waar ik niet meer dan lof over hoor .... MSDE en PostgreSQL hoor ik mensen niet eg heel blij mee zijn ....

Toch vreemd dat ik altijd het tegenovergestelde hoor eigenlijk. Uit de sig van ACM: http://vulcanus.its.tudelft.nl/acm/got/antimysql.php

[sig69]

250 mensen die een vragenlijstje moeten invullen is natuurlijk peanuts voor MSDE. De beperking is het het aan tal concurrent users, dus 250 keer een vragenlijst in de DB opslaan is zeker geen probleem als je gewoon netjes je verbinding afsluit etc.

[EfBe]

whoami schreef op woensdag 18 mei 2005 @ 12:31:
MSDE heeft een maximum aantal concurrent connections.... Niet max. users...
Dat is dus heel wat anders....
Als jij een beetje netjes progged, dan moet MSDE dat wel aankunnen...

MSDE is gelimiteerd op 5 transactions per clock, dat houdt in dat wanneer jij een select uitvoert met 5 'derived table selects' (SELECT ... FROM (select * from bar) as bar)) dan is het erg traag, ookal ben jij de enige op de bak

Je kunt ong met 35 man tegelijk op een msde install, mits de queries vrij kort zijn. Daarna wordt het erg langzaam.

De topicstarter zou een blik kunnen werpen op Firebird.

[Verwijderd]

party42 schreef op woensdag 18 mei 2005 @ 12:46:
[...]

Dat lijkt mij idd ook. Ik wil ook nogmaals even wijzen op de max 25 concurrent users. Volgens mij is MSDE gewoon een prima database applicatie die het in het geval van de TS zeker genoeg moet zijn.

Overigens:

[...]


Volgens mij als je je database afhandeling netjes programmeert en recordsets z.s.m. weer loslaat dan volstaat Acces ook wel. Ik vind dat Acces onterecht geschoffeerd wordt als waardeloze database app.

Mijn ervaring met Access is dat als het volloopt en er werken een aantal mensen tegelijk op dat het dan traag gaat worden .... echter wuif ik het normalerwijs niet direct weg ... het is een prima db om mee te werken, doe nie anders....

Wat betreft de concurrent users ... in mijn beleving zijn dat de actieve gebruikers die op je server/database bezig zijn ... vandaar dat ik ook vermeld dat er een mail de deur uit gaat naar 250 mensen ... gaat 10% aan het invullen, prima, niets aan de hand ... 20% kan ook prima goed gaan .... maar zijn het er meer dan kan je dus boven die 25 komen .... of ben ik nou gek ???

[Verwijderd]

EfBe schreef op woensdag 18 mei 2005 @ 12:55:
[...]

De topicstarter zou een blik kunnen werpen op Firebird.

Working on it !

[DJ Adidas]

whoami schreef op woensdag 18 mei 2005 @ 12:31:
MSDE heeft een maximum aantal concurrent connections.... Niet max. users...
Dat is dus heel wat anders....
Als jij een beetje netjes progged, dan moet MSDE dat wel aankunnen...

Nu kan ik me natuurlijk vergissen. Maar zodra je gebruik maakt van ASP ben je maar met 1 User verbonden met die DB ? Lijkt me dus niet eens een kwestie van handig programmeren, maar weten waar je over praat

MSDE is volgens mij dus ook gewoon nogsteeds een optie. Mede doordat ASP & MSSQL goed met elkaar overweg kunnen heeft dit erg vaak de voorkeur.

[whoami]

DJ Adidas schreef op woensdag 18 mei 2005 @ 12:58:
[...]


Nu kan ik me natuurlijk vergissen. Maar zodra je gebruik maakt van ASP ben je maar met 1 User verbonden met die DB ? Lijkt me dus niet eens een kwestie van handig programmeren, maar weten waar je over praat

Het gaat niet over users maar over connecties.
En beweer je nu dat ik niet weet waar ik over praat ?

Mede doordat ASP & MSSQL goed met elkaar overweg kunnen heeft dit erg vaak de voorkeur.

Mja, dit klasseer ik onder hetzelfde rubriekje dat je MySQL moet kiezen als je met PHP bezig bent.
Als je op basis van zo'n stelling een DBMS kiest, dan ben je niet goed bezig.

[DJ Adidas]

whoami schreef op woensdag 18 mei 2005 @ 13:03:
Mja, dit klasseer ik onder hetzelfde rubriekje dat je MySQL moet kiezen als je met PHP bezig bent.
Als je op basis van zo'n stelling een DBMS kiest, dan ben je niet goed bezig.

Lijkt me juist wel, waarom zou je het jezelf moeilijker maken ?
Net zoals je zelf idd al aangeeft werkt PHP het beste met MySQL PostgreSQL etc.
Ik zeg niet dat het niet met elkaar werkt, maar bepaalde dingen binnen de ASP-taal zijn beter voorbereid op MSSQL dan op MySQL.

[whoami]

DJ Adidas schreef op woensdag 18 mei 2005 @ 13:06:
[...]


Lijkt me juist wel, waarom zou je het jezelf moeilijker maken ?
Net zoals je zelf idd al aangeeft werkt PHP het beste met MySQL PostgreSQL etc.
Ik zeg niet dat het niet met elkaar werkt, maar bepaalde dingen binnen de ASP-taal zijn beter voorbereid op MSSQL dan op MySQL.

En als ik nu eens een website moet maken in PHP, en de onderliggende DB heeft
- transacties nodig
- triggers nodig
- stored procedures nodig
- UDF's nodig
- referentiele integriteit
- etc...
nodig. Ga je dan nog altijd mySQL gebruiken ?

Of stel: je moet een website maken voor een bedrijf in ASP, en dat bedrijf heeft in house knowledge van Oracle DBMS'en, en heeft al een rits aan Oracle DB's staan.
De webapplicatie die jij moet maken heeft gegevens nodig die in zo'n Oracle DB staan. Ga je dan ook dat bedrijf proberen te overtuigen om over te stappen naar SQL Server, omdat het jou goed uikomt ?

[rb338]

-NMe- schreef op woensdag 18 mei 2005 @ 12:35:
[...]

Wat is dit dan?

Je kunt zo'n beetje alle Oracle software gratis downloaden en je mag het gebruiken, maar niet in een 'productie-omgeving' of hoe je het wilt noemen (wat de TS dus wil). Ik zit op dit moment op kantoor bij Oracle en heb het nog even nagevraagd

edit: Uit de license agreement:

License Rights
We grant you a nonexclusive, nontransferable limited license to use the programs only for the purpose of developing a single prototype of your application, and not for any other purpose. If you use the application you develop under this license for any internal data processing or for any commercial or production purposes, or you want to use the programs for any purpose other than as permitted under this agreement, you must contact us, or an Oracle reseller, to obtain the appropriate license. We may audit your use of the programs.

[ Voor 44% gewijzigd door rb338 op 18-05-2005 13:12 ]

[DJ Adidas]

whoami schreef op woensdag 18 mei 2005 @ 13:10:
[...]


En als ik nu eens een website moet maken in PHP, en de onderliggende DB heeft
- transacties nodig
- triggers nodig
- stored procedures nodig
- UDF's nodig
- referentiele integriteit
- etc...
nodig. Ga je dan nog altijd mySQL gebruiken ?

Of stel: je moet een website maken voor een bedrijf in ASP, en dat bedrijf heeft in house knowledge van Oracle DBMS'en, en heeft al een rits aan Oracle DB's staan.
De webapplicatie die jij moet maken heeft gegevens nodig die in zo'n Oracle DB staan. Ga je dan ook dat bedrijf proberen te overtuigen om over te stappen naar SQL Server, omdat het jou goed uikomt ?

Zonder te flamen wil ik je adviseren om het begin topic nog even na te lezen, want daar kom ik nergens deze wensen tegen.

Daarnaast zei ik daarnet ook al dat het een VOORKEUR betreft. Als een klant reeds over een Database Omg. beschikt lijkt me dat een duidelijk zaak.
Tevens zei ik ook dat de verschillende pakketten WEL met elkaar samenwerken.

[whoami]

DJ Adidas schreef op woensdag 18 mei 2005 @ 13:21:
[...]


Zonder te flamen wil ik je adviseren om het begin topic nog even na te lezen, want daar kom ik nergens deze wensen tegen.

Zonder te flamen wil ik je zeggen dat een DB kiezen op basis van de regel die jij voorstelt kwatsch is.

En kan je mij ook concreet zeggen welke 'delen' van de ASP taal er beter op MS-SQL voorbereid zijn dan op MySQL ?

[ Voor 15% gewijzigd door whoami op 18-05-2005 13:23 ]

[T-MOB]

-NMe- schreef op woensdag 18 mei 2005 @ 12:50:
[...]
Toch vreemd dat ik altijd het tegenovergestelde hoor eigenlijk. Uit de sig van ACM: http://vulcanus.its.tudelft.nl/acm/got/antimysql.php

De link werkt momenteel niet bij mij, maar ik ken het lijstje wel. Voor veel simpele webapplicaties is het lijstje helemaal niet zo relevant. Boeiend dat MySQL beperkt is in het garanderen van integriteit, boeiend dat MySQL soms afwijkt van officiële specificaties. Als je dat weet (of niet beter weet) valt daar prima mee te werken. MySQL is een database die redelijk eenvoudig te leren is (iig samen met PHP), bij welhaast elke hoster wordt aangeboden en z'n ding best goed (zelfs bij GoT).

Dat Postgres of welk ander database-programma "beter" is geloof ik best (alhoewel elk er van overtuigd ben dat elk DBMS zijn nukken heeft). Voor heel veel webapplicaties biedt MySQL echter meer dan genoeg (en voor weinig ).

[DJ Adidas]

whoami schreef op woensdag 18 mei 2005 @ 13:23:
[...]

Zonder te flamen wil ik je zeggen dat een DB kiezen op basis van de regel die jij voorstelt kwatsch is.

En kan je mij ook concreet zeggen welke 'delen' van de ASP taal er beter op MS-SQL voorbereid zijn dan op MySQL ?

Lees nou de starttopic eens. Daarin staat nergens eisen voor de DB. Kortom, de gebruiker kan in dat stadium nog een hoop kanten op.
Iedereen geeft daarna een advies wat hem/haar het beste lijkt in deze situatie zoals ook ik dat doe. Dat je het daar niet mee eens bent oké, maar geef dan aan waarom hij dat product absoluut niet zou moeten kiezen ipv. mijn redenen te doorboren.

De gebruiker heeft meer aan de Positieve kanten van de keuze die jij zou maken zodat hij die tegen elkaar kan afwegen.

Verder ga ik hier niet inhoudelijk in op een "Wie heeft de langste" kind off topic. We zijn hier tenslotte om de TS te helpen en niet om elkaar de grond in te boren.

[Verwijderd]

Met ASP geen ervaring, maar ik weet (wel uit ervaring) dat de combo asp.net en mysql wel gewoon lekker werkt, alleen moet je wat extra software op de server installeren om het mogelijk te maken.

Dus ik zou voor zoiets, wat gewoon lekker snel en simpel moet zijn (qua DB) "gewoon" voor MySQL gaan.

[whoami]

DJ Adidas schreef op woensdag 18 mei 2005 @ 13:36:
[...]


Lees nou de starttopic eens

Heb ik gedaan.

Daarin staat nergens eisen voor de DB. Kortom, de gebruiker kan in dat stadium nog een hoop kanten op.

Dat zeg ik ook niet; ik zeg dat gewoon als reactie op jouw stelling.

Dat je het daar niet mee eens bent oké, maar geef dan aan waarom hij dat product absoluut niet zou moeten kiezen ipv. mijn redenen te doorboren.

Ik heb ook nergens gezegd dat hij niet voor MSDE moet gaan.
Misschien moet jij nog maar eens het topic herlezen.

Daarbij heb jij nog geen enkele keer inhoudelijk op mijn vragen geantwoord.

[Verwijderd]

rb338 schreef op woensdag 18 mei 2005 @ 13:10:
[...]

Je kunt zo'n beetje alle Oracle software gratis downloaden en je mag het gebruiken, maar niet in een 'productie-omgeving' of hoe je het wilt noemen (wat de TS dus wil). Ik zit op dit moment op kantoor bij Oracle en heb het nog even nagevraagd

edit: Uit de license agreement:

[...]

Heb ik ook op de website aangetroffen ... en de licentie die aan zou sluiten op mijn verhaal komt op een 11.500 euri ... wat nie eg peanuts is voor mij haha ...

Maar ok ik begrijp dat als ik een beetje netjes prog (en dat doe ik naar mijn mening ... tis niet de eerste app die ik schrijf) kan ik met MSDE en MySQL goed uit de voeten .... nu heb ik mijn hosting provider eens aan de mouw getrokken over MSDE (wat zij niet ondersteunen qua hosting) en daar willen ze dus niet aan beginnen .... MySQL daarentegen wel ....

Is een hosting wissel het eventuele voordeel van MSDE waard ??? op zich is een dergelijke wissel niet zo'n probleem omdat ik tog voor de app uiteindelijk een aparte account aan moet gaan ..... maar waarheen dan ???

wat een vragen haha

Wil sowieso iedereen bedanken voor de input .... heeft me op het goede spoor gezet .... jullie zijn helden

[whoami]

Ik vraag me af of er wel gratis hosters zijn voor MSDE.....

Als de data die je gaat gaan opslaan niet zo 'kritisch' is, dan zou je gewoon MySQL kunnen verkiezen (gewoon uit gemak), al is het niet mijn favo db.

[ReallyStupidGuy]

Heb je misschien al gedacht aan Firebird? (Werk ik op dit moment mee en bevalt goed!)

En waarom MySQL niet zou kunnen snap ik niet helemaal. MySQL wordt idd vaak gebruikt icm PHP (ik denk omdat veel hosts het hebben) maar ik neem aan dat je dezelfde mogelijkheden hebt als bij andere DBMS-en.

[P_de_B]

EfBe schreef op woensdag 18 mei 2005 @ 12:55:
[...]

MSDE is gelimiteerd op 5 transactions per clock, dat houdt in dat wanneer jij een select uitvoert met 5 'derived table selects' (SELECT ... FROM (select * from bar) as bar)) dan is het erg traag, ookal ben jij de enige op de bak

De workload governor grijpt in bij meer dan 8 gelijktijdige operaties, en volgens mij wordt een batch met opdrachten als 1 operatie gezien. Dat zou betekenen dat bovenstaande voorbeeld als slechts 1 operatie telt.

Kijk hier maar: http://msdn.microsoft.com...rchitec/8_ar_sa2_0ciq.asp of lees ik dit nu verkeerd?

[Ronald]

T-MOB schreef op woensdag 18 mei 2005 @ 13:25:
[...]


De link werkt momenteel niet bij mij, maar ik ken het lijstje wel. Voor veel simpele webapplicaties is het lijstje helemaal niet zo relevant. Boeiend dat MySQL beperkt is in het garanderen van integriteit, boeiend dat MySQL soms afwijkt van officiële specificaties. Als je dat weet (of niet beter weet) valt daar prima mee te werken. MySQL is een database die redelijk eenvoudig te leren is (iig samen met PHP), bij welhaast elke hoster wordt aangeboden en z'n ding best goed (zelfs bij GoT).

Dat Postgres of welk ander database-programma "beter" is geloof ik best (alhoewel elk er van overtuigd ben dat elk DBMS zijn nukken heeft). Voor heel veel webapplicaties biedt MySQL echter meer dan genoeg (en voor weinig ).

Die lijst van ACM zie ik als een dikke flame. Omdat hij argumenten gebruikt als: In versie <heeeel oud> kon het dit niet. Wat je hier opgenoemd hebt zijn de voornaamste punten die je je moet realiseren bij het gebruik van Mysql, de rest van de ACM lijst mag van mij in /dev/null gedumpt.

Als je een oude versie van Oracle neemt kan je daar ook vast wel gebreken in vinden, moet je daar de huidige productie versie op afrekenen? ACM lijkt te denken van wel. Be your own judge.

[curry684]

Verwijderd schreef op woensdag 18 mei 2005 @ 12:37:
[...]


Hmm ga ik eens testen ! top ! en jah das wel de opzet, ASP en MySQL combineren om gebruik te maken van die database variant .... het is de enige variant waar ik niet meer dan lof over hoor .... MSDE en PostgreSQL hoor ik mensen niet eg heel blij mee zijn ....

Laat ik me dan bij de rest van de mensen in dit topic aansluiten en zeggen dat MySQL een baggerprodukt is, nu kun je iig nooit meer claimen dat je alleen maar lof over dat stuk wanstalt hoort

Punt dat veel mensen hier vergeten (whoami probeert hetzelfde punt te maken) is dat je de goede database voor je toepassing moet kiezen, niet bij je platform. Als je gewoon meukdata opslaat, stel dat die questionnaire voor studenten van een universiteit is, is MySQL meer dan afdoende en geen enkel probleem. Als de questionnaire bedoeld is om klanten van een multinational te ondervragen over hun tevredenheid over de geleverde service en de progressie daarvan over meerdere jaren statistisch te analyseren om op basis daarvan werkplanningen van marketing en sales te kunnen maken ben je een van de pot gerukte zot als je daar MySQL op durft te zetten.

MySQL is een mooi produkt zolang de data niet belangrijk is en het niet veel mag kosten. PostgreSQL is langzamer dan MySQL, moet ook wel omdat het tig checks wel uitvoert die MySQL overboord gooit. PostgreSQL is minder market-accepted dan duurdere DBMS'en maar wel haalbare kaart voor data die aan het doel van MySQL voorbij schiet. MSDE is gewoon SQL Server, en dus een rocksolid enterprise database die alle mogelijke features kent en ondersteunt. Als het binnen de concurrency margin valt en je een eigen bak aan internet hebt hangen absoluut de beste optie: voor commerciele hosting is licentietechnisch SQL Server Standard volgens mij per definitie verplicht (4999 dollar) dus dat heeft geen enkele hoster.

Al met al hangt veel af van hoe vitaal de data is. En dat zul je zelf moeten beoordelen, en erbij onthouden dat alle kwaliteit een prijs heeft

[DaCoTa]

curry684 schreef op woensdag 18 mei 2005 @ 15:06:
[...]
Al met al hangt veel af van hoe vitaal de data is. En dat zul je zelf moeten beoordelen, en erbij onthouden dat alle kwaliteit een prijs heeft

offtopic:
Als de data van vitaal belang is, moet je meer effort steken in de veiligstelling daarvan, onafhankelijk van DBMS. Ik heb evenvaak - onder normale gebruiksomstandigheden - een Oracle database zonder aanwijsbare reden het puin in zien lopen als een MySql, om even twee uitersten te noemen. In beide gevallen word je alleen gered door je backup, niet door het DBMS.

[curry684]

DaCoTa schreef op woensdag 18 mei 2005 @ 15:16:
[...]

offtopic:
Als de data van vitaal belang is, moet je meer effort steken in de veiligstelling daarvan, onafhankelijk van DBMS. Ik heb evenvaak - onder normale gebruiksomstandigheden - een Oracle database zonder aanwijsbare reden het puin in zien lopen als een MySql, om even twee uitersten te noemen. In beide gevallen word je alleen gered door je backup, niet door het DBMS.

Da's bull. Oracle heeft wel een transactionlog die je per transaction kunt rollbacken, evenals SQL Server. Veel plezier met MySQL Tevens kun je de Enterprise DBMS'en wel bruikbaar replicaten, op federated servers zetten, gescheiden datafiles en logfiles over meerdere disk subsystems spannen, binary columns in losse datafiles afsplitsen, en ga zo maar door. Een goed ingericht EDBMS is stukken moeilijker plat te krijgen dan een MySQL-installatie... maar daar komt de kwaliteit van de beheerder ook vaak om de hoek kijken.

Ik heb laatst een praktijkgeval gezien waarbij iemand per ongeluk een DELETE zonder where-clause had gedaan op SQL Server. In de transaction logs opgezocht wie het had gedaan en vervolgens gerollbacked tot exact voor de fatale transactie. Dat is databeheer, en wat anders dan een backup van vorige week terugknallen.

[EfBe]

P_de_B schreef op woensdag 18 mei 2005 @ 14:40:
De workload governor grijpt in bij meer dan 8 gelijktijdige operaties, en volgens mij wordt een batch met opdrachten als 1 operatie gezien. Dat zou betekenen dat bovenstaande voorbeeld als slechts 1 operatie telt.

Kijk hier maar: http://msdn.microsoft.com...rchitec/8_ar_sa2_0ciq.asp of lees ik dit nu verkeerd?

Bij mijn weten was het altijd 5 transactions per tick, maar dat kan ik natuurlijk altijd verkeerd hebben gelezen (kan goed hoor, ik heb '5' onthouden, maar dat kunnen er best 8 zijn geweest en gezien hetgeen jij linkt heb ik ongelijk, dus 8 it is ). Die subselects zijn wel degelijk aparte acties, want in llblgen 1.x (die oude generator) had ik een inmense query met vrij veel subselects en die was echt retetraag op msde maar gewoon snel op sqlserver. De enige verklaring die ik ervoor kan geven is dat de subselects ook als aparte acties worden gezien.

[ Voor 4% gewijzigd door EfBe op 18-05-2005 15:28 ]

[P_de_B]

Hmm, ik heb geen MSDE installatie, maar anders zou je in het log de melding DBCC CONCURRENCYVIOLATION oid moeten zien als er teveel concurrent workloads zijn.. Kun je dat nog testen?

Anders moet ik toch maar eens installeren, ik hoor hier zoveel halve waarheden en onwaarheden over dat ik het wel eens wil weten.

[EfBe]

P_de_B schreef op woensdag 18 mei 2005 @ 15:27:
Hmm, ik heb geen MSDE installatie, maar anders zou je in het log de melding DBCC CONCURRENCYVIOLATION oid moeten zien als er teveel concurrent workloads zijn.. Kun je dat nog testen?

Anders moet ik toch maar eens installeren, ik hoor hier zoveel halve waarheden en onwaarheden over dat ik het wel eens wil weten.

Ik heb ook MSDE hier niet, op mn locale bak staat sqlserver dev edition, dus die heeft er geen problemen mee

Deze query:

SQL:

SELECT INFORMATION_SCHEMA.COLUMNS.*,
(
    SELECT COLUMNPROPERTY(OBJECT_ID(@sTableName), INFORMATION_SCHEMA.COLUMNS.COLUMN_NAME, 'IsComputed')
) AS IsComputed,
(
    SELECT COL_LENGTH(@sTableName, INFORMATION_SCHEMA.COLUMNS.COLUMN_NAME)
) AS ColumnLength,
(
    SELECT COLUMNPROPERTY(OBJECT_ID(@sTableName), INFORMATION_SCHEMA.COLUMNS.COLUMN_NAME, 'IsIdentity')
) AS IsIdentity,
(
    SELECT COLUMNPROPERTY(OBJECT_ID(@sTableName), INFORMATION_SCHEMA.COLUMNS.COLUMN_NAME, 'IsRowGuidCol')
) AS IsRowGuidColumn,
(
    ISNULL( 
    (
        SELECT  1
        FROM    INFORMATION_SCHEMA.KEY_COLUMN_USAGE
        WHERE   TABLE_NAME=@sTableName AND TABLE_SCHEMA='dbo'
            AND COLUMN_NAME=INFORMATION_SCHEMA.COLUMNS.COLUMN_NAME
            AND EXISTS
            (SELECT * FROM INFORMATION_SCHEMA.TABLE_CONSTRAINTS
            WHERE TABLE_NAME=@sTableName AND TABLE_SCHEMA='dbo' AND CONSTRAINT_TYPE = 'PRIMARY KEY'
            AND CONSTRAINT_NAME=INFORMATION_SCHEMA.KEY_COLUMN_USAGE.CONSTRAINT_NAME)
    ), 0)
) AS IsPrimaryKey,
(
    ISNULL( 
    (   
        SELECT  1
        FROM    INFORMATION_SCHEMA.KEY_COLUMN_USAGE
        WHERE   TABLE_NAME=@sTableName AND TABLE_SCHEMA='dbo'
            AND COLUMN_NAME=INFORMATION_SCHEMA.COLUMNS.COLUMN_NAME
            AND EXISTS
            (SELECT * FROM INFORMATION_SCHEMA.TABLE_CONSTRAINTS
            WHERE TABLE_NAME=@sTableName AND TABLE_SCHEMA='dbo' AND CONSTRAINT_TYPE = 'FOREIGN KEY'
            AND CONSTRAINT_NAME=INFORMATION_SCHEMA.KEY_COLUMN_USAGE.CONSTRAINT_NAME)
    ), 0)
) AS IsForeignKey, 
(
    ISNULL( 
    (   
        SELECT  1
        FROM    INFORMATION_SCHEMA.KEY_COLUMN_USAGE
        WHERE   TABLE_NAME=@sTableName AND TABLE_SCHEMA='dbo'
            AND COLUMN_NAME=INFORMATION_SCHEMA.COLUMNS.COLUMN_NAME
            AND EXISTS
            (SELECT * FROM INFORMATION_SCHEMA.TABLE_CONSTRAINTS
            WHERE TABLE_NAME=@sTableName AND TABLE_SCHEMA='dbo' AND CONSTRAINT_TYPE = 'UNIQUE'
            AND CONSTRAINT_NAME=INFORMATION_SCHEMA.KEY_COLUMN_USAGE.CONSTRAINT_NAME)
    ), 0)
) AS HasUniqueConstraint
FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME = @sTableName AND TABLE_SCHEMA='dbo'

Deze loopt dus over de 8 queries heen.

[sopsop]

Ik heb een website met (in de hoogtijdagen) dik 300.000 hits per maand, alle content komt uit de database en iedere view resulteert sowieso in een update en een insert query. En mijn databaseje houdt dat allemaal prima bij.

En het is gewoon een Access 2000 database i.c.m. ASP.

[ACM]

RonaldH schreef op woensdag 18 mei 2005 @ 14:57:
Die lijst van ACM zie ik als een dikke flame. Omdat hij argumenten gebruikt als: In versie kon het dit niet. Wat je hier opgenoemd hebt zijn de voornaamste punten die je je moet realiseren bij het gebruik van Mysql, de rest van de ACM lijst mag van mij in /dev/null gedumpt.

Als je een oude versie van Oracle neemt kan je daar ook vast wel gebreken in vinden, moet je daar de huidige productie versie op afrekenen? ACM lijkt te denken van wel. Be your own judge.

Op het moment van schrijven waren het geen oude, maar de meest actuele productie-versies. Dat er ondertussen wat verbeteringen zijn gekomen maakt de lijst toen niet ongeldig. Sowieso is het geen flame, maar een lijst met feiten onderbouwde statements.
Overigens zijn veel van de rariteiten van mysql nog steeds vrolijk in MySQL 4.1 aanwezig. Pas in MySQL 5.0 kan je bijvoorbeeld opgeven dat een tabel geen default waarde heeft als ie not null is... Ook in die versie worden pas waardes niet silenlty truncated/converted als er incorrecte data ingevoerd wordt. Als je als datumveld "dit is geen datum" invult, vindt MySQL 4.1 dat wel best, maakt ie er wel 0000-00-00 van, maar geeft je er geen melding over.

Ook kan MySQL 4.1 nog steeds niet goed achterwaarts sorteren, is de InnoDB-storage nog steeds niet de standaard, moet je nog steeds verplicht indices op foreign keys hebben (die kolom die je met references tabel(kolom)). En zo zijn er veel punten gewoon nog steeds aanwezig.

[ACM]

curry684 schreef op woensdag 18 mei 2005 @ 15:06:
Laat ik me dan bij de rest van de mensen in dit topic aansluiten en zeggen dat MySQL een baggerprodukt is, nu kun je iig nooit meer claimen dat je alleen maar lof over dat stuk wanstalt hoort

Baggerproduct is overdreven. Maar het gebruik van MySQL heeft wel haken en ogen. Net als het gebruik van alle andere dingen (Oracle/SQL Server bijv de kosten om er maar een te noemen).

PostgreSQL is langzamer dan MySQL, moet ook wel omdat het tig checks wel uitvoert die MySQL overboord gooit.

Dat is trouwens een onzin-statement. Want PostgreSQL's query-planner is dusdanig geavanceerder dat hij bij de meer complexe zaken vele malen sneller kan zijn. Alleen met de triviale queries is MySQL nog wat sneller, maar om maar een praktijkvoorbeeld te geven waar MySQL echt helemaal de mist in ging. Ik wilde weten of onze user-database in de loop de jaren grote "gaten" heeft (het waarom doet er niet toe). Daar had ik een aantal queries voor bedacht:

SQL:

SELECT a.UserID, b.UserID FROM F_Users a, F_Users b WHERE
b.UserID = (SELECT c.UserID FROM F_Users c WHERE c.UserID > a.UserID ORDER BY c.
UserID LIMIT 1)
AND
b.UserID > (a.UserID + 5);

SELECT a.UserID, (SELECT c.UserID FROM F_Users c WHERE c.UserID > a.UserID ORDER
 BY c.UserID LIMIT 1) AS nextid
FROM F_Users a
HAVING nextid > a.UserID + 5;

Beide queries waren in MySQL dusdanig traag, dat het sneller was om de data te exporteren, die data te converteren naar een formaat voor postgresql en de data in postgresql te importeren en die query daar in uit te voeren. MySQL was na meer dan een half uur nog niet klaar met de laatste terwijl postgres die in 0.7 seconde deed!

Overigens is MySQL over het algemeen best bruikbaar, maar "niets dan lof" is in mijn ogen nogal een foute uitdrukking om de kwaliteit van MySQL te beschrijven

[P_de_B]

EfBe schreef op woensdag 18 mei 2005 @ 15:32:
[...]

Ik heb ook MSDE hier niet, op mn locale bak staat sqlserver dev edition, dus die heeft er geen problemen mee

Deze query:

SQL:

SELECT INFORMATION_SCHEMA.COLUMNS.*,
(
    SELECT COLUMNPROPERTY(OBJECT_ID(@sTableName), INFORMATION_SCHEMA.COLUMNS.COLUMN_NAME, 'IsComputed')
) AS IsComputed,
(
    SELECT COL_LENGTH(@sTableName, INFORMATION_SCHEMA.COLUMNS.COLUMN_NAME)
) AS ColumnLength,
(
    SELECT COLUMNPROPERTY(OBJECT_ID(@sTableName), INFORMATION_SCHEMA.COLUMNS.COLUMN_NAME, 'IsIdentity')
) AS IsIdentity,
(
    SELECT COLUMNPROPERTY(OBJECT_ID(@sTableName), INFORMATION_SCHEMA.COLUMNS.COLUMN_NAME, 'IsRowGuidCol')
) AS IsRowGuidColumn,
(
    ISNULL( 
    (
        SELECT  1
        FROM    INFORMATION_SCHEMA.KEY_COLUMN_USAGE
        WHERE   TABLE_NAME=@sTableName AND TABLE_SCHEMA='dbo'
            AND COLUMN_NAME=INFORMATION_SCHEMA.COLUMNS.COLUMN_NAME
            AND EXISTS
            (SELECT * FROM INFORMATION_SCHEMA.TABLE_CONSTRAINTS
            WHERE TABLE_NAME=@sTableName AND TABLE_SCHEMA='dbo' AND CONSTRAINT_TYPE = 'PRIMARY KEY'
            AND CONSTRAINT_NAME=INFORMATION_SCHEMA.KEY_COLUMN_USAGE.CONSTRAINT_NAME)
    ), 0)
) AS IsPrimaryKey,
(
    ISNULL( 
    (   
        SELECT  1
        FROM    INFORMATION_SCHEMA.KEY_COLUMN_USAGE
        WHERE   TABLE_NAME=@sTableName AND TABLE_SCHEMA='dbo'
            AND COLUMN_NAME=INFORMATION_SCHEMA.COLUMNS.COLUMN_NAME
            AND EXISTS
            (SELECT * FROM INFORMATION_SCHEMA.TABLE_CONSTRAINTS
            WHERE TABLE_NAME=@sTableName AND TABLE_SCHEMA='dbo' AND CONSTRAINT_TYPE = 'FOREIGN KEY'
            AND CONSTRAINT_NAME=INFORMATION_SCHEMA.KEY_COLUMN_USAGE.CONSTRAINT_NAME)
    ), 0)
) AS IsForeignKey, 
(
    ISNULL( 
    (   
        SELECT  1
        FROM    INFORMATION_SCHEMA.KEY_COLUMN_USAGE
        WHERE   TABLE_NAME=@sTableName AND TABLE_SCHEMA='dbo'
            AND COLUMN_NAME=INFORMATION_SCHEMA.COLUMNS.COLUMN_NAME
            AND EXISTS
            (SELECT * FROM INFORMATION_SCHEMA.TABLE_CONSTRAINTS
            WHERE TABLE_NAME=@sTableName AND TABLE_SCHEMA='dbo' AND CONSTRAINT_TYPE = 'UNIQUE'
            AND CONSTRAINT_NAME=INFORMATION_SCHEMA.KEY_COLUMN_USAGE.CONSTRAINT_NAME)
    ), 0)
) AS HasUniqueConstraint
FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME = @sTableName AND TABLE_SCHEMA='dbo'

Deze loopt dus over de 8 queries heen.

Kan iemand die MSDE heeft deze query even runnen en in het log kijken of de DBCC CONCURRENCYVIOLATION error optreedt bij het gebruik van deze query?

[jochemd]

ACM schreef op woensdag 18 mei 2005 @ 19:01:

Overigens zijn veel van de rariteiten van mysql nog steeds vrolijk in MySQL 4.1 aanwezig. Pas in MySQL 5.0 kan je bijvoorbeeld opgeven dat een tabel geen default waarde heeft als ie not null is... Ook in die versie worden pas waardes niet silenlty truncated/converted als er incorrecte data ingevoerd wordt. Als je als datumveld "dit is geen datum" invult, vindt MySQL 4.1 dat wel best, maakt ie er wel 0000-00-00 van, maar geeft je er geen melding over.

Recent kwam ik op mysql@ nog een juweeltje tegen over ambiguous identifiers in joins die gebruik maken van USING. "select pk from a inner join b using (pk);" zou ambiguous zijn (dat is hij niet), maar "select * from a inner join b using (pk) group by pk;" niet (en die is het juist wel). Hoe verzin je zoiets in godsnaam


Het bezwaar dat ik bij al deze features/bugs/slordige implementaties die keer op keer in MySQL opduiken heb is dat zo zo'n gigantische puinhoop creeren waar het gedrag in elke versie anders is. Keer op keer wordt er quick & dirty een feature geimplementeerd zodat er weer een extra regeltje aan de crash-me toegevoegd kan worden. En vervolgens blijkt de feature incompleet te zijn en wordt het gedrag in de volgende versie anders te zijn. En dan moet het gedrag nog een keer veranderd worden omdat men in alle haast even vergeten is dat men de database conform de standaard gaat maken.
Het beste voorbeeld hiervan is misschien nog wel het timestamp datatype. Voor 4.1 deed die compleet andere dingen dan in 4.1. En het gedrag is ook nog eens afhankelijk van de positie in de tabel. En van de opties waarmee MySQL is gecompileerd en gestart. En van de stand van de maan, het weer en de verstreken tijd sinds je voor het laatst een geit hebt geofferd.

Met een database die niet alle mogelijke features heeft kunnen we best leven (we hebben tenslotte niet allemaal een mainframe). Maar MySQL is de enige database die ik ken waar features structureel dusdanig geimplementeerd worden dat ze gegarandeerd backward compatibility problemen gaan opleveren bij de volgende stap in de reeds gepubliceerde roadmap. Genoemd probleem met USING (inmiddels bug 10646) bijvoorbeeld kan niet zonder backward compatibility problemen gerepareerd worden..
Niets dan lof zijn zeker niet de woorden waarmee ik MySQL zou beschrijven.

moet je nog steeds verplicht indices op foreign keys hebben (die kolom die je met references tabel(kolom)).

Dat is geen bug maar een feature. Zie ISO/IEC 9075-2:2003 11.8 Syntax Rule 3 (voor jou verkrijgbaar in de bibliotheek van de TU Delft).

[Verwijderd]

jochemd schreef op woensdag 18 mei 2005 @ 19:41:
En van de opties waarmee MySQL is gecompileerd en gestart. En van de stand van de maan, het weer en de verstreken tijd sinds je voor het laatst een geit hebt geofferd.

Betreft de MSDE, die mocht voor zover ik van een collega heb begrepen, die dit vorige week moest uitzoeken wel commercieel gebruikt worden zonder problemen.

[ACM]

jochemd schreef op woensdag 18 mei 2005 @ 19:41:
Dat is geen bug maar een feature. Zie ISO/IEC 9075-2:2003 11.8 Syntax Rule 3 (voor jou verkrijgbaar in de bibliotheek van de TU Delft).

(zie ondertitel)

Owja, ik noemde de verkeerde tabel. Die regel is inderdaad logisch, maar er zijn er twee:

quote: http://dev.mysql.com/doc/...eign-key-constraints.html

In the referencing table, there must be an index where the foreign key columns are listed as the first columns in the same order.

In the referenced table, there must be an index where the referenced columns are listed as the first columns in the same order.

[BertS]

P_de_B schreef op woensdag 18 mei 2005 @ 19:25:
[...]


Kan iemand die MSDE heeft deze query even runnen en in het log kijken of de DBCC CONCURRENCYVIOLATION error optreedt bij het gebruik van deze query?

Het lukt mij niet om die error te laten optreden (ik ken hem wel, maar dat is in een andere situatie waar idd meerdere users zitten).
Volgens mij is het gebaseerd op het aantal gelijktijdige queries dat wordt uitgeverd, en bovenstaande wordt dan als één query (batch) gezien.

Overigens, ter informatie: in SQL Server 2005 Express (de vervanger van MSDE) is deze beperking niet meer aanwezig. Daar is het aantal concurrent acties dus theoretisch onbeperkt. Nadeeltje is dan wellicht weer dat er maar 1 processor en max 1Gb geheugen wordt toegestaan.

[Verwijderd]

jochemd schreef op woensdag 18 mei 2005 @ 19:41:
[...]

Recent kwam ik op mysql@ nog een juweeltje tegen over ambiguous identifiers in joins die gebruik maken van USING. "select pk from a inner join b using (pk);" zou ambiguous zijn (dat is hij niet), maar "select * from a inner join b using (pk) group by pk;" niet (en die is het juist wel). Hoe verzin je zoiets in godsnaam

SQL:

select pk from tablea inner join tableb using (pk);

excuseer, maar bij mijn weten lukt zoiets ook niet in ORACLE. Ik kan je morgen indien gewenst de foutmelding geven maar zijn foutmelding meldt rechtstreeks dat je het veld van de join condition niet kan selecteren.

SQL:

select a.pk from tablea a inner join tableb b on a.pk = b.pk;

werkt dan weer wel... dus heb ik er een gewoonte van gemaakt in al m'n queries de on ... syntax te gebruiken.
Dus volgens mij kan je enkel zeggen dat de foutmelding nogal onduidelijk is, maar het moet toch ergens een reden hebben dat er nog andere DBMSen een dergelijke select niet aankunnen.


(voor die andere twijfel ik of het wel mag om een group by te doen zonder een aggregate function?)

[PhoneTech]

curry684 schreef op woensdag 18 mei 2005 @ 15:06:
[...]

Laat ik me dan bij de rest van de mensen in dit topic aansluiten en zeggen dat MySQL een baggerprodukt is, nu kun je iig nooit meer claimen dat je alleen maar lof over dat stuk wanstalt hoort

[...]

Als het binnen de concurrency margin valt en je een eigen bak aan internet hebt hangen absoluut de beste optie: voor commerciele hosting is licentietechnisch SQL Server Standard volgens mij per definitie verplicht (4999 dollar) dus dat heeft geen enkele hoster.

[...[

Interned Services (http://www.is.nl) biedt SQL hosting al aan vanaf 30 euro per maand, dus daar kan je geen buil aan vallen...

MySQL komt in mijn boekje nog altijd als een bagger product over. Vooral die irritante timestamp notatie heeft mij heel wat kopzorgen bezorcht. Effe overgaan tussen versies zit er niet bij. (hoewel ik nu ook veel problemen met Oracle 10g heb, maar daar heb ik een ander topic over...)

[jochemd]

Verwijderd schreef op woensdag 18 mei 2005 @ 21:25:

SQL:

select pk from tablea inner join tableb using (pk);

excuseer, maar bij mijn weten lukt zoiets ook niet in ORACLE. Ik kan je morgen indien gewenst de foutmelding geven maar zijn foutmelding meldt rechtstreeks dat je het veld van de join condition niet kan selecteren.

Dan is Oracle dus ook brak. Joins die gebruik maken van USING of NATURAL horen in de resultset de originele kolommen uit elke tabel weggegooid te hebben en vervangen te hebben door een gemergde kolom zonder een tabel prefix. Oftewel:

code:

a: pk, X
b: pk, Y, Z

SELECT * FROM a NATURAL JOIN b        ->  pk, a.X, b.Y, b.Z
SELECT * FROM a JOIN b USING (pk)     ->  pk, a.X, b.Y, b.Z
SELECT * FROM a JOIN b ON a.pk = b.pk ->  a.pk, a.X, b.pk, b.Y, b.Z

SQL:

select a.pk from tablea a inner join tableb b on a.pk = b.pk;

werkt dan weer wel... dus heb ik er een gewoonte van gemaakt in al m'n queries de on ... syntax te gebruiken.

Dat hoort ook te werken.

(voor die andere twijfel ik of het wel mag om een group by te doen zonder een aggregate function?)

Dat is de reden dat ik schrijf dat het niet klopt. Maar daarnaast kan je natuurlijk zeggen dat het nogal vreemd is dat hier een unqualified pk wel mag maar in het originele voorbeeld niet.

[P_de_B]

bee-es schreef op woensdag 18 mei 2005 @ 20:15:
[...]

Het lukt mij niet om die error te laten optreden (ik ken hem wel, maar dat is in een andere situatie waar idd meerdere users zitten).
Volgens mij is het gebaseerd op het aantal gelijktijdige queries dat wordt uitgeverd, en bovenstaande wordt dan als één query (batch) gezien.

Kijk, dat maak ik ook op uit de documentatie. Een batch van SQL statements worden als 1 operatie gezien. ik zal wel eens wat gaan testen. Ik neem aan de eFBe niet gaat liegen over zijn ervaringen

[justmental]

Waarom lijkt de pijn altijd weer in de licentiekosten te zitten?

Wat is de levensduur van de applicatie? Wat is de benodigde beheerinspanning? Hoe worden de ontwikkelkosten beinvloedt? Welke infrastructuur heb je nodig?
Licentiekosten zijn over het algemeen maar een klein deel van de kosten aan een systeem.

[P_de_B]

justmental schreef op donderdag 19 mei 2005 @ 08:24:
Waarom lijkt de pijn altijd weer in de licentiekosten te zitten?

Wat is de levensduur van de applicatie? Wat is de benodigde beheerinspanning? Hoe worden de ontwikkelkosten beinvloedt? Welke infrastructuur heb je nodig?
Licentiekosten zijn over het algemeen maar een klein deel van de kosten aan een systeem.

True, maar als het gaat om kleinschalige (hobby-)projecten is het wat anders. Ik kan me voorstellen dat je daar geen SQL Server Enterprise licentie a 20K voor gaat gebruiken. Zaken als beheer en ontwikkeltijd kun je dan alleen meten in je eigen vrije tijd.

Voor zakelijke projecten kan ik je alleen maar gelijk geven.

[Boss]

Heb niet het hele topic gelezen, maar wil nog even een ander idee aankaarten:

Als het om een aantal enquetes gaat, kan je inderdaad zelf een mooi systeem daarvoor ontwikkelen. Je kan het echter ook via een reeds bestaande online-enquete-service doen. Scheelt je een heleboel werk, en waarschijnlijk dus ook kosten.

Een vriendin van mij heeft voor haar scriptie een heleboel enquetes moeten afnemen, en dat hebben we toen via www.formdesk.nl gedaan. Goeie service, goeie prijs en een hele mooie enquete. Hebben (serieus!) een hoop reacties gehad van een hoop deelnemers dat de enquete goed in elkaar zat.

Dus.... misschien is het iets voor TS?

[BertS]

P_de_B schreef op donderdag 19 mei 2005 @ 08:27:
[...]


True, maar als het gaat om kleinschalige (hobby-)projecten is het wat anders. Ik kan me voorstellen dat je daar geen SQL Server Enterprise licentie a 20K voor gaat gebruiken. Zaken als beheer en ontwikkeltijd kun je dan alleen meten in je eigen vrije tijd.

Voor zakelijke projecten kan ik je alleen maar gelijk geven.

Tja, wat versta je dan onder een zakelijk project.

Voor een bedrijfje met 10 gebruikers, is het imo een hoop geld om SQL Server aan te schaffen + 10 CAL's

[P_de_B]

bee-es schreef op donderdag 19 mei 2005 @ 08:32:
[...]

Tja, wat versta je dan onder een zakelijk project.

Voor een bedrijfje met 10 gebruikers, is het imo een hoop geld om SQL Server aan te schaffen + 10 CAL's

Ja, maar dan geldt al snel wat justmental bedoelde. Onderhoud, support, ontwikkelkosten en dataverlies kan veel duurder zijn dan de eenmalige licentiekosten van een echte database. Je moet bij het bepalen van de kosten van zo'n systeem niet alleen kijken naar de initiele kosten.

http://www.microsoft.com/sql/howtobuy/default.asp

SQL Server 2000 standard edition kost US$ 2250,= met 10 CAL's. In een ontwikkeltraject is dat niet zoveel hoor.

[EfBe]

P_de_B schreef op donderdag 19 mei 2005 @ 08:11:
Kijk, dat maak ik ook op uit de documentatie. Een batch van SQL statements worden als 1 operatie gezien. ik zal wel eens wat gaan testen. Ik neem aan de eFBe niet gaat liegen over zijn ervaringen

Heh Maar, omdat je die error niet krijgt hoeft het niet zo te zijn dat de query niet vertraagd wordt. Is de query nl. traag vergeleken bij een normale sqlserver? Hier scheelde dat dus dag en nacht. Ik kan dat alleen maar verklaren met die debiele limiet die in msde zit.

Overigens is een batch wat anders: dat is select... ;select...;select....;insert...;

[ Voor 8% gewijzigd door EfBe op 19-05-2005 09:18 ]

[P_de_B]

EfBe schreef op donderdag 19 mei 2005 @ 09:18:
[...]

Heh Maar, omdat je die error niet krijgt hoeft het niet zo te zijn dat de query niet vertraagd wordt. Is de query nl. traag vergeleken bij een normale sqlserver? Hier scheelde dat dus dag en nacht. Ik kan dat alleen maar verklaren met die debiele limiet die in msde zit.

Overigens is een batch wat anders: dat is select... ;select...;select....;insert...;

Nou, in de docs staat dat als de limiet bereikt is -en er expres gewacht wordt door de engine- deze foutmelding in de logs moet staan.

[Verwijderd]

jochemd schreef op woensdag 18 mei 2005 @ 22:39:
heel verhaal...

mijn excuses, ik heb het net even getest en het blijkt gewoon gelul van mijnentwege


select el_cd from tabb inner join taba using(pk)

werkt WEL

maar

select b.el_cd from tabb b inner join taba a using(pk)

geeft ORA-25154 (column part of USING clause cannot have qualifier)

Dus dat lijkt inderdaad wel correct te zijn adhv jouw uitleg

[BKJ]

P_de_B schreef op donderdag 19 mei 2005 @ 08:44:
[...]


Ja, maar dan geldt al snel wat justmental bedoelde. Onderhoud, support, ontwikkelkosten en dataverlies kan veel duurder zijn dan de eenmalige licentiekosten van een echte database. Je moet bij het bepalen van de kosten van zo'n systeem niet alleen kijken naar de initiele kosten.

http://www.microsoft.com/sql/howtobuy/default.asp

SQL Server 2000 standard edition kost US$ 2250,= met 10 CAL's. In een ontwikkeltraject is dat niet zoveel hoor.

Weet je wat het is? Sinds de komst van internet zie je gewoon veel zgn. nerds (niet hier toch? ) in hun eentje op een zolderkamer zonder veel geld (sterker nog: geen, want alles is opgegaan aan de laatste techniek in CM) site en apps bouwen die niet teveel mogen kosten (liever: niets). En wat is daar geschikt voor als er een DB achterhangt? Juist, een opensource DB zoals bv MySQL.

Op zich is dat niet erg, en ik denk ook dat dat het succes is van mySQL, maar ze moeten ook niet zeuren dat als ze van zolderkamer naar kantoor gaan met BMW voor de deur (no offence, femme) dat er op een goeie dag of een crash zich voordoet (BC3?) of de app of website zo complicated wordt dat de structuur of ingebouwde features van een opensource DB niet meer toereikend zijn.

Daarbij is het ook denk ik zo dat commerciële DB's veel klanten hebben die ooit op een zolderkamer zijn begonnen met een opensource DB en nu functionaliteit, support, rollbacking en stabiliteit willen. (kortom: het wordt tijd dat tweakers overgaat op windows bakken )

[P_de_B]

offtopic:
Ik neem aan dat waar je opensource schrijft je eigenlijk gratis bedoelt?

[curry684]

hitchhacker schreef op donderdag 19 mei 2005 @ 09:47:
[...]

Daarbij is het ook denk ik zo dat commerciële DB's veel klanten hebben die ooit op een zolderkamer zijn begonnen met een opensource DB en nu functionaliteit, support, rollbacking en stabiliteit willen. (kortom: het wordt tijd dat tweakers overgaat op windows bakken )

Geinig detail overigens hierbij is dat het zelfs wel eens min of meer serieus besproken is In de situatie van Tnet geldt echter al heel snel dat de bestaande oplossing nog perfect voldoet en alleen het migratietraject in manuren al te duur zou zijn tegenover te verwachten winst op middellange termijn

P_de_B schreef op donderdag 19 mei 2005 @ 08:44:
[...]

http://www.microsoft.com/sql/howtobuy/default.asp

SQL Server 2000 standard edition kost US$ 2250,= met 10 CAL's. In een ontwikkeltraject is dat niet zoveel hoor.

Voor internetsites heb je overigens per definitie een processor license a $4999 nodig. Slimme inkopers passen dan wel een mouw aan die prijzen

[ Voor 30% gewijzigd door curry684 op 19-05-2005 10:33 ]

[Verwijderd]

En een PostgreSQL? Ik kan me het financiële aspect echt wel voorstellen, maar je investering van jaren op een MySQL configuratie, poeh.

[wizzkizz]

PhoneTech schreef op woensdag 18 mei 2005 @ 21:55:
[...]


Interned Services (http://www.is.nl) biedt SQL hosting al aan vanaf 30 euro per maand, dus daar kan je geen buil aan vallen...

Het hostingbedrijf waar ik mee samenwerk, heeft het al vanaf 10 euro per maand (http://www.webstekker.nl/ms-sql.php). Dus ook voor een niet zo heel grote db die wel rock-solid moet zijn lukt het best wel om MSSQL te nemen.

[_JGC_]

Verwijderd schreef op woensdag 18 mei 2005 @ 12:37:
[...]


Hmm ga ik eens testen ! top ! en jah das wel de opzet, ASP en MySQL combineren om gebruik te maken van die database variant .... het is de enige variant waar ik niet meer dan lof over hoor .... MSDE en PostgreSQL hoor ik mensen niet eg heel blij mee zijn ....

en voor zover ik weet heeft oracle geen vrije versie .... maar durf ik nie 100% zeker te zegge

MSSQL is gewoon een goede database (goh dat ik dat als niet-MS fan zeg, maar MSSQL is dus de database waar ik de minste problemen mee heb ondervonden ), MSDE is gewoon een lite-versie die minder concurrent users aankan.

Over PostgreSQL: Waarom niet tevreden erover? Tuurlijk, het ding is niet zo simpel als MySQL en daarom niet zoveel gebruikt, maar het is de meest geavanceerde opensource database die er bestaat met zowat alle features die je zou willen. Als ik moet kiezen tussen MySQL en PostgreSQL, ga ik sowieso voor PostgreSQL, omdat MySQL nu pas met developer releases komt waar functies inzitten die PostgreSQL al kent sinds de eerste versie.

[_JGC_]

hitchhacker schreef op donderdag 19 mei 2005 @ 09:47:
[...]


Weet je wat het is? Sinds de komst van internet zie je gewoon veel zgn. nerds (niet hier toch? ) in hun eentje op een zolderkamer zonder veel geld (sterker nog: geen, want alles is opgegaan aan de laatste techniek in CM) site en apps bouwen die niet teveel mogen kosten (liever: niets). En wat is daar geschikt voor als er een DB achterhangt? Juist, een opensource DB zoals bv MySQL.

Op zich is dat niet erg, en ik denk ook dat dat het succes is van mySQL, maar ze moeten ook niet zeuren dat als ze van zolderkamer naar kantoor gaan met BMW voor de deur (no offence, femme) dat er op een goeie dag of een crash zich voordoet (BC3?) of de app of website zo complicated wordt dat de structuur of ingebouwde features van een opensource DB niet meer toereikend zijn.

Daarbij is het ook denk ik zo dat commerciële DB's veel klanten hebben die ooit op een zolderkamer zijn begonnen met een opensource DB en nu functionaliteit, support, rollbacking en stabiliteit willen. (kortom: het wordt tijd dat tweakers overgaat op windows bakken )

Als jij gewoon backups maakt van je database, zal iets als BC3 niet gebeuren. Echter als jij je RAID sets als RAID-0 configureert ipv RAID-1, en dat niet op tijd ziet, en je backups al dagen of maanden of zelfs meerdere maanden niet lukt, dan heb je een probleem op het moment dat jij je disk tegen de vlakte smijt tijdens een serverombouw. Kan een profi database niets aan doen.

Verder is MySQL nooit ontworpen als database met alle enterprise features die je zou willen, MySQL is ontworpen om als simpele database voor de simpele gebruiker zo snel mogelijk data te kunnen verwerken. Uiteindelijk is dat ding het populaire databeest geworden voor website prutsprojectjes. Als je niet genoeg hebt aan de features van MySQL, moet je gewoon kijken naar iets anders, zoals MSSQL, Oracle, Sybase of PostgreSQL. MySQL is gewoon betrouwbaar in waar het voor gemaakt is.

[ACM]

hitchhacker schreef op donderdag 19 mei 2005 @ 09:47:
Op zich is dat niet erg, en ik denk ook dat dat het succes is van mySQL, maar ze moeten ook niet zeuren dat als ze van zolderkamer naar kantoor gaan met BMW voor de deur (no offence, femme) dat er op een goeie dag of een crash zich voordoet (BC3?) of de app of website zo complicated wordt dat de structuur of ingebouwde features van een opensource DB niet meer toereikend zijn.

Femme heeft geen BMW hoor
En de term "opensource DB" vindt ik nogal onjuist toegepast. Je doelt op MySQL, gebruik dan de term MySQL. Want Firebird en PostgreSQL zijn ook OS-DB's, en die bieden veel van de functionaliteit die MySQL mist wel.

Daarbij is het ook denk ik zo dat commerciële DB's veel klanten hebben die ooit op een zolderkamer zijn begonnen met een opensource DB en nu functionaliteit, support, rollbacking en stabiliteit willen. (kortom: het wordt tijd dat tweakers overgaat op windows bakken )

We hebben een keer serieus gekeken naar Sybase, zij wilden wel een interessante deal voor ons maken. Kwam er toen op neer dat we dan alsnog enkele jaarsalarissen kwijt waren als we er failure-takeover/loadbalancing bij wilden, ondanks de mooie deal...
Bovendien missen de meeste "serieuze databases" die ik heb bekeken de eenvoudige "lange tekst"-support (het text-veld dus) die MySQL en PostgreSQL wel bieden.

Maar de belangrijkste reden dat we ondertussen niet zo gauw meer op een ander DBMS zullen overstappen is het simpele feit dat veel queries voor MySQL zodanig zijn geoptimaliseerd dat ze op elke andere DB een performance-drama worden... Dat moet dus herschreven worden, inclusief in sommige gevallen de complete structuur hoe data opgevraagd wordt in de php-code (meer in één query doen, ipv "moeilijke dingen" opsplitsen in losse queries).

Overigens is een overstap naar windows vziw nooit echt serieus overwogen. Voor de stabiliteit en beheersbaarheid zie ik er iig geen enkele reden toe.

[djc]

_JGC_ schreef op donderdag 19 mei 2005 @ 13:38:
Verder is MySQL nooit ontworpen als database met alle enterprise features die je zou willen, MySQL is ontworpen om als simpele database voor de simpele gebruiker zo snel mogelijk data te kunnen verwerken. Uiteindelijk is dat ding het populaire databeest geworden voor website prutsprojectjes. Als je niet genoeg hebt aan de features van MySQL, moet je gewoon kijken naar iets anders, zoals MSSQL, Oracle, Sybase of PostgreSQL. MySQL is gewoon betrouwbaar in waar het voor gemaakt is.

Volgens mij zijn er ook wel features die in MySQL beter beschikbaar / meer geïntegreerd zijn dan in Postgres, bijvoorbeeld de Cluster-functionaliteit.

[DaCoTa]

curry684 schreef op woensdag 18 mei 2005 @ 15:22:
[...]
Da's bull. Oracle heeft wel een transactionlog die je per transaction kunt rollbacken, evenals SQL Server. Veel plezier met MySQL Tevens kun je de Enterprise DBMS'en wel bruikbaar replicaten, op federated servers zetten, gescheiden datafiles en logfiles over meerdere disk subsystems spannen, binary columns in losse datafiles afsplitsen, en ga zo maar door. Een goed ingericht EDBMS is stukken moeilijker plat te krijgen dan een MySQL-installatie... maar daar komt de kwaliteit van de beheerder ook vaak om de hoek kijken.

Nog even hierop verder:

Met goed databeheer kom je idd met Oracle een gigantisch stuk verder vergeleken met MySQL.

Maar in de 2 jaar die ik nu met Oracle heb gewerkt heb ik een productieomgeving stuk zien lopen op een Oracle fatal error, waarbij de database niet meer in de lucht te brengen was, laat staan dat er nog iets met de transaction logging te doen was. Nadat Oracle support kwam met de melding: "Sorry, wij weten niet wat er aan de hand is, u bent de eerste die met die foutmelding komt, heeft u een backup die u terug kunt zetten?" konden we niks anders dan de laatste dagelijkse full backup terugzetten.

Daarnaast heb ik in de ontwikkelomgeving ontelbare malen Oracle gewoon zien stoppen op fatal errors vanwege ik weet niet wat allemaal voor oorzaken. Ik denk dat ik onderhand 20 verschillende ORA meldingen heb verzameld die - als je ze in google stopt - terugkomen met 5 vage meldingen op taiwanese pagina's. En volgens mij doe ik niet echt veel bijzonders met die database. (Voor de goede orde: Oracle 9.2.0.1, de laatste incarnatie van 9 op het windows platform.)

Helaas zijn wij in die omgeving niet gezegend met goede dba'ers, maar ik wil in dit geval de schuld niet zomaar in hun schoenen schuiven. Sinds deze incidenten ben ik wel wat genuanceerder gaan denken over het product Oracle. Ook daarmee kan het zomaar stuklopen.

[ Voor 3% gewijzigd door DaCoTa op 20-05-2005 14:03 ]

[ACM]

Manuzhai schreef op vrijdag 20 mei 2005 @ 08:47:
Volgens mij zijn er ook wel features die in MySQL beter beschikbaar / meer geïntegreerd zijn dan in Postgres, bijvoorbeeld de Cluster-functionaliteit.

Volgens mij zijn er twee dingen die wel in MySQL en niet in PostgreSQL geintegreerd zijn, de full text search en de slave/single-master replication.
Voor beide zijn bij PostgreSQL wel third-party (of meer second-and-a-half-party) oplossingen, met name voor replicatie zijn er meerdere. Sinds kort zijn er ook diverse multi-master oplossingen voor replicatie bij PostgreSQL, iets dat MySQL nog altijd mist.

Overigens is die cluster-functionaliteit niet (echt/volledig) geintegreerd in MySQL, maar werkt dat met allerlei externe deamons.
De functionaliteit oogt wel leuk, maar de data moet in het ram-geheugen van de storage servers staan en in ons geval zouden we dan iets van 48GB netto aan RAM beschikbaar moeten hebben voor onze databases... Wellicht dat we na wat geklooi met tabellen die wat minder relevant zijn voor de performance we aan 32GB genoeg zouden hebben, maar de functionaliteit mist dus nog wel het een en ander om het vooralsnog echt bruikbaar te maken. Daarnaast is het opslaan in RAM-geheugen natuurlijk niet bijster handig in termen van stabiliteit en beschikbaarheid. Daarbij komt ook nog dat alle records in dat ramgeheugen in hun maximale veldlengte worden opgeslagen. Sla je dus een text field op, dan wordt die sowieso 64KB groot aan opslag, ook al zit er maar 1KB aan tekst in... En daardoor zouden wij bruto misschien zelfs wel 128GB of meer aan RAM-geheugen moeten hebben voor de opslag van onze databases in die clustering-oplossing.
Als je alleen maar kleine fixed-size records opslaat is dat een minder relevante issue.