Archief - Wat is uw brutoloon? - Deel 9
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.
desolation
Legacy Member
da_flux zei:Dat is bizar want de T480 is nog maar wat meer dan 2j oud en totaal niet traag te noemen
Tenzij ze een slechte config heeft gekregen (Bron. Dit bericht is getypt op een T480die zwaar gebruikt wordt)
8GB RAM was toen voldoende te noemen, nu helaas niet meer. Upgraden is vrij kostelijk (allez niet als ge het zelf doet, maar wel om het door hun supplier te laten doen)
ThekillingGoku
Legacy Member
't Is wel te zeggen ... als ge 'op de client' moet zitten wachten op resultaten van DB queries ... dan is het echt niet de client die traag is.
De query wordt uitgevoerd op de server zelf natuurlijk, de client is mor dat ... de client.
Tenzij ge effectief een DB lokaal gaat draaien, maar dan heb je afhankelijk van het DB type wel wat meer 'muscle' nodig e. SQL server 'full' zie ik mij nog niet direct op m'n lokaal systeem draaien want die doet ni liever dan RAM zuipen. Laat staan dat elke WN apart een licentie zou krijgen voor een full blown Enterprise edition (of zelfs standard).
Anyway ... SQL Server 'light' om het zo te stellen daarentegen is gratis, maar beperkt in wat em biedt en wordt regelmatig al eens lokaal gedraaid.
MySQL en consoorten zijn zo zwaar ni echt.
Bottom line ... als ze bv. in een BI situatie zit, met een centrale DB & veel zit te wachten op query execution ligt het mogelijks eerder aan de inefficiëntie van de queries, niet de PK's van de client.
En 8GB is al vele jaren niet meer voldoende voor een development laptop. Als ik gewoon al eens mijne Chrome & FireFox bekijk zuipen die elk al een paar GB memory & dan staat er nog genen IDE open.
Bij ons is de lifecycle van een laptop 3j. Dus om de +/-3j krijg ik een nieuwe.
Eerlijk gezegd ... de grootste performance voordelen voor mij zijn SSD boot & RAM (naar gelang van wat uwe workload is natuurlijk, mor in mijn geval dus).
De mijne is 1 keer volledig geformatteerd geweest na een WinUpdate. Ineens blu-screen, dus boel om zeep.
1x geprobeerd te fixen, heeft 1 dag gedraaid ... WinUpdate trug gekregen -----> jah ... same deal, dus nieuw image der op.
Hardware is wel niet vervangen geweest want er was duidelijk niets aan.
De query wordt uitgevoerd op de server zelf natuurlijk, de client is mor dat ... de client.
Tenzij ge effectief een DB lokaal gaat draaien, maar dan heb je afhankelijk van het DB type wel wat meer 'muscle' nodig e. SQL server 'full' zie ik mij nog niet direct op m'n lokaal systeem draaien want die doet ni liever dan RAM zuipen. Laat staan dat elke WN apart een licentie zou krijgen voor een full blown Enterprise edition (of zelfs standard).
Anyway ... SQL Server 'light' om het zo te stellen daarentegen is gratis, maar beperkt in wat em biedt en wordt regelmatig al eens lokaal gedraaid.
MySQL en consoorten zijn zo zwaar ni echt.
Bottom line ... als ze bv. in een BI situatie zit, met een centrale DB & veel zit te wachten op query execution ligt het mogelijks eerder aan de inefficiëntie van de queries, niet de PK's van de client.
En 8GB is al vele jaren niet meer voldoende voor een development laptop. Als ik gewoon al eens mijne Chrome & FireFox bekijk zuipen die elk al een paar GB memory & dan staat er nog genen IDE open.
Bij ons is de lifecycle van een laptop 3j. Dus om de +/-3j krijg ik een nieuwe.
Eerlijk gezegd ... de grootste performance voordelen voor mij zijn SSD boot & RAM (naar gelang van wat uwe workload is natuurlijk, mor in mijn geval dus).
De mijne is 1 keer volledig geformatteerd geweest na een WinUpdate. Ineens blu-screen, dus boel om zeep.
1x geprobeerd te fixen, heeft 1 dag gedraaid ... WinUpdate trug gekregen -----> jah ... same deal, dus nieuw image der op.
Hardware is wel niet vervangen geweest want er was duidelijk niets aan.
HUSKE
Legacy Member
parabellum zei:
Bij ons heeft het departement waar ik werk geen last gehad van Corona, maar aangezien het nogal een groot bedrijf is zijn er departementen die een serieuze financiële hit hebben gehad. We zien vandaag dat alles terug genormaliseerd is. 2021 een potentieel slechter jaar kan worden, maar all in all geen probleem mag vormen.
Wat doe je dan als bedrijf, je IT/R&D van het ene departement loonsopslag geven en de andere niet... Lijkt me logisch dat het gewoon niemand wordt. Al zou ik zelf graag een paar honderd euro erbij hebben en dat ga ik ook gewoon proberen. You never know, ik kan persoonlijk redelijk goede performance voorleggen, net zoals een paar honderd duizend aan operationele savings en een paar miljoen aan extra revenue in 2020/2021 en later.
desolation
Legacy Member
ThekillingGoku zei:'t Is wel te zeggen ... als ge 'op de client' moet zitten wachten op resultaten van DB queries ... dan is het echt niet de client die traag is.
De query wordt uitgevoerd op de server zelf natuurlijk, de client is mor dat ... de client.
Tenzij ge effectief een DB lokaal gaat draaien, maar dan heb je afhankelijk van het DB type wel wat meer 'muscle' nodig e. SQL server 'full' zie ik mij nog niet direct op m'n lokaal systeem draaien want die doet ni liever dan RAM zuipen. Laat staan dat elke WN apart een licentie zou krijgen voor een full blown Enterprise edition (of zelfs standard).
Anyway ... SQL Server 'light' om het zo te stellen daarentegen is gratis, maar beperkt in wat em biedt en wordt regelmatig al eens lokaal gedraaid.
MySQL en consoorten zijn zo zwaar ni echt.
Bottom line ... als ze bv. in een BI situatie zit, met een centrale DB & veel zit te wachten op query execution ligt het mogelijks eerder aan de inefficiëntie van de queries, niet de PK's van de client.
En 8GB is al vele jaren niet meer voldoende voor een development laptop. Als ik gewoon al eens mijne Chrome & FireFox bekijk zuipen die elk al een paar GB memory & dan staat er nog genen IDE open.
Bij ons is de lifecycle van een laptop 3j. Dus om de +/-3j krijg ik een nieuwe.
Eerlijk gezegd ... de grootste performance voordelen voor mij zijn SSD boot & RAM (naar gelang van wat uwe workload is natuurlijk, mor in mijn geval dus).
De mijne is 1 keer volledig geformatteerd geweest na een WinUpdate. Ineens blu-screen, dus boel om zeep.
1x geprobeerd te fixen, heeft 1 dag gedraaid ... WinUpdate trug gekregen -----> jah ... same deal, dus nieuw image der op.
Hardware is wel niet vervangen geweest want er was duidelijk niets aan.
Zijn allemaal helaas lokale databases, diegene die op de server draaien gaan in een oogwenk.
ThekillingGoku
Legacy Member
zarathustra zei:
Wel ... eigenlijk wel akkoord met Mister Z hier. Maar da's mss omdat we uitgaan van een welbepaalde workload.
Mss zijn er geldige redenen om een lokale DEV omgeving op een laptop 'logisch' te maken.
Zoals ik eerder al even aanhaalde, afhankelijk van het type DB & waarom je die nodig hebt kan dat wel. Basic webdevelopment met een MySQL of SQLite of iets dergelijks kan gerust met een 'full' local DEV.
Al zie ik weinig 'delays' op DB bewerkingen in die workload (en weinig focus op den DB trouwens), dus ik betwijfel dat het iets in die aard is.
Gezien er 'lang gewacht moet worden' op DB bewerkingen betekent in principe dat er gigantische hoeveelheden data op d'een of d'ander manier lokaal op iedereen z'n laptop worden gepompt om er dan mee te spelen (in mss een BI context?). Da's dan weer niet echt de meest handige setup.
Als er lokaal ontwikkeld wordt ... is dat meestal ook op DEV data, wat over 't algemeen de moeite ni is qua volume.
Anyway ... nu benne'k curieus welke workload zo zwaar gebruik maakt van DB's, maar geen server ter beschikking heeft om ze te draaien.
Alternatieven die ik tegen kom zijn bv. 'personal DEV VPC/Server', 'Centralized DB Systems waar iedere DEV 'eigen repo' of iets dergelijks heeft', ...
desolation
Legacy Member
Tis puur datamigratie dat ze doet. Iedereen werkt aan aparte projecten en draait zijn zaken lokaal.
Dat komt voor een groot stuk verder uit het feit dat (en nu gaan iedereen zijn haren hier recht staan) dat de te migreren offices allemaal op access draaien
Het is zeker geen ideale situatie en er wordt gigantisch veel tijd mee verscheten, wat exact ook de reden is dat ze aan dat migratietraject bezig zijn.
Dat komt voor een groot stuk verder uit het feit dat (en nu gaan iedereen zijn haren hier recht staan) dat de te migreren offices allemaal op access draaien
Het is zeker geen ideale situatie en er wordt gigantisch veel tijd mee verscheten, wat exact ook de reden is dat ze aan dat migratietraject bezig zijn.
Musk
Legacy Member
desolation zei:Tis puur datamigratie dat ze doet. Iedereen werkt aan aparte projecten en draait zijn zaken lokaal.
Dat komt voor een groot stuk verder uit het feit dat (en nu gaan iedereen zijn haren hier recht staan) dat de te migreren offices allemaal op access draaien
Het is zeker geen ideale situatie en er wordt gigantisch veel tijd mee verscheten, wat exact ook de reden is dat ze aan dat migratietraject bezig zijn.
Daar gaan mijn haren idd van rechtop staan
Hier is dat eerst in de sandbox wat klooien, dan in dev, dan in twee verschillende QA's (UAT en dan regressie door de business) alvorens ook maar iets naar productie te mogen transporteren
Nu goed, ik ben werkzaam in de pharma/medical devices - weinig margin for error daar.
ThekillingGoku
Legacy Member
desolation zei:Tis puur datamigratie dat ze doet. Iedereen werkt aan aparte projecten en draait zijn zaken lokaal.
Dat komt voor een groot stuk verder uit het feit dat (en nu gaan iedereen zijn haren hier recht staan) dat de te migreren offices allemaal op access draaien
Het is zeker geen ideale situatie en er wordt gigantisch veel tijd mee verscheten, wat exact ook de reden is dat ze aan dat migratietraject bezig zijn.
OK. Lokaal uit noodzaak dus. MS Access kunt ge nl. genen DB noemen. Om te beginnen is dat feitelijk al single-user & file based dus om da centraal te gaan zetten heeft weinig zin. Enige wat centraal zou staan is de file, de lokale Access applicatie is gene client, maar nog altijd verantwoordelijk om alles te doen. Duuuuus jah ... 't is ni voor niets dat dat eigenlijk gewoon een huis, tuin- & keuken DB'ke is.
Still ... als het een migratie traject is dan moet ze in principe weinig of geen 'queries' uitvoeren om op te wachten. Testdata kan handig zijn bij migraties, maar de basis is niet het uitvoeren van 'complex queries', maar eerder gewoon 'Select *' -> 'foreach' -> 'do this'.
De 'do this' heb je in principe zelfs geen data nodig om dit uit te werken, laat staan GB's aan data.
Heck ... tijdens de ontwikkeling van die migratie heb je liefst zo weinig mogelijk volume & zo veel mogelijk specifieke gevallen om mee te werken zodat ge dat snel, vlot & gemakkelijk kunt doen.
Eens een groot stuk v/d migratie logica is uitgewerkt zal je wel eens een meer complete test willen doen op 'echte' data, maar daar zit je over 't algemeen niet op te staren tijdens de werkuren. Laat dat ding gewoon een nacht/weekend z'n ding doen & check dan de logging & resultaat of 't op iets trekt (zou redelijk goe moeten zijn als ge al tot het punt van een echte test geraakt bent).
Dus ... bottom line ... de laptop zelf zou niet echt een bottleneck mogen zijn in de meeste gevallen.
Gezien die dat wel is zit je wss constant ne 'SELECT *' te doen in DEV om dan 1 of 2 records te debuggen om wat logica te testen, en dit op GB's aan productie data die lokaal staan. Redelijk inefficiënt zou ik dan zeggen.
Zeker als daar opsplitsing in de logica zit om een paar 'WHERE' clauses er in te steken op non-indexed columns.
In 't slechtste geval, als ge toch met productie volume zit ... beperken tot 'SELECT * WHERE id = TstId' om de DEV runs te doen. Primary key selects zouden een pak rapper moeten zijn.
Anyway ... Getting too techy here ain't it.
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.