In het land der blinden... part 5

Door RobIII op maandag 24 augustus 2009 02:38 - Reacties (30)
CategorieŽn: In het land der blinden..., Life as a developer, Rants, Views: 6.385

Zo; vandaag eens geen XSS exploitable sites maar een major WTF die een 9 scoorde op mijn persoonlijke WTF-schaal. In softwareland komen we van alles en nog wat tegen; pareltjes van applicaties die je dagelijks het leven vergemakkelijken en veraangenamen tot ware nachtmerries waar we, noodgedwongen of van hogeraf opgelegd vaak, mee moeten worstelen tot we rood voor de ogen zien. Uiteraard, omdat dit item in de categorie 'rants' staat gaat het hier dus over een gedrocht uit de tweede categorie :P Die zijn nou eenmaal leuker om over te schrijven ;)

Helaas kan ik ditmaal geen bedrijven aan de haren erbij sleuren en met namen gaan smijten; de 'stakes' liggen ditmaal ťrg hoog en we hebben het nu over bedragen van ettelijke tonnen aan software, nogmaals tonnen aan consultancy en tonnen aan overboord gemikkerde "cross your fingers and pray it works" oplossingen welke dus niet deden wat ze hoorden te doen. Ook kan ik, helaas weliswaar, niet alles uit de doeken doen of te specifiek worden omdat ditmaal dit blogitem niet is 'goedgekeurd' door de opdrachtgever. Niet omdat ze dat niet zouden doen maar omdat ik het niet aan ze heb voorgelegd om redenen die je verder niets aan gaan (en de ruzie die nog steeds woedt tussen hen en de software leverancier) :P Ik hoop dat het het lezen van onderstaande tekst niet minder leuk maakt.

http://tweakers.net/ext/f/WNMs80VIxI2RQxEhgcynwn0H/full.jpgHet verzoek
Een paar maanden geleden werd ik benaderd door een goede klant van ons; ik zal ze voorlopig even Happy'n'Merry Inc. noemen; H&M zeg maar :P (En nee, het was dus geen H&M). Zij namen contact op met ons om ons licht te laten schijnen op een ERP applicatie die zij in gebruik hadden en waarvan ze het vermoeden graag zouden zien bevestigd danwel ontkracht dat de software op technisch vlak "niet goed in elkaar zou zitten" (Red: even vrij vertaald en wat krachttermen achterwege gelaten). De software van Monster Inc. zou dusdanig traag zijn dat er niet mee te werken viel. En ondanks dat ik bar weinig kennis heb van het domein waarin H&M opereert en ik dus waarschijnlijk niet goed kon oordelen of de traagheid terecht zou zijn (en of concurrerende producten misschien wel eenzelfde probleem zouden hebben) stond opdrachtgever toch op een evaluatie door ondergetekende.

Na dit korte telefonische verzoek, waarin ik meteen vertelde dat linksom of rechtsom de uitslag ze niet zou bevallen, werd besloten dat ik toch maar even op locatie moest gaan kijken. De reden waarom de uitslag niet zou bevallen en waarom ik dat al voorzag is simpel: Zou de applicatie ernstige problemen hebben dan moest er voor veel geld geÔnvesteerd worden in een fix want een applicatie in die orde van grootte nestelt zich in ieder hoekje van je bedrijf en die kiep je dus niet even in een week buiten om te vervangen door een concurrerend product. En zou de applicatie wťl deugdelijk zijn dan kon er niets aan gedaan worden behalve voor veel geld investeren in meer en betere hardware. Ongeacht mijn conclusie zou het ze veel geld gaan kosten en, at best, een werkbare situatie leveren die natuurlijk bij oplevering al geweest had moeten zijn. Het enige wat ze konden winnen met een technisch onderbouwde evaluatie was een stok om de softwareleverancier mee te slaan.

http://tweakers.net/ext/f/Utx2aqTrMFsZNgjX4Vpnd5Iq/full.jpgIk ben dus, schoorvoetend omdat ik weet waar dit doorgaans op uit draait, op onderzoek uit gegaan. Ik had, omdat het systeem zo goed als 24/7 in bedrijf is, weinig kans om in de daadwerkelijke productieomgeving te kijken maar heb dat wel zo nu en dan toch even gedaan. Al met al was mijn bezoekje iets van 2 tot 3 uur tijd waarvan ik het grootste deel van dat bezoek vooral moeite heb moeten doen om mijn lach te bedwingen en ettelijke explosies van complete furie vanwege de schandalige kwaliteit van de software te onderdrukken. "Maar RobIII, hoe kun je dan zo'n applicatie, zonder specifieke domeinkennis, en in zo'n korte tijd, beoordelen?". Nou; oordeelt u zelf maar even mee en spot de WTF's...

http://tweakers.net/ext/f/VMuf8bc7Buv6eqvPRVhmbrCO/full.jpgHarware
Het grootste 'slachtoffer' was, voor mij, het arme 2U servertje dat de applicatie draaide; deze kreeg het meest op z'n donder in het hele verhaal. De software van Monster Inc. draaide op een, door hunzelf geadviseerde en voor H&M op maat 'berekende', Windows 2003 Server (64 bits) met 2 quad core XEON processors en 8Gb geheugen. De snelheid van deze processors is me helaas niet bijgebleven maar zelfs in het allergunstigste geval, uitgaand van state-of-the-art huidig leverbare modellen, niet echt relevant. De database is MSSQL Server 2005 Standard Edition (64 bits). De database was, op dat moment, ruim 90 Gigabyte groot (waarbij de log bestanden nog niet meegeteld zijn) en was opgeslagen op een RAID5 systeem. Er waren, doorgaans, 50+ concurrent gebruikers verbonden met SQL server.

Database - Tabellen
Bij het bekijken van de database, het hart van de applicatie, vielen een aantal zaken vrijwel meteen op. Zo bestond de DB uit, op dat moment, 3.256 tabellen. Dit aantal alleen al is een behoorlijke indicator van de kwaliteit van de architectuur van de applicatie (of het gebrek daar aan).

http://tweakers.net/ext/f/fmVEAPPWiFUkxggzNZ4r7pFm/full.jpgVan die tabellen werd, steekproefsgewijs vanwege het enorme aantal, geconcludeerd dat er een aantal tabellen aanwezig waren met 475+ velden. Ook dat aantal is wederom een reden om vraagtekens te gaan zetten bij de oplossing die Monster Inc. geproduceerd heeft. In de gevallen waar het toch voorkomt is het doorgaans een, voorzichtig gesteld, "gebrekkig" ontwerp. Van deze tabellen was de naamgeving ervan ook al een goede indicator; Het leek er op dat deze machinaal gegenereerd waren (wat doorgaans architectonisch en kwalitatief slecht blijkt te gaan). Tabelnamen als sy8326_001_5096_xo04, sy0860_000_0119_09B4_scr02 en du612099_lib04 zijn voor mensen doorgaans niet erg bruikbaar. Daarbij bleken er veel tabellen aanwezig met namen als vi2650_001_20090302, vi2650_001_20090402 en vi2650_001_20090502 wat er op wijst dat er maandelijks een nieuwe tabel in gebruik wordt genomen voor het opslaan van bepaalde data. Ook dit valt onder een "bad practice". Hoewel het in een aantal gevallen vanwege partitionering of archivering van gegevens bijvoorbeeld te verdedigen zou zijn leek het in dit geval niet aan de orde en helaas onderdeel te zijn van de vele slechte ontwerpkeuzes in de Monster Inc. applicatie.

Van deze tabellen werden er een aantal waargenomen waarbij "samengestelde primary keys" (compound primary keys) bestonden uit 5 of meer velden; in een extreem geval werd het aantal 13 zelfs waargenomen (welke tot overmaat van ramp ook nog clustered bleek te zijn); op onderbuikgevoel (wegens gebrek aan domein specifieke kennis van de gegevens erin) leek dit een rampzalige keuze te zijn geweest wegens a) de onwaarschijnlijke grootte van de samengestelde PK en b) de zeer waarschijnlijk niet-sequentiŽle aard van de gegevens erin welke een drastische performance impact hebben wegens clustering van de key. Vele tabellen bevatten velden van het type "Binary/BLOB" welke, op het oog, niet veel meer dan platte tekst leken te bevatten. De keuze voor binary zou, wanneer deze gegevens inderdaad platte tekst zouden zijn, minstens"vreemd" te noemen zijn.

http://tweakers.net/ext/f/zNtduHKXmRUC7k8R5VBm7J0a/full.jpgDatabase - Views
De 58 views die de database rijk was zijn ook steekproefsgewijs bekeken. Een flink aantal daarvan, zo niet alle, bleken niet veel meer te doen dan gegevens uit verschillende'maandtabellen' te combineren middels een Union. An sich is dit geen vreemd gebruik; echter wegens de waarschijnlijk non-existente reden voor het bestaan van de 'maandtabellen' had dit al voorkomen kunnen worden. Daarbij bleek het SQL statement waaruit deze views bestaan in vele gevallen enkele tientallen en in veel gevallen zelfs honderden Kilobytes groot te zijn. In een extreem geval (let wel; ik heb enkel steekproeven genomen) bleek het SQL statement 215+ Kilobyte groot te zijn en middels een Union 25 tabellen zonder enige restricties in where-clauses (sterker: een compleet gebrek aan where-clauses) samen te voegen. Daarbij moet opgemerkt dat het aantal velden dat de SELECT retourneerde 373 velden bedroeg. Wederom een voor menselijke begrippen amper te bevatten enorm brouwsel aan onbegrijpelijke velden als RG3177_PR_EINHEIT_2, RG3775_MTV_B_MAX_ART_WERT en RG3177_SORT_GRP_10. Vele views bleken 300+ velden te retourneren en, zoals gezegd, enorme unions aan te gaan op vele, vele tabellen. Het zal zťlfs de doorgewinterde DBA's inmiddels beginnen te duizelen.

http://tweakers.net/ext/f/1MQS8RFYXoajIEHbA5Fipt34/full.jpgDatabase - Algemeen
De database bleek, na enig onderzoek en tijdelijk aan mijn eigen kunnen getwijfeld te hebben, geen enkele Foreign Key te bevatten. Geen enkele. Ik heb een script ter plekke moeten schrijven om alle tabellen na te lopen om zťker te weten dat ik niet gek werd. Het hele nut van het gebruik van een RDBMS als SQL server (waarbij RDBMS staat voor Relational Database Management System en dus de R in deze afkorting volledig teniet wordt gedaan) is hierdoor zo goed als overbodig. Foreign Keys zorgen ervoor dat SQL server kan garanderen dat data consistent is en blijft. Het ontbreken van een FK kan, in bepaalde gevallen, verdedigd worden. Het ontbreken van enige FK in een database met ruimschoots 3.000 tabellen is echter ronduit ongehoord. Hierdoor komt de verantwoordelijkheid van het consistent houden van de data volledig bij de software te liggen en, hoewel dat in kleine(re) projecten soms nog te doen is, dat zal op den duur en zeker op deze schaal zo goed als gegarandeerd inconsistente data betekenen met alle gevolgen van dien. De schaal van de impact was moeilijk in te schatten en zal, afhankelijk van waar de inconsistenties optreden, groter of kleiner zijn maar het idee ervan alleen al deed me huiveren.

http://tweakers.net/ext/f/aBUDyQlW2ICB6aX6PMocadqp/full.jpgTijdens mijn bezoek heb ik, ťrg omzichtig uiteraard, een "Profiler Trace" uitgevoerd op het gebruik van de database in een "real life scenario" (lees: in de productieomgeving). Deze trace werd, vanwege mijn voorzichtigheid, na een enkele minuut reeds gestopt. Tijdens een dergelijke trace wordt feitelijk het gebruik van de database aan een "hartmonitor" gehangen en wordt inzichtelijk gemaakt hoe de database door de vele gelijktijdige gebruikers benaderd wordt en welke gegevens opgevraagd worden. Vanwege diezelfde voorzichtigheid heb ik de trace erg compact gehouden en zijn de verkregen en gemeten gegevens dus erg beknopt geweest. Toch kon op basis hiervan ook een aantal conclusies getrokken worden. Zo kwam er tijdens deze trace geen enkele "join" voorbij; iets wat, zeker gezien het aantal gelijktijdige gebruikers en het aantal benaderingen van de DB in die tijd, toch wel verwacht mag worden. Een "join" koppelt gegevens van bepaalde tabellen aan elkaar en relateert dus feitelijk gegevens uit verschillende tabellen aan elkaar. Dit zijn bewerkingen waar SQL Server uitermate geschikt voor is en vallen onder basisprincipes van het opvragen van gegevens. Het gebrek aan deze joins en de manier waarop de DB benaderd wordt blijkens de trace wees er op dat de gegevens allemaal door de clientsoftware aan elkaar gekoppeld en dus gerelateerd werden. Dit betekent tevens dat de DB onnodig vaak benaderd zal worden om gegevens uit tabel X en dan weer uit Y en dan uit Z op te halen en verklaart, zoals overigens de meeste zo niet alle waarnemingen, de klacht dat het pakket onwerkbaar traag was.

http://tweakers.net/ext/f/sdJlvSDoaLJJtzki4nBSDrbr/full.jpgEen flink aantal van de benaderingen die de cliŽntsoftware op de DB uitvoerde bleek ook nog eens vele, vaak honderden, velden te bevragen uit tabellen. De hoeveelheid gegevens die opgevraagd werden leken te veel te zijn voor het praktisch gebruik dat de gebruikers van de software plegen. Het is haast ondenkbaar dat gebruikers op bepaalde momenten inzage nodig hebben in honderden velden. Uiteraard kan de hoeveelheid verklaard worden doordat deze nodig zijn voor intern gebruik van de software (en dus niet zo zeer het presenteren van die gegevens aan de gebruikers in een GUI) maar wederom zei mijn onderbuikgevoel dat dit niet het geval was. Tevens bleken alle verbindingen met de clients tijdens de trace gebruik te maken van het SA account; het "System Administrator" account. Dit betekent dat de software volledige toegang heeft tot alles, maar dan ook alles, binnen de database. An sich hoeft dit geen probleem te zijn zolang de software geen fouten bevat en gebruikers afschermt van acties waartoe zij niet gemachtigd zijn maar dan worden er dus onwerkelijke aannames gedaan dat a) de software geen fouten bevat (dat is een utopie) en b) gebruikers geen fouten maken of c) gebruikers geen kwaad zouden kunnen willen (denk aan ontevreden werknemers etc.). Het gebruik van het SA account zet dan ook de deur wagenwijd open voor catastrofes op enorme schaal.

Database / cliŽntsoftware - Cursors
Een andere waarneming die ik deed en welke wťl, tot op bepaalde hoogte, wat diepgaandere analyse heeft gehad, is dat ik zag dat alle benaderingen op de SQL server gebruik maakten van "server-side cursors". Hierbij doelen we niet op de bekende "cursors" binnen SQL server maar op driver-niveau aanwezige cursors. Software kan de SQL server op 2 manieren (2 cursors) benaderen; server-side cursors en client-side cursors. Bij het gebruik van client-side cursors wordt (eenvoudig gezegd) de SQL server benaderd voor bijv. het opvragen van bepaalde gegevens welke bijv. 10 resultaten zal opleveren. In het geval van een client-side cursor zullen deze 10 resultaten alle 10 meteen naar de client gestuurd worden. Dat houdt in dat er een enkele "roundtrip" naar SQL gemaakt wordt. De client benadert de server en ontvangt de resultaten.

http://tweakers.net/ext/f/cCyRqKMHJj2bR1ZSv7SZYVgt/full.jpgWat ik echter waarnam was het gebruik van server-side cursors. Het bestaan ervan alleen al is indicatie dat er reden is om hiervoor te kiezen; het is echter ten minste twijfelachtig te noemen dat deze zo frequent gebruikt werd. De werking van een server-side cursor is als volgt: De client benaderd de server, zoals in voorgaand voorbeeld, voor bepaalde gegevens. Wederom zal de server 10 resultaten verzamelen op basis van de vraag. Echter, in dit geval, retourneert de server volgens onze trace maar een enkel resultaat. Wanneer de client dit ontvangen heeft en het volgende resultaat wil hebben zal deze opnieuw de server moeten benaderen waarop deze het tweede resultaat retourneert. Dit zal zich, wanneer de client over alle 10 resultaten wil beschikken, dus 10 maal herhalen en dus 10 "roundtrips" betekenen. Dit houdt in dat het netwerk ook zwaarder belast wordt. Bedenk daarbij dat dit door 50+ clients gedaan wordt, SQL server van alle 50+ clients de (tijdelijke) resultaten zal moeten vasthouden voor volgende benaderingen etc. en duidelijk mag zijn dat de belasting vele malen zwaarder is voor het netwerk en de servers resources als CPU cycles en geheugengebruik. Ook de I/O resources zullen zwaarder belast worden welke toch al, wegens alle waarnemingen over o.a. de tabellen zoals eerder beschreven, erg hoog waren. Het is mogelijk om deze belasting te verlagen door, wanneer er toch vastgehouden wordt aan het server-side cursor principe, de server te vragen telkens meer dan 1 resultaat te retourneren. Zo kan, als voorbeeld, gevraagd worden om 5 resultaten per keer te retourneren. Dit zal betekenen dat er feitelijk, voor 10 resultaten, maar 2 "roundtrips" naar de server nodig zijn en de belasting op alle voorgenoemde resources en het netwerk verlagen (let wel: niet halveren!). In ons voorbeeld hebben we het over 10 resultaten maar het wordt pas ťcht interessant wanneer het over tientallen, honderden of zelfs duizenden resultaten gaat. Wat de beste "keuze" is voor het aantal resultaten geretourneerd per keer is zo niet te zeggen, maar vast staat dat het lang niet altijd 1 zal zijn. De trace toonde echter vele, vele "exec sp_cursorfetch x,y,z,1" statements waarbij x, y en z niet relevant zijn en de 1 aantoont dat er om een enkel resultaat wordt gevraagd door de client software (bron, zie punt 2). Naar mijn mening kan dit onmogelijk gunstig zijn geweest.

http://tweakers.net/ext/f/NqzmgosHWmXqg8x7p3HFnIrK/full.jpgSoftware - Algemeen
Hoewel buiten de scope van het verzoek dat aan mij gericht was (ik werd er bij gehaald vanwege mijn SQL kennis), heb ik toch even gekeken naar de applicatie zelf. Omdat ik inhoudelijk niet kon oordelen over de werking van de applicatie heb ik dat dan ook nagelaten. De applicatie bleek, hoewel traag, wel te voldoen aan de vraag over het algemeen genomen; voor zover ik kon beoordelen althans en van de gebruikers vernam. Toch heb ik wat kanttekeningen gemaakt met betrekking tot de software architectuur van de applicatie. Zoals eerder besproken werd is de manier waarop de software de database benaderd twijfelachtig. Ook bleek de applicatiemap waarin de software stond 11.995 DLL bestanden te bevatten; een astronomisch aantal. Ook hier bleek de naamgeving van de bestanden erg "exotisch" te noemen en wees alles weer op machinaal gegenereerde bestanden (en dus code). Ter indicatie; een "aardig volle" PC met Windows en daarop geÔnstalleerde allerhande software bevat rond de 4.000 a 8.000 DLL bestanden. Het aantal van bijna 12.000 bestanden an sich is al reden om verbazing te wekken, de daarbij toegepaste naamgeving (ev5762.dll, ev5765.dll, ev5767.dll, ko260902.dll, ko261003.dll etc. etc.) bevestigde enkel wederom mijn vermoeden van slecht doordachte software architectuur.

Deze hoeveelheid bestanden betekent ook, en dat is ook waargenomen, dat de gemiddelde client die de Monster Inc. software start tijdens het gebruik vele tientallen tot honderden file handles in gebruik heeft in een sessie. Dat betekent veel 'administratief werk' voor de server; in dit geval bleek tot overmaat van ramp de "file server" welke de bestanden bevatte ook nog eens dezelfde machine te zijn die de SQL Server taak toegewezen had gekregen. Deze had, zoals aangetoond, toch al een flinke belasting van de beschikbare resources.

http://tweakers.net/ext/f/FyezS6nUkk7FhUmtqUrRu3dL/full.jpgConclusie
Hoewel er dus her-en-der misschien wat zaken met een goede onderbouwing enigszins te verdedigen zouden zijn was de totale ervaring die ik daar opdeed niet al te best. Het mag een wonder heten dat 't gedrocht Łberhaupt iets deed en dat Monster Inc. weg kwam (en komt) met deze wanstaltige software. De conclusie van mijn 7 pagina's tellende rant rapport laat zich raden. Hoe dat afliep en hoe het gesprek ging toen ik op 't matje werd geroepen door Monster Inc. om mijn rapport toe te lichten bewaar ik voor deel 6 ;)

TwitterNuJIJeKudosFacebookFriendfeedGoogle BookmarksDiggdel.ici.ousTechnoratiSphinnMixxStumpleUponYahoo! BookmarksMaak je eigen RML op RobIII.nl!

Volgende: In het land der blinden... part 6 08-'09 In het land der blinden... part 6
Volgende: In het land der blinden... part 4 08-'09 In het land der blinden... part 4

Reacties


Door Tweakers user BM, maandag 24 augustus 2009 08:17

Holy... sh*t.

Ik ben zelf software ontwikkelaar, en zal de laatste zijn om te beweren dat ik daarin extreem goed ben, maar hier krijg je gewoon kippenvel van :X
Hoe komen leveranciers erbij om dit soort draken van software op te leveren, en op deze manier te configureren. Volgens mij is 1 van de basisdingen dat je applicatieserver en databaseservers op 2 aparte machines installeerd :?

Door Tweakers user onhandigesjaak, maandag 24 augustus 2009 09:18

Amazing discoveries.

Leuk gemaakt met de foto's erbij.

Door Tweakers user ScytheNL, maandag 24 augustus 2009 09:21

Mwah, gebeurt vaker dan je denkt.

Hier op het werk draaien wij sinds een tijdje een nieuw administratief en voorraadtechnische applicatie en een nieuwe server met Windows server 2008 Standaard...De server is ongeveer van het kaliber wat hierboven is beschreven alleen dan maar 500GB in 2 disk raid geloof ik. Het software programma is een Bťta versie waar de foutmeldingen je om de oren vliegen en waar iedereen op de zelfde "demo" inlog zit te werken. Ook hier is gekozen voor 1 en dezelfde server voor applicatie en database omdat dat goedkoper is... lang verhaal kort: zodra er wat te besparen valt of mensen hebben het idee dat ze eerder kunnnen leveren doordat er geen verstand van zaken is of er niet naar word geluisterd (zoals in mijn geval) omdat er kosten bespaard moeten worden...

Het enige wat die server nu staat te doen is het nieuwe programma te draaien terwijl het eigenlijk de bedoeling was om de terminal server kant op te gaan. De rest van alle werkzaamheden gebeuren nog steeds lokaal dus die server staat uit z'n neus te vreten als een lamme.


Mooi verhaal iig. Ik kijk uit naar de volgende versie. :)

[Reactie gewijzigd op maandag 24 augustus 2009 09:22]


Door Tweakers user squaddie, maandag 24 augustus 2009 09:42

Erm..... Ben er gewoon stil van van zo'n knoeiwerk. In het verleden heb ik ook aan software ontwikkeling gedaan en daar zitten ook fouten in door onervarenheid maar zulk werk nee.

@ BM
Overigens is het met de moderne server steeds minder noodzakelijk om per rol een nieuwe server te hebben. Meestal is het niet de processor of geheugen wat de beperkende factor is van de server maar de schijven. Als je de applicaties over verschillende raidsets verdeelt zullen ze elkaar weinig in de weg zitten.


Door Tweakers user bechown, maandag 24 augustus 2009 10:04

Kreeg steeds de smaak van ..... in mijn mond bij dit stukje.. Veel te veel dll's waardoor ik op mijn ontwikkel pc het absoluut niet heb staan.. maar op een paar punten weer totaal niet.. Vaak worden bij grote ERP/HRM etc. applicaties die al lang bestaan door borduurd op oude manier van werken.. (DOS/Unix tijdperk) Waardoor de structuur wordt geprobeerd te handhaven zodat de volgende upgrade bij bestaande klanten geen problemen veroorzaken.. Daarnaast door het weglaten van tabelkoppelingen in de databasestructuur blijft de verkochte applicatie nodig.. Bijvoorbeeld zelf een koppeling maken voor een module die de firma zelf had kunnen verkopen.. Dit voorkomt natuurlijk ook externe problemen veroorzaakt door prutsers.. Dus tja wat is goed? Verkeerd is natuurlijk hoe het programma nu is.. Door de spaghetti die ontstaan is is het lastig nu een makkelijke upgrade uit te voeren naar een goede structuur waardoor de enige mogelijkheid is het programma volledig opnieuw te schrijven..

[Reactie gewijzigd op maandag 24 augustus 2009 10:11]


Door Tweakers user D2k, maandag 24 augustus 2009 10:04

OMFG @ die query. Dat kan je gewoon niet menen!

Door Tweakers user Apache, maandag 24 augustus 2009 10:22

Als jee consultant kom ik ook gepruts op grote schaal tegen ... niet echt iets heel uitzonderlijk jammer genoeg. Prijs & beste diner met management zijn nu eenmaal de doorslaggevende factoren bij de leverancier voor je applicatie kiezen. Eventueel ook nog het smeermiddel wat gebruikt word.

Verder als ik zo die structuur van de tabellen/dll's zie doet het mij sterk denken aan een code-generator op basis van een business model? Daar komt dan idd crap code uit die idd wel vaak doet waar het bedoeld voor is.

Oa cap gemini is daar wel fan van.

Het zou misschien niet slecht zijn om een grote schandpaal website te starten op internet met projecten, de uitvoerder en technische argumenten waarom die app nooit zou mogen bestaan, enkel de nda's houden me tegen :)

Door Tweakers user 0siris, maandag 24 augustus 2009 10:25

hmm...aan de tabelnamen te zien is het een duits ERP (zal geen namen noemen :P), maar het feit dat MSSQL 2005 std. edition gebruikt wordt, en de enorme hoeveelheid DLL's, en de mij niet bekende tabelnamen, doen vermoeden dat het hier niet om hťt duitse ERP gaat, tenzij het een enorm stuk maatwerk hierbovenop is, die deze ERP puur als framework gebruikt :)

Door Tweakers user ItsValium, maandag 24 augustus 2009 10:42

Dit zijn zaken die ik heel vaak tegenkom, laatst nog een bedrijf waar een ticketingsysteem in gebruik was die draaide op een cluster van vier servers met elke 4 xeons op en hopen geheugen, nog liep de applicatie traag. Net zoals hierboven beschreven werden er duizenden calls naar de DB gedaan per minuut die dan verwerkt werden door de clientsoftware (IN JAVA in godsnaam) waardoor de gebruikers dikwijls ettelijke minuten moesten wachten op de software.

Onbruikbaar, Onwerkbaar, heb daar op zes maand tijd (kort lopend project) alles overhoop gehaald, DB volledig herschreven en de van hun javaapplicatie afgestapt en naar een simpele webapplicatie gegaan middels php ... resultaat, twee servers zijn nu buiten dienst gesteld omdat ze compleet overbodig zijn en de langste opbouwtijd van een pagina is 0,9 seconden, waardoor de gebruikers tegenwoordig meer dan tevreden zijn. En ik een aanbod gekregen heb om bij hen in vast dienstverband te gaan (wat ik trouwens geweigerd heb)

Erg jammer hoe GROTE bedrijven zo'n brakke software uitleveren om dan nog te zwijgen over de prijzen die ervoor betaald worden.

Door Tweakers user Seroo, maandag 24 augustus 2009 10:47

Leuke blog, altijd leuk om te lezen hoe anderen de zooi verknoeien. Ook leuk gedaan met de plaatjes :P

Door Tweakers user MMaI, maandag 24 augustus 2009 10:54

ik zeg: insturen naar thedailywtf.com
je verhaal is schitterend geschreven en voor de meeste (applicatie)beheerders te herkenbaar voor woorden, ik dacht even dat je het over software had die bij mijn laatste project gebruikt werd XD (maar dat was in-house ontwikkeld ipv door MI)

Door Tweakers user Motrax, maandag 24 augustus 2009 11:12

0siris: het is niet HET Duitse ERP pakket, de tabelnamen in SAP zijn logisch voor een insider. Tenminste, als je Duits kunt en de grundlichkeit en uitzonderingen een beetje snapt :P En de historie en en... maar er zit een logica achter!

Ik moet van deze blog bijna huilen :'(

Door Tweakers user Apache, maandag 24 augustus 2009 11:22

@ItsValium:
Je doet alsof java daar een rol inspeelt, je kan in elke taal slecht programmeren, als je in php je hele db binnentrekt en daarin je bewerkingen doet loopt dat net zo goed slecht af.

Java zal indien goed gebruikt volgens mij zelfs een pak sneller zijn dan standaard php (volledige parsing vs bytecode+hotspot optimizations).

--
Dit doet mij trouwens terugdenken aan wat korte ervaring met navision, nu microsoft dynamics, dat ding maakte ook aan de lopende band tabellen aan. Dus ook zeker kans dat het dat is, als dat zo is kan dit best een interessant artikel zijn aangezien er nu een evaluatie onderweg is om naar dynamics te switchen.

[Reactie gewijzigd op maandag 24 augustus 2009 11:40]


Door Tweakers user garagaholic, maandag 24 augustus 2009 11:37

Wellicht toch handig om de naam van het pakket te noemen, zodat anderen niet in de valkuil die Monster Inc maakt trappen? Of ligt dat toch nog niet *iets* te gevoelig? :)

Door Tweakers user bredend, maandag 24 augustus 2009 12:56

Erg leerzaam verhaal!

Door Tweakers user Noork, maandag 24 augustus 2009 12:57

* Hier moet ik gepost hebben. Nou ja, gewoon een TVP. Wat een verschrikkelijk systeem. Dat zou ik niet eens gemaakt hebben.

Ben benieuwd of er volgende week een paar honderd tabellen en DLL's extra zijn :)

Door Tweakers user MM99, maandag 24 augustus 2009 14:40

Ik zou heel graag willen weten wie Monster Inc. is. Dan weet ik waar ik zeker geen zaken mee wilt doen.

Door Tweakers user BreezahBoy, maandag 24 augustus 2009 15:43

klinkt als een object relational semantic gap, waarbij de sql expert de neerslag van de objecten met attributen in tabellen ziet. de object jongens aan de client kant gebruiken de database kennelijk alleen als persistent storage en relateren de objecten in de client software met associations en andere oo middelen. maar sommige metrieken aan de client kant komen mij ook ongeloofwaardig voor hoor, zoveel dll's lijkt me overbodig; misschien gegenereerd?

[Reactie gewijzigd op maandag 24 augustus 2009 15:43]


Door Tweakers user Patriot, maandag 24 augustus 2009 15:52

Ergens vraag je je af hoe de mensen die het pakket gemaakt hebben dat hebben kunnen doen. Volgens mij vergt het heel veel concentratie om zo'n achterlijk ingewikkeld gedrocht af te krijgen.

Door Tweakers user curry684, maandag 24 augustus 2009 16:12

Briljante applicatie. Doe mij die projectarchitect om in dienst te nemen!

Door Tweakers user Erkens, maandag 24 augustus 2009 18:14

Het is dat het hier om MS SQL gaat, maar ik dacht direct aan dit topic: [MySQL] hoe te optimaliseren? :P

Door Tweakers user RobIII, maandag 24 augustus 2009 18:27

@Erkens: Dat topic verbleekt bij wat ik daar zag :P

Door Tweakers user Erkens, maandag 24 augustus 2009 19:09

Ik dacht bij het zien van dat topic dat het niet erger kon, blijkbaar had ik het fout :+

Door Tweakers user roy-t, maandag 24 augustus 2009 23:34

quote: NMal
ik zeg: insturen naar thedailywtf.com
Eensch met Nmal! Prachtig verhaal!

Door Tweakers user MueR, dinsdag 25 augustus 2009 00:40

Mn vriendin was helemaal blij toen ze het las. Ze dacht dat zij slecht was in database ontwerp :+

Door Tweakers user Archiebald, dinsdag 25 augustus 2009 12:12

OMG @ SQL statement :o

Heb zelf weinig tot geen ervaring met Windows servers, maar wat was de load/belasting van die server?

Door Tweakers user Erick81, woensdag 26 augustus 2009 09:30

Waar blijft part 6? Ben eigenlijk wel benieuwd hoe het gesprek bij Monsters Inc. is verlopen!

Door Tweakers user RobIII, woensdag 26 augustus 2009 09:32

Waar blijft part 6? Ben eigenlijk wel benieuwd hoe het gesprek bij Monsters Inc. is verlopen!
:D Dude! Ik heb meer te doen dan bloggen :P Maar trust me, 't komt er aan ;)

Door Tweakers user Erick81, woensdag 26 augustus 2009 10:07

Snap ik! Zeker zolang er bedrijven zoals Monsters Inc. bestaan :P Ben alleen erg nieuwsgierig ;)

Ik hou je blog wel in de gaten!

ps,
geen tijd om te bloggen maar wel in 2 minuten reageren? Ga eens werken man :P

Reageren is niet meer mogelijk