advies over database structuur

woensdag 13 november 2013 21:52

Admin Devschuur®

^ Romeinse Ⅲ ja!

Behalve dat iedereen je hier zal afraden naar 3500 tabellen te gaan is er, met de karige informatie die je eigenlijk in een heleboel wol hebt gestopt, weinig zinnigs te zeggen. Begrijp me niet verkeerd, maar je lijkt me 't type projectmanager of whatevermanager die dit op z'n bordje geschoven heeft gekregen en nu probeert te roeien met de riemen die hij/zij heeft. Daar is niets mis mee, maar je zult heel wat dieper moeten gaan en heel wat meer informatie moeten bieden willen we enigszins iets nuttigs bij kunnen dragen in deze kwestie.

Het feit dat er alleen maar naar aantallen records en "kolommen" wordt gekeken en er overwogen wordt tabellen per klant te maken zegt eigenlijk al genoeg (en don't get me wrong; er zijn situaties waarin dat te rechtvaardigen is, maar je zult waaaay voor die tijd eerst indexes gaan analyzeren/optimaliseren, normaliseren (en mogelijk denormaliseren), read/write locks optimaliseren, partitioning overwegen etc. etc. voordat je daar ooit bij uit komt). Geen enkel fatsoenlijk RDBMS wordt warm van +/- 10M records, ook al heb je die 10x in 20 tabellen; mits goed ingericht. Wat betreft de XML bestanden 'tzelfde: Als je, om even van je max uit te gaan, 5000 XML bestanden per dag verwerkt (en laten we dan even geen 24 uur maar 8 uur aanhouden) dan is 't nog steeds maar 1 XML bestand per 5 à 6 seconden. Nu weet ik niet hoe groot / complex zo'n bestand is (en dus weer geen echte indicatie over de daadwerkelijke load af te leiden) maar, hell, hoeveel kun je vertellen over een auto? Zo spannend kan die XML nou ook weer niet zijn. Afgaand op m'n water kan ik je met redelijke zekerheid vertellen dat daar zelfs een oude laptop met een 486 nog niet warm of koud van wordt (so to speak

).

Mocht je iemand in dienst hebben die, bij wijze van, "in the trenches" zit en zich daadwerkelijk met de DB / programmeren bezig houdt dan laat diegene hier eens even komen babbelen. En mocht ik je verkeerd geïnterpreteerd hebben en je bent daadwerkelijk zelf diegene: kom dan a.u.b. over de brug met info waar we iets mee kunnen

Uiteindelijk houdt het overigens ook hier, "aan onze kant", een keer op: om tot de beste oplossing voor je probleem te komen zul je, in the end, zélf moeten gaan meten waar de bottleneck(s) zich bevinden. Meten == weten. Eens die bottlenecks gevonden zijn kun je gericht gaan zoeken naar een oplossing(en). En dat is niet iets wat wij hier kunnen doen; we kunnen hooguit meedenken en gissen en je meetresultaten (mee) helpen interpreteren.

Verder: ik heb je startpost ontdaan van alle linkjes/namedropping. Voor je probleem is 't totaal niet relevant hoe jullie heten, wie jullie partners zijn, wat jullie websites zijn etc. en 't komt nogal spammerig over

[edit]

Ik had natuurlijk ook even in je profiel kunnen kijken i.p.v. gissen

Maar goed, ondanks dat daar "IT Manager" staat is daarmee nog niet uitgesloten dat je knee-deep in de code/database zit

[ Voor 17% gewijzigd door RobIII op 13-11-2013 22:40 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij

Acties:

BasieP

Afhankelijk van je database is het soms duur om rijen te verwijderen. Je kunt vaak beter een kolom toevoegen die zegt dat een record 'weg' is, en 1x per uur ofzo een keer een batch delete doen ("delete form tabel where logishverwijderd = 1" of iets in die geest)

Verder weet ik niet of je insert voor insert los in de DB zet, maar dat kun je ook batchgewijs oppakken door dingen te doen als

SQL:

1	insert into tabel values('data', 1, 'data', etc.), ('data2', 2 'data2', etc.), etc.

en ik ben het met die mensen hierboven eens:

Met de eisen die je hierboven zegt kan ik dit draaien op mijn 4 gig intern thuispctje...
het is allemaal niet heel spannend wat je roept.
De vraag is of er niet ergens een hele rare domme bottleneck zit.

[ Voor 20% gewijzigd door BasieP op 13-11-2013 21:54 ]

This message was sent on 100% recyclable electrons.

woensdag 13 november 2013 22:11

Acties:

HMS

Klinkt als een probleem dat opgelost kan worden met de juiste indexes. De hoeveelheid data klinkt niet bijzonder spannend, dus dat is het probleem niet.

edit: spuit 11,12,13

[ Voor 7% gewijzigd door HMS op 13-11-2013 22:13 ]

woensdag 13 november 2013 22:14

Acties:

woensdag 13 november 2013 22:29

Huur een specialist in voor een paar dagen die je database voor je kan optimaliseren. Is gezien de problemen waarschijnlijk z'n geld meer dan waard. Zelf kun je dit, gezien de optie die jij voor ogen hebt, absoluut niet.

[ Voor 19% gewijzigd door Hydra op 13-11-2013 22:14 ]

https://niels.nu

Acties:

donderdag 14 november 2013 00:15

Admin Devschuur®

^ Romeinse Ⅲ ja!

Hydra schreef op woensdag 13 november 2013 @ 22:14:
Huur een specialist in voor een paar dagen die je database voor je kan optimaliseren. Is gezien de problemen waarschijnlijk z'n geld meer dan waard. Zelf kun je dit, gezien de optie die jij voor ogen hebt, absoluut niet.

...even aangenomen dat de DB de bottleneck is (wat waarschijnlijk is, maar niet zéker

). Het zal niet voor 't eerst zijn dat, with all due respect, "ontwikkelaars uit India" belabberde code leveren die ver onder de maat is. (Let wel: ik zeg niet dat alle ontwikkelaars uit India dergelijke code leveren, en ook andere nationaliteiten (inc. Nederlanders!) kunnen er wat van hoor...). Wat wél vaak gebeurt is dat er "hier" geen kennis aanwezig is en men 't "dus" uitbesteedt elders waarna er geen/weinig inzicht is op de geleverde kwaliteit (joh, het werkt toch? Go go GO!) waarna, onder druk, dergelijke projecten dan alsnog bezwijken. In 't land der blinden is éénoog koning enzo

[ Voor 42% gewijzigd door RobIII op 13-11-2013 22:33 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij

Acties:

donderdag 14 november 2013 00:39

Topicstarter

Tot zover bedankt voor de reacties, ik snap dat de informatie karig is, maar ik moest ergens beginnen (wellicht uit enthousiasme) . Ik verwacht ook niet de gouden oplossing, maar was wel benieuwd hoe de menig van anderen is. Probeer jezelf voor te stellen dat mijn baas dit verzonnen heeft, zelf moest verzinnen hoe het moest werken en proberen klanten binnen te halen, dit met zo goed als 0 budget. Ik ben er 2 jaar later als stagiaire mijn afstudeer project gaan doen en uiteindelijk een functie gaan vervullen waar behoefte aan was (en waar ik blij van wordt

). We proberen er het beste van te maken en moet zeggen dat het in ieder geval met plezier gebeurd. Nee ik ben niet diegene met de kennis, en IT manager haha zo zou je het werk kunnen noemen wat ik doe (zoals ik mezelf ook CIO mag noemen, of hoe dan ook), maar ik heb een commercieel/economische opleiding gedaan. Bij nader inzien is dit ook mss ook niet echt de juiste actie geweest en komen mijn bedoelingen niet goed over. En ik wil al zeker niet spammen. Morgen is er bespreking met onze vrienden, ik hoop dat ze met een goede oplossing komen:)

Acties:

sig69

Ik zie dat je van typen houdt..
We kunnen weinig met je verhaal, dat had je denk ik al begrepen, maar ik wil er nog even aan toevoegen:
-Je os en database op één disk is geen goed idee
-Raid0 voor je disks waar je databases op staan is geen goed idee

Maar de machine die je beschrijft mag absoluut geen problemen hebben met dit soort kleine volumes, dus er zit wel iets fout ergens.

[ Voor 21% gewijzigd door sig69 op 14-11-2013 00:44 ]

Roomba E5 te koop

donderdag 14 november 2013 01:33

Acties:

donderdag 14 november 2013 08:43

Wat ik me ten eerste zou afvragen is : Zijn wachtrijen voor imports per definitie slecht? Want als een klant in 1 batch 2000 xml's aflevert mag dit dan niet wat tijd kosten? Of kan je gewoon afspreken dat de xml's binnen 24 uur verwerkt zijn in onafgesproken batches (dus continu) en bijv binnen 2 uur vanaf tijdstip x/y (bijv 1 batch om 01:00)

En ten tweede zou ik het probleem opsplitsen in 3 stukken :
- Import problemen (gewoon laten nakijken of de importer wel optimaal geschreven is)
- Backend problemen (db nakijken)
- Frontend problemen op losse klanten sites (wellicht een aparte db-server / webserver voor enkel de iframe's die met db-synchs gelijk wordt gehouden met de algemene backend zodat je in ieder geval een gedeelte van de load verdeelt)

Acties:

donderdag 14 november 2013 08:52

@Rob: ik zeg ook nergens dat de db het enige probleem is, maar om dat verder te onderzoeken hebben ze terplekke een expert nodig. Met dit topic schiet de ts weinig verder op dan dat ie hopelijk doorkrijgt dat zijn kennis volkomen ontoereikend is.

@ts: ga jezelf ajb geen CIO noemen, je bent zo groen als gras.

https://niels.nu

Acties:

donderdag 14 november 2013 08:54

Topicstarter

Beste Hydra, ik mag mezelf noemen hoe ik wel, en is absoluut niet serieus bedoeld, maar blijkbaar kan je daar moeilijk de humor van in zien. De boodschap is iig duidelijk, wat mij betreft mag het topic op slot

Acties:

Ramon

Waarom zou je dit topic willen sluiten? je krijgt hier allerlei waardevolle tips over hoe je database kan optimaliseren. Dat wilde je toch?

Check mijn V&A ads: https://tweakers.net/aanbod/user/9258/

donderdag 14 november 2013 10:03

Acties:

donderdag 14 november 2013 10:14

Beste TS: het is een goedbedoelde tip. Kennelijk hoor je hier niet wat je horen wil.

https://niels.nu

Acties:

donderdag 14 november 2013 10:17

Moderator Devschuur®

Het belangrijkste is inderdaad eerst eens goed uitzoeken wat de problemen zijn. Mensen die hier meteen al technische oplossingen gaan roepen bedoelen het misschien goed, maar als je niet weet wat het exacte probleem is schiet het niet op als je zomaar wat gaat rommelen.

Als de verwachting is dat het aan de DB ligt ga daar dan eerst eens gewoon een trace op los laten. Bekijk hoe de IO en CPU load van de server is.

Kijk daarna ook naar de andere processen in het geheel ( Denk aan de web-server en het import proces ). Als je dan de bottleneck gevonden hebt kun je gericht gaan kijken hoe je die op kunt lossen.

Zoals RobIII ook al aangeeft ben ik niet echt onder de indruk van een tabel met 120.000 records. Ik heb vaak zat met databases gewerkt die vele miljoenen records hadden ( Hell zelfs een paar miljard was nog werkbaar ). En ja je moet soms goed kijken welke indexen je wel of niet wil zetten, en hoe je verder de storage van je database wil regelen. Soms is met een simpele aanpassing van een query al een wereld van verschil te bereiken. Maar een query tunen heeft niet zoveel nut als bijvoorbeeld het proces dat de XML files inleest eigenlijk de bottleneck is.

“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”

Acties:

donderdag 14 november 2013 10:29

Wtfuzzle

RobinMM schreef op woensdag 13 november 2013 @ 21:23:
Bepaalde tabellen in de database worden door verschillende processen bewerkt waardoor vertraging ontstaat. Alle signalen lijken erop te wijzen dat de huidige database structuur niet meer geschikt is en zal dus anders moeten.

Stel dat je MyISAM als engine gebruikt, dan zou je te maken kunnen hebben met table-locks.

Ik denk dat we per klant 3 tabellen moeten hebben, en niet 3 tabellen met alle auto's van onze klanten. Op dit moment hebben we 1160 actieve klant_ids. Dat zou betekenen dat de database ongeveer 3500 tabellen krijgt. Is dit raar? Hiermee voorkom je toch dat er constant in dezelfde tabellen gewerkt wordt?

Dat is een verkeerde manier van normaliseren. Klanten horen thuis in de tabel 'klanten', elke rij is één klant. Kijk eens heel simpel naar een willekeurige tabel (een fysieke), als je die op dezelfde manier zou gebruiken krijg je toch ook een heel raar idee?

Daarnaast denk ik dat er 2 tabellen bij moeten komen, 1 tabel die gebruikt kan worden om te bepalen of de klant waarvan we de auto binnen krijgen bestaat en actief is.

En een tabel die alleen de unieke gegevens bevat van alle auto's om te bepalen of de te verwerken auto al in onze database bestaat (en dus gewijzigd moet worden) of niet, en dus aangemaakt moet worden.

Gewoon één tabel voor alle klanten, met één rij per klant. Je kunt inderdaad de auto's voorzien van ID's die horen bij merken en modellen. Nu heb je vast bij elke auto het merk in tekst staan, terwijl je (bijv.) de merknaam maar één keer op hoeft te slaan en dan steeds het ID koppelt aan de rest van de (unieke) informatie van de auto.

Het voordeel van losse tabellen per klant is dat de iframe's die we gebruiken voor de website integratie ook sneller kunnen werken omdat hij dan puur de tabel aanspreekt die alleen auto's van die klant bevat.

Dat gaat niet op, tenzij je (zoals ik eerder zei) last hebt van table-locks

[ Voor 5% gewijzigd door TheNephilim op 14-11-2013 10:18 ]

Acties:

winkbrace

Als er meer dan 20 kolommen in een tabel staan, gaan bij mij alarmbellen rinkelen.

De concencus lijkt te zijn dat met indexen het probleem van TS grotendeels verholpen is, maar je moet niet onderschatten hoeveel extra leeswerk al die kolommen met zich meebrengt. Het slim opknippen van al die data in logische groepen is ook essentieel voor de verbetering van het database model. (Van een model is in de huidige situatie eigenlijk geen sprake, overigens)
Hoe je het indeelt zou je kunnen laten afhangen van welke gegevens je op welke pagina nodig hebt, maar ik vind het zelf altijd makkelijker om data in te delen in een structuur gebaseerd op de data zelf.
dus bijvoorbeeld tabellen met brands, models, specs, images, suppliers, etc
Normaliseren dus, wat Rob III al zei.

donderdag 14 november 2013 10:33

Acties:

donderdag 14 november 2013 10:38

Moderator Devschuur®

BazzPsychoNut schreef op donderdag 14 november 2013 @ 10:29:
De concencus lijkt te zijn dat met indexen het probleem van TS grotendeels verholpen is

Dat lijkt me dan niet de goede concencus, hoewel het misschien wel zo kan zijn is er gewoon veel te weinig informatie over.

BazzPsychoNut schreef op donderdag 14 november 2013 @ 10:29:
Normaliseren dus, wat Rob III al zei.

Dat is helemaal niet wat er perse moet gebeuren, in veel gevallen is een gedeeltelijk gedenormaliseerd model juist sneller. Daar valt echter niet iets generieks over te zeggen als je niet weet welke bewerkingen er op de data gedaan worden.

[ Voor 29% gewijzigd door Woy op 14-11-2013 10:34 ]

“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”

Acties:

wezep

BTW een raid0 configuratie waar de database op draait?
1 SSD kapot en de hele database kwijt (even los van backup).

donderdag 14 november 2013 10:40

Acties:

winkbrace

Woy schreef op donderdag 14 november 2013 @ 10:33:
Dat is helemaal niet wat er perse moet gebeuren, in veel gevallen is een gedeeltelijk gedenormaliseerd model juist sneller. Daar valt echter niet iets generieks over te zeggen als je niet weet welke bewerkingen er op de data gedaan worden.

Als je voor elke denkbare situatie goede indexen hebt, is alle gegevens op 1 rij inderdaad sneller. Maar dat heb je nooit, want het leven is dynamisch.

En zodra je een full table scan moet doen, ben je met 155 kolommen doorgaans een hele tijd bezig.

De andere situatie is rapportages, waarbij je juist wel alle gegevens wilt lezen. Maar je draait geen rapportages over welke auto's je hebt. Eerder over welke je verkocht hebt.

donderdag 14 november 2013 10:45

Acties:

donderdag 14 november 2013 10:45

Moderator Devschuur®

BazzPsychoNut schreef op donderdag 14 november 2013 @ 10:40:
[...]
Als je voor elke denkbare situatie goede indexen hebt, is alle gegevens op 1 rij inderdaad sneller. Maar dat heb je nooit, want het leven is dynamisch.
En zodra je een full table scan moet doen, ben je met 155 kolommen doorgaans een hele tijd bezig.

Zonder te weten over wat er precies met de data gebeurt kun je daar weinig van zeggen, en ten tweede is normalisatie niet perse iets dat dat oplost.

De andere situatie is rapportages, waarbij je juist wel alle gegevens wilt lezen. Maar je draait geen rapportages over welke auto's je hebt. Eerder over welke je verkocht hebt.

Ook dat zijn speculaties.

“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”

Acties:

donderdag 14 november 2013 10:48

Wtfuzzle

BazzPsychoNut schreef op donderdag 14 november 2013 @ 10:40:
[...]

Als je voor elke denkbare situatie goede indexen hebt, is alle gegevens op 1 rij inderdaad sneller. Maar dat heb je nooit, want het leven is dynamisch.
En zodra je een full table scan moet doen, ben je met 155 kolommen doorgaans een hele tijd bezig.

De andere situatie is rapportages, waarbij je juist wel alle gegevens wilt lezen. Maar je draait geen rapportages over welke auto's je hebt. Eerder over welke je verkocht hebt.

300 kolommen in een tabel is geen probleem hoor, dat ligt aan de situatie. Anders krijg je oplossingen als 'klant_1', 'klant_2' etc. Daarnaast; je moet ook eigenlijk nooit full table scans doen hè.

Acties:

donderdag 14 november 2013 10:53

Moderator Devschuur®

TheNephilim schreef op donderdag 14 november 2013 @ 10:45:
[...]
Daarnaast; je moet ook eigenlijk nooit full table scans doen hè.

Nooit is een gevaarlijke uitspraak

. Er zijn best situaties waar je een index achterwege laat, en dus een full-table scan nodig hebt, omdat andere query's die vaker uitgevoerd worden en performance kritischer zijn daar baat bij hebben.

“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”

Acties:

donderdag 14 november 2013 10:56

Wtfuzzle

Woy schreef op donderdag 14 november 2013 @ 10:48:
[...]

Nooit is een gevaarlijke uitspraak . Er zijn best situaties waar je een index achterwege laat, en dus een full-table scan nodig hebt, omdat andere query's die vaker uitgevoerd worden en performance kritischer zijn daar baat bij hebben.

Daarom staat er ook 'eigenlijk' bij, soms zijn er inderdaad situaties waarbij (bijv.) het updaten van bepaalde indexes meer werk kost dan af en toe een table scan.

Maarja, ik denk dat we het er allemaal wel over eens zijn, dat die tabel-per-klant het in ieder geval niet moet worden. Dat de TS daarover begint is misschien al wel het grootste probleem.

Persoonlijk zou ik er niet zelf mee aan de slag gaan in die situatie. Je hele onderneming draait erop en fouten maken zou je dan de kop kunnen kosten. Gewoon een specialist inhuren is helemaal geen slecht idee. Het is dan alleen nog de kunst om niet zo'n overbetaalde consultant te vinden, maar een gewone kerel, die thuis is in de database wereld.

Acties:

donderdag 14 november 2013 11:27

BazzPsychoNut schreef op donderdag 14 november 2013 @ 10:29:
Als er meer dan 20 kolommen in een tabel staan, gaan bij mij alarmbellen rinkelen.

Complete onzin. Als die velden gewoon bij dat record horen en er gewoon een 1:1 relatie tussen is, is er geen enkel probleem. Sterker nog; denormaliseren van gegevens kan juist winst opleveren. Zonder een analyze van het model en de queries is hier helemaal NIETS zinnigs over te zeggen. Mensen die wel dingen gaan roepen zijn gewoon niet de mensen die, hoe goed bedoeld ook, niet weten waar ze het over hebben.

De concencus lijkt te zijn dat met indexen het probleem van TS grotendeels verholpen is,

Daar is helemaal geen consensus over. Sterker nog; als je de mensen die meteen al hun conclusie klaar hebben weglaat; is de enige conclusie dat er gewoon te weinig informatie is.

maar je moet niet onderschatten hoeveel extra leeswerk al die kolommen met zich meebrengt.

Wederom compleet onzin. Jij weet niet hoe die data gebruikt wordt. Als je kolom X, Y en Z altijd tegelijkertijd nodig hebt, is het volkomen nutteloos deze apart op te halen. Sterker nog; je maakt 't waarschijnlijk trager.

Het slim opknippen van al die data in logische groepen is ook essentieel voor de verbetering van het database model. (Van een model is in de huidige situatie eigenlijk geen sprake, overigens)

Je kent de huidige situatie nieteens!!!!

Hoe je het indeelt zou je kunnen laten afhangen van welke gegevens je op welke pagina nodig hebt, maar ik vind het zelf altijd makkelijker om data in te delen in een structuur gebaseerd op de data zelf.
dus bijvoorbeeld tabellen met brands, models, specs, images, suppliers, etc
Normaliseren dus, wat Rob III al zei.

En wederom heb je geen flauw idee of dat uberhaupt iets oplost. Het is maar de vraag of het uitnormaliseren van simpele dingen zoals merken uberhaupt iets oplost; als je een fatsoenlijke facetted search wilt leveren zul je toch al snel naar iets als lucene moeten zoeken.

Mijn persoonlijke vermoeden is ook dat er 1) in de database een hoop scheef zit en dat 2) de applicatie zelf slecht gebruik maakt van de database (selecteren op index-loze kolommen, textsearches op index-loze kolommen, etc) maar kennelijk is er nog meer aan de hand want zelfs het inlezen van de data gaat retetraag.

Oftewel: ze hebben iemand ter plekke nodig met kennis van zaken en dat gaat 'em gewoon geld kosten. En naar mensen die wel weten waar het probleem zit moet je sowieso niet luisteren, dat zijn geen professionals.

Woy schreef op donderdag 14 november 2013 @ 10:48:
[...]

Nooit is een gevaarlijke uitspraak . Er zijn best situaties waar je een index achterwege laat, en dus een full-table scan nodig hebt, omdat andere query's die vaker uitgevoerd worden en performance kritischer zijn daar baat bij hebben.

Laten we niet in dit soort margegeneuzel vervallen. Daar heeft niemand wat aan. Iedere fatsoenlijke dev weet wel dat er altijd uitzonderingen zijn.

[ Voor 8% gewijzigd door Hydra op 14-11-2013 10:57 ]

https://niels.nu

Acties:

SPee

Mijn persoonlijke vermoeden is ook dat er 1) in de database een hoop scheef zit en dat 2) de applicatie zelf slecht gebruik maakt van de database (selecteren op index-loze kolommen, textsearches op index-loze kolommen, etc) maar kennelijk is er nog meer aan de hand want zelfs het inlezen van de data gaat retetraag.

3) de applicatie teveel gebruik maakt van de database (b.v. voor elk xml veld een query, distinct en ongelimiteerde joins, losse queries ipv de in(..) functie, etc )

Als het inlezen van de data traag gaat, zou je kunnen kijken of het met parallele verwerking sneller/beter gaat. Dus niet 1 import proces die steeds 1 xml afhandeld, maar meerdere processen tegelijkertijd.

En waarom dat proces zo langzaam gaat zul je achter moeten zien te komen. Zijn de bestanden (te) groot, wordt het slecht uitgelezen, kan de vergelijking met de database optimaler, wordt de database niet te vaak aangeroepen, etc. Worden er in de code bijvoorbeeld loopjes gebruikt waarbinnen queries uitgevoerd worden? 1000 keer een query van 1ms en het duurt 1 seconde, duurt de query 1 seconde dan duurt het al een kwartier!

En zoals gezegd; controleer de indexen op de database. En zorg dat queries die gebruikt worden ook gebruik maken van die geindexeerde kolommen.

Mijn vermoeden is dat een audit op de code geen slecht idee is.

let the past be the past.

donderdag 14 november 2013 11:52

Acties:

donderdag 14 november 2013 11:59

SPee schreef op donderdag 14 november 2013 @ 11:27:
En zoals gezegd; controleer de indexen op de database. En zorg dat queries die gebruikt worden ook gebruik maken van die geindexeerde kolommen.

Nogmaals: de TS heeft die kennis zelf niet uit huis. En niemand gaat gratis tig uur besteden aan het oplossen van die problemen. Of nouja, niemand die geld waard is tenminste.

RobinMM schreef op donderdag 14 november 2013 @ 11:49:
Dit was trouwens een reactie van onze hosting partij over ons server gebruik (en na upgrade geheugen):

Een hosting bedrijf is volledig nutteloos als het gaat om het oplossen van dit soort problemen: het is niet hun zaak hoe jij de zooi die daar gehost staat gebruikt.

[ Voor 30% gewijzigd door Hydra op 14-11-2013 11:54 ]

https://niels.nu

Acties:

donderdag 14 november 2013 12:01

Wtfuzzle

Hydra schreef op donderdag 14 november 2013 @ 11:52:

[...]

Een hosting bedrijf is volledig nutteloos als het gaat om het oplossen van dit soort problemen: het is niet hun zaak hoe jij de zooi die daar gehost staat gebruikt.

Nouja, ze kunnen wel bekijken hoe druk de server is en waarmee die zo druk is. Klaarblijkelijk heeft de server helemaal niet zo druk, dat is inderdaad een ander verhaal.

Acties:

donderdag 14 november 2013 12:01

Topicstarter

Hydra wellicht kan je me een tip geven door wie ik een audit kan laten doen

?

Acties:

donderdag 14 november 2013 12:02

Moderator Devschuur®

Hydra schreef op donderdag 14 november 2013 @ 10:56:
[...]
Laten we niet in dit soort margegeneuzel vervallen. Daar heeft niemand wat aan. Iedere fatsoenlijke dev weet wel dat er altijd uitzonderingen zijn.

Laten we dan ook vooral geen stellingen als absolute waarheden neerzetten, want er zijn genoeg dev's die zoiets klakkeloos overnemen. Juist in dit geval zonder duidelijke informatie is het gewoon niet goed om dergelijke uitspraken te doen, want het gaat helemaal niet zo om zulke uitzonderlijke margegevallen, er zijn genoeg gevallen waarbij het niet erg is dat er een tablescan gedaan moet worden, als de frequentie maar laag genoeg is en de performace daarbij geen probleem is.

“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”

Acties:

proatjeboksem

Tip: Hou je grootste tabellen zo algemeen mogelijk.
Ik denk zelf dat je aan 4 hoofdtabellen genoeg hebt:

Klant, Auto, Extra's/Accesoires en Voertuig. De links ertussen doe je met koppeltabellen.

Voertuig is het te verkopen object (kenteken, chassisno, bijzonderheden en opmerkingen),
Auto is voertuiginformatie (merk, type, uitvoering)
- Hiermee hoef je niet 200 keer opel astra 1.6 op te slaan, maar 200 links tussen Voertuig en Auto
- kan ook gebruikt worden voor algemene info, voor je website, info die de verkoper niet opgeeft, zoals verbruik, 0-100 tijd, etc.
Extra's/Accessoires in algemene bewoordingen (open dak, trekhaak, electrische ramen)
- wederom, niet honderden accessoires per Voertuig, maar gewoon een link met 'vinkjes')
Klant, spreekt voor zich, te koppelen aan Voertuig

donderdag 14 november 2013 12:23

Acties:

donderdag 14 november 2013 12:25

RobinMM schreef op donderdag 14 november 2013 @ 11:49:
Dit was trouwens een reactie van onze hosting partij over ons server gebruik (en na upgrade geheugen):

1 tip : Stel je niet te veel voor van de "onbetaalde" support van je hosting partij. Je complete setup is niet enkel je db.
Je hebt meer factoren waarnaar je moet kijken en jezelf blindstaren op de load van een db-server is redelijk nutteloos (maar de gemiddelde hosting partij heeft niet meer technische kennis in huis).

RobinMM schreef op donderdag 14 november 2013 @ 12:01:
Hydra wellicht kan je me een tip geven door wie ik een audit kan laten doen ?

In principe zal hiervoor hetzelfde gelden als voor de rest van het topic : Geef meer info en je kan wellicht advies krijgen...
Maar met de huidige gegeven info (er is een programma en die communiceert met een database en er is ook nog een aantal websites) kan er enkel een algemeen audit buro aangeraden worden die groot genoeg is om alle specialiteiten in huis te hebben

Acties:

kwaakvaak_v2

duh... proatjeboksem, dat is gok ik ook de hoofdreden dat meer mensen hier om een DB model hebben gevraagd. Want dit hele topic riekt naar bad design met bad practises. Alleen jammer dat de TS/OP er niet zo goed tegen lijkt te kunnen als hem dat wordt uitgelegd.

Tijd dat ie de ballen krijgt om als CIO dus tegen zijn CEO te zeggen dat ze een goede CTO moeten in huren

Driving a cadillac in a fool's parade.

donderdag 14 november 2013 12:27

Acties:

donderdag 14 november 2013 12:28

Moderator Devschuur®

kwaakvaak_v2 schreef op donderdag 14 november 2013 @ 12:25:
Tijd dat ie de ballen krijgt om als CIO dus tegen zijn CEO te zeggen dat ze een goede CTO moeten in huren

Laten we het hier wel inhoudelijk houden en niet op de man/titel spelen.

“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”

Acties:

donderdag 14 november 2013 12:45

RobinMM schreef op donderdag 14 november 2013 @ 12:01:
Hydra wellicht kan je me een tip geven door wie ik een audit kan laten doen ?

De vraag is vooral of jullie daar het geld voor hebben. Je geeft aan dat het bedrijf krap bij kas zit en je een blik indiers opengetrokken hebt om het werk te doen. Tja, if you pay peanuts you get monkeys. Je geeft verder niet aan welke database / welk platform gebruiken (wilde gok: MySQL + PHP?) dus je moet op zoek gaan naar bedrijven met ervaring in e-commerce bovenop het platform dat jullie gebruiken. Daar zijn er nogal veel van.

Best case kunnen ze in een week de ergste problemen voor je verhelpen (reken op 100E per uur), worst case is je applicatie zo'n draak dat ze hun handen er niet aan willen branden. Ik verwacht zelf, gezien het feit dat je datamodel vrij simpel is en er verder weinig spannends aan je site zit, dat er gewoon grote relatief simpel te vinden fouten in zowel je DB als het gebruik daarvan door de applicatie zitten. Als je weet wat er precies fout zit kun je overwegen door wie je de fouten op wilt laten lossen; je indiers of iemand die snapt hoe een RDBMS werkt

Woy schreef op donderdag 14 november 2013 @ 12:01:
Laten we dan ook vooral geen stellingen als absolute waarheden neerzetten

offtopic:
Je moet ook een beetje tussen de regels kunnen lezen. Iedereen snapt volgens mij prima wat hij bedoeld en het is een enorm slechte en irritante eigenschap van veel developers om betweterig te gaan lopen doen over non-issues. Als je dat uit wil knokken is er altijd zo iets als DMs.

TheNephilim schreef op donderdag 14 november 2013 @ 11:59:
Nouja, ze kunnen wel bekijken hoe druk de server is en waarmee die zo druk is. Klaarblijkelijk heeft de server helemaal niet zo druk, dat is inderdaad een ander verhaal.

Een server die full table scans aan 't doen is lijkt helemaal niet druk als je naar CPU en geheugengebruik kijkt, maar ondertussen is je hele applicatie aan 't bottlenecken op disk-reads.

[ Voor 29% gewijzigd door Hydra op 14-11-2013 12:33 ]

https://niels.nu

Acties:

donderdag 14 november 2013 13:02

Topicstarter

Ik zal je de ellende besparen van onze vrienden, maar dit was jaren geleden de enige manier om vooruit te kunnen. We zijn wel op een punt aangekomen waar we serieus aan het kijken zijn hoe we verder moeten. Krap bij kas betekend niet dat er geen geld is voor zo'n audit. Want daar zal waardevolle informatie uit komen, die ook belangrijk zal zijn voor de toekomst van ons bedrijf(je).

Het platform dat gebruikt wordt is MSSQL 2012,asp.net en c#. En wat betreft of iemand een partij weet die een audit kan doen, is een serieus verzoek.

Dit is nog even een aanvulling op hoe het xml proces verloopt:

Here are the operations marked as (D*) database operations we are processing for hexon (is onze grootste partij die xml bestanden aanleverd)

Basic Flow of Hexon Process
Get the XML file from Specific Path
Read the XML File
Read the advertisement info
Read the dealer information
Get DealerId from dealerDataSupplierID(D*)
Set Dealer object using DealerId(D*)
Gets Dealer Discount using dealerDataSupplierID(D*)
Read the vehicle Information
Read License plate information(D*)
Read technical information
Read Price information
Read vehicle option (Accessory) information(D*)
Read the Make and Model information(D*)
Set Car, CarDetail and CarImage table objects
Set the car object(D*)
Car price calculation
Set the CarDetail object
Set the CarImage object(D*)
Insert the entire three objects together(D*)
Insert Hexon file name in the table(D*)

Set the Car Object after inserting details of car(D*)
Check conditions and make entry in queue(D*)
this are upto EW only..we have mobile.de later if it has send car to mobile.de checked

EDIT: zo ziet de xml eruit: http://195.191.16.110/xml/130289031540120000.xml

Acties:

donderdag 14 november 2013 13:04

Moderator Devschuur®

RobinMM schreef op donderdag 14 november 2013 @ 12:45:
Het platform dat gebruikt wordt is MSSQL 2012,asp.net en c#. En wat betreft of iemand een partij weet die een audit kan doen, is een serieus verzoek.

Hier is niet de juiste plek om de partijen te bespreken. Maar bel een willekeurige dienstverlener op die veel .NET ontwikkeling doet en plan eens een gesprek in. Beoordeel dan zelf aan de hand van de referenties of het een betrouwbare partner is en of je een goed gevoel bij de aanpak die ze voorstellen krijgt.

“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”

Acties:

donderdag 14 november 2013 13:19

RobinMM schreef op donderdag 14 november 2013 @ 12:45:
Ik zal je de ellende besparen van onze vrienden, maar dit was jaren geleden de enige manier om vooruit te kunnen. We zijn wel op een punt aangekomen waar we serieus aan het kijken zijn hoe we verder moeten. Krap bij kas betekend niet dat er geen geld is voor zo'n audit. Want daar zal waardevolle informatie uit komen, die ook belangrijk zal zijn voor de toekomst van ons bedrijf(je).

Het platform dat gebruikt wordt is MSSQL 2012,asp.net en c#. En wat betreft of iemand een partij weet die een audit kan doen, is een serieus verzoek.

Vroegah in een project gepartnerred met http://www.evident.nl/, goeie ervaring destijds.

Dit is nog even een aanvulling op hoe het xml proces verloopt:

Here are the operations marked as (D*) database operations we are processing for hexon (is onze grootste partij die xml bestanden aanleverd)

[*knip proces*]

Dit zegt weinig helaas. Nogmaals: je moet iemand daar hebben die 't systeem door kan lichten.

EDIT: zo ziet de xml eruit: http://195.191.16.110/xml/130289031540120000.xml

Dat is geen 'rare' XML die problemen op zou moeten leveren. 5000 van die files verwerken zou geen enkel probleem moeten zijn.

https://niels.nu

Acties:

Bensjero

Ik ben het, Bensjero.

Na dit topic even snel doorgespit te hebben, valt me op dat iedereen maar aan SQL databases, of iig relationele databases denkt. (of was dat de eis correct me if im wrong).

Doordat je erg veel data binnen krijgt (veel is relatief) en de data redelijk complex is door de relaties lijkt het mij een goed alternatief om eens te kijken naar NoSQL databases, zoals MongoDB.

Wat dat inhoud is dat je data opslaat 'object style'. Je schrijft eigenlijk complete objecten naar een file.
Het voordeel is dat ze niet gelijk hoeven te zijn, een auto kan bijvoorbeeld een repair date hebben, of juist een accesoiretype (ik noem maar wat), of geen van beide. Er is dus maar 1 'tabel' (het is dus eigenlijk geen tabel) wat de auto's bevat.

De voordelen van SQL houdt je wel: je kan gewoon alle auto's van klant A zoeken die onlangs zijn gerepareerd of whatever. En een auto object veranderd dynamisch mee met de auto, wil je iets toevoegen, hoef je niet de hele database weer aan te passen

MongoDB gebruikt JSON style objecten, wat heeeeel makkkelijk om te zetten is vanuit XML, om je auto's op te slaan. En het is snel, heel snel: een klein projectje wat ik vorig jaar opgezet heb met een paar medestudenten, parste makkelijk die 3000 tot 5000 xml bestanden per minuut. Oké, dat was dan wel multithreaded (alleen mogelijk als de auto nog niet bestaat, om data corruptie te voorkomen), maar het geeft je even een idee van snelheid.

Voor de klanten kun je gewoon 1 tabel gebruiken, je zou dat gewoon in SQL kunnen doen, hier zit de grote data niet in.

Echter, je situatie moet ook makkelijk kunnen met SQL, SQL schaalt immers tegenwoordig steeds beter, en je hoeveelheid data valt nog wel mee.

donderdag 14 november 2013 13:27

Acties:

elhopo

Grappig wel, hoe de XML in elkaar zit. De kleur van de auto wordt bepaald door 1 van de waarden op Yes of No te zetten, de kleur van het interieur kan je gewoon invoeren :-) Oh ja, een roze auto is niet mogelijk...

maar verder kan je denk ik het beste zoeken bij de bekendere namen kwa detacheerders, of een ZZP er inhuren die verstand heet van het een en ander.

De reden van het traag worden is zo niet te achterhalen. Als je met je auto bij een autobedrijf komt en zegt dat hij af en toe spontaan afslaat, dan zegt de monteur ook niet meteen: Ah, dat is het brandstof relais. Er op reageren met: Ah, gebruik techniek x lost niets op.

Voorbeeld hierboven met MongoDB: Voor het gemak vertel je er niet bij dat je het moet clusteren over minimaal 3 linux servers, En als een auto 'veranderd' wordt onderliggend een nieuw record aangemaakt en het oude staat op 'invalid'. Eens in de zoveel tijd moet je de database rebuilden en dan ben je uit de lucht. Het indexeren / zoeken is dan ook nog niet meegenomen. Lucene, Solr?

Affijn, goed bedoelde adviezen en zo, maar 1. Meneer weet technisch niet precies wat het inhoud, en 2. het lost het probleem niet op als je niet eens weet wat het probleem is. De melding is: we krijgen 5000 xml's niet verwerkt. Is dat 5000 verspreid over de dag, of in een batch? Waaruit blijkt dat het niet kan worden verwerkt? Deadlocks? Timeouts op de frontend?

Ik kan 1001 optimalisaties noemen, maar als je niet weet hoe of wat precies, dan blijft het een grote gok.

Blijkt dat citroenvlinders helemaal niet naar citroen smaken.

donderdag 14 november 2013 13:28

Acties:

donderdag 14 november 2013 14:47

Wtfuzzle

Kan je geen tips geven over welk bedrijf je moet inschakelen. Echter zou ik oppassen voor bedrijven die je meteen allerlei hippe en technisch hoogstaande oplossingen willen opdringen. Ik snap dat in ze vakgebied dat het nieuwste en beste is, maar soms moet je voor een solide oplossing een stapje terug doen.

Hydra schreef op donderdag 14 november 2013 @ 12:28:

[...]

Een server die full table scans aan 't doen is lijkt helemaal niet druk als je naar CPU en geheugengebruik kijkt, maar ondertussen is je hele applicatie aan 't bottlenecken op disk-reads.

Ik lees in de uitleg van de hoster dat IO juist omlaag gegaan is, maar er zijn inderdaad legio redenen waarom ze in die situatie kunnen zitten. Code, database of een combinatie van die twee.

Acties:

donderdag 14 november 2013 14:51

JensinatoR schreef op donderdag 14 november 2013 @ 13:19:
Doordat je erg veel data binnen krijgt (veel is relatief) en de data redelijk complex is door de relaties lijkt het mij een goed alternatief om eens te kijken naar NoSQL databases, zoals MongoDB.

Fantastisch idee. Suggereer iemand die weinig van databases weet maar die wel een relationeel model heeft om voor een compleet andere soort database te gaan, een document-store, die helemaal niet zo goed is in relationele modellen.

De 'snelheid' van MongoDB is vooral slimme marketing. Weer iemand die de klok heeft horen luiden maar niet doorheeft dat de 'hipheid' van vooral Mongo tegenwoordig achterhaald is nu blijkt dat zelfs de PostGres JSON object store sneller is dan mongo.

Komt bij dat de default settings van Mongo gewoon niet ACID-compliant zijn. Als je Mongo zo instelt dat het wel ACID-compliant is, ben je je snelheid kwijt.

Relationele DBs zijn misschien niet zo hip als NoSQL databases tegenwoordig zijn, maar ze zijn extreem geschikt in de opslag van relationele data waarbij je vanuit verschillende invalshoeken de data wil benaderen (oftewel bijna elke DB use-case). En dat zijn ze al meer dan 40 jaar. En als je dan toch een situatie hebt waarbij je erg veel logdata oid (geschikte usecase voor NoSQL) hebt, dan zijn er veel betere alternatieven dan Mongo

Als een tegengeluid voor alle MongoDB hipheid (ben er zelf ook ingestonken, tot ik wat meer onderzoek ging doen):
http://nosql.mypopescu.co...ous-post-dont-use-mongodb

Je suggestie om MongoDB te gaan gebruiken is bizar. Het lost niks op, kost klauwen met geld kwa ontwikkelingstijd, levert geen performancewinst (een use case met 5k XML documents is niks, je zit met MongoDB gewoon naar memory te schrijven) en is puur gebaseerd op marketing en slechte default MongoDB settings.

[ Voor 8% gewijzigd door Hydra op 14-11-2013 15:02 ]

https://niels.nu

Acties:

pedorus

JensinatoR schreef op donderdag 14 november 2013 @ 13:19:
Doordat je erg veel data binnen krijgt (veel is relatief) en de data redelijk complex is door de relaties lijkt het mij een goed alternatief om eens te kijken naar NoSQL databases, zoals MongoDB.

Wel een interessante oplossing om gelijk maar de hele database om te gooien. Volgens mij gaat het hier niet om veel data, en is er daadwerkelijk wat structuur, dus kan het prima in SQL blijven

Ik vermoed dat als iemand even kijkt naar de queries die gebruikt worden, welke indexen er zijn en gebruikt worden en of transacties wel in batch gebeuren ipv per record, er al grootse verbeteringen mogelijk zijn.

Vitamine D tekorten in Nederland | Dodelijk coronaforum gesloten

donderdag 14 november 2013 14:58

Acties:

donderdag 14 november 2013 15:01

Website says no

Ligt het aan mij of weet niemand nog welke database gebruikt wordt? Lijkt me wel relevant voor de oorzaak van het probleem en de aan te dragen oplossingen.

Als het een Oracle database is wil ik wel met je meedenken maar dan zal ik meer info moeten hebben, en zonodig remote meekijken om tot een oplossing te komen.

/edit sorry, zie nu dat het MSSQL is. Ik dacht dat qua schaalbaarheid MSSQL wel kon concurreren met Oracle, ik sta er van te kijken dat MSSQL zich hier al in verslikt. Benieuwd wat hier uit komt.

[ Voor 23% gewijzigd door page404 op 14-11-2013 15:02 ]

ZIPper: Zelfstandig Interim Professional

Acties:

donderdag 14 november 2013 15:02

page404 schreef op donderdag 14 november 2013 @ 14:58:
Ligt het aan mij of weet niemand nog welke database gebruikt wordt? Lijkt me wel relevant voor de oorzaak van het probleem en de aan te dragen oplossingen.

RobinMM schreef op donderdag 14 november 2013 @ 12:45:
Het platform dat gebruikt wordt is MSSQL 2012,asp.net en c#. En wat betreft of iemand een partij weet die een audit kan doen, is een serieus verzoek.

https://niels.nu

Acties:

elhopo

page404 schreef op donderdag 14 november 2013 @ 14:58:
Ligt het aan mij of weet niemand nog welke database gebruikt wordt? Lijkt me wel relevant voor de oorzaak van het probleem en de aan te dragen oplossingen.

Ja, het ligt aan jou, er is al vermeld : MSSQL 2012.

Prima database. Klein nadeel is dat je wat sneller locks krijgt dan bij Oracle. Groot voordeel is dat de licenties veel duidelijker zijn.

Blijkt dat citroenvlinders helemaal niet naar citroen smaken.

donderdag 14 november 2013 15:03

Acties:

donderdag 14 november 2013 15:07

Website says no

elhopo schreef op donderdag 14 november 2013 @ 15:02:
[...]

Ja, het ligt aan jou, er is al vermeld : MSSQL 2012.

Prima database. Klein nadeel is dat je wat sneller locks krijgt dan bij Oracle. Groot voordeel is dat de licenties veel duidelijker zijn.

Dat is een heeel groot maar dan ook meteen het enige voordeel

ZIPper: Zelfstandig Interim Professional

Acties:

donderdag 14 november 2013 15:16

page404 schreef op donderdag 14 november 2013 @ 15:03:
Dat is een heeel groot maar dan ook meteen het enige voordeel

page404 schreef op donderdag 14 november 2013 @ 14:58:
/edit sorry, zie nu dat het MSSQL is. Ik dacht dat qua schaalbaarheid MSSQL wel kon concurreren met Oracle, ik sta er van te kijken dat MSSQL zich hier al in verslikt. Benieuwd wat hier uit komt.

En weer iemand die niet weet waar 'ie het over heeft...

Dus nu gaan we maar MS bashen?

https://niels.nu

Acties:

donderdag 14 november 2013 16:15

JensinatoR schreef op donderdag 14 november 2013 @ 13:19:
Doordat je erg veel data binnen krijgt (veel is relatief) en de data redelijk complex is door de relaties lijkt het mij een goed alternatief om eens te kijken naar NoSQL databases, zoals MongoDB.

Waar lees jij dat het om veel data zou gaan? En waar lees jij dat het redelijk complex zou zijn ( 3 tabellen? )?

Ik bedoel je gooit hier gewoon even een ideetje neer die waarschijnlijk maanden programmeerwerk op gaat leveren als de TS het idee overneemt en ik ben dan toch wel erg benieuwd waarom je denkt dat dit uberhaupt iets gaat uithalen?
Je praat bij dit soort overgangen niet over een paar duizend euro kosten, met een beetje app gaat een overgang van rdbms naar nosql gewoon in de tonnen lopen.

Ik lees dat het gaat om 3 tabellen (= simpel) en een heel erg laag aantal records

page404 schreef op donderdag 14 november 2013 @ 14:58:
/edit sorry, zie nu dat het MSSQL is. Ik dacht dat qua schaalbaarheid MSSQL wel kon concurreren met Oracle, ik sta er van te kijken dat MSSQL zich hier al in verslikt. Benieuwd wat hier uit komt.

Waar verslikt MSSQL zich dan exact in? Ik bedoel ik kan een willekeurige oracle server ook op zijn bek krijgen met custom query's over 1 tabel met 1.000 rows, betekent dit dat oracle zich ook verslikt in 1.000 rows in 1 tabel (heck een .txt bestand kan het nog beter doen

).
Of betekent het enkel dat mijn query's / app gewoon butt zijn?

Acties:

donderdag 14 november 2013 16:17

Website says no

Hydra schreef op donderdag 14 november 2013 @ 15:07:
[...]

[...]

En weer iemand die niet weet waar 'ie het over heeft...

Dus nu gaan we maar MS bashen?

oh ja, dit is het programmeerhoekje, daar kunnen we alleen maar aangeschoten reageren en doen alsof we het zelf allemaal weten en die andere prutsers kunnen niks (gebaseerd op één regel op een forum).

ZIPper: Zelfstandig Interim Professional

Acties:

donderdag 14 november 2013 17:29

page404 schreef op donderdag 14 november 2013 @ 16:15:
oh ja, dit is het programmeerhoekje, daar kunnen we alleen maar aangeschoten reageren en doen alsof we het zelf allemaal weten en die andere prutsers kunnen niks (gebaseerd op één regel op een forum).

Als je met fatsoenlijk advies zou komen kreeg je dergelijke reacties niet.

https://niels.nu

Acties:

Ahrnuld

Eens met de voorgaande reacties die zeggen dat de code en de DB gecheckt moeten worden door iemand die een beetje thuis is in performance optimalisatie bij de combinatie C#/SQL Server/ASP.NET.

Niets...

donderdag 14 november 2013 19:09

Acties:

donderdag 14 november 2013 19:50

Website says no

Hydra schreef op donderdag 14 november 2013 @ 16:17:
[...]

Als je met fatsoenlijk advies zou komen kreeg je dergelijke reacties niet.

Lezen is ook lastig voor je, als je dat wel kon had je gezien dat ik geen "fatsoenlijk advies" geef omdat ik zelf al aangeef geen kennis van andere DB's te hebben dan Oracle. Maar je herkent het begrip zelfreflectie natuurlijk niet.

ZIPper: Zelfstandig Interim Professional

Acties:

donderdag 14 november 2013 19:52

offtopic:
[quote]page404 schreef op donderdag 14 november 2013 @ 19:09:
[...]
Lezen is ook lastig voor je, als je dat wel kon had je gezien dat ik geen "fatsoenlijk advies" geef omdat ik zelf al aangeef geen kennis van andere DB's te hebben dan Oracle. Maar je herkent het begrip zelfreflectie natuurlijk niet.
[/quote]
Dus je hebt geen kennis van andere DB's maar je kan wel zeggen dat de licentiestructuur het enige voordeel is... Does not compute...

Maar fanboy / troll lekker door hoor.

Acties:

vrijdag 15 november 2013 13:18

Admin Devschuur®

^ Romeinse Ⅲ ja!

Zooooooooo. Ben er wel een beetje klaar mee. TS geeft te weinig info en na een aantal reacties is daar zo goed als nul aan toegevoegd en inmiddels is 't sfeertje ook pet. Het was gezellig.

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij

Acties: