Logica in database of code: Wat is een goed ontwerp?

[-RenE-]

In de meeste databases kan een groot deel van de applicatie logica worden geimplementeerd d.m.v. o.a. stored procedures en triggers. Een groot voordeel hiervan is de robuustheid van de applicatie: Alle aanroepen gaan via de database, die fouten er uithaalt. Tegelijkertijd doet deze wijze van ontwikkelen een aanslag op de schaalbaarheid en performance: Het aantal database trips neemt sterk toe.

Het valt mij op dat veel bestaande webapplicaties gebruik maken van MySQL en de database alleen voor data-opslag en niets meer gebruiken. Is dit nu verstandig design of is dit onbekendheid met wat complexere databases zouden kunnen doen? En is dit verstandig?
Hetzelfde zie ik bij het gebruik van Frameworks. Neem Symfony, een PHP-framework gebaseerd op Ruby-on-Rails. Hierbij wordt de database in objecten gegoten, waardoor applicatie logica in de database vrijwel onmogelijk wordt. Wederom de vraag: Is dit verstandig?

Ik sta op het punt om een nieuwe webapplicatie te ontwikkelen en wordt dus opnieuw geconfronteerd met deze vragen. Graag zou ik jullie mening horen over deze zaken? Discussie dus....

Brand maar los!

[seamus21]

Meestal is de vraag is dit verstandig? verbonden met Wat heb ik nodig? En welke oplossingen zijn hiervoor? Wat zijn de voordelen van een keuze en wat zijn de nadelen?

Als blijkt dat na het bekijken van de oplossingen een bepaald iets beter uit de bus komt dan kies je natuurlijk daarvoor.

[ Voor 12% gewijzigd door seamus21 op 25-06-2006 11:40 ]

[Gurbe de n00b]

Ik gebruikte eerst altijd MySQL icm met PHP,

Ben nu overgegaan naar SQL-Server icm Met ASP.Net C#,
Ik moet zeggen dat dat wel heel lekker werkt.

Vooral de database vind ik een grote verbetering.
Gewoon 1 engine die overal ondersteuning voor biedt.

[Kama]

Mijn mening... Omdat een webapplicatie geen instanties van objecten over meerdere pagina's kan vasthouden, ben je genoodzaakt om deze instanties voortdurend uit de database op te halen (bijv. accountgegevens). (edit: het KAN natuurlijk wel, met cookies of zoiets, maar dat is imo onveilig cq slecht design).

Je kunt dus imo beter dit optimaliseren: Het is niet efficient om een instantie uit een database te halen, er vervolgens een bewerking op te doen en daarna weer weg te schrijven naar de database. Het is dan efficienter om met 1 sp de bewerking uit te laten voeren.

Of het mooi is, is een tweede. Je loopt er wel tegenaan dat je logica verdeeld gaat zijn over de logica in je applicatie en in de database. Erger nog, sommige dingen zul je misschien wel synchroon moeten gaan houden. (Bijv: settings/constanes die je in je logica gebruikt, zul je soms in je logica en soms in de sp's willen gebruiken).

[ Voor 7% gewijzigd door Kama op 25-06-2006 11:53 . Reden: nuancering ]

[Kama]

Gurbe de n00b schreef op zondag 25 juni 2006 @ 11:42:
Ben nu overgegaan naar SQL-Server icm Met ASP.Net C#,
Ik moet zeggen dat dat wel heel lekker werkt.

Volgens mij was de bedoeling van de TS meer om het over het concept te hebben. Niet zozeer met welke tools je daar invulling aan geeft

Ik gebruik overigens ook sql server, asp.net / c# voor m'n webapps

[ Voor 2% gewijzigd door Kama op 25-06-2006 11:51 . Reden: Typo's ]

[seamus21]

Kama schreef op zondag 25 juni 2006 @ 11:48:
Mijn mening... Omdat een webapplicatie geen instanties van objecten over meerdere pagina's kan vasthouden, ben je genoodzaakt om deze instanties voortdurend uit de database op te halen (bijv. accountgegevens).

Je kunt dus imo beter dit optimaliseren: Het is niet efficient om een instantie uit een database te halen, er vervolgens een bewerking op te doen en daarna weer weg te schrijven naar de database. Het is dan efficienter om met 1 sp de bewerking uit te laten voeren.

Of het mooi is, is een tweede. Je loopt er wel tegenaan dat je logica verdeeld gaat zijn over de logica in je applicatie en in de database. Erger nog, sommige dingen zul je misschien wel synchroon moeten gaan houden. (Bijv: settings/constanes die je in je logica gebruikt, zul je soms in je logica en soms in de sp's willen gebruiken).

Webapplicaties gemaakt met bv Struts enzo en draaiend op een aplicatieserver zoals Tomcat kunnen prima objecten bewaren. Je hoeft het dan echt niet steeds in de database te controleren. Als je gegevens op lange termijn wil opslaan moeten ze natuurlijk wel in iets van een database.

[whoami]

Hoe zit het met onderhoudbaarheid van je code als je alle logica in je DB -dmv triggers en SP's- zet ? Het zal wellicht performanter zijn om het zo te doen, maar, ik vind het geen goed idee om je logica in je DB te plaatsen.
Op dit moment ben ik nogal geinteresseerd in Domain Driven Design en Unit Test/Test Driven Development. In deze aanpak gaat men de business logica dmv een 'model' gaan voorstellen. Er worden Unit Tests geschreven om ervoor te zorgen dat je geimplementeerde Business Logica correct
is (dan moet je natuurlijk wel goede tests hebben). Ik kan me voorstellen dat het schier onmogelijk is (of toch heel moeilijk) om dergelijke automatische tests te schrijven voor Business Logica die zich in een Trigger bevindt.

Ik zeg niet dat BL in de DB not done is - voor bepaalde dingen zou ik het ook verkiezen; bv echte data intensieve batch processen bv-, maar ik zou er voor kiezen om de echte 'core logica' niet in de DB te hebben. Stel je bv eens voor dat je een applicatie hebt, die verschillende DBMS'en ondersteunt (Sql Server, Oracle, ...). Dan zal je diezelfde logica voor ieder type DB opnieuw moeten implementeren en onderhouden.

De keuze om de logica al of niet in de DB te plaatsen hangt af van situatie tot situatie, maar over het algemeen verkies ik er voor om deze niet in de DB te hebben. (Onderhoudbaarheid, testbaarheid, duidelijkheid).

Een ander topic over dit onderwerp vind je ook hier:
[rml][ Alg] Business Logic in de database[/rml]

[whoami]

Dit is trouwens eerder iets wat in Software Engineering & Architecture thuishoort.

-> SE&A

[Kama]

whoami schreef op zondag 25 juni 2006 @ 12:03:
Hoe zit het met onderhoudbaarheid van je code als je alle logica in je DB -dmv triggers en SP's- zet ? Het zal wellicht performanter zijn om het zo te doen, maar, ik vind het geen goed idee om je logica in je DB te plaatsen.

Geheel mee eens, maar we hebben het hier specifiek over webapplicaties... Daar moet je noodgedwongen toch vaak de instanties en states weer ergens vandaan halen...

Als je altijd alle data bij de hand kunt houden hebt, moet je vooral al je logica werkt een echt model het beste. Je hoeft dan alleen maar te zorgen dat alle delta's die je in je model veroorzaakt weer wegschrijft naar je database. (mja, dat kun je mooi in een andere laag doen).

Je kunt dit wel voor webapplicaties simuleren, maar dan is je database dus je "memory" en dan moet je voor iedere scheet een call naar de DB maken. Dat schiet niet op in een webapplicatie, waar potentieel 100-en mensen op werken.

[Vedett.]

-RenE- schreef op zondag 25 juni 2006 @ 11:36:
Tegelijkertijd doet deze wijze van ontwikkelen een aanslag op de schaalbaarheid en performance: Het aantal database trips neemt sterk toe.

Ik geloof in het tegenovergestelde. Ik ben zeker voorstander om zoveel mogelijk logica in code te implementeren. Maar als ik daar te veel round trips voor nodig heb naar de DB, dan maak ik een SP aan. Triggers vind ik helemaal overbodig ivm logica.

Stel, je moet een of ander veld update voor al de personen die ouder zijn dan 65j plus die nog aan 1 of 2 voorwaarden voldoen. Als je dit in code wilt implementeren ga je veel te veel data eerst uit de DB halen, controleren en indien nodig terug updaten. Een stored procedure kan dit wel in één update statement. De performantie gaat dus een stuk omhoog.
(Laten we sql in code schrijven buiten beschouwing laten. Daar hou ik ook niet van.)

[whoami]

Vedett. schreef op zondag 25 juni 2006 @ 14:13:
[...]


(Laten we sql in code schrijven buiten beschouwing laten. Daar hou ik ook niet van.)

Waarom niet ?
Sql is gewoon een 'domain specific language', en waarom zou je niet verschillende talen kunnen gebruiken om je logica te implementeren ?
Het is dan natuurlijk wel netjes om alle DAL code gescheiden te houden door bv TableGateway's te gebruiken, en waarvan je abstractie kunt maken.
Je 'applicatie-code' heeft dan bv een soort 'Service' class, die de juiste method uit een TableGateway gaat gaan aanroepen, en die doet dat bepaalde UPDATE statement.

[Anoniem: 99283]

Vedett. schreef op zondag 25 juni 2006 @ 14:13:
[...]

Ik geloof in het tegenovergestelde. Ik ben zeker voorstander om zoveel mogelijk logica in code te implementeren. Maar als ik daar te veel round trips voor nodig heb naar de DB, dan maak ik een SP aan.

Over het algemeen is dat mijns inziens eerder een indicatie dat je met een te simpele data access solutie werkt (een voorbeeld hiervan lijkt me het n+1 select probleem). Verder ben ik het wel met je eens; ik ben geen voorstander van het verplaatsen van business logica van je business tier naar je data tier. Door deze fragmentatie wordt je applicatie simpelweg minder beheersbaar.

Andere kant van het verhaal is natuurlijk: als de topicstarter veel meer ervaring heeft met de door hem beschreven methode en die methode voldoet vooralsnog, dan kan het een verstandige keuze zijn om die methode aan te houden voor de opdracht in kwestie. Pionieren met (voor jezelf) nieuwe methodes is niet altijd even verstandig onder de druk van een deadline.

[ Voor 7% gewijzigd door Anoniem: 99283 op 25-06-2006 14:39 ]

[Anoniem: 99283]

Kama schreef op zondag 25 juni 2006 @ 11:48:
Mijn mening... Omdat een webapplicatie geen instanties van objecten over meerdere pagina's kan vasthouden, ben je genoodzaakt om deze instanties voortdurend uit de database op te halen (bijv. accountgegevens). (edit: het KAN natuurlijk wel, met cookies of zoiets, maar dat is imo onveilig cq slecht design).

Je zit voor het cachen van objecten heus niet aan cookies vast
Denk bijv aan de Application, Session en Request objecten, of begrippen als first- en second-level cache.

[Vedett.]

whoami schreef op zondag 25 juni 2006 @ 14:28:
[...]

Waarom niet ?
Sql is gewoon een 'domain specific language', en waarom zou je niet verschillende talen kunnen gebruiken om je logica te implementeren ?

Het vervuild de code heel erg vind ik. Het leest ook helemaal niet prettig, al die " "+ ? + " ".
Plus, er zijn er nog altijd die blijven zweren bij SP's, ook onze DBA. Volgens hem zou het veel minder problemen geven ivm locks en optimistic concurency. Plus het zou nog altijd een beetje performanter zijn.

[Vedett.]

Anoniem: 99283 schreef op zondag 25 juni 2006 @ 14:37:
[...]

Over het algemeen is dat mijns inziens eerder een indicatie dat je met een te simpele data access solutie werkt (een voorbeeld hiervan lijkt me het n+1 select probleem).

Verplaatsen van logica naar de data acces, is ongeveer hetzelfde als logica verplaatsen naar de stored procedure. Het is een bijde een andere logische laag. Het enige verschil is dat de database fysiek ook ergens anders staat.

Dus logica naar de data acces laag verplaatsen voelt voor mij hetzlefde aan als logica naar de stored procedure verplaatsen.

[Anoniem: 99283]

Vedett. schreef op zondag 25 juni 2006 @ 15:33:
[...]


Het vervuild de code heel erg vind ik. Het leest ook helemaal niet prettig, al die " "+ ? + " ".
Plus, er zijn er nog altijd die blijven zweren bij SP's, ook onze DBA. Volgens hem zou het veel minder problemen geven ivm locks en optimistic concurency. Plus het zou nog altijd een beetje performanter zijn.

Je hoeft je query-code toch ook niet op die manier in je applicatie op te nemen? Die specificeer ik gewoon samen met de andere meta-data voor de O/R-mapper. Het performantie-argument is overigens behoorlijk achterhaald, maar daarvoor verwijs ik je liever door naar de posts op Frans Bouma's weblog erover.

[ Voor 12% gewijzigd door Anoniem: 99283 op 25-06-2006 16:28 ]

[Anoniem: 99283]

Vedett. schreef op zondag 25 juni 2006 @ 15:39:
[...]


Verplaatsen van logica naar de data acces, is ongeveer hetzelfde als logica verplaatsen naar de stored procedure. Het is een bijde een andere logische laag. Het enige verschil is dat de database fysiek ook ergens anders staat.

Dus logica naar de data acces laag verplaatsen voelt voor mij hetzlefde aan als logica naar de stored procedure verplaatsen.

Volgens mij is dat niet het geval, omdat dergelijke functionaliteit generiek kan worden geïmplementeerd in de data access laag.

[ Voor 5% gewijzigd door Anoniem: 99283 op 25-06-2006 15:53 ]

[whoami]

Mensen, mag ik even wijzen op het bestaan van de edit-knop ?

Een SP hoeft idd niet performanter te zijn dan een parametrized query. Het enige waar een SP wel z'n voordeel kan uithalen, dat is dat je soms kan besparen op round-trips naar de DB.
En DBA's zijn al altijd fans geweest van logica in de DB. Dat zie ik als een soort van zelfbescherming voor zichzelf, dus dergelijke argumenten vind ik niet echt overtuigend.

[JaQ]

whoami schreef op zondag 25 juni 2006 @ 16:11:
Mensen, mag ik even wijzen op het bestaan van de edit-knop ?

Een SP hoeft idd niet performanter te zijn dan een parametrized query. Het enige waar een SP wel z'n voordeel kan uithalen, dat is dat je soms kan besparen op round-trips naar de DB.
En DBA's zijn al altijd fans geweest van logica in de DB. Dat zie ik als een soort van zelfbescherming voor zichzelf, dus dergelijke argumenten vind ik niet echt overtuigend.

Een DBA die het aantal roundtrips naar de database aanhaalt die (pardon my french) lult uit zijn nek. Zelfbescherming door het zelf kunnen aanpassen van code zou zeker ook geen reden tot een stored procedure danwel trigger mogen zijn. Sterker nog, het risico op foutief aanpassen van code is veel te groot en kan daarom uberhaupt niet.

Een database is bedoeld om je data zo integer mogelijk te bewaren. Dit betekend dat bepaalde logica in de database thuis hoort en soms inderdaad in een stored procedure of een trigger. Een RDBMS is geen filesystem waar je toevallig een ander taaltje (genaamd SQL) tegen praat, het is een robust product dat uitgebreide mogelijkheden kent. Gebruik die dan ook!

Persoonlijk spuug ik regelmatig in de richtig van (meestal java) ontwikkelaars die met behulp van die fijne object mappers SQL genereren. De ontwikkelaar van de "lazy sql" optie in hypernate verdient imho een langzame en pijnlijke dood. De troep die daar 90% van de tijd uit komt rollen durf ik in ieder geval geen SQL te noemen. Het eenvoudiger maken van de toegang tot de database betekend niet dat de kwaliteit van de code daardoor omhoog gaat!

Een paar simpele voorbeelden van problemen:

• ontbreken of foutief gebruik van bindvariables (zowel voor Oracle als SQL-server) Geef die dingen eens een naam, ipv een nummer! Is wel zo fijn voor de optimizer
• Case insensitive zoeken (hoezo je doet upper() om je kolom heen, denk je dat je dan nog een index gebruikt?)
• sql-tuning, of eigenlijk vooral het ontbreken van de juiste mogelijkheden. Het kan wel, maar dan wordt de code opeens onbeersbaar volgens de meeste ontwikkelaars 2 x raden waarom: het is niet meer standaard gegenereerd

Verder vind ik persoonlijk dat:

• een trigger prima gebruikt kan worden voor het uitdelen van een sequence nummer
• sorteren van data sneller in de database kan dan in code
• iedere ontwikkelaar de basis principes van zowel database ontwerp als sql-tuning moet kennen (explain plan anyone?)
• ontwikkelaars ook wel eens naar de nieuwe features van het door hun gebruikte RDBMS mogen kijken en niet alleen maar over nieuw platform X voor hun favoriete taal moeten kwijlen

De database is nou eenmaal een belangrijk onderdeel van een applicatie, maar imnsho wordt dit onderdeel door veel ontwikkelaars als minder belangrijk beschouwd. Toch valt hier veel winst te halen (echter enkel door het wijzigen van database parameters door een DBA valt niet meer dan een procent of vijf te winnen).

_{Ik ben Oracle DBA met als specialisme Oracle applicatie servers. Mijn dagelijkse bezigheden zijn het tunen en optimaliseren van j2ee applicaties op Oracle AS in combinatie met Oracle RDBMS-en. Ik durf mezelf dus wel een gefrustreerde ervaringsdeskundige te noemen}

[whoami]

Er zijn natuurlijk altijd afwegingen die je moet maken als je een O/R mapper gebruikt.
De vraag die je dan stelt is; weegt de (vaak minieme) performance winst die je kan behalen door geen O/R mapper te gebruiken op, tegenover de productiviteits-winst die je kan behalen als je wel een O/R mapper gebruikt ?

Bepaalde dingen kunnen natuurlijk in de DB, maar, uit onderhoudbaarheids-overwegingen, test-mogelijkheden, etc... zou ik toch stellen dat de meeste logica niet in de DB thuis hoort.

Sommigen zien de DB als een belangrijk onderdeel van de applicatie, anderen zien het als een implementatie-detail.
Echter, het is niet zo dat de DB het hart van de applicatie is. De business-logica, de domein-laag, is het hart van de applicatie. Deze bevat nl. de logica en de regels die moeten toegepast worden om de applicatie te laten doen wat ze moet doen.

Het is wel zo dat een goed data-model een groot stuk van je performance bepaald. Een slecht datamodel kan je performance naar de haaien helpen. Maar daar gaat het hier eigenlijk niet over.
Tuurlijk is het sorteren van de data iets dat in de DB thuishoort (maar dat kan je moeilijk 'logica' noemen), en ik vind ook dat je als ontwikkelaar toch wel iets van SQL moet kennen, en wat van performance tuning moet kennen, maar, als ik moet kiezen tussen een applicatie waarbij alle logica dmv SP's en triggers in de DB zit, en een applicatie waar de logica (op een goede manier) in de applicatie zit (dmv een business layer bv), dan kies ik toch voor het 2de; al is de eerste performanter.
(Ervan uitgaande natuurlijk dat de 2de ook performant genoeg is).

[JaQ]

whoami schreef op zondag 25 juni 2006 @ 17:56:
Er zijn natuurlijk altijd afwegingen die je moet maken als je een O/R mapper gebruikt.
De vraag die je dan stelt is; weegt de (vaak minieme) performance winst die je kan behalen door geen O/R mapper te gebruiken op, tegenover de productiviteits-winst die je kan behalen als je wel een O/R mapper gebruikt ?

Ik ben absoluut voor het gebruik van een O/R mapper, maar volgens mij kan je de SQL die een mapper genereerd best beinvloeden. Daar heb je last van als je later dingen anders wilt (true), maar de winst die je daar mee haalt is enorm. Sommige (voornamelijk batchmatige) routines werken echter wel beter vanuit de DB (of als OS script), waarbij je beheersbaarheid ook als argument moet meenemen.

whoami schreef op zondag 25 juni 2006 @ 17:56:
Bepaalde dingen kunnen natuurlijk in de DB, maar, uit onderhoudbaarheids-overwegingen, test-mogelijkheden, etc... zou ik toch stellen dat de meeste logica niet in de DB thuis hoort.

Logica hoort in een business layer. In het geval van Java is dat dus niet in de database. Toch is het wel prettig als op zijn mist de minimale beperkingen (uniciteits constraints, foreign key's etc.) wel aanwezig zijn (soms kom je dingen tegen ). Ik vind het echter onzin dat code in de database niet beheerbaar zou zijn, alsmede niet onderhoudbaar. Dat er weinig tools zijn die het overzicht behouden als code zowel in een database als in een applicatie zit mag hiervoor geen excuus zijn.

whoami schreef op zondag 25 juni 2006 @ 17:56:
Sommigen zien de DB als een belangrijk onderdeel van de applicatie, anderen zien het als een implementatie-detail.
Echter, het is niet zo dat de DB het hart van de applicatie is. De business-logica, de domein-laag, is het hart van de applicatie. Deze bevat nl. de logica en de regels die moeten toegepast worden om de applicatie te laten doen wat ze moet doen.

De DB is niet het hart, maar wel een core onderdeel. Overigens is het in niet-webapplicaties gebruik om de domein laag in de database te leggen. Dat verklaart de haslstarrigheid van een hoop DBA's. Het kan wel, de vraag is of het "good practice" is.

whoami schreef op zondag 25 juni 2006 @ 17:56:
Het is wel zo dat een goed data-model een groot stuk van je performance bepaald. Een slecht datamodel kan je performance naar de haaien helpen. Maar daar gaat het hier eigenlijk niet over.

Ik heb hier op GoT al vele malen naar een artikel van Tom Kyte over generieke database ontwerpen verwezen. Dat is een voorbeeld bij uitstek.

whoami schreef op zondag 25 juni 2006 @ 17:56:
Tuurlijk is het sorteren van de data iets dat in de DB thuishoort (maar dat kan je moeilijk 'logica' noemen),

ik kom anders ladingen applicaties tegen die alles maar in geheugen op de AS jassen en vervolgens gaan sorteren. (de laatste was zowaar zelfs een front-end op een data warehouse van een paar honderd TB ). Ook zie ik steeds meer omgevingen waar de applicatie maar zoveel mogelijk in memory houd om dat vervolgens op verschillende plaatsen (en in verschillende sessies) te hergebruiken. Data integriteit is daarbij blijkbaar niet meer belangrijk (records in een database kunnen geupdate worden....)

whoami schreef op zondag 25 juni 2006 @ 17:56:
en ik vind ook dat je als ontwikkelaar toch wel iets van SQL moet kennen, en wat van performance tuning moet kennen,

Iets meer dan een beetje zou prettig zijn, aangezien er als DBA niets veranderd kan (en mag) worden aan een O/R mappen (iets wat overigens terecht is, aangezien dit ook in de applicatie grote gevolgen kan hebben). Een basis cursus database internals is voor veel ontwikkelaars op zijn plaats.

whoami schreef op zondag 25 juni 2006 @ 17:56:
maar, als ik moet kiezen tussen een applicatie waarbij alle logica dmv SP's en triggers in de DB zit, en een applicatie waar de logica (op een goede manier) in de applicatie zit (dmv een business layer bv), dan kies ik toch voor het 2de; al is de eerste performanter.
(Ervan uitgaande natuurlijk dat de 2de ook performant genoeg is).

Alle logica ergens neerleggen is volgens mij nooit een goede keuze, het kan best een verdeling zijn... Overigens vind ik het maken van een database onafhankelijke applicatie geen argument. Daar geloof ik uberhaupt niet in. Iedere database heeft zijn eigen SQL dialect en karakterastieken. Dit impliceerd verschillende gedrag op dezelfde query en derhalve verschillende performance.

[whoami]

JaQ schreef op zondag 25 juni 2006 @ 18:31:
[...]


Toch is het wel prettig als op zijn mist de minimale beperkingen (uniciteits constraints, foreign key's etc.) wel aanwezig zijn (soms kom je dingen tegen ).

Helemaal mee eens.

Ik vind het echter onzin dat code in de database niet beheerbaar zou zijn, alsmede niet onderhoudbaar. Dat er weinig tools zijn die het overzicht behouden als code zowel in een database als in een applicatie zit mag hiervoor geen excuus zijn.

Mijn ervaring zegt me toch dat BL geimplementeerd mbhv T-SQL of PL/SQL oid in triggers / SP's een hel zijn.

Overigens vind ik het maken van een database onafhankelijke applicatie geen argument. Daar geloof ik uberhaupt niet in. Iedere database heeft zijn eigen SQL dialect en karakterastieken. Dit impliceerd verschillende gedrag op dezelfde query en derhalve verschillende performance.

Dat is waar de O/R mapper bij kan helpen. En als je dat niet hebt, kan je voor iedere DBMS een aparte data-laag schrijven. De applicatie gebruikt dan de juiste implementatie daarvan; iedere implementatie is dan op maat gemaakt voor die specifieke dbms.

Alle logica ergens neerleggen is volgens mij nooit een goede keuze, het kan best een verdeling zijn...

Er kan idd een verdeling zijn; en niet alle logica hoeft in dezelfde taal geschreven te zijn, zoals ik al eerder in deze thread zei.

_{maar nu ga ik f1 kijken.}

[ Voor 11% gewijzigd door whoami op 25-06-2006 18:52 ]

[soulrider]

Algemeen beantwoord (en in mijn ogen/mening):

is de database server en web server volledig in eigen beheer:
minimale logica in database
slim design van query's in code.
meeste logica in code.
omdat het toch gezien moet worden als 1 geheel.

de webserver bouwt de weergave op en toont dit aan de gebruiker/bezoeker.
(de database-server staat quasi naast de webserver - of is zelfs hetzelfde machine terwijl de gebruiker/ site-bezoeker net zo goed aan de andere kant van de wereld kan zitten)

gebruik je het eerder voor bv verkopers die off-site zijn en een door jou ontwikkeld programma gebruiken voor database-toegang dan plaats je best veel logica in de database en weinig in de programma's.

dit laatste zodat ze niet bij elke update van de database of query's dat programma moeten laten aanpassen, maar een SP triggeren, en de data afwachten.
voordeel dat de sql-query's niet over onbekende netwerken moeten gaan om dan pas aan de database te geraken (met alle ev. manipulatie onderweg).

zij hebben al een programma voor de opbouw, zij hebben enkel de data nodig voor onderweg.
de pc die zorgt voor weergave/opvragen van data kan net zo goed aan de andere kant van de wereld staan tov de database-server. (als het een eigen ontwikkeld programma is eh )
(dan kan het gerust zijn dat er nog een verkoper met een oude versie op stap is maar ook zijn programma blijft werken met een ev. aangepaste database en SP: zolang het maar de zelfde namen blijft gebruiken in de communicatie terug naar dat programma ...)

Je moet het dus een beetje zien per toepassing van de database:

waar de data zit, waar de verwerking van de data moet gebeuren en de opbouw naar de gebruiker toe, en waar die gebruiker zit ...

[ Voor 16% gewijzigd door soulrider op 26-06-2006 01:44 ]

[JaQ]

whoami schreef op zondag 25 juni 2006 @ 18:51:
Mijn ervaring zegt me toch dat BL geimplementeerd mbhv T-SQL of PL/SQL oid in triggers / SP's een hel zijn.

Vergelijkbaar met mijn ervaringen van O/R mappers dus Laten we het er maar op houden dat het in beide gevallen netjes kan, maar niet altijd gebeurt...

[Anoniem: 154981]

Wat in de praktijk voor mij het beste heeft gewerkt is om database en applicatie gescheiden te houden. Mensen met databasekennis maken het datamodel en alle queries. Deze worden in stored procedures gezet.

Applicatie-ontwikkelaars krijgen alleen toegang tot exact die stored stored procedures die zij nodig hebben. De interface daarvoor wordt afgesproken. Welke stored procedure met welke parameters roep je aan en wat kun je als result-set en/of returnwaarde terug verwachten.

De grap is dat de gehele database geredesigned kan worden, maar zolang de stored procedures maar hetzelfde blijven werken, merkt de buitenwereld hier niets van.

Over het algemeen blijfkt alles zo beter en netter werkt. Ook is het (mits goed gedaan) vaak veiliger dan SQL in programmacode. Ook heb ik sterkte twijfels over de SQL kwaliteiten van de gemiddelde programmeur. De queries die je dan soms ziet, zijn echt om te huilen.

Maar er zijn ook nadelen:

- Je bent afhankelijk van de gebruikte database. Een port naar een andere database betekent dat de stored procedures opnieuw geschreven moeten worden. In de praktijk gebeurd zoiets echter zelden is mijn ervaring. Ook een database zonder stored procedures is vaak niet zomaar te porten, omdat er toch teveel in een bepaalde SQL variant is geschreven.

- Als je volledig OO wilt werken, kun je objecten mbv OR mapping in de database stoppen. Je schrijft dan zelf geen SQL. De mapper doet alles. Dit kan erg fijn werken en voorkomt het schrijven en onderhouden van stored procedures. De code is wel erg gekoppeld aan de database en deze kan lastig los van de applicatie geoptimaliseerd worden de scheiding DB<->Applicatie met een duidelijk afgesproken interface (zoals hierboven besproken) is weg. Ook is een echte OO database meer geschikt hiervoor. Toch worden ze erg weinig gebruikt. Jammer.

Waar je welke logica stopt, blijft een lastig verhaal. Bij O/R mapping zit alle logica in de applicatie.
Doe je dit niet, dan heb je meer mogelijkheden. Mijn voorkeur is om de logica die zorgt voor de integriteit van het datamodel in de database te stoppen, maar om alle logica daarboven in de applicatie te stoppen. Ofwel door het aanroepen van de stored procedures kun je nooit een niet correct datamodel krijgen / het model gebruiken op een manier hoe het bedoeld is. (even ervan uitgaan dat je niet alle regels van je model in foreign key relaties en (unique) contraints kan vatten)

Dus dat een order altijd aan een klant gekoppeld moet zijn stop je in de database.
Iets als minimale ordergrootte / prijs zit in de applicatie, dat kan in de toekomst wijzigen, zonder dat de bestaande data incorrect wordt. Misschien is dit laatste wel een goede richtlijn (tenzij je voor OR mapping gaat...)

[ Voor 22% gewijzigd door Anoniem: 154981 op 26-06-2006 22:48 ]

[kenneth]

Anoniem: 154981 schreef op maandag 26 juni 2006 @ 22:41:
Over het algemeen blijfkt alles zo beter en netter werkt. Ook is het (mits goed gedaan) vaak veiliger dan SQL in programmacode.

Mits goed gedaan maakt het helemaal niets uit.

[Anoniem: 154981]

kenneth schreef op maandag 26 juni 2006 @ 22:47:
[...]
Mits goed gedaan maakt het helemaal niets uit.

Idd MITS goed gedaan

Wat ik meer bedoel te zeggen, is dat de praktijkvoorbeelden van handgeschreven SQL in een applicatie die ik gezien heb, over het algemeen meer te wensen overlieten (qua veiligheid en onderhoudbaarheid) dan de applicaties die gebruik maken van stored procedures.

OR mapping blijft een ander verhaal... Maar ook daar komt in eerste instantie handwerk bij kijken dat goed moet gebeuren.

Verder kan ik me geheel bij jaQ aansluiten... Zo gemakkelijk is het allemaal nog niet en de database is belangrijker dat je denkt en niet zomaar een filesysteem. Vooral als de performance goed moet blijven bij grote hoeveelheden gegevens. Ik heb een tijdje terug nog een voorbeeld gezien van een mooi OR model dat zodra de database iets groter werd voor geen meter meer performde. Toen ervaren DBA'ers er naar keken konden ze wel huilen... Nadat het geheel met de hand opnieuw gedaan was. Juiste relaties, typen, indexen etc... wat voor een database werkt en niet wat handig / gebruikelijk is (in dit geval) Java. En waarempel het blijkt wel snel te kunnen werken :-)

[ Voor 38% gewijzigd door Anoniem: 154981 op 26-06-2006 23:03 ]

[whoami]

Anoniem: 154981 schreef op maandag 26 juni 2006 @ 22:41:
Wat in de praktijk voor mij het beste heeft gewerkt is om database en applicatie gescheiden te houden. Mensen met databasekennis maken het datamodel en alle queries. Deze worden in stored procedures gezet.

Applicatie-ontwikkelaars krijgen alleen toegang tot exact die stored stored procedures die zij nodig hebben. De interface daarvoor wordt afgesproken. Welke stored procedure met welke parameters roep je aan en wat kun je als result-set en/of returnwaarde terug verwachten.

Dit vind ik een achterhaald idee; een beetje hokjes cultuur, of paardenbril mentaliteit.
Of laat ons eerder zeggen dat het begrip programmeur misschien achterhaald is. Een software ontwikkelaar van 'bedrijfssystemen' moet op de hoogte zijn van database-ontwerp, SQL kennis hebben, weten hoe hij z'n queries kan optimaliseren , etc....

De grap is dat de gehele database geredesigned kan worden, maar zolang de stored procedures maar hetzelfde blijven werken, merkt de buitenwereld hier niets van.

Tja, maar als er dan een bepaalde functionaliteit moet bijkomen / aangepast worden, dan is het wachten op die database-gast tot wanneer hij zich de moeite genomen heeft om de gewenste aanpassing te doen.

Over het algemeen blijfkt alles zo beter en netter werkt. Ook is het (mits goed gedaan) vaak veiliger dan SQL in programmacode. Ook heb ik sterkte twijfels over de SQL kwaliteiten van de gemiddelde programmeur. De queries die je dan soms ziet, zijn echt om te huilen.

Waarom zou het veiliger zijn dan parametrized queries in programma-code ?

- Als je volledig OO wilt werken, kun je objecten mbv OR mapping in de database stoppen. Je schrijft dan zelf geen SQL. De mapper doet alles. Dit kan erg fijn werken en voorkomt het schrijven en onderhouden van stored procedures. De code is wel erg gekoppeld aan de database en deze kan lastig los van de applicatie geoptimaliseerd worden de scheiding DB<->Applicatie met een duidelijk afgesproken interface (zoals hierboven besproken) is weg. Ook is een echte OO database meer geschikt hiervoor. Toch worden ze erg weinig gebruikt. Jammer.

Een OO database heeft ook nadelen; ikzelf vind een RDBMS nog altijd de ideale manier om kritische gegevens op te slaan. Het is mogelijk om naar een OO model te mappen, ivm raportage is een RDBMS imho nog altijd zeer geschikt, en wat als je een andere view op je model wilt hebben ?
Zie ook de discussie die ik met questa hierover had.

Waar je welke logica stopt, blijft een lastig verhaal. Bij O/R mapping zit alle logica in de applicatie.
Doe je dit niet, dan heb je meer mogelijkheden. Mijn voorkeur is om de logica die zorgt voor de integriteit van het datamodel in de database te stoppen

Ja, maar dit is geen 'business logica', en ik denk dat de TS het wel daar over had.
Tuurlijk moet je de mogelijkheden die de DB biedt (foreign keys, unique constraints, domains, etc...) volledig gaan benutten, en dergelijke dingen niet in applicatie code gaan doen.

Maar goed, iedereen heeft zijn eigen manier van werken, en de 'enige juiste weg' bestaat niet.

[Anoniem: 154981]

whoami schreef op maandag 26 juni 2006 @ 23:18:
[...]
Dit vind ik een achterhaald idee; een beetje hokjes cultuur, of paardenbril mentaliteit.
Of laat ons eerder zeggen dat het begrip programmeur misschien achterhaald is. Een software ontwikkelaar van 'bedrijfssystemen' moet op de hoogte zijn van database-ontwerp, SQL kennis hebben, weten hoe hij z'n queries kan optimaliseren , etc....

Dit zou ideaal zijn en bij goede ontwikkelaar is dit het geval. De praktijk is echter vaak HEEL erg anders... Zeker bij instellingen en bedrijven waar mensen al jaren op een bepaalde plek zitten.

Tja, maar als er dan een bepaalde functionaliteit moet bijkomen / aangepast worden, dan is het wachten op die database-gast tot wanneer hij zich de moeite genomen heeft om de gewenste aanpassing te doen.

Dit klopt inderdaad vaak als het gaat om de bovengenoemde situatie. Bij een klein team gaat dit meestal flexibeler.

Waarom zou het veiliger zijn dan parametrized queries in programma-code ?

Is het niet. Zie boven. Ik had duidelijker moeten zijn in het onderscheid in wat er kan in tegenstelling tot wat je vaak tegenkomt in de praktijk. Mits goed gedaan maakt het idd niets uit.

Een OO database heeft ook nadelen; ikzelf vind een RDBMS nog altijd de ideale manier om kritische gegevens op te slaan. Het is mogelijk om naar een OO model te mappen, ivm raportage is een RDBMS imho nog altijd zeer geschikt, en wat als je een andere view op je model wilt hebben ?
Zie ook de discussie die ik met questa hierover had.

Andere view is geen probleem bij een actieve OO database.
Ik heb met CA Jasmine gewerkt en dan kon je gewoon queries draaien, de objecten bestaan ook echt in de database. Veel OO databases zijn niet meer dan stores van gestreamde objecten.
Voor ingewikkelde OO structuren is een OO database sneller. Voor de meeste kaartenbak applicaties blijft een RDBMS idd toch sneller. Ook is men er bekend mee en is het proven technologie, men stapt er niet zo gemakkelijk vanaf. En iderdaad, voor opslag van kritische gegevens zijn de meeste OO databases nog te experimenteel.

Als laatstse : Inderdaad de beste manier bestaat niet. Ik gaf alleen aan wat ik in de praktijk goed heb zien werken en wat geheel fout heb zien gaan. Het wil niet zeggen dat het op de manier die fout ging in de praktijk theoretisch niet goed gedaan had kunnen worden.

[whoami]

Anoniem: 154981 schreef op maandag 26 juni 2006 @ 23:42:
[...]


Andere view is geen probleem bij een actieve OO database.
Ik heb met CA Jasmine gewerkt en dan kon je gewoon queries draaien, de objecten bestaan ook echt in de database. Veel OO databases zijn niet meer dan stores van gestreamde objecten.
Voor ingewikkelde OO structuren is een OO database sneller. Voor de meeste kaartenbak applicaties blijft een RDBMS idd toch sneller. Ook is men er bekend mee en is het proven technologie, men stapt er niet zo gemakkelijk vanaf. En iderdaad, voor opslag van kritische gegevens zijn de meeste OO databases nog te experimenteel.

Ik bedoel maar: bij een OO database zal je DB wellicht een één op één spiegeling zijn van je classes in je applicatie. Dit is geen probleem zolang je maar die ene applicatie hebt die die DB gebruikt; wat als je echter nog een andere applicatie hebt, die ook die gegevens die zich in die DB bevinden, wil gebruiken, maar een heel andere kijk heeft op de data ?
En in sommige gevallen is het ook zo dat je een applicatie schrijft die een reeds bestaande DB benaderd.

[JaQ]

Anoniem: 154981 schreef op maandag 26 juni 2006 @ 23:42:
[Andere view is geen probleem bij een actieve OO database.
Ik heb met CA Jasmine gewerkt en dan kon je gewoon queries draaien, de objecten bestaan ook echt in de database. Veel OO databases zijn niet meer dan stores van gestreamde objecten.
Voor ingewikkelde OO structuren is een OO database sneller. Voor de meeste kaartenbak applicaties blijft een RDBMS idd toch sneller. Ook is men er bekend mee en is het proven technologie, men stapt er niet zo gemakkelijk vanaf. En iderdaad, voor opslag van kritische gegevens zijn de meeste OO databases nog te experimenteel.

Om maar even een sidestep richting OO databases te maken; het probleem is wat mij betreft niet de fase waarin deze producten zich bevinden (iig geen proven technology). Veel belangrijker is dat het moeilijk (onmogelijk?) is om hier beheerders voor te vinden. Zodra je omgeving eenmaal in de lucht is, moet ie het ook blijven he

[Tubby]

En dan hebben we het nog niet eens gehad over klanten die intern al bepaalde database software hebben draaien (en beheerders voor hebben) en graag zien dat alle applicaties daarop draaien. Dit ivm itern aangekocht 3rd party analyse tools.

Er zijn legio redenen te noemen om een klant niet op te zadelen met een database van jouw keuze omdat jouw applicatie er toevallig mee werkt.

[ Voor 3% gewijzigd door Tubby op 28-06-2006 07:48 ]

[Anoniem: 154981]

Een mooi OO datamodel is net zo bruikbaar voor andere applicaties als voor de applicatie waarvoor het gemaakt is. Ik zie hier geen verschil. Een relationele database zou hetzelfde probleem hebben als iemand er echt iets anders mee wil.

Met een ECHTE actieve OO database kun je gewoon queries maken en zo alles op alle manieren combineren. De koppeling applicaite -> database is bij deze producten niet zo hoog als bij de gebruikelijkere passieve OO database, daarbij heb je wel de door jullie genoemde problemen.

Verder ben ik het geheel eens met de argumenten over onderhoudbaarheid en compatibiliteit met bestaande rapportage en analysetools (alhoewel er voor jasmine ook gewoon een ODBC toegang mogelijk was, maargoed...) Feit is dat Jasmine niet erg mature was en het ook niet meer geleverd wordt. Dat zegt genoeg. Dit is dan ook geen pleidooi voor OO databases, zeker niet, maar je kunt ze ook niet allemaal over een kam scheren en het is gewoon leuk om eens naar de mogelijkheden te kijken.

In de praktijk kom ik voornamelijk de volgende 3 databases tegen (in alfabetische volgorde)
- Microsoft SQL Server
- mySQL
- Oracle

en kies, als ik de keuze krijg, keer op keer , mede met eerder genoemde argumenten, voor 1 van deze drie, afhankelijk van de klantomgeving.

PS wellicht is het beter om deze discussie te sluiten of in een ander topic door te zetten, we raken namelijk erg off-topic

Zie verder:
http://www.leavcom.com/db_08_00.htm
Denk dat dat wel een goed beeld geeft.
Vooral meedere users was idd een probleem en dat wil je binnen bedrijven nu juist vaak.
Wel erg geschikt voor hele technische modellen. Maar voor gewone kaartenbakken in de computer zetten kun je toch het beste een relationele database pakken... Maar dan blijft de vraag, hoeveel logica stop je in de database en hoeveel in je applicatie ?

[ Voor 19% gewijzigd door Anoniem: 154981 op 30-06-2006 22:28 ]

[flowerp]

whoami schreef op zondag 25 juni 2006 @ 17:56:
Er zijn natuurlijk altijd afwegingen die je moet maken als je een O/R mapper gebruikt.
De vraag die je dan stelt is; weegt de (vaak minieme) performance winst die je kan behalen door geen O/R mapper te gebruiken op, tegenover de productiviteits-winst die je kan behalen als je wel een O/R mapper gebruikt ?

Inderdaad. Ik heb vroeger dezelfde argumenten gehoord die nu tegen O/R mappers gebruikt worden. Zo was er vroeger nog een groep mensen die tegen 'high level' talen als C waren en vonden dat alles gewoon in assembly gedaan moest worden. Namelijk, alleen in assembly had je de volledige controlle over je hardware. De 'troep' die C compilers aan assembly genereerde konden die mensen toen ook geen assembly noemen. "Jouw machine is meer dan een generiek stuk hardware. Elke CPU heeft bepaalde eigenschappen. Gebruik die dan ook!". Het is een citaat die ik bijna letterlijk op deze manier heb gehoord en die ik nu in bijna identieke vorm weer terug hoor hier.

Wat men toen vergat, en wat men nu nog steeds vergeet, is dat een high level taal (in dit geval de O/R mapper) ook kan optimaliseren en naar verloop van tijd voor jou 'gratis' beter wordt. Tevens kan een high level taal ( O/R mapper hier dus ), automatisch optimaliseren voor verschillende DBMS's vanuit de zelfde source.

Als ik in Java een complex object persist naar de DB (er zit een standaard O/R mapper in Java) dan kan Java dit optimaliseren voor een hele reeks aan DBs. Zou ik zelf handmatig de SQL schrijven, dan zou ik alleen optimaliseren voor de DB die ik toevallig heb staan. Gaat nu iemand anders mijn code op een andere DB draaien, dan zouden mijn handmatige SQL optimalisaties vrij waarschijnlijk vrij nutteloos zijn, terwijl mijn high level persistance code ook voor die andere DBs meer optimale code zal genereren.

Daarnaast zal Java met het verschijnen van nieuwe versies ongetwijfeld beter optimaliseren. Vanuit mijn oogpunt is dit gratis performance. Bij handmatig geschreven SQL zou ik telkens moeten blijven optimaliseren, en dat voor al mijn queries en theoretisch voor alle mogelijke DBs. Maar bij Java hoef ik alleen maar de nieuwe Java versie te installeren en alles gaat weer een stuk sneller.

Vergelijk dit bijvoorbeeld met GCC die met elke versie beter ging optimaliseren en dat ook deed voor steeds nieuwere hardware. Had ik een assembly base gehad voor mijn code, dan had ik nooit in mijn eentje de performance winsten van GCC voor al mijn code en voor al die nieuwe CPUs met hun exotische features bij kunnen houden.

Bij elkaar opgeteld zal -nu- de productiviteit velen malen hoger zijn met een kleine penalty in performance. Op termijn zal deze penalty echter omslaan en juist een performance winst worden. In heel exotische gevallen zal het handmatig tunen van SQL ook in de toekomst noodzakelijk blijven. Net zoals C inline assembly biedt voor deze gevallen, zo biedt bijna elke O/R mapper (en dus ook de Java Persistence API) mogelijkheden voor native of manual SQL.

[flowerp]

JaQ schreef op zondag 25 juni 2006 @ 18:31:
ik kom anders ladingen applicaties tegen die alles maar in geheugen op de AS jassen en vervolgens gaan sorteren.

Je kan dit niet in het algemeen als slecht bestempelen. Het hangt sterk van de situatie af of het goed is of niet. Er zijn diverse scenario's denkbaar waarbij het wel degelijk goed is om dit te doen.

Denk bijvoorbeeld aan data die vrij kostbaar is om te genereren. Ik denk hierbij bijvoorbeeld aan complexe aggregates die specificiek voor een bepaalde user uitgevoerd worden. Nadat dergelijke data uit een query komt, zal de user ook hierin willen sorteren op diverse kolommen. Het telkens overniew genereren van de data is geen optie omdat dit simpel weg te lang duurt.

In de praktijk heb ik dit meegemaakt. Een query voor enkele 100'en rijen duurde een flink aantal secondes. Telkens als de user op een andere kolom wilde sorteren moest weer die aantal secondes gewacht worden. Knappere koppen dan ik zijn hier lang mee bezig geweest. Over handmatige optimalisaties gesproken (zie vorige post): de data werd in 3 levels voorberekent. Simpelweg ALLE combinaties voor ALLE users voorberekenen was gewoon onmogelijk (users konden uit niet minder dan 12 parameters kiezen en het ging om miljoenen rijen). Zelfs die 3 levels liep al tegen alle realistische grenzen aan. Het voorberekenen duurde ettelijke uren en de resulterende tabel was 10-tallen GB's groot.

Een typische user query leverde hoogstens enkele 100'en rijen op. Deze laden we als zogenaamde detached resultset in onze (java) applications servers. Het sorteren hiervan op de AS resulteerd in een round trip time van slechts enkele milli seconden.

Een tweede voordeel van het op de AS afhandelen is dat je je DB ontlast. Een AS is veel makkelijker te clusteren dan een DB. Gewoon 'sticky' sessions gebruiken en je kunt voor meerdere users gewoon meerdere AS' gebruiken. Zowel memory als cpu belasting verdeel je nu automatisch over meer systemen zodat je DB vrij blijft voor dinge die die beter kan doen.

Natuurlijk zijn er ook wel problemen. De actualiteit van de data bijvoorbeeld. Nu was dat in ons geval geen probleem (nieuwe data kwam slechts 1 x per 24 uur binnen), maar zolang je data zich in een detached resultset bevind op de AS kan deze al snel 'stale' zijn. O/R mappers lossen dit probleem automatisch voor je op: het systeem 'weet' wanneer welke data dirty is en zodra je een read request op je AS voor dirty data doet zal dit automatisch resulteren in een nieuwe query naar de DB toe.

Bij ons systeem hadden we nog geen O/R mapper, maar hebben we het opgelost door het event "new data instream" af te vuren vanuit de business logic die de SQL insert en update queries beheerde. Dit event werd door ons caching systeem opgevangen wat automatisch de juiste groep van resultsets invalideerde, zodat ook hier een user request tot een nieuwe query leidde.

In andere gevallen voldoet het soms ook om simpel weg een "refresh" knop in de GUI te zetten. Zeker in bepaalde domains zijn users het gewend dat de data die ze voor zich hebben niet perse de meest actuele hoeft te zijn. -> zelfs al houd je al je data in je DB ipv je AS, dan nog heb je een copy van de data op je scherm staan in een web omgeving. Als de user hier een bewerking op uitvoert zit je feitelijk met hetzelfde integriteits probleem.

zijn... Overigens vind ik het maken van een database onafhankelijke applicatie geen argument. Daar geloof ik uberhaupt niet in. Iedere database heeft zijn eigen SQL dialect en karakterastieken. Dit impliceerd verschillende gedrag op dezelfde query en derhalve verschillende performance.

En CPU onafhankelijk C code bestaat ook niet he? Gelukkig dat alle mensen die direct of indirect aan bijvoorbeeld Debian mee werken daar niet in geloven. Debian met al z'n 1000'en applicaties werkt uitstekend op een hele sloot aan zeer diverse CPUs, van PPC via MIPS tot aan IA64 en X86.