[java] Object opslaan in PostgreSQL database

[Hatsekie_D]

Is het mogelijk om een object (serializable?) op te slaan in een PostgreSQL database?

Ik heb zo'n vermoeden dat dat moet kunnen door het volgende stukje code:

Java:

      baos = new ByteArrayOutputStream();
      oos = new ObjectOutputStream(baos);
      oos.writeObject(item.item);
      oos.flush();

      byte[] b = baos.toByteArray();

maar ik krijg dan vervolgens b niet in de database.

Iemand een idee hoe ik dit zou moeten doen?

Ik werk met een DBCon object die een doUpdate(String sqlquery) aanroept om toegang te krijgen tot de database, misschien moet dit anders?

[Alarmnummer]

Hatsekie_D schreef op 22 september 2003 @ 16:31:
Is het mogelijk om een object (serializable?) op te slaan in een PostgreSQL database?

Als je een veld aanmaakt van het type blob dan moet het geen probleem zijn.

Ik wil je alleen Serializen van objecten wel afraden. Er komen zoveel problemen bij te kijken, dat je imho een stuk verstandiger eraan doet om het op een andere manier te doen (eentje waarbij je beter moet nadenken wat je mee gaat slepen). Als je namelijk niet oppast serialize je je hele applicatie, singletons en krijg je ineens meerdere instanties van dezelde entiteit (en probeer dan maar te zoeken waar het probleem zit).

Daarnaast krijg je met serializen te maken met het feit dat je code misschien veranderd en je een geserialized object niet goed meer terug kan krijgen. Serializen dus alleen gebruiken voor shortterm persitence en niet voor longterm.

[edit]
kijk eens naar jdo of xml.

[ Voor 3% gewijzigd door Alarmnummer op 22-09-2003 16:56 ]

[Hatsekie_D]

Alarmnummer schreef op 22 September 2003 @ 16:52:
[...]

Als je een veld aanmaakt van het type blob dan moet het geen probleem zijn.

Ik wil je alleen Serializen van objecten wel afraden. Er komen zoveel problemen bij te kijken, dat je imho een stuk verstandiger eraan doet om het op een andere manier te doen (eentje waarbij je beter moet nadenken wat je mee gaat slepen). Als je namelijk niet oppast serialize je je hele applicatie, singletons en krijg je ineens meerdere instanties van dezelde entiteit (en probeer dan maar te zoeken waar het probleem zit).

Daarnaast krijg je met serializen te maken met het feit dat je code misschien veranderd en je een geserialized object niet goed meer terug kan krijgen. Serializen dus alleen gebruiken voor shortterm persitence en niet voor longterm.

PGAdmin (de admin voor PostgreSQL die ik gebruik) kent het type blob niet...
Verder weet ik ook niet helemaal hoe ik dan het object moet opslaan. Kan dit überhaupt wel via een SQL query of moet ik hiervoor rechtstreeks de Statement aanspreken?

[Alarmnummer]

Ik moet eerlijk toegeven dat het al weer jaren geleden is dat ik het nog een keer heb gedaan, dus ik kan je niet verder voorzien van praktische informatie. Maar kijk anders hier eens naar:
http://java.sun.com/products/jfc/tsc/articles/persistence4/

Dan kan je het tenminste als string opslaan.

[Hatsekie_D]

Alarmnummer schreef op 22 September 2003 @ 17:06:
Ik moet eerlijk toegeven dat het al weer jaren geleden is dat ik het nog een keer heb gedaan, dus ik kan je niet verder voorzien van praktische informatie. Maar kijk anders hier eens naar:
http://java.sun.com/products/jfc/tsc/articles/persistence4/

Dan kan je het tenminste als string opslaan.

tnx, ik ga het even bekijken

[Alarmnummer]

Hatsekie_D schreef op 22 September 2003 @ 17:09:
[...]

tnx, ik ga het even bekijken

Kijk ook even naar jdo. Daarmee kan je 'declaratief' programmeren binnen java. Jij geeft op waarheen bepaalde velden en classes gemapt moeten worden, en de rest van de database code wordt erbij gegenereerd door een bytecode enhancer.

Nog een nadeel aan geserializde objecten is dat andere applicaties die geen beschikking hebben over je classes er niets mee kunnen. Je kan dus bv niet gaan querien, en je kan ook geen garanties meer geven dat je database consistent is. Stel dat je een haar-kleur rood object meeserialezed bij een hoofd-object, en je verwijderd de haarkleur rood uit de database, dan zit het nog wel steeds bij jouw object. Als je de key van dehaarkleur meeneemt ipv het object, dan blijf je ook dat probleem houden.

dus.... niet serializen:)

[ Voor 46% gewijzigd door Alarmnummer op 22-09-2003 17:14 ]

[Hatsekie_D]

Alarmnummer schreef op 22 september 2003 @ 17:11:
[...]

Kijk ook even naar jdo. Daarmee kan je 'declaratief' programmeren binnen java. Jij geeft op waarheen bepaalde velden en classes gemapt moeten worden, en de rest van de database code wordt erbij gegenereerd door een bytecode enhancer.

Nog een nadeel aan geserializde objecten is dat andere applicaties die geen beschikking hebben over je classes er niets mee kunnen. Je kan dus bv niet gaan querien, en je kan ook geen garanties meer geven dat je database consistent is. Stel dat je een haar-kleur rood object meeserialezed bij een hoofd-object, en je verwijderd de haarkleur rood uit de database, dan zit het nog wel steeds bij jouw object. Als je de key van dehaarkleur meeneemt ipv het object, dan blijf je ook dat probleem houden.

dus.... niet serializen:)

Dat verhaal van de haarkleur is nou juist wél de bedoeling...
Ik moet facturen opslaan in de database, en die moeten dus niet afhankelijk zijn van prijswijzigingen en artikelnummerwijzigingen.

Maar goed... ik zal niet serializen

[ Voor 3% gewijzigd door Hatsekie_D op 22-09-2003 17:18 ]

[Alarmnummer]

Hatsekie_D schreef op 22 September 2003 @ 17:17:
[...]


Dat verhaal van de haarkleur is nou juist wél de bedoeling...
Ik moet facturen opslaan in de database, en die moeten dus niet afhankelijk zijn van prijswijzigingen en artikelnummerwijzigingen.

aaaaarrgghh... dit is dus een waahaardeloze oplossing. Je kan beter je database structuur zo aanpassen dat deze dit goed kan verwerken ipv gebruik te maken van dat kutgevolg van het serializen.

[Hatsekie_D]

Alarmnummer schreef op 22 September 2003 @ 17:23:
[...]

aaaaarrgghh... dit is dus een waahaardeloze oplossing. Je kan beter je database structuur zo aanpassen dat deze dit goed kan verwerken ipv gebruik te maken van dat kutgevolg van het serializen.

eh... suggesties?
Ik zie niet echt een andere oplossing.
Het ging mij er om dat ik een object kon opslaan in de database en ik dacht dat dat moest door te serializen, dat blijkt niet echt zo te zijn...
Als ik de eerder genoemde XMLEncoder nu kan gebruiken, is dat wel een goede oplossing dan?
De factuur hoeft zeker NIET meer aan te passen te zijn nadat hij is opgeslagen en moet dus onafhankelijk zijn van de artikelen-tabel.

[Alarmnummer]

Hatsekie_D schreef op 22 september 2003 @ 17:27:
[...]
eh... suggesties?

Stel dat dit je structuur is:

Artikel {artikelnr, prijs, omschrijving}

Order {ordernr, klantnr , ...}

OrderRegel{artikelnr, aangenomen_prijs, ordernr, ..}

Op deze manier kan je dus de prijs handhaven die dat product had bij aanname van die Order.

Het voordeel hieraan is dat je wel referentiele integriteit kan afdwingen. Als namelijk een Artikel wordt verwijderd, dan kan dit ook binnen de contracten worden afgedwonen.

Verder is het misschien niet verstandig om een artikel helemaal te verwijderen uit de db, maar van een flag te voorzien: in_assortiment.

Als ik de eerder genoemde XMLEncoder nu kan gebruiken, is dat wel een goede oplossing dan?

Beter dan het serializen omdat een XML string tenminste nog door een ander uitgelezen kan worden. Verder zou ik het zelf echt relationeel gaan mappen zodat informatie voor iedereen beschikbaar blijft, en je fijn gebruik kan maken van allerlei lieve mechanismes die de database voor je uitvoerd.

ps:
en wat heeft je leraar database design je geleerd over redundantie?Denk maar eens goed na over je eigen ontwerp

[ Voor 7% gewijzigd door Alarmnummer op 22-09-2003 17:40 ]

[Hatsekie_D]

Alarmnummer schreef op 22 September 2003 @ 17:32:
[...]

Stel dat dit je structuur is:

Artikel {artikelnr, prijs, omschrijving}

Order {ordernr, klantnr , ...}

OrderRegel{artikelnr, aangenomen_prijs, ordernr, ..}

Op deze manier kan je dus de prijs handhaven die dat product had bij aanname van die Order.

Het voordeel hieraan is dat je wel referentiele integriteit kan afdwingen. Als namelijk een Artikel wordt verwijderd, dan kan dit ook binnen de contracten worden afgedwonen.

Verder is het misschien niet verstandig om een artikel helemaal te verwijderen uit de db, maar van een flag te voorzien: in_assortiment.


[...]

Beter dan het serializen omdat een XML string tenminste nog door een ander uitgelezen kan worden. Verder zou ik het zelf echt relationeel gaan mappen zodat informatie voor iedereen beschikbaar blijft, en je fijn gebruik kan maken van allerlei lieve mechanismes die de database voor je uitvoerd.

ps:
en weet heeft je leraar database design je geleerd over redundantie?

Dit systeem had ik tot nu toe ook wel maar het leek mij handiger om (omdat een factuur toch niet gewijzigd mag worden) hem op te slaan als object, ook vanwege ruimtebesparing in de database.

Ik denk nu dat ik het toch maar bij het huidige laat, met een factuurregel-tabel dus, want nu ik dit zo eens bekijk is dat toch handiger.

Bedankt voor de hulp!

[Alarmnummer]

Hatsekie_D schreef op 22 September 2003 @ 17:39:
[...]

Dit systeem had ik tot nu toe ook wel maar het leek mij handiger om (omdat een factuur toch niet gewijzigd mag worden) hem op te slaan als object, ook vanwege ruimtebesparing in de database.

Ik betwijfel over het minder ruimte kost. Een geserialized object krijg allerlei informatie mee zoals oa serialize id.

Ik denk nu dat ik het toch maar bij het huidige laat, met een factuurregel-tabel dus, want nu ik dit zo eens bekijk is dat toch handiger.

gelukkig *heeft ie in ieder geval 1 goede daad vericht vandaag*

Bedankt voor de hulp!

np Ik heb er zelf vroeger ook mee lopen kloten en ik heb daar in de tussentijd veel over na kunnen denken. Kijk anders eens naar het boek van Fowler: Patterns of Enterprise Application Architecture.

[zneek]

Misschien eens kijken naar Hibernate? Of misschien zelfs wel EJB? EJB gaat mischien wat ver als je alleen persistence zoekt, maar Hibernate is ook redelijk "dun" toe te passen.

[Alarmnummer]

zneek schreef op 22 september 2003 @ 20:16:
Of misschien zelfs wel EJB?

EJB is wel een beetje met een kanon op een mug schieten

EJB gaat mischien wat ver als je alleen persistence zoekt

idd.

maar Hibernate is ook redelijk "dun" toe te passen.

Ik heb zelf nog niets gedaan met hibernate maar het schijnt wel vrij populair te zijn.

[zneek]

Alarmnummer schreef op 23 September 2003 @ 09:32:
[...]

EJB is wel een beetje met een kanon op een mug schieten


[...]

idd.


[...]

Ik heb zelf nog niets gedaan met hibernate maar het schijnt wel vrij populair te zijn.

Kijk maar eens op http://www.hibernate.org. Ze gaan de EJB persistence laag van Jboss invullen. Hibernate is al aardig volwassen, en gaat nog beter worden. Zou je zeker eens moeten bekijken.