Results 1 to 15 of 15

Thread: Database ontwerp vraag - PDF documenten in aparte tabel of niet?

  1. #1

    Database ontwerp vraag - PDF documenten in aparte tabel of niet?

    Hallo hallo,

    In mijn applicatie genereer ik diverse pdf bestanden van o.a. definitieve orders, facturen etc. die ik wil opslaan in de database. Nu zit ik al een tijdje te filosoferen waar ik deze pdf bestanden het beste kan neerzetten. In een aparte document tabel of in de desbetreffende tabel zelf (factuur pdf in factuur tabel, order PDF in order tabel). Wat is wijsheid?

    Bij voorbaat dank!

  2. #2
    Stijn Sanders develyoy's Avatar
    Join Date
    Jun 2008
    Location
    GentBrugge, Belgi?½
    Posts
    1,046
    Op welke database zit je? Want ze gaan niet allemaal op dezelfde manier om met binaire blobs.

  3. #3
    Postgres 9.3

  4. #4
    Ik zou ze uberhaupt niet in de database opslaan, maar als je dat toch doet, doe het dan in een aparte tabel. Blobs en andere grote velden staan vaak op een aparte plaats opgeslagen. Dat is al zo in klassieke file based DBFs, maar ook nog in moderne DBMS'en. Door de files in een aparte tabel te houden, loop je minder risico dat deze blob per ongeluk opgehaald, bekeken of uberhaupt gelockt wordt, en dat kan query performance ten goede komen. Mocht je de pdf een keer wel nodig hebben (en hoe vaak is dat nou, na het initieel afdrukken), dan kan je die tabel erbij joinen, of simpel op basis van het id het veld ophalen. Als het id goed geindexeerd is, zal dat niet of nauwelijks trager zijn dan met een blob die in de tabel zelf zit.

    Overigens slaan wij die factuur pdf's uberhaupt niet op. De informatie staat al in de database, dus genereren we gewoon een nieuwe pdf als dat nodig is. Eventueel zou je de PDF wel op kunnen slaan, zodat hij de eerste tijd beschikbaar is, maar alles ouder dan x dagen alsnog verwijderen en desnoods opnieuw genereren, zodat je in ieder geval de ruimte bespaart.
    1+1=b

  5. #5
    John Kuiper
    Join Date
    Apr 2007
    Location
    Almere
    Posts
    8,747
    Overigens slaan wij die factuur pdf's uberhaupt niet op. De informatie staat al in de database, dus genereren we gewoon een nieuwe pdf als dat nodig is. Eventueel zou je de PDF wel op kunnen slaan, zodat hij de eerste tijd beschikbaar is, maar alles ouder dan x dagen alsnog verwijderen en desnoods opnieuw genereren, zodat je in ieder geval de ruimte bespaart.
    +1
    Delphi is great. Lazarus is more powerfull

  6. #6
    Quote Originally Posted by GolezTrol View Post
    Overigens slaan wij die factuur pdf's uberhaupt niet op. De informatie staat al in de database, dus genereren we gewoon een nieuwe pdf als dat nodig is. Eventueel zou je de PDF wel op kunnen slaan, zodat hij de eerste tijd beschikbaar is, maar alles ouder dan x dagen alsnog verwijderen en desnoods opnieuw genereren, zodat je in ieder geval de ruimte bespaart.
    Dat is wel handig maar ik weet niet of dat juridisch mag...

    Wat als bijvoorbeeld een adres of bedrijfsnaam wijzigt van een klant en jij moet naderhand een kopie van de factuur/pdf overhandigen (aan de klant of belastingdienst)? Dan staan daar dus verkeerde gegevens op. Ik was in de veronderstelling dat je altijd een origineel kopie (op papier of pdf) moest bewaren. Opnieuw genereren zou dan dus eigenlijk niet mogen.

    (Als je zelf altijd een papieren kopie in een map doet dan is dat dus geen probleem)

  7. #7
    John Kuiper
    Join Date
    Apr 2007
    Location
    Almere
    Posts
    8,747
    Oke. Ben gedeeltelijk met (Jos) Goleztrol eens. Buiten dat wij deze ook nog een PDF via mail versturen, slaan wij de gegevens ook op. Maar dat is niet de PDF, maar de gegenereerde factuur zelf. Deze wordt extern bewaard en kan dus worden teruggehaald met de gegevens die toen zijn gegenereerd. Dus niet in een tabel. De PDF, die wordt gemaakt voor de mail, wordt verwijderd na een bepaalde tijd. Is is nutteloos om de gegenereerde rapport en PDF te bewaren.
    Delphi is great. Lazarus is more powerfull

  8. #8
    Wat als bijvoorbeeld een adres of bedrijfsnaam wijzigt van een klant en jij moet naderhand een kopie van de factuur/pdf overhandigen (aan de klant of belastingdienst)? Dan staan daar dus verkeerde gegevens op.
    Dat heeft toch niks te maken met het opslaan van een PDF?

    Een factuurtabel heeft als het goed is altijd de juiste adresgegevens van dat moment in zich. Dat dat adres later wijzigt is niet relevant. Op basis van die factuurtabel en je factuurdetail kun je dan toch altijd een nieuwe PDF aanmaken?

  9. #9
    Normaal gesproken wel, als je alle relevante gegevens van de klant ook dupliceert bij de factuur (Naam, adres, btwnummer e.d.).
    Dit wordt echter niet altijd gedaan in een database design. Vaak wordt alleen een klant-id opgeslagen bij de factuur en wordt op moment van factureren de gegevens uit de klant tabel gehaald.

    Hou dan ook rekening met het opslaan van je eigen bedrijfsnaam, Adres, KvK en BTW nummer bij die factuur in de history. Want ook die zouden kunnen wijzigen waarna je je oorspronkelijke factuur niet meer kunt genereren. Het gaat dus niet alleen om klantgegevens maar om ALLE gegevens die op een factuur staan.

    Kun jij die uit jouw factuurtabellen halen?

  10. #10
    Kun jij die uit jouw factuurtabellen halen?
    Ja. Facturen zijn een voorbeeld waarbij ik data kopieer. Dat betreft dus alle contactgegevens maar ook bijvoorbeeld in de factuurregels de artikelgegevens (artikelcode, artikelcomschrijving e.d.) en prijsgegevens.

    Doe je dat niet dan zul je volgens mij versioning op je gegevenstabellen moeten zetten, zodat je altijd de originele info kunt herstellen.

  11. #11
    Quote Originally Posted by Benno View Post
    Ja. Facturen zijn een voorbeeld waarbij ik data kopieer. Dat betreft dus alle contactgegevens maar ook bijvoorbeeld in de factuurregels de artikelgegevens (artikelcode, artikelcomschrijving e.d.) en prijsgegevens.
    En je eigen bedrijfsnaam, adresgegevens, btw en KvK nummer?
    Heb je die ook in die tabel staan?

    Of bewaar je de oorspronkelijke PDF-template (waaroverheen geprint wordt) met datum van wijziging?

    (want anders heb je nog geen juiste factuur als één van die gegeven zouden wijzigen)

  12. #12
    Ik bewaar zelf de PDF documenten en vroeger de papieren originelen die ik verstuurde per post.

    Dus je hebt wel een punt, maar ik denk dat als je maar zorgt dat je de correcte klant info altijd kunt genereren dat je dan al veel hebt gewonnen. Het is sowieso een grijs gebied, omdat een PDF bijvoorbeeld niet verplicht gesigned hoeft te zijn in Nederland. Hoe bewijs je dan dat de PDF die je hebt gearchiveerd ook daadwerkelijk de PDF is die je destijds hebt verzonden.

    Onze overheid zou uberhaupt dat soort zaken is wat beter en vooral eenduidig moeten organiseren. Hoe ga je bv om als je een UBL krijgt met embedded PDF en daarbij een PDF bijlage die afwijkt?

  13. #13
    Quote Originally Posted by Benno View Post
    Hoe bewijs je dan dat de PDF die je hebt gearchiveerd ook daadwerkelijk de PDF is die je destijds hebt verzonden.
    Als er een verkeerd eigen adres op staat is dat natuurlijk wel evident

    Maar ik geloof dat de bewijslast eigenlijk niet zo zwaar is m.b.t. facturen. Dus met alle gegevens van de klant (en artikelen) ben je inderdaad al een heel eind. En mochten eigen gegevens gewijzigd zijn kun je natuurlijk altijd nog een oude PDF-template gebruiken.

    Ik ben me pas nét aan het oriënteren op UBL (SI). Ik begrijp dat het daarbij de bedoeling is om de factuur in ieder geval als aparte bijlage te versturen (met dezelfde naam). De gegevens in de UBL dienen natuurlijk wel overeen te komen met de PDF. Als dat niet zo is dan klopt er natuurlijk iets niet. Lijkt mij een leuke voor de belastinginspecteur...

    Bij de UBL Ketentest is afgesproken om in elk geval de factuur in PDF ook als aparte bijlage te versturen (dus niet emdedded).
    http://www.softwarepakket.nl/wiki_ui...d_document.htm

  14. #14
    Ik ben ook aan het kijken naar de SI variant van UBL. Maar als je bv bij hun voorbeeldbestanden kijkt van leveranciers die de ketentest al hebben gedaan, dan zie je dat er een hoop zijn die de PDF ook embedded in de UBL hebben staan.

    De diensten die een scan omzetten naar een UBL maken het nog bonter. Daar wijken de adresgegevens in de UBL af van die op de factuur, omdat ze de gegevens opzoeken op KvK en die vervolgens invullen in de UBL.

    Daarom zei ik al het is hoog tijd dat de overheid de (digitale) processen eens eenduidig gaat vastleggen.

  15. #15
    Ik heb mijn factuur tabellen zo ontworpen dat zodra een factuur definitief is er een moment opname wordt gemaakt van alle gegevens die niet meer mogen wijzigen ik sla deze op in aparte velden. Naast deze statische gegevens, staan er ook gewoon verwijzingen naar product, klant e.d. i.v.m. met de statistieken. De reden dat ik overwoog om er ook een PDF van te maken, is dat ook het template/briefpapier gegevens kan bevatten die aan verandering onderhevig zijn. Eigenlijk wat Rik ook al aangaf.

    Uiteindelijk heb ik besloten om alle gegenereerde documenten tijdelijk te bewaren, mocht er na die tijd nog iemand zij die een printje wil, dan moet dit op een default template gedrukt worden met alleen gegevens uit de database en niet bijvoorbeeld een voorgedrukt BTW nummer of iets dergelijks.

    Bedankt voor het meedenken!

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •