Wat voor (database) structuur raden jullie mij aan?

[bvdbijl]

Hallo,
Ik zit met een probleem:
Ik ben bezig met een systeem om mijn facturen te beheren, en daarbij staat een factuur als volgende in mijn database:
id
client_id
description

Nu heeft elke factuur meerdere "taken", bijvoorbeeld "de layout maken" die dan 5 uur duurt en 10 euro per uur is, enzovoorts
Nu heeft elke factuur meerdere taken, en is hier mijn probleem:
Ik wil dat ik zelf de orde van de taken kan veranderen, en dat de taken bewerkt en verwijdert kunnen worden en er meer toegevoegd kunnen worden.
Nu vraag ik me af wat de beste manier hier voor is? Als ik het in mijn (MySQL) database doe dan moet ik elke keer controleren of er taken weg zijn en die verwijderen, of er taken bewerkt zijn en die updaten en als er nieuwe taken zijn die toevoegen, en dit lijkt me nodeloos complex.
Ik kan ook de taken in CSV of JSON formaat in de factuur tabel opslaan maar dan is het een stuk minder flexibel doordat ik niet een taak apart kan selecteren.

Dus ik zou om jullie advies willen vragen, bij voorbaat dank

[NMe]

Dit is een standaard orders vs. orderregels-probleem. Google daar maar eens op.

[bvdbijl]

NMe schreef op zaterdag 21 augustus 2010 @ 21:06:
Dit is een standaard orders vs. orderregels-probleem. Google daar maar eens op.

Ok, ik heb een beetje gegoogled en ik denk dat ik toch maar voor de gescheiden variant ga, ook al moet ik dan wel een hele hoop logica erbij programmeren.

[NMe]

Daar ontkom je toch niet aan. Je hebt een factuur met 1 of meerdere regels die natuurlijk op zichzelf staande entiteiten zijn.

Overigens is het bij facturen wel belangrijk dat je bepaalde data redundant opslaat. Ik weet niet of dit voor school is of voor iets dat daadwerkelijk in gebruik genomen gaat worden, maar je wil niet dat je oude facturen in je database ineens op magische wijze veranderen als Nederland overstapt op andere BTW-tarieven of als je klant verhuist. Je moet een factuur te allen tijde opnieuw kunnen afdrukken precies zoals die in de eerste instantie naar de klant is gestuurd.

[Verwijderd]

Een alternatief: Je kan ook gewoon Magento pakken om je klanten/facturen te maken. Werkt prima. Dan gebruik je alleen de backend. Facturen, creditnota's etc kan je gewoon sturen per e-mail en (online) capturen via iDeal. Met Magento kan je heel veel met producten.

[keesdewit]

@NMe Sterker nog, de fiscus wil een hard copy (pdf) hebben en geen dynamische output uit jouw database. Tevens moet de authenticiteit aantoonbaar zijn van deze hard copy (hash code, digitale ondertekening). XML leent zich erg goed voor het maken van facturen. Hiermee kun je in 1 document alle data kwijt, hiervoor zijn speciale xml database engines zoals MongoDB. Tevens bied mssql native xml ondersteuning door de xml datatype.

[NMe]

Verwijderd schreef op zaterdag 21 augustus 2010 @ 21:36:
Een alternatief: Je kan ook gewoon Magento pakken om je klanten/facturen te maken. Werkt prima. Dan gebruik je alleen de backend. Facturen, creditnota's etc kan je gewoon sturen per e-mail en (online) capturen via iDeal. Met Magento kan je heel veel met producten.

Ik zou vooral niet een complex pakket als Magento nemen alleen om je facturatiesysteem te draaien. Sowieso heeft Magento nogal wat eigenaardigheden en is het allesbehalve een pretje om het aan te passen op jouw specifieke wensen.

keesdewit schreef op zaterdag 21 augustus 2010 @ 21:42:
@NMe Sterker nog, de fiscus wil een hard copy (pdf) hebben en geen dynamische output uit jouw database. Tevens moet de authenticiteit aantoonbaar zijn van deze hard copy (hash code, digitale ondertekening). XML leent zich erg goed voor het maken van facturen. Hiermee kun je in 1 document alle data kwijt, hiervoor zijn speciale xml database engines zoals MongoDB. Tevens bied mssql native xml ondersteuning door de xml datatype.

Zo'n hashcode zegt niks, die sla je ook gewoon zelf op? Overigens sla ik wel gewoon netjes hardcopies op van de facturen in het meest recente factureringssysteem dat ik gemaakt heb, zowel met als zonder briefpapier op de achtergrond. Maar da's niet alleen voor de Belastingdienst handig, da's ook handig voor klanten die via extranet hun factuur willen inzien.

[bvdbijl]

NMe schreef op zaterdag 21 augustus 2010 @ 21:33:
Daar ontkom je toch niet aan. Je hebt een factuur met 1 of meerdere regels die natuurlijk op zichzelf staande entiteiten zijn.

Overigens is het bij facturen wel belangrijk dat je bepaalde data redundant opslaat. Ik weet niet of dit voor school is of voor iets dat daadwerkelijk in gebruik genomen gaat worden, maar je wil niet dat je oude facturen in je database ineens op magische wijze veranderen als Nederland overstapt op andere BTW-tarieven of als je klant verhuist. Je moet een factuur te allen tijde opnieuw kunnen afdrukken precies zoals die in de eerste instantie naar de klant is gestuurd.

Ok, bedankt voor de tip, het BTW tarief en dergelijke zal ik dan bij de factuurregel opslaan
Het is een project om mezelf OOP-PHP te leren, en ik ga (tenminste dat ben ik van plan) het ook gebruiken om mijn eigen facturen voor mijn klanten te beheren, en misschien maar ik er wel een webdienst van (zoals freshbooks...) of geef ik het uit als opensource.

[MueR]

NMe schreef op zaterdag 21 augustus 2010 @ 21:50:
Sowieso heeft Magento nogal wat eigenaardigheden en is het allesbehalve een pretje om het aan te passen op jouw specifieke wensen.

Dit wil ik even onderschrijven. Met een heel dikke, bloederige lijn.

[bvdbijl]

Ok, maar nu heb ik nog een vraag:
Zal ik dan elke keer dat een factuur bewerkt wordt alle factuurregels verwijderen en ze opnieuw met de goede volgorde erin zetten of ze een voor een updaten, deleten, en inserten?

[NMe]

Ehm, volgorde doe je toch zeker gewoon met een SortOrder-veldje waar je op sorteert?

[bvdbijl]

NMe schreef op zondag 22 augustus 2010 @ 15:31:
Ehm, volgorde doe je toch zeker gewoon met een SortOrder-veldje waar je op sorteert?

Ja natuurlijk
Maar als ik de volgorde wil veranderen dan zal ik bij moeten houden welke er bewerkt zijn en die updaten en verwijderde regels deleten en nieuwe regels inserten, terwijl het veel simpeler is om simpelweg alle regels te verwijderen en opnieuw aan te maken als je begrijpt wat ik bedoel

[NMe]

Ehm...hoezo? Als je een record naar voren verplaatst:

SQL:

SET SortOrder = SortOrder + 1 WHERE SortOrder < huidige_sorteerplek AND SortOrder >= nieuwe_sorteerplek

En naar achteren:

SQL:

SET SortOrder = SortOrder - 1 WHERE SortOrder > huidige_sorteerplek AND SortOrder <= nieuwe_sorteerplek

Vervolgens hoef je alleen nog de sortorder van het verplaatste record aan te passen.

Overigens zou het best eenvoudiger kunnen zijn om alle records te verwijderen en opnieuw in te voegen maar dat hangt verder van de situatie af.

[bvdbijl]

NMe schreef op zondag 22 augustus 2010 @ 17:02:
Ehm...hoezo? Als je een record naar voren verplaatst:

SQL:

SET SortOrder = SortOrder + 1 WHERE SortOrder < huidige_sorteerplek AND SortOrder >= nieuwe_sorteerplek

En naar achteren:

SQL:

SET SortOrder = SortOrder + 1 WHERE SortOrder > huidige_sorteerplek AND SortOrder <= nieuwe_sorteerplek

Vervolgens hoef je alleen nog de sortorder van het verplaatste record aan te passen.

Overigens zou het best eenvoudiger kunnen zijn om alle records te verwijderen en opnieuw in te voegen maar dat hangt verder van de situatie af.

Ik zoek het verder wel uit, bedankt!

[RobIII]

keesdewit schreef op zaterdag 21 augustus 2010 @ 21:42:
@NMe Sterker nog, de fiscus wil een hard copy (pdf) hebben en geen dynamische output uit jouw database. Tevens moet de authenticiteit aantoonbaar zijn van deze hard copy (hash code, digitale ondertekening).

Heb je daar een bron voor?

keesdewit schreef op zaterdag 21 augustus 2010 @ 21:42:
XML leent zich erg goed voor het maken van facturen. Hiermee kun je in 1 document alle data kwijt, hiervoor zijn speciale xml database engines zoals MongoDB. Tevens bied mssql native xml ondersteuning door de xml datatype.

Een paar zaken:

• Wat is het voordeel van XML boven een DB? Of boven een Excel sheet for that matter? Of een textfile? Of...
• Wat heeft MongoDB met XML te maken MongoDB is een zgn. "NoSQL" DB die niet eens XML gebruikt...
• Waarom zou je in vredesnaam de (idd aanwezige) native XML ondersteuning van MSSQL hiervoor gaan gebruiken Wat is het voordeel hiervan?
• ...en nog een heleboel vraagtekens en kanttekeningen... ik weet niet eens waar te beginnen...

HuHu schreef op zondag 22 augustus 2010 @ 20:53:
Ah... iemand heeft de XML-klok horen luiden.

offtopic:
Ik kreeg een flashback naar 2001

[ Voor 10% gewijzigd door RobIII op 22-08-2010 23:46 ]

[HuHu]

keesdewit schreef op zaterdag 21 augustus 2010 @ 21:42:
@NMe Sterker nog, de fiscus wil een hard copy (pdf) hebben en geen dynamische output uit jouw database. Tevens moet de authenticiteit aantoonbaar zijn van deze hard copy (hash code, digitale ondertekening).

Nee hoor, op m'n werk maken we al enkele jaren digitale facturen. Het papier is al lang de deur uit, alle PDF's bewaren we ook. Maar alleen de database is noodzakelijk voor de fiscus, de PDFs kun je immers met één druk op de knop zo weer opnieuw genereren. Ook hash-codes of digitale handtekeningen zijn niet noodzakelijk.

XML leent zich erg goed voor het maken van facturen. Hiermee kun je in 1 document alle data kwijt, hiervoor zijn speciale xml database engines zoals MongoDB. Tevens bied mssql native xml ondersteuning door de xml datatype.

Ah... iemand heeft de XML-klok horen luiden.

[Gé Brander]

HuHu schreef op zondag 22 augustus 2010 @ 20:53:
[...]

Ah... iemand heeft de XML-klok horen luiden.

Uit profiel:

Beroep: Webdeveloper, Appicatiedeveloper, netwerkbeheerder,systeembeheerder,Internet

Beroep: Internet... ?

NMe schreef op maandag 23 augustus 2010 @ 00:43:
Zullen we hem anders even niet op zijn profiel aanpakken maar op zijn argumenten?

Je hebt helemaal gelijk... Excuses.

[ Voor 27% gewijzigd door Gé Brander op 23-08-2010 07:20 ]

[NMe]

Zullen we hem anders even niet op zijn profiel aanpakken maar op zijn argumenten?

[keesdewit]

Waarom zitten jullie meteen zo te bashen? XML is echt een goed middel om facturen in te bewaren, ik werk er al ruim 8 jaar mee.....

@HuHu: Dat wil niet zeggen dat ze het op jouw werk volgens de richtlijnen doen. De informatie die ik heb komt rechtstreeks uit de elsevier belasting gids. Overigens kun je met 1 druk op de knop ook alle bedragen in je database veranderen.

Met de native ondersteuning in sql server kun je de xml queryen en genereren, bijvoorbeeld aan de hand van diversen factuurregels binnen een order. Vervolgens kun je met een stylesheet (xslt) de factuur tonen of exporteren naar pdf. xml laat zich ook ondertekenen zodat er met zekerheid vast staat dat het document niet is gewijzigd sinds de ondertekening. Eigenlijk is de ondertekende xml jouw bewijs richting de fiscus. Wat kan anders aantonen dat de factuur ook die factuur is die aan de klant is verzonden?

[NMe]

keesdewit schreef op woensdag 01 september 2010 @ 18:24:
Waarom zitten jullie meteen zo te bashen? XML is echt een goed middel om facturen in te bewaren, ik werk er al ruim 8 jaar mee.....

Dat jij er al 8 jaar mee werkt wil niet zeggen dat het een goed plan is. XML is nooit als een data-opslagstructuur bedoeld. Het is een ideaal formaat om data tussen applicaties door te geven, niet voor permanente opslag, te meer omdat je er niet snel in kan zoeken. Dus nee, het is geen formaat dat ik zou kiezen voor de permanente opslag van facturen.

[HuHu]

keesdewit schreef op woensdag 01 september 2010 @ 18:24:
Waarom zitten jullie meteen zo te bashen? XML is echt een goed middel om facturen in te bewaren, ik werk er al ruim 8 jaar mee.....

@HuHu: Dat wil niet zeggen dat ze het op jouw werk volgens de richtlijnen doen. De informatie die ik heb komt rechtstreeks uit de elsevier belasting gids. Overigens kun je met 1 druk op de knop ook alle bedragen in je database veranderen.

Met de native ondersteuning in sql server kun je de xml queryen en genereren, bijvoorbeeld aan de hand van diversen factuurregels binnen een order. Vervolgens kun je met een stylesheet (xslt) de factuur tonen of exporteren naar pdf. xml laat zich ook ondertekenen zodat er met zekerheid vast staat dat het document niet is gewijzigd sinds de ondertekening. Eigenlijk is de ondertekende xml jouw bewijs richting de fiscus. Wat kan anders aantonen dat de factuur ook die factuur is die aan de klant is verzonden?

Ach, de boekhouder kwam er zelf mee, omdat de regels gewijzigd waren en het was toegestaan. De accountant keurt het goed, dus het zal wel kloppen dan lijkt me.

Overigens kun je in het bovenstaande verhaal het woord XML prima vervangen door, bijvoorbeeld, PDF, of iets anders. En dan gaat je verhaal nog steeds op. Dus ik zie nog niet echt overtuigende argumenten voor het XML gebeuren.

[cariolive23]

keesdewit schreef op woensdag 01 september 2010 @ 18:24:
Waarom zitten jullie meteen zo te bashen? XML is echt een goed middel om facturen in te bewaren, ik werk er al ruim 8 jaar mee.....

En noem nu eens een formaat waar je geen factuurgegevens mee kunt opslaan...

Wanneer XML goed genoeg is, dan is een DBMS of een pdf ook goed genoeg. XML is niet meer dan een text bestandje die toevallig een structuur heeft die jij zelf hebt bedacht. Dat is met een DBMS niet anders.

@HuHu: Dat wil niet zeggen dat ze het op jouw werk volgens de richtlijnen doen. De informatie die ik heb komt rechtstreeks uit de elsevier belasting gids. Overigens kun je met 1 druk op de knop ook alle bedragen in je database veranderen.

Je weet dat dit met jouw XML ook kan?

Met de native ondersteuning in sql server kun je de xml queryen en genereren, bijvoorbeeld aan de hand van diversen factuurregels binnen een order. Vervolgens kun je met een stylesheet (xslt) de factuur tonen of exporteren naar pdf. xml laat zich ook ondertekenen zodat er met zekerheid vast staat dat het document niet is gewijzigd sinds de ondertekening. Eigenlijk is de ondertekende xml jouw bewijs richting de fiscus. Wat kan anders aantonen dat de factuur ook die factuur is die aan de klant is verzonden?

Vrijwel ieder formaat is dus goed genoeg, je zal gewoon een sluitende administratie moeten opleveren. En dan niet in jouw XML-formaat, dat zullen de blauwe vrienden echt niet accepteren. XML bewijst niks, het gaat om de administratie in zijn geheel.

[Dido]

offtopic:
En ik kom op het forum om even bij te komen van een dag luisteren naar managementbobo's die denken dat XML een applicatie, bestandsformaat, communicatieprotocol, developmentplatform, interface en programmeertaal is.

[RobIII]

keesdewit schreef op woensdag 01 september 2010 @ 18:24:
@HuHu: Dat wil niet zeggen dat ze het op jouw werk volgens de richtlijnen doen. De informatie die ik heb komt rechtstreeks uit de elsevier belasting gids.

Wil je dan ook even een quote / linkje of whatever doen? En me even precies vertellen hoe dat werkt met die hashcode en digitale ondertekening?

keesdewit schreef op woensdag 01 september 2010 @ 18:24:
Waarom zitten jullie meteen zo te bashen? XML is echt een goed middel om facturen in te bewaren, ik werk er al ruim 8 jaar mee.....

Wil je me even vertellen hoeveel van Product_X we afgelopen maand, kwartaal en 4 jaar we hebben verkocht? Wat de gemiddelde marge was? In welke maand(en) piekt de verkoop van Product_Y? En hoeveel omzet hebben we gedraaid? *pruttel* XML files indexeren *pruttel* XML file openen *pruttel* XML file openen *pruttel* XML file openen *pruttel* XML file openen *pruttel* XML file openen *pruttel* XML file openen ...

Dido schreef op woensdag 01 september 2010 @ 19:39:

offtopic:
En ik kom op het forum om even bij te komen van een dag luisteren naar managementbobo's die denken dat XML een applicatie, bestandsformaat, communicatieprotocol, developmentplatform, interface en programmeertaal is.

XML is pas een compleet platform nadat je Javascript toevoegt. Dat weet toch iedereen? Managementbobo's

[ Voor 61% gewijzigd door RobIII op 01-09-2010 21:53 ]

[Hydra]

Dido schreef op woensdag 01 september 2010 @ 19:39:

offtopic:
En ik kom op het forum om even bij te komen van een dag luisteren naar managementbobo's die denken dat XML een applicatie, bestandsformaat, communicatieprotocol, developmentplatform, interface en programmeertaal is.

offtopic:
Je vergeet dat het uitermate goed in de cloud past.

[keesdewit]

@RobIII: De inhoud van bijvoorbeeld een XML bestand kan door middel van een X509 certificaat ondertekend worden. (Net als SAML tokens bij WIF) Hierdoor kun je nagaan of het document ondertussen is veranderd. Als het document is veranderd klopt de uitkomst van de hash niet meer versus je public key uit het X509 certificaat. Na het maken van een factuur wordt de xml ondertekend en op het bestandssyteem opgeslagen. Met het certificaat kun je onomstotelijk vaststellen dat: De identiteit is gecheckt door een bevoegde CA, het document op een bepaald tijdstip is ondertekend, er geen wijzigingen zijn gedaan aan het document. Het opnieuw genereren van deze bestanden gaat niet op, het tijdstip is immers ook van belang.

Met XML kun je vrij makkelijk dergelijke cijfers krijgen. Juist door de native ondersteuning in mssql van het xml datatype kun je indexes bouwen en vrij makkelijk via xQuery syntax alle xml documenten doorzoeken. Er is op dat moment niet meer zoiets als veel xml bestanden op een bestandsysteem, maar een document georienteerde database (althans een hybride versie in dit geval).

@Nme: Met XML kun je veel meer dan alleen maar gegevens uitwisselen. Aangiftes in XBRL formaat worden ook zo opgeslagen, danwel voor het uitwisselen naar andere partijen, maar ook om bijvoorbeeld een schema validatie of consistentie check te doen. XML leent zich verder ook prima om configuraties in op te slaan voor je applicatie (denk aan web.config). Sterker nog; Het office 2007 formaat (.docx) bestaat voor een groot gedeelte uit XML. Dat niet snel kunnen zoeken is behoorlijk achterhaald, kijk maar bijvoorbeeld naar ICECAT die zijn volledige product assortiment (paar miljoen artikelen) in xml aanbied, maar ook zelf zijn site daarop heeft gebaseerd. Samen met een document georienteerde database is het erg makkelijk en snel om bijvoorbeeld alle computers te vinden met een bepaalde CPU. Ik geef toe dat het importeren een behoorlijk intensieve actie is, maar als hij eenmaal in de db staat met de juiste indexes vergeet je bijna qua performance dat je tegen xml documenten aan het queryen bent. Overigens kun je via stylesheets (xslt) vrij makkelijk het document presenteren naar wens.

@HuHu: Als de belastingdienst bij jullie controlle komt houden, hoe toon jij dan aan dat de facturen uit jouw systeem/database ook daadwerkelijk de factuur is die naar de klant is gegaan?

[HuHu]

keesdewit schreef op donderdag 02 september 2010 @ 10:26:

@HuHu: Als de belastingdienst bij jullie controlle komt houden, hoe toon jij dan aan dat de facturen uit jouw systeem/database ook daadwerkelijk de factuur is die naar de klant is gegaan?

Er staat een bankoverschrijving of kassa-bon tegenover.

[cariolive23]

keesdewit schreef op donderdag 02 september 2010 @ 10:26:
@RobIII: De inhoud van bijvoorbeeld een XML bestand kan door middel van een X509 certificaat ondertekend worden.

En waarom zou dat niet kunnen met andere formaten? XML is niet meer dan een onvoorstelbaar simpel stukje platte tekst die je met Notepad kunt aanmaken. Maak een nieuwe XML, laat dit ondertekenen en je hebt weer een correcte administratie? Dacht het niet.

XML is heel erg leuk maar het kan nooit een doel op zich zijn. Daarnaast is het zeer ongeschikt om grote hoeveelheden data in op te slaan, de hype van XML-databases is inmiddels ook al weer overgewaaid.

Dat er databases zijn die het datatype XML kennen en daar ook leuke dingen mee kunnen doen, dat is een ander verhaal. De data wordt dan gewoon intern opgeslagen, net zoals stukken tekst, integers, etc. Het is de DBMS die dan het werk doet en dit toevallig uitvoert op het datatype XML.

[keesdewit]

@HuHu: Maar je kan de facturen toch ook aanpassen aan de boeking op de bank?

@cariolive23: Dit zou ook met andere formaten kunnen die zich laten ondertekenen, bijvoorbeeld PDF, maar die laat zich niet doorzoeken door een DBMS. Een nieuwe XML ondertekenen heeft geen zin, gezien het tijdstip/datum niet meer klopt tenopzichte van de factuurdatum zelf. Grote hoeveelheden binnen 1 document is inderdaad 'not done', maar veel documenten bij elkaar die samen veel vormen is geen probleem. Zaken opslaan/uitwisselen in xml is toch echt nog in de mode. Zie bijvoorbeeld het XBRL formaat.

[NMe]

keesdewit schreef op donderdag 02 september 2010 @ 10:26:
@Nme: Met XML kun je veel meer dan alleen maar gegevens uitwisselen. Aangiftes in XBRL formaat worden ook zo opgeslagen, danwel voor het uitwisselen naar andere partijen, maar ook om bijvoorbeeld een schema validatie of consistentie check te doen. XML leent zich verder ook prima om configuraties in op te slaan voor je applicatie (denk aan web.config). Sterker nog; Het office 2007 formaat (.docx) bestaat voor een groot gedeelte uit XML.

Je noemt een documentformaat. Daar leent XML zich inderdaad prima voor. Je hebt markup nodig om een document op te maken, en laat de eXtensible Markup Language daar nu bij uitstek geschikt voor zijn...

Dat niet snel kunnen zoeken is behoorlijk achterhaald, kijk maar bijvoorbeeld naar ICECAT die zijn volledige product assortiment (paar miljoen artikelen) in xml aanbied, maar ook zelf zijn site daarop heeft gebaseerd. Samen met een document georienteerde database is het erg makkelijk en snel om bijvoorbeeld alle computers te vinden met een bepaalde CPU.

Hoe snel je zo'n systeem ook maakt, het gaat nooit zo snel zijn als een fatsoenlijke relationele database. Tenzij je een of andere engine gebruikt die een complete relationele database om je XML heen gaat gooien, maar dan gebruik je stiekem geen XML meer.

Ik geef toe dat het importeren een behoorlijk intensieve actie is, maar als hij eenmaal in de db staat met de juiste indexes vergeet je bijna qua performance dat je tegen xml documenten aan het queryen bent. Overigens kun je via stylesheets (xslt) vrij makkelijk het document presenteren naar wens.

Overigens kun je via PHP vrij makkelijk spul uit MySQL presenteren naar wens.
Overigens kun je via ASP.net vrij makkelijk spul uit Access presenteren naar wens.
Overigens kun je via Delphi vrij makkelijk tekstfiles presenteren naar wens.

Ik zie een patroon.

[cariolive23]

keesdewit schreef op donderdag 02 september 2010 @ 12:02:
Zaken opslaan/uitwisselen in xml is toch echt nog in de mode. Zie bijvoorbeeld het XBRL formaat.

Uitwisselen in XML-formaat is handig en wordt veel gedaan, perfecte toepassing. Opslaan? No way, veel te omslachtig en vrijwel onbruikbaar wanneer het "veel" wordt.En met XML is het al vrij snel "veel", dit wordt veroorzaakt door de enorme overhead.

<adres type="post">Postbus 23</adres>

10 karakters data...

[jmzeeman]

Ter info over elektronische facturen/bewaren en de belastingdienst:
http://download.belasting...waarplicht_al0401z8fd.pdf
http://www.belastingdiens...bijhouden/facturen_maken/
De belastingdienst doet niet zo moeilijk. Het komt er eigenlijk op neer dat je je facturen moet bewaren/opslaan zoals je ze maakt/ontvangt. Als jij ze op de computer maakt moet je ze op de computer bewaren als je ze op papier maakt moet je ze op papier bewaren. Belangrijkste punt is dat ze niet aanpasbaar zijn, bijvoorbeeld als je klant verhuisd moet op de oude facturen als je ze uit je systeem tovert niet het nieuwe adres staan. Converteren tussen opslagmethodes mag maar er mogen geen authenticiteits kenmerken verloren gaan. Gaan er wel kenmerken verloren moet je doormiddel van een audit bewijzen hoe je het vervallen van die kenmerken ondervangt.
Of je dit nou in een DB, een txt bestand, een pdf of een xml bestand doet maakt niks uit. Certificaten zijn leuk en fijn voor de klant zodat ie zeker weet dat de factuur van jou komt maar zijn niet verplicht. Certificaten betekenen wel dat je klant jou factuur nooit in een ander formaat of op papier mag bewaren aangezien het certificaat dan verloren gaat en er dus een authenticiteitskenmerk verloren gaat.

[ Voor 26% gewijzigd door jmzeeman op 02-09-2010 13:57 ]

[keesdewit]

Folder belasingdienst:

"Het is van groot belang dat de oorspronkelijkheid (authenticiteit) en de inhoud van de
gegevens (integriteit) juist zijn. Voor een factuur bijvoorbeeld is het van belang te weten dat
het document daadwerkelijk van de leverancier afkomstig is. Het is ook van belang dat de
factuur niet te veranderen is. De Belastingdienst moet dit bij een controle kunnen vaststellen."

Een digitale ondertekening samen met de audit trail van een document (pdf, xml, etc) is een erg sterk middel om de authenticiteit en integriteit aan te tonen. Het wisselen van gegevensdrager kan zonder zorgen op die manier gedaan worden door de klant gezien hij via de handtekening de authenticiteit duidelijk kan aantonen.

@jmzeeman: Een klant mag Überhaupt mijn digitale factuur (met of zonder ondertekening) niet op papier bewaren; zie folder:

"3.3 Afdrukken van gegevens
In principe is het niet toegestaan om computerbestanden af te drukken en vervolgens de
computerbestanden te verwijderen. Alleen als uw administratie van geringe omvang is zodat
een controle van de afgedrukte bestanden binnen redelijke tijd kan worden gedaan, mag u
uw gegevensbestanden verwijderen. Neem hierover eerst contact op met de Belastingdienst."

Waarom zou een klant mijn factuur naar een ander formaat willen converteren?

@cariolive23: Je kun xml ook voor langdurige opslag (bewaarplicht) met bijvoorbeeld een gzip compressie (60/70% minder bytes) Ik zei overigens in het begin al dat bij een hybride model zoals sql server er minder performance verlies is en xml handig kan werken ook in combinatie met (of binnen in) een relationeel database model. Laat ik bijvoorbeeld stellen dat de xml van een factuur opgeslagen is in de database (alle gegevens van de factuur) in dezelfde tabel zit ook een kolom met het factuurnummer, welke primary key is binnen jouw relationele model. Nu kun je enkel en alleen met het factuurnummer in 1 keer alle gegevens uit een enkele tabel krijgen zonder dat je de juiste gegevens met elkaar moet JOINen en zonder dat je aparte querys moet maken voor de adres gegevens, factuurgegevens, factuurregels.... (dus minder serverbelasting) nu hoef je alleen maar in je applicatie de xml op de juiste manier te presenteren.

[NMe]

keesdewit schreef op donderdag 02 september 2010 @ 20:15:
Folder belasingdienst:

"Het is van groot belang dat de oorspronkelijkheid (authenticiteit) en de inhoud van de
gegevens (integriteit) juist zijn. Voor een factuur bijvoorbeeld is het van belang te weten dat
het document daadwerkelijk van de leverancier afkomstig is. Het is ook van belang dat de
factuur niet te veranderen is. De Belastingdienst moet dit bij een controle kunnen vaststellen."

Een digitale ondertekening samen met de audit trail van een document (pdf, xml, etc) is een erg sterk middel om de authenticiteit en integriteit aan te tonen. Het wisselen van gegevensdrager kan zonder zorgen op die manier gedaan worden door de klant gezien hij via de handtekening de authenticiteit duidelijk kan aantonen.

Dat het een sterk middel is wil niet zeggen dat het de enige manier is. Bovendien is dat niet iets dat alleen op XML werkt. Een checksum maken met MD5 van je PDF is namelijk net zo goed een teken van authenticiteit.

@jmzeeman: Een klant mag Überhaupt mijn digitale factuur (met of zonder ondertekening) niet op papier bewaren; zie folder:

"3.3 Afdrukken van gegevens
In principe is het niet toegestaan om computerbestanden af te drukken en vervolgens de
computerbestanden te verwijderen. Alleen als uw administratie van geringe omvang is zodat
een controle van de afgedrukte bestanden binnen redelijke tijd kan worden gedaan, mag u
uw gegevensbestanden verwijderen. Neem hierover eerst contact op met de Belastingdienst."

Waarom zou een klant mijn factuur naar een ander formaat willen converteren?

Je interpreteert het verkeerd, dit gaat om verstuurde facturen, niet ontvangen facturen. Je klant mag zijn factuur best uitprinten als hij liever een papieren administratie heeft dan een digitale.

@cariolive23: Je kun xml ook voor langdurige opslag (bewaarplicht) met bijvoorbeeld een gzip compressie (60/70% minder bytes) Ik zei overigens in het begin al dat bij een hybride model zoals sql server er minder performance verlies is en xml handig kan werken ook in combinatie met (of binnen in) een relationeel database model. Laat ik bijvoorbeeld stellen dat de xml van een factuur opgeslagen is in de database (alle gegevens van de factuur) in dezelfde tabel zit ook een kolom met het factuurnummer, welke primary key is binnen jouw relationele model. Nu kun je enkel en alleen met het factuurnummer in 1 keer alle gegevens uit een enkele tabel krijgen zonder dat je de juiste gegevens met elkaar moet JOINen en zonder dat je aparte querys moet maken voor de adres gegevens, factuurgegevens, factuurregels.... (dus minder serverbelasting) nu hoef je alleen maar in je applicatie de xml op de juiste manier te presenteren.

Minder serverbelasting omdat je niet hoeft te joinen? De gemiddelde database schudt de gemiddelde join zo uit zijn mouw. Juist disk access is héél tijdrovend en dus duur, en laat XML daar dus héél slecht op scoren. Kom nou eens met echte steekhoudende argumenten, want XML is nooit en te nimmer performanter dan een normale relationele database. Het stylen van rauwe data is nog steeds een stuk goedkoper in tijd dan het selecteren uit een XML-dataset.

Dat jij het om de een of andere reden de heilige graal vindt is intussen wel duidelijk, maar zowel je argumenten dat het van de Belastingdienst "moet" als ook de performance- en eenvoudargumenten houden gewoon geen stand. Er blijft niet veel van je argument over.

[cariolive23]

keesdewit schreef op donderdag 02 september 2010 @ 20:15:
@cariolive23: Je kun xml ook voor langdurige opslag (bewaarplicht) met bijvoorbeeld een gzip compressie (60/70% minder bytes)

En dat is weer niet te doorzoeken, dus dat voordeel ben je kwijt. Dan sla ik liever de aangemaakte pdf op, die kan ook signeren en vervolgens op tape backuppen. Voor de dagelijkse werkzaamheden heb ik dan een snelle RDBMS tot m'n beschikking en voor de Belastingdienst heb ik de boel op tape staan.

Het heeft geen enkele zin om een stuk XML te bewaren wat niemand ooit weer gaat gebruiken en wat ik on the fly kan reproduceren. XML is niet 1-2-3 leesbaar, je moet altijd weer omzetten naar iets anders, neemt veel ruimte in beslag en doorzoeken kost (relatief) veel tijd. Wat is dan het voordeel t.o.v. een pdf (die ik toch al maak voor m'n klant) en m'n RDBMS? Niets.

Ik ben een liefhebber van XML, maar smeer het niet op m'n brood, laat staan dat ik het in de koffie doe of m'n servers mee ga vervuilen. XML is voor het gestructureerd uitwisselen van data, niet voor opslag van data, daar zijn veel betere formaten voor.

Edit: Inderdaad, dat verhaal over JOIN's raakt echt kant noch wal, een database die niet fatsoenlijk met JOIN's uit de voeten kan, mag je direct bij het grof vuil neerzetten. Dit is de basis van een RDBMS, waar je denk je dat de R vandaan komt? Relaties... En daar gebruik je JOIN's voor.

[ Voor 11% gewijzigd door cariolive23 op 02-09-2010 21:08 ]

[Janoz]

Keesdewit heeft een punt mbt de joins, maar de argumentatie slaat compleet nergens op. Voor je audittrail is het inderdaad beter om niet zomaar een relatie te leggen. Dat heeft echter geen kont te maken met performance. Het probleem is dat een wijziging van je klantgegevens (bv doordat ze naar een andere vestiging gaan of van naam veranderen) er voor zorgt dat dit met terugwerkende kracht ook op je oude facturen doorgevoerd wordt. Dat is wat veel mensen nog wel eens vergeten (Meestal denken ze alleen aan de in rekening gebrachte bedragen).

De oplossing daarvoor hoeft echter helemaal niet te zijn dat je alles gaat denormaliseren. Gewoon een audittrail bijhouden van je gegevens is genoeg. Dan kun je niet alleen je oude facturen terug halen, maar ook uit een database die precies de staat op dat moment weergeeft. Vaak zijn daarvoor standaard oplossingen beschikbaar. Denk bijvoorbeeld aan Envers voor Hibernate.

[keesdewit]

@janoz: uiteindelijk heeft het niet hoeven joinen van tabellen invloed op de i/o bewerkingen en dus op de totale performance van je server onder belasting.

Juist omdat er een aantal variablen in de factuur zitten (btw, naw, etc) moet je er voor zorgen dat deze gegevens per factuur "vast" staan

@Nme: Wie zegt de belastingdienst dat het checksum niet opnieuw is berekend toen het document ook opnieuw werdt gegenereerd? Bij een ondertekening heb je tenminste een middel wat dat voorkomt, anders gezegt een checksum is wijzigbaar. Ik denk dat jij het verkeerd ziet namelijk; alle gegevens uit de administratie, waaronder ontvangen facturen dus. Zie ook: "niet toegestaan om computerbestanden af te drukken" Een checksum in combinatie met een sluitende audit trial lijkt mij wel een goede methode, ik zeg ook niet dat dit de enige methode is, maar wel een die steeds meer gebruikt gaat worden. Het kost overigens minder i/o's om via 1 query 1 tabel aan te spreken dan met verschillende querys en joins

@cariolive: Doorzoeken is in dit geval niet de toepassing, maar bewaren voor langere periode wel. Overigens is het document vanuit het relationele model via de id kolom te vinden. (net zo goed als andere documenten ipv xml) En ja, vaak is het makkelijk om gegevens in PDF te bewaren, maar ook wil ik vaste gegevens in xml bewaren, omdat die gebruikt worden om bijvoorbeeld informatie uit te wisselen (met accountants, fiscus, kvk, etc) Denk hierbij aan financieele systemen van accountantkantoren.

[ Voor 72% gewijzigd door keesdewit op 02-09-2010 22:04 . Reden: Aanvulling ]

[cariolive23]

Janoz schreef op donderdag 02 september 2010 @ 21:24:
Keesdewit heeft een punt mbt de joins

Waar dan? JOIN's bestaan al een eeuwigheid, databases zijn hierop geoptimaliseerd en performen als een dolle. Op een simple x86-servertje met een paar GB RAM en 4 schijfjes in RAID 10, heb ik uit een miljoen records en een query met een 12-tal JOIN's (staat in een VIEW), binnen een paar honderdsten van een seconde de factuurgegevens van klant X of Y uit het systeem. Nu kun je dat langzaam noemen, maar met XML kan ik eerst cola en pizza gaan bestellen om niet te verhongeren tijdens het wachten op antwoord.

Kom op zeg, het is 2010, je kunt nu toch echt niet meer volhouden dat JOIN's langzaam zijn, dan heb je echt wel een paar fundamentele fouten in je systeem gemaakt.

[keesdewit]

@cariolive23: Het gaat hier om gegevens die vast staan zoals facturen. Waarom zou ik iedere keer 3 querys loslaten op mijn database (Algemene gegevens factuur, Adres gegevens klant, Factuurregels) als ik de vaste gegevens met 1 query kan ontvangen in xml of een ander formaat? Als het gaat om performance bedoel ik ook het totale beeld in i/o's 500 verzoeken * 3 querys is meer io's dan 500 * 1 om hetzelfde document te krijgen.

[Janoz]

Kees, joinen doe je met 1 query.

[cariolive23]

Wie zegt dat je 3 queries nodig hebt? Eéntje is genoeg.

Mijn databases leveren zoveel performance dat ze vooral staan te wachten op de applicaties, die zijn niet snel genoeg om de database te laten zweten.

[keesdewit]

@Janoz: Klopt, maar het is niet zo efficient om de adres gegevens met de factuurregels te joinen, vandaar de meerdere querys

[ Voor 13% gewijzigd door keesdewit op 02-09-2010 22:16 ]

[Janoz]

cariolive23 schreef op donderdag 02 september 2010 @ 22:03:
[...]

Waar dan? JOIN's bestaan al een eeuwigheid, databases zijn hierop geoptimaliseerd en performen als een dolle. Op een simple x86-servertje met een paar GB RAM en 4 schijfjes in RAID 10, heb ik uit een miljoen records en een query met een 12-tal JOIN's (staat in een VIEW), binnen een paar honderdsten van een seconde de factuurgegevens van klant X of Y uit het systeem. Nu kun je dat langzaam noemen, maar met XML kan ik eerst cola en pizza gaan bestellen om niet te verhongeren tijdens het wachten op antwoord.

Kom op zeg, het is 2010, je kunt nu toch echt niet meer volhouden dat JOIN's langzaam zijn, dan heb je echt wel een paar fundamentele fouten in je systeem gemaakt.

Duh... Ik snap dat het stoom uit je oren komt wanneer iemand met droge ogen beweert dat een join een performance hit oplevert. Lees echter ook even de rest van mijn reactie. Er zijn goede redenen om je facturatie gegevens gedenormaliseerd op te slaan, maar performance is daar niet 1 van.

[cariolive23]

Janoz schreef op donderdag 02 september 2010 @ 22:17:
[...]

Duh... Ik snap dat het stoom uit je oren komt wanneer iemand met droge ogen beweert dat een join een performance hit oplevert. Lees echter ook even de rest van mijn reactie. Er zijn goede redenen om je facturatie gegevens gedenormaliseerd op te slaan, maar performance is daar niet 1 van.

Helemaal mee eens, geen speld tussen te krijgen en niets meer aan toevoegen

[Dido]

offtopic:
* Dido pakt de pop-corn er weer bij. Op de een of andere manier kan ik er in dit topic wel van genieten, op het werk een stuk minder

[keesdewit]

@Janoz: Dat hangt volgens mij wel af van het feit hoe vaak de gegevens worden geraadpleegd. Iedere keer die tabellen bij elkaar betrekken lijkt mij meer intensief dan iedere keer 1 tabel gebruiken om een vast gegeven er uit te halen. Als je het over vaste gegevens hebt dan is het eerst bij elkaar zoeken, samenvoegen, sorteren, etc meer werk dan 1 document binnenhalen. (en ookal raap je informatie uit verschillende tabellen, de output is vast bij iedere aanroep, je hebt immers de btw en naw vast staan...)

[ Voor 4% gewijzigd door keesdewit op 02-09-2010 22:24 ]

[cariolive23]

keesdewit schreef op donderdag 02 september 2010 @ 22:15:
@Janoz: Klopt, maar het is niet zo efficient om de adres gegevens met de factuurregels te joinen, vandaar de meerdere querys

Nu wordt ook duidelijk waarom jouw systeem langzaam wordt wanneer je de database gaat gebruiken... Blijkbaar denk jij het beter te weten dan jouw database. Dankzij jouw meerdere queries kan jouw database niet meer efficient werken, werk jij deze tegen. Dit is wat anders dan een langzame database, dit is gewoon jouw keuze, jij wilt blijkbaar een langzame database. Dat kan, maar ga dan niet beweren dat dit normaal is.

[keesdewit]

@cariolive23: Dan mag jij mij vertellen hoe ik middels een JOIN statement op een efficiente manier de factuurregels en naw gegevens in 1 dataset terug krijg, zonder dat de adres gegevens bij iedere factuurregel record erbij staan.

select kolom1, kolom2, etc from tblOrders inner join tblOrderDetails on tblOrders.orderid = tblOrderDetails.orderid inner join tblUsers on tblUsers.userid = tblOrders.userid

[ Voor 27% gewijzigd door keesdewit op 02-09-2010 22:31 ]

[Dido]

Ontopic:
@keesdewit: als het enige wat je ooit met je factuurhistorie gaat doen het opnieuw uitdraaien van je faacturen is heb je op zich een punt. Een heel kleintje, want die paar milliseconden per factuur gana je exact 0,0 opleveren die enkele keer dat je dat doet.
Factuurhistorie wordt echter ook voor andere zaken gebruikt, zoals BI en BA. Dan wil je (bijvoorbeeld) weten hoeveel je x% grootste afnemers de laatse Y jaar hebben afgenomen, en wat voor trends daarin zitten. Veel succes met je 1-record-voor-de-hele-factuur-in-XML-database.
En dan betaal je wel elke keer dat je zo'n overzicht draait een flinke performance penalty.

[Janoz]

keesdewit schreef op donderdag 02 september 2010 @ 22:27:
@cariolive23: Dan mag jij mij vertellen hoe ik middels een JOIN statement op een efficiente manier de factuurregels en naw gegevens in 1 dataset terug krijg, zonder dat de adres gegevens bij iedere factuurregel record erbij staan.

Wat je beter kunt doen is proberen je aanname omtrent de rechtstreekse relatie tussen de efficientie van het uitlezen van gegevens aan de ene kant en de grootte van de geretourneerde dataset aan de anderekant daadwerkelijk eens te testen zodat je in kunt zien dat die aanname helemaal nergens op slaat.


Sowieso vind ik het nogal vreemd dat je zo druk over efficientie aan het kletsen bent terwijl je een oplossing voorsteld waarbij je gegevens niet in een (zelfs in gedenormaliseerde staat) database eigen bestands formaat opslaat, maar gewoon als verzameling XML-etjes waar MSSQL wel even wat van mag proberen te maken.

[ Voor 19% gewijzigd door Janoz op 02-09-2010 22:34 ]

[NMe]

keesdewit schreef op donderdag 02 september 2010 @ 21:37:
@Nme: Wie zegt de belastingdienst dat het checksum niet opnieuw is berekend toen het document ook opnieuw werdt gegenereerd? Bij een ondertekening heb je tenminste een middel wat dat voorkomt, anders gezegt een checksum is wijzigbaar.

De Belastingdienst interesseert zich niet voor checksums of ondertekeningen. Het enige dat de Belastingdienst eist is dat facturen niet wijzigen. Ze gaan echt niet jouw ondertekende files checken, ze doen wel een gewone audit waarin ze je papierwerk (al dan niet digitaal) narekenen.

Ik denk dat jij het verkeerd ziet namelijk; alle gegevens uit de administratie, waaronder ontvangen facturen dus. Zie ook: "niet toegestaan om computerbestanden af te drukken"

Voor de versturende partij niet nee. Voor de ontvangende partij wel. Als ik een factuur krijg van de zaak waar ik computeronderdelen koop dan is het eerste dat ik doe de factuur uitprinten en in een map met aankoopbewijzen en facturen stoppen. Als mijn administratie zo werkt is dat mijn goed recht. De versturende partij moet zijn zaken natuurlijk beter op orde hebben, maar die heeft doorgaans ook met veel meer facturen te maken.

Een checksum in combinatie met een sluitende audit trial lijkt mij wel een goede methode, ik zeg ook niet dat dit de enige methode is, maar wel een die steeds meer gebruikt gaat worden. Het kost overigens minder i/o's om via 1 query 1 tabel aan te spreken dan met verschillende querys en joins

Query caching, goeie indexes en views maken dat allemaal wel heel erg marginaal.

Janoz schreef op donderdag 02 september 2010 @ 22:17:
[...]

Duh... Ik snap dat het stoom uit je oren komt wanneer iemand met droge ogen beweert dat een join een performance hit oplevert. Lees echter ook even de rest van mijn reactie. Er zijn goede redenen om je facturatie gegevens gedenormaliseerd op te slaan, maar performance is daar niet 1 van.

Klopt, zie ook NMe in "Wat voor (database) structuur raden jull..." hierboven. Maar dat komt niet ter sprake in het betoog van keesdewit, en het performanceargument dat hij wel voert is dus onzin.

keesdewit schreef op donderdag 02 september 2010 @ 22:15:
@Janoz: Klopt, maar het is niet zo efficient om de adres gegevens met de factuurregels te joinen, vandaar de meerdere querys

Pardon? Heb je de Query Analyzer in de MSSQL Management Studio al eens geprobeerd? Een dubbele join op drie tabellen met de juiste indexes is maar marginaal minder efficiënt dan queriën op één enkele tabel. Sowieso vind ik dit argument juist van iemand die zelf XML loopt te prediken als ideaal opslagmiddel erg grappig. XML is toch écht veel minder efficiënt.

[keesdewit]

@janoz: is jouw argument dan wel getest? Het ligt inderdaad volledig aan de toepassing.

[Erwinvz1]

bvdbijl schreef op zaterdag 21 augustus 2010 @ 21:04:
Hallo,
Ik zit met een probleem:
Ik ben bezig met een systeem om mijn facturen te beheren, en daarbij staat een factuur als volgende in mijn database:
id
client_id
description

Nu heeft elke factuur meerdere "taken", bijvoorbeeld "de layout maken" die dan 5 uur duurt en 10 euro per uur is, enzovoorts
Nu heeft elke factuur meerdere taken, en is hier mijn probleem:
Ik wil dat ik zelf de orde van de taken kan veranderen, en dat de taken bewerkt en verwijdert kunnen worden en er meer toegevoegd kunnen worden.
Nu vraag ik me af wat de beste manier hier voor is? Als ik het in mijn (MySQL) database doe dan moet ik elke keer controleren of er taken weg zijn en die verwijderen, of er taken bewerkt zijn en die updaten en als er nieuwe taken zijn die toevoegen, en dit lijkt me nodeloos complex.
Ik kan ook de taken in CSV of JSON formaat in de factuur tabel opslaan maar dan is het een stuk minder flexibel doordat ik niet een taak apart kan selecteren.

Dus ik zou om jullie advies willen vragen, bij voorbaat dank

Hoe compleet wil je het systeem hebben??
Wil je facturen koppelen aan je inkoop, verkoop, boekhouding inclusief grootboek etc.?
Of is het gewoon een kleine test programma maken voor facturen.

Maar om facturen te maken moet je bijhouden wanneer hij gemaakt word, en dat verbieden dat je facturen niet kan aanpassen als hij eenmaal afgesloten is.
Er mogen namelijk nooit dubbele factuurnummers bestaan met verschilllende gegevens.
Eigenlijk is er ook maar 1 orgineel die uit de printer mag komen en andere is een kopie factuur.

Er is volgens mij ook eenn verschil tussen een normale factuur en een contant factuur (die je in een winkel ontvangt).

Je moet ook denken aan dingen als betalingsherinderen en openstaande kosten lijst.
Hoe je dat oplost.


Hoezo moet je alle orginele bestanden bewaren?
Als je boekhouding herproduceerbaar is dat goed zover ik weet.
EN je bewaard je facturen ook op papier lijk me als bedrijf?

[NMe]

keesdewit schreef op donderdag 02 september 2010 @ 22:41:
@janoz: is jouw argument dan wel getest? Het ligt inderdaad volledig aan de toepassing.

Helemaal niet. Als jij mijn één goed genormaliseerde datastructuur in een RDBMS aanwijst met de indexes op de juiste velden die langzamer query't dan XML met dezelfde dataset, dan neem ik alles dat ik in dit topic heb gezegd terug. Het ligt helemaal niet aan de toepassing wat er sneller is, queriën op XML zal altijd het onderspit delven in deze vergelijking.

[RobIII]

@keesdewit: Dus jij wil beweren, met droge ogen, dat joins hier niet tegen op kunnen:

keesdewit schreef op donderdag 02 september 2010 @ 10:26:
Juist door de native ondersteuning in mssql van het xml datatype kun je indexes bouwen en vrij makkelijk via xQuery syntax alle xml documenten doorzoeken. Er is op dat moment niet meer zoiets als veel xml bestanden op een bestandsysteem, maar een document georienteerde database (althans een hybride versie in dit geval).

---

/edit: Zo Laaaaat Ik zie dat een aantal mensen me al voor is geweest. Tabje wat te lang open laten staan en topic gaat hard



Om dan toch nog wat zinnigs toe te voegen: neem Back to Basics eens door. Misschien gaat er dan een lampje branden en krijg je het inzicht waarom XML never, ever, performanter kan zijn dan een RDBMS met de juiste indices. Ook XML in een RDBMS opgeslagen verbetert dat niet (veel). Ik raad je aan het héle stuk te lezen (want het is echt de moeite waard), maar als je meteen naar het voor jou interessante deel wil, CTRL-F dan even op "Last week I wrote that you can't".

En mocht je daar niet genoeg aan hebben, kijk dan (o.a.) even hier onder "Performance Guidelines":

Performance Guidelines

The XML data model is richer and more complex than the relational one. Not only does the XML data model allow you to model complex data, but it also must preserve hierarchical relationships and document order within the data. Document order is maintained by sorting based on XML node identifiers; this simultaneously maintains hierarchical relationships. These contribute to a more complex query plan.

Structured data should be stored in relational columns of tables for better performance. Choose the XML data model for modeling needs when your data is semi-structured, or unstructured, and contains XML markup but not with the expectation of better performance. XML schemas aid in query optimization.

Een factuur met factuurregels e.d. is "structured". Basta.

offtopic:
Toen MS net die XML zaken in SQL server stopte riep ik al dat je dit soort situaties zou gaan krijgen... en lo en behold... Abstraction is a bitch

Het heeft écht wel z'n nut om XML zo nu en dan in je RDBMS te knallen en het kan zéker handig zijn in bepaalde situaties, maar deze situatie is er daar, écht, geen van.

[ Voor 76% gewijzigd door RobIII op 02-09-2010 23:37 ]