Archief - Welke database?
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
adrianhates
Legacy Member
Webber zei:
offtopic , hoe komt ge daarbij? Das gewoon het voordehandst liggende en makkelijkste omdat de PDO layer nogal vrij geavanceerd is.
Ni zo heel veel ervaring met ASP.NET maar ook alleen nog maar MS SQL Server gebruikt en dat ging toch ook heel vlotjes. Die ondersteuning zit dan ook direct in Visual Studio.
dJeez
Legacy Member
Dat hangt puur van het gebruik van je website af. Als je uitsluitend (of zo goed als enkel) selects uitvoert dan zal MySQL bijna steeds winnen. Replicatie is bij MySQL ook veel beter dan bij PostgreSQL (cfr. MySQL vs PostgreSQL - WikiVS), qua schaalbaarheid zijn ze zo goed als evenwaardig.Curahee Q zei:
Maar daar staat dan weer tegenover dat MySQL echt vreemde dingen toelaat die quasi geen enkel ander rdbms zou toelaten, met ook wel vreemde resultaten als gevolg... Het wordt pas erg als mensen er dan vanuit gaan dat wat ze doen correct is (en uiteindelijk moeten vaststellen dat hun code totaal niet portable is
).En om een bommetje te droppen : je kan in MySQL met InnoDB en gedefinieerde foreign keys zonder enig probleem inconsistente data opladen door helemaal in 't begin een SET FOREIGN_KEY_CHECKS=0; te zetten. Als je dan een SET FOREIGN_KEY_CHECKS=1; uitvoert gaat hij vanaf dan wel terug beginnen testen voor alle komende updates/inserts, maar de huidige (inconsistente) data blijft gewoon mooi waar die zit. Persoonlijk vind ik dat niet echt denderend...
wonko
Legacy Member
(
Op zich prima gedocumenteerd, heeft zijn nut (zowel qua snelheid als het inladen van data in een willekeurige volgorde) en hier zou ik geen database-server op afrekenen.)
Al bij al zijn voor 99% van alle projecten die op gewone shared hosting draaien de DB die eronder gezet wordt van weinig belang. Meestal is de dataset, de belasting en de query-ing zo simpel dat elk rdbms er prima overweg mee kan, ofwel gaan elk rdbms onderuit omdat de nieuwbakken code-quote-guru-unquote nog nooit van indexen, joins of optimalisatie heeft gehoord.
Als je een "speciaal" project hebt, met speciale noden op DB gebied, ga je meestal toch even goed nadenken en onderzoeken welk rdbms systeem de meeste voordelen biedt, en gaat heel je setup staan of vallen met een goede samenwerking van code, db-server, hardware,...
dJeez zei:
Op zich prima gedocumenteerd, heeft zijn nut (zowel qua snelheid als het inladen van data in een willekeurige volgorde) en hier zou ik geen database-server op afrekenen.)
Al bij al zijn voor 99% van alle projecten die op gewone shared hosting draaien de DB die eronder gezet wordt van weinig belang. Meestal is de dataset, de belasting en de query-ing zo simpel dat elk rdbms er prima overweg mee kan, ofwel gaan elk rdbms onderuit omdat de nieuwbakken code-quote-guru-unquote nog nooit van indexen, joins of optimalisatie heeft gehoord.
Als je een "speciaal" project hebt, met speciale noden op DB gebied, ga je meestal toch even goed nadenken en onderzoeken welk rdbms systeem de meeste voordelen biedt, en gaat heel je setup staan of vallen met een goede samenwerking van code, db-server, hardware,...
Curahee Q
Legacy Member
adrianhates
Legacy Member
dJeez zei:
Is dit dan niet het geval bij de MyISAM engine? ( Ik heb echt geen zin om da te testen ze
, zou wel straf zijn) Kgebruik altijd gewoon MyISAM, heb mij daar anderzijds ook nog niet al te veel vragen bij gesteld qua performantie. Kgan wel dringend moeten overschakelen naar innodb voor transactions volledig te kunnen benutten, nu haddek daar men eigen shit voor geschreven .Onlangs in die MySQL 5 certification guide nog gelezen dat indexen wegvallen bij LIKE's, Foreign keys kunnen gelegd worden in MyISAM maar worden straal genegeerd etc... Da zijn ook allemaal zoon kleine dingen die in totaal wel een verschil maken..
Als ge toch MySQL 5 zou gebruiken is dit wel handig om te lezen , zeker als ge een zwaar geladen DB gebruikt met veel queries.
5.0 http://dev.mysql.com/doc/refman/5.0/en/optimization.html
5.1 http://dev.mysql.com/doc/refman/5.1/en/optimization.html
5.5 http://dev.mysql.com/doc/refman/5.5/en/optimization.html
wonko
Legacy Member
Indexen worden pas onbruikbaar bij "LIKE '%zoekstring'" dingen. Een index is meestal opgebouwd met een BTree als datastructuur. Elke bit/byte zorgt voor een afdaling in de tree, en op het eind zit er een referentie naar de rijen die voldoen aan de index.
Wanneer je nu echter een wildcard meegeeft als eerste karakter, kan de b-tree niet afgedaald worden.
Vergelijk het met het doorzoeken van een telefoonboek naar iedereen waarvan de naam eindigt op "damme", of "deh" bevat. De index (het alfabetisch gesorteerd zijn) helpt je hier niet om sneller op te zoeken. Hetzelfde probleem vind je bij index-gebruik met %iets(%).
Alles met indexen en snelle queries is eigenlijk vrij eenvoudig, eens je wat weet hoe het onder de motorkap werkt.
Wanneer je nu echter een wildcard meegeeft als eerste karakter, kan de b-tree niet afgedaald worden.
Vergelijk het met het doorzoeken van een telefoonboek naar iedereen waarvan de naam eindigt op "damme", of "deh" bevat. De index (het alfabetisch gesorteerd zijn) helpt je hier niet om sneller op te zoeken. Hetzelfde probleem vind je bij index-gebruik met %iets(%).
Alles met indexen en snelle queries is eigenlijk vrij eenvoudig, eens je wat weet hoe het onder de motorkap werkt.
woony
Legacy Member
heb het niet helemaal gelezen,
maar de meest voor de handliggende keuze is MSSql, ook om te ontwikkelen in uw Visual studio. Heb zo onderhand al genoeg tegengekomen als je iets wat anders gebruikt dan M$ het voorzien heeft je wel met problemen geraakt sooner or later. Dus als je kunt kiezen gebruik toch maar MSSQL vind ik persoonlijk wel een zeer goede db en samen met Management Studio zeer makkelijk te gebruiken.
maar de meest voor de handliggende keuze is MSSql, ook om te ontwikkelen in uw Visual studio. Heb zo onderhand al genoeg tegengekomen als je iets wat anders gebruikt dan M$ het voorzien heeft je wel met problemen geraakt sooner or later. Dus als je kunt kiezen gebruik toch maar MSSQL vind ik persoonlijk wel een zeer goede db en samen met Management Studio zeer makkelijk te gebruiken.
metalleke
Legacy Member
woony zei:
"Zeer goede BD", hangt af in welke gevallen eh. Als je enige eis is dat het goed samenwerkt met .NET / Visual Studio ga dan maar voor MSSQL.
wonko zei:
Afhankelijk van welke db je gaat gebruiken zijn hiervoor (in de nieuwere versies) toch al alternatieven voor.
Cycloon
Legacy Member
wonko zei:
Op zich valt het wel mee om dat te doorzoeken. Je moet gewoon niet starten van de root maar van het niveau n-length(zoekstring). Je zal dan gewoon meer subtrees hebben om te onderzoeken, maar dat zou geen probleem mogen vormen, je gaat hier zelf geen lineaire vertraging door bekomen.
Overigens zijn databanken zeer complexe systemen omdat daar heel wat technieken in gebruikt worden om zowel het zoeken te versnellen als opslagruimte te winnen. Weinig databanken zullen nog simpele btrees gebruiken, er zijn betere alternatieven.
adrianhates zei:Hebt ge misschien schoon linkskes waar al die 'onder de motorkap'-uitleg zit?
Zoek een degelijk boek die handelt over algoritmen die zoeken in strings, er zijn héél veel verschillende technieken, elk met hun eigen voor- en nadelen. Elke databank gebruikt dan ook zijn eigen systemen, daarom dat ze allemaal verschillende kenmerken hebben.
dJeez
Legacy Member
Dat het zijn nu heeft en vermeld staat in de documentatie ga ik niet ontkennen, maar het is wel vreemd dat als je zegt : "check de foreign keys nu maar", dat die dan niet ff snel nakijkt of de data die momenteel al in de DB zit wel consistent is. Ik heb er ooit een stored procedure voor gevonden die dat afcheckt (vind die nu niet direct meer terug). Maar noem mij eens 1 andere DB die effectief toelaat van foreign key constraints te overtreden? Ik ken er geen...wonko zei:
MySQL heeft zeker zijn nut (anders zou ik het niet gebruiken), maar er zijn toch wel rariteiten, en het grootste probleem zijn wel die waarbij MySQL totaal geen fout teruggeeft maar probeert te raden wat je wil en dan maar wat potentieel foutieve data in de DB steekt. Dat yapf lijstje geeft er een goed overzicht van, hoewel ik al 1 ding zie dat ontbreekt : je kan een tabel die gebruikt wordt in een view zonder enig probleem droppen. Dat zorgt er dan voor dat je ineens geen volledige backup van je DB kan maken (aangezien die view nu verwijst naar een onbestaande tabel en de DB daar dan ineens wel over valt). Dit heb ik aan den lijve ondervonden
.wonko
Legacy Member
@Djeez: De fouten in MySQL zijn niet goed te praten, en ga ik zeker niet doen. Veel van de rariteiten zijn het gevolg van het initiële doel van MySQL (een eenvoudige en snelle DB-server maken) en dus een erfenis uit het verleden. Het staat iedereen vrij om een andere DB-server te kiezen, als je echter kiest voor MySQL moet je er enkele rariteiten bijnemen.
bvb het kunnen uitschakelen van de FK checks is een feature met een duidelijk doel; gebruik hem dan enkel daarvoor. Het zijn extra tools en die komen met verantwoordelijkheden voor de gebruiker. Het is gedocumenteerd, en anders komen we in situaties zoals de meldingen op mircogolfovens dat je er geen dieren mag insteken, of handleidingen bij tandenstokers...
Gelukkig is er een goede development-staff en luisteren ze naar de community zoals bvb de invoering van de strict-mode om mysql meer "standaard-compliant" te maken. (Met heel het Monty/Maria en MySQL debacle is het natuurlijk nu wel afwachten hoe alles gaat lopen.)
@cycloon n-th level is niet altijd mogelijk (denk niet gebalanceerde bomen, of aan %iets%). Zoeken op stringdata zou hoe dan ook altijd met specifieke methoden opgelost moeten worden, afhankelijk van je data (fulltext indexen, externe indexers,...), of door je data anders te structureren.
(en ja, ik weet wel dat het intern geen eenvoudige en simpele BTree of hash is, maar anders ging m'n uitleg flink afdwalen)
bvb het kunnen uitschakelen van de FK checks is een feature met een duidelijk doel; gebruik hem dan enkel daarvoor. Het zijn extra tools en die komen met verantwoordelijkheden voor de gebruiker. Het is gedocumenteerd, en anders komen we in situaties zoals de meldingen op mircogolfovens dat je er geen dieren mag insteken, of handleidingen bij tandenstokers...
Gelukkig is er een goede development-staff en luisteren ze naar de community zoals bvb de invoering van de strict-mode om mysql meer "standaard-compliant" te maken. (Met heel het Monty/Maria en MySQL debacle is het natuurlijk nu wel afwachten hoe alles gaat lopen.)
@cycloon n-th level is niet altijd mogelijk (denk niet gebalanceerde bomen, of aan %iets%). Zoeken op stringdata zou hoe dan ook altijd met specifieke methoden opgelost moeten worden, afhankelijk van je data (fulltext indexen, externe indexers,...), of door je data anders te structureren.
(en ja, ik weet wel dat het intern geen eenvoudige en simpele BTree of hash is, maar anders ging m'n uitleg flink afdwalen)
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.