Ik heb een best wel veel velden in een 'redelijk groot' tabel.
Ik maak tijdelijke tabellen aan, om zo meervoudige aanpassingen te kunnen doen. Zonder dat de eindgebruiker die 1-20seconden hier last van heeft.
Deze data wil ik graag weer terug updaten naar de 'live' tabel.
Maar zo lui als ik ben, wil ik niet ALLE velden gaan benoemen, want het is 100% zeker dat de veldnamen hetzelfde zijn.
Ik gebruik namelijk
CREATE TABLE tmp_' . $hdesk . ' AS
SELECT *
FROM dns_tickets
WHERE ticket_hdesk = ' . $hdeskID
tickets heeft een primary key ticket_id met Auto Increment.
Ik heb wel het een en ander opgezocht en kwam eigenlijk op het volgende uit:
REPLACE INTO dns_tickets live SELECT tmp.* FROM tmp_' . $hdesk . ' tmp WHERE live.ticket_id = tmp.ticket_id
Maar hierover las ik ook weer dat deze functie eigenlijk eerst doet deleten, en dan doet inserten, klopt dit?
Is er een betere oplossing hiervoor ?
Waar komt de noodzaak vandaan om een kopie te trekken? Dit lijkt mij onwenselijk omdat je dan ineens twee bronnen hebt van wat in wezen dezelfde informatie is.
Heb je al geprobeerd om bijvoorbeeld een (of meer) index(en) aan te maken voor snelle(re) lookup? Of gekeken hoe het komt dat e.e.a. traag is (aangenomen dat dat de reden is, of vanwaar dus deze wens)?
Het komt doordat de update best wel wat langer duurt.
Ik moet alle tickets updaten mbt SLA's en kosten berekenen.
Per afdeling kunnen de kosten verschillen.
In eerste instantie dmv csv, xml en xls files update ik vrijwel alle tickets al met een vaste datum, zodat ik daarna kan zien welke geupdate zijn in de live tabel, en vervolgens in de import tabel zie welke nieuw zijn.
Alle updatet tickets moet ik bijwerken mbt SLA kosten en afdelingen, daarna de tickets uit de import tabel toevoegen, en ook nog eens bijwerken, met missende gegevens.
Dit x10 met een cronjob van 5 minuten, het liefst sneller, maar helaas heeft het update script iets tijd nodig om 100 duizenden tickets te bewerken.
M'n updates zijn op basis van de ticket_id, waarvan ik verwacht dat het niet veel sneller kan dmv extra index fields.
Hierdoor lopen gebruikers ietswat vertraging op.
Het gaat maar om seconden werk, soms iets langer dan 3 seconden in totaal om alles bij te werken, maar de tabel dns_tickets raakt gelocked, en staan queries in de wacht tijdens de updates na het importeren.
Dit wil ik graag teniet doen, door per helpdesk een copy te maken van de live tickets, incl. ID, en daarin te werken tot het klaar is, en dan in 1 klap de updates te verwerken.
(de inserts gebeuren wel op de live tabel, maar dat zijn aanzienlijk minder dan de updates)
Ik verwacht dat de eindgebruikers op deze manier geen tot zeer weinig vertraging oplopen, wat frustraties en ban's zal verminderen.
Bans in de zin van, qos bans omdat ze als kippen zonder kop refresh table blijven klikken (een ajax request dat de tickets ophaald op basis van hun filter en aantallen p. pagina)
Wat ik me afvraag, is of het noodzakelijk is om alle records van de tabel in een beweging te updaten en zo regelmatig ook. Zou je kunnen volstaan met enkel van records die geraadpleegd worden een actuele/ ge-update versie te tonen. Vervolgens ‘s nachts alle records bijwerken.
Ja dit is gewenst.
Binnen een paar miljoen tickets zijn er gemiddeld vrijwel ongeveer 150.000 aanpassingen, soms meer binnen 3 minuten :-/
Ik heb trouwens dynamische waardes, maar ik weet niet of de SQL server er vrolijk van wordt als ie zelf alle berekeningen in een klap moet uitvoeren en dus zelf de records al update tijdens de import ipv uitbesteden aan php.
Ik zit er bijna aan te denken om over te gaan naar een SAP backend.
Hoewel ik niet denk dat het er veel beter op zal gaan worden.
Ik ga nog wat verder stoeien, en anders zeg ik gewoon dat ze maar ietwat geduld moeten hebben of hun verwachtingen moeten aanpassen in het FO en een nieuwe change aanvragen.
Het gaat dus om enorm veel records (>1mln) met daarin veel aanpassingen in een kort tijdsbestek. Als ik het goed heb begrepen zijn er ook aanpassingen waar een bepaald(e) algoritme/ rekenregel aan ten grondslag ligt. Ik kan me voorstellen dat er op één moment slechts van een beperkt aantal records (<1mln, <150k en misschien zelfs <100) de SLA-kosten geraadpleegd worden en dus bekend hoeven zijn. Kortom, toepassing van die algoritmes over >1mln records met zo'n 150k aanpassingen kon wel 's beduidend meer resources kosten als het 'on the fly' toepassen van algoritmes op de basisgegevens (?).
Het wordt al complexer als je over meerdere records een totaalplaatje opvraagt ('SLA afdelingskosten'?), maar het is nog steeds te doen en misschien wel efficiënter als bewerkingen die ook nog 's een UPDATE en/of INSERT met zich meebrengen.
Databases verschillen ook in snelheid. Met voor soort database werkt SAP? HANA?
Databases verschillen ook in snelheid. Met voor soort database werkt SAP? HANA?
SAP werkt doorgaans met Oracle maar kan in kleinere omgevingen ook Microsoft en HANA werken. Oracle is marktleider in SAP. In alle gevallen is het RDBMS wel bereikbaar buiten SAP maar een herkenbaar datamodel is niet echt beschikbaar. Een tabel aangemaakt met het SAP frontend is niet 1:1 terug te vinden in het RDBMS
Het gaat in een totaal plaatje inderdaad om miljoenen records, waarvan er gemiddeld 150.000 updates zijn in kort tijdbestek.
Het 'on the fly' toepassen van de algoritmes en berekeningen kan wel, maar het gaat niet om enkele gebruikers, en inderdaad zijn de totalen het meest van belang en het visualiseren van de data.
Uiteraard is dit nooit van ALLE tickets, maar in tijdsbestekken, en per team.
Het bedrijf waar ik werk is wereldwijd en een van de marktleiders op logistiek transport.
Deze tickets komen uit vele helpdesks, welke langzaam maar zeker wel ver gaan uitdunnen tot 1 centraal systeem (eindelijk). Maar dat betekend niet dat de tickets minder worden ;-)
Op het moment heb ik meerdere servers, p.s. draaien SQL op OutSystems
Ik ben met kleine projectjes bezig met SAP Hana en Fiori, maar .. anyways ik voel dat we afdwalen :D
Kan ik simpelweg gewoon alle kolommen en records van tabel updaten naar tabel2 op tabel1.id = tabel2.id
Zonder alle veldnamen te specificeren, jullie begrijpen wel dat dit een uitgebreid en 'levend' project is, en als ik deze query elke keer moet aanpassen als ik weer een nieuwe variable erbij krijg per ticket, dat ik rekening moet houden om ALLE queries bij te werken van alle helpdesk imports..
@Dennis Eerlijk gezegd durf ik deze vraag niet met een ja of nee te beantwoorden, omdat ik bij deze orde van grootte (# records / velden) zelf probeer te voorkomen SQL dit soort geheugen-intensieve operaties te laten uitvoeren.
Exact, INSERT en UPDATE kunnen behoorlijk veel capaciteit vragen. Terug naar hoofdvraag, hoe krijg je flexibiliteit als je extra velden gaat toevoegen .... Bij een MongoDB bijvoorbeeld heb je wat dat betreft (misschien) meer flexibiliteit.
