Klasse in DB opslaan?

[ChessSpider]

Hey mede-tweakers,

Ik heb hier een gast op mijn MSN-lijst die zweert bij het opslaan van een PHP-klasse in de database.
Dan heb je bijvoorbeeld een klasse gebruikers, met de variabelen gebruikersnaam en een paar functies, en dan doet hij serialize() over de gehele klasse en zet hij het in de database, waarna je de gehele klasse op kan halen via een SELECT statement. Unserialize() erover en je kan hem meteen gebruiken.

Alle veranderingen worden opgeslagen in de gebruikersklasse, waarna de gehele klasse weer in de database word gestopt. Natuurlijk moeten ook alle veranderingen via de klasse gaan, je kan niet even in de database een wachtwoordje aanpassen.

Zelf haalde ik altijd bij de Constructor de meeste gegevens die ik nodig had uit de database, en soms als ik meer gegevens nodig had in de aparte methodes nog een keer.. Op zijn manier haal je in 1 keer de gehele klasse eruit en heb je meteen altijd alle gegevens die je ooit nodig hebt.

Ik heb nog nooit over zijn manier gehoord.. Wat vinden jullie ervan?

[RobIII]

Leuk zoeken, sorteren en informatie gebruiken uit die DB dan
* RobIII turft lijntje erbij. Weer iemand die het wiel opnieuw heeft uitgevonden in vierkante variant

[ Voor 42% gewijzigd door RobIII op 06-05-2008 11:01 ]

[ludo]

Ik heb die manier helaas iets te vaak gehoord... Dat mensen zoiets serieus toepassen vind ik best eng. Het is natuurlijk volstrekt belachelijk, zeker in het geval dat jij beschrijft. Alle kracht van een relationele database heb je hiermee uitgeschakeld. Op deze manier is het misschien nog makkelijker/sneller om de klasse naar een bestand op je filesystem te serializen...

[Snake]

Sja dat kan soms handig zijn, als ge grotere dingen hebt, dan moet ge neit constant een apparte mapping schrijven, maar gewoon het object erin rammen, als zijn de binairy oid.

Slecht of goed? Dat hangt echt af van de overhead die ge ermee krijgt, u user zit zowiezo in de database, dan wordt het een beetje groter (door de XML, ik heb geen idee hoe PHP serializeerd).

En het is natuurlijk een keuze. Als ge echt door en door OO werkt, kunt ge met serialize altijd ervoor zorgen dat ge met objecten werkt.

Aan u de keuze

[RAJH]

Je kunt dat beter gebruiker gaan maken van een OR-mapper. Trouwens sla je geen klasse op in de database maar een object

[Woy]

En dan voeg je een keer een veld toe aan je Gebruiker klasse en moet je alle data uit je database gaan halen, converteren en weer opslaan. Of je wilt alle gebruikers die achternaam x hebben?

Ik zou echter ook niet de data in de constructor van de class ophalen. Je kan beter een degelijke datalaag gebruiken, die je instanties vult. De Class die gepersist word kan het best niks weten van de manier hoe hij opgeslagen word. Ten eerste word je class dan niet vervuild met database logica ( Die dan waarschijnlijk ook weer in meerdere classes gecopy paste word ) en als je later nog eens wijzigingen wilt maken aan de opslag hoef je alleen die laag aan te passen.

[ Voor 4% gewijzigd door Woy op 06-05-2008 11:04 ]

[Cloud]

Er zijn een paar gevallen waarin het handig kan zijn, maar over het algemeen (en zeker voor zoiets als een gebruikerstabel!) is het zéér onpraktisch.

Bijvoorbeeld: Hoe log je in?

Alle gebruikers ophalen vanuit de DB en in een array plaatsen. Alle elementen deserialiseren, en daarna door alle elementen heenlopen om te kijken of het wachtwoord klopt met het opgeslagen wachtwoord in het geserialiseerde object
Nee, handig.

[ChessSpider]

RAJH schreef op dinsdag 06 mei 2008 @ 11:03:
Je kunt dat beter gebruiker gaan maken van een OR-mapper. Trouwens sla je geen klasse op in de database maar een object

strikt gezien een string
http://nl2.php.net/manual/en/function.serialize.php


@rwb;
een veld toevoegen is zo simpel als een nieuwe variabale aanmaken..

[Woy]

wolkje schreef op dinsdag 06 mei 2008 @ 11:04:
Er zijn een paar gevallen waarin het handig kan zijn, maar over het algemeen (en zeker voor zoiets als een gebruikerstabel!) is het zéér onpraktisch.

Een van de weinige dingen waar ik me bij kan bedenken dat het nuttig kan zijn is iets van een Sessie tabel die gepersist moet worden.

ChessSpider schreef op dinsdag 06 mei 2008 @ 11:05:
[...]
@rwb;
een veld toevoegen is zo simpel als een nieuwe variabale aanmaken..

Maar als je de volgende class serialized

code:

class Gebruiker
{
      Naam;
      Achternaam;
}

Daarna bedenk je dat je ook een tussenvoegsel wilt hebben en verander je de code naar

code:

class Gebruiker
{
     Naam;
     Tussenvoegsel;
     Achternaam;
}

Dan gaat het vast niet goed als je de oude geserializde versie gaat deserialiseren.

[ Voor 42% gewijzigd door Woy op 06-05-2008 11:09 ]

[Cloud]

Het is natuurlijk afhankelijk van het feit of je erop wilt kunnen sorteren/zoeken in je database. Is dat niet nodig? Dan is het een mogelijkheid om de zaken geserialiseerd op te slaan. Maar dan nog zit je met een aantal zaken.

Stel de definitie van je klasse verandert, er komt een eigenschap bij, of een type van een eigenschap wijzigt. Hoe ga je dan om met de al geserialiseerde instanties die je in je database hebt zitten?

[curry684]

ChessSpider schreef op dinsdag 06 mei 2008 @ 10:58:
Ik heb nog nooit over zijn manier gehoord.. Wat vinden jullie ervan?

Lach- en meelijwekkend.

[whoami]

wolkje schreef op dinsdag 06 mei 2008 @ 11:08:
Het is natuurlijk afhankelijk van het feit of je erop wilt kunnen sorteren/zoeken in je database. Is dat niet nodig?

Als zoeken niet nodig is, waarom gebruik je dan een database ?

Zoals RobIII al zei: waarom een DB gebruiken als je (alle) gegevens op een dergelijke manier opslaat ?
De DB gebruiken om de consistentie van je data te bewaken ? Errr... zit er niet in
De DB gebruiken om snel correcte gegevens op te zoeken ? Errr... zit er niet in
Redundancy vermijden ? nope
etc..

Wat is het voordeel dan om je DB als een filesysteem met overhead te gaan gebruiken ?

[Verwijderd]

Je kunt natuurlijk ook naast het object de hoofdzakelijk (denk aan pass,username) nog er naast in de database zetten, daarnaast kun je dan wel weer snel het object ophalen en snel weer een diepe functie utivoeren (bijvoorbeeld, $blaat->show_user_cars , waarbij de tabel cars weer aan een user vast zit)

Daarna bedenk je dat je ook een tussenvoegsel wilt hebben en verander je de code naar

Ik begrijp niet waarom je ineens een tussenvoegsel wilt hebben, zoiets moet je van te voren hebben uitgedacht en niet ineens gaan veranderen.

[RobIII]

whoami schreef op dinsdag 06 mei 2008 @ 11:13:
Wat is het voordeel dan om je DB als een filesysteem met overhead te gaan gebruiken ?

offtopic:
Wikipedia: WinFS

Verwijderd schreef op dinsdag 06 mei 2008 @ 11:19:
Ik begrijp niet waarom je ineens een tussenvoegsel wilt hebben, zoiets moet je van te voren hebben uitgedacht en niet ineens gaan veranderen.

Ja joh! Requirements veranderen nooit in the real world!

[ Voor 38% gewijzigd door RobIII op 06-05-2008 11:21 ]

[Cloud]

whoami schreef op dinsdag 06 mei 2008 @ 11:13:
Als zoeken niet nodig is, waarom gebruik je dan een database ?

Ik begrijp wat je bedoelt. In de situatie die de TS beschrijft is het natuurlijk hartstikke fout.

Ik bedoelde alleen niet een gehele tabel serialiseren, daar kan ik inderdaad geen enkel goed nut voor bedenken. Maar je zou bijvoorbeeld kunnen denken aan een tabel waarbij één kolom een geserialiseerde hoeveelheid data bevat met details over het record. Het kan prima zijn dat je niet op die details hoeft te kunnen zoeken/sorteren, maar dat dat bij de rest van de informatie wel moet kunnen. De vraag is dan natuurlijk waarom je niet die geserialiseerde velden ook als kolommen in je tabel opslaat, maar toch; er zijn toepassingen te bedenken.

Dit alles natuurlijk theoretisch hé. Veruit in de meeste gevallen zal het zeker niet handig zijn.

[Kettrick]

Verwijderd schreef op dinsdag 06 mei 2008 @ 11:19:
Ik begrijp niet waarom je ineens een tussenvoegsel wilt hebben, zoiets moet je van te voren hebben uitgedacht en niet ineens gaan veranderen.

Helaas werkt dat in de praktijk niet zo, de schaalbaarheid van een applicatie is vrijwel altijd van cruciaal belang. Een applicatie is vrijwel nooit "af"

[Verwijderd]

Dan ga je toch fijn verschillende versies van een class bijhouden en hiervan een versienummer in de database zetten....

Oke, je software word dan 100x zo complex om mee te werken en te debuggen.... maar hey... het kan wel

[Janoz]

ChessSpider schreef op dinsdag 06 mei 2008 @ 11:05:
[...]


strikt gezien een string
http://nl2.php.net/manual/en/function.serialize.php

Nee, strikt gezien is het gewoon het object en niet de klasse. Dat het uiteindelijk weer een string wordt is niet relevant voor wat RAJH aan wil geven. De opmerking 'een klasse opslaan' betekent namelijk dat je de code opslaat, terwijl gewoon wordt bedoeld dat de instantie, en dus de data opgeslagen wordt.

@rwb;
een veld toevoegen is zo simpel als een nieuwe variabale aanmaken..

Waarna je hele database corrupt is omdat het niet meer gedeserialiseerd kan worden (maar dat was al gezegd)

[RobIII]

Kort samengevat; volgende keer dat die vriend komt opscheppen over z'n geniale systeem gewoon netjes blijven knikken en vooral laten blijken hoe geweldig zijn systeem is. Vertel er dan bij dat het voor jou te ingewikkeld is en dat je nooit kunt tippen aan zijn genialiteit en dat je dus opgescheept zit met het ouderwets 'dom' opslaan van je data. En dan langzaam wat stapjes achteruit blijven doen tot 'ie een klein stipje aan de horizon is. Om vervolgens je schaterlach eruit te gooien en jezelf eens lekker op de dijen te kletsen.

Ik denk dat dat nog het beste advies in heel dit topic is

[ChessSpider]

Janoz schreef op dinsdag 06 mei 2008 @ 11:26:
[...]


Nee, strikt gezien is het gewoon het object en niet de klasse. Dat het uiteindelijk weer een string wordt is niet relevant voor wat RAJH aan wil geven. De opmerking 'een klasse opslaan' betekent namelijk dat je de code opslaat, terwijl gewoon wordt bedoeld dat de instantie, en dus de data opgeslagen wordt.

k

Waarna je hele database corrupt is omdat het niet meer gedeserialiseerd kan worden (maar dat was al gezegd)

Sorry, maar hier ben je mij kwijt.. Als je het object opgehaald hebt en geunserialized, kan je controleren of die variabele bestaat en zo niet aanmaken ( lol ).

Ik ben iniedergeval wel overtuigd om hier vandaan te blijven... Ik zelf dacht dat het ook langzamer was.. Ik dacht dat serialize en unserialize() aanroepen wel een groot effect zal hebben op performance, zeker met wat grotere objecten.

[whoami]

Verwijderd schreef op dinsdag 06 mei 2008 @ 11:19:

Ik begrijp niet waarom je ineens een tussenvoegsel wilt hebben, zoiets moet je van te voren hebben uitgedacht en niet ineens gaan veranderen.

the only constant in software is change.

[Sebazztiaan]

Verwijderd schreef op dinsdag 06 mei 2008 @ 11:25:
Dan ga je toch fijn verschillende versies van een class bijhouden en hiervan een versienummer in de database zetten....

Oke, je software word dan 100x zo complex om mee te werken en te debuggen.... maar hey... het kan wel

Of anders kan je ook een 'Memento' pattern gebruiken

[RobIII]

ChessSpider schreef op dinsdag 06 mei 2008 @ 11:33:
Ik dacht dat serialize en unserialize() aanroepen wel een groot effect zal hebben op performance, zeker met wat grotere objecten.

Bij een resultset van een paar tientallen of honderden* records is het misschien amper merkbaar, maar zodra je met een beetje serieuze bak gegevens aan de slag gaat... I'd hate to be around Maar dat is dus alleen nog maar (een klein stukje) van het performance nadeel dat je hebt; dan heb je de rest nog niet eens in die berekening meegenomen...

Er is gewoon geen 'nice way' om dit te brengen; het is gewoon van voor-tot-achter kans-loos.

_{* en honderd+ betwijfel ik al...}

[ Voor 25% gewijzigd door RobIII op 06-05-2008 11:44 ]

[Verwijderd]

Je zou die gast ook naar het [Alg] Slechtste programmeervoorbeelden deel 3 topic kunnen sturen als subtiele hint...

Of hij snapt het of hij gaat die voorbeelden verwerken in zijn eigen code...

Wie weet...

[Kettrick]

RobIII schreef op dinsdag 06 mei 2008 @ 11:35:
[...]

Bij een resultset van een paar tientallen of honderden records is het misschien amper merkbaar, maar zodra je met een beetje serieuze bak gegevens aan de slag gaat... I'd hate to be around

Je kan natuurlijk een stored procedure schrijven die de data deserialized in je db en daar een index op maken . Behalve dat dat leuk is om te doen heb je er geen zak aan, maar het kan

als in

code:

SELECT iets FROM person WHERE extract_from_serialized(iets,naam) = 'Piet'

[ Voor 9% gewijzigd door Kettrick op 06-05-2008 11:39 ]

[SchizoDuckie]

RoeLz schreef op dinsdag 06 mei 2008 @ 11:37:
[...]


Je kan natuurlijk een stored procedure schrijven die de data deserialized in je db en daar een index op maken . Behalve dat dat leuk is om te doen heb je er geen zak aan, maar het kan

als in

code:

SELECT iets FROM person WHERE extract_from_serialized(iets,naam) = 'Piet'

Move => TheDailyWTF

[Kettrick]

SchizoDuckie schreef op dinsdag 06 mei 2008 @ 11:47:
[...]

Move => TheDailyWTF

Het lijkt heel gek, maar ik denk als je de php serialization vervangt door XML en de stored procedure vervangt voor xpath_query dat het ineens "hip en trendy" is

[whoami]

Ik denk het niet.
XML mag je niet zien als vervanger van een DBMS (al zijn er natuurlijk mensen die dat wel doen, maar dat hoort dan evengoed op The Daily WTF thuis).

[Kettrick]

whoami schreef op dinsdag 06 mei 2008 @ 12:38:
Ik denk het niet.
XML mag je niet zien als vervanger van een DBMS (al zijn er natuurlijk mensen die dat wel doen, maar dat hoort dan evengoed op The Daily WTF thuis).

Uiteraard niet, maar toch zie je een aantal databases die dergelijke xml functies ondersteunen, volgens mij doen MSSQL, Oracle ( sinds versie 9?) en postgres het sowieso. Maar dat neemt idd niet weg dat de manier waarop TS het omschrijft kansloos is

[Woy]

Idd het is een beetje^* stom om xml in je database te gaan stoppen en dan in query's aan de hand van een xpath query data te gaan zoeken. De database zal dan lekker gebruik kunnen maken van al zijn indexes.

^*understatment

RoeLz schreef op dinsdag 06 mei 2008 @ 12:52:
[...]
Uiteraard niet, maar toch zie je een aantal databases die dergelijke xml functies ondersteunen, volgens mij doen MSSQL, Oracle ( sinds versie 9?) en postgres het sowieso. Maar dat neemt idd niet weg dat de manier waarop TS het omschrijft kansloos is

Dat iets ondersteund word zegt nog niet dat het handig is om het te gebruiken. Ik ken wel wat applicaties die het gebruiken, maar dat is dan meestal voor xml input die aan een sp aangeleverd word. Maar zelfs daar verdient het niet echt de schoonheidsprijs natuurlijk.

[ Voor 58% gewijzigd door Woy op 06-05-2008 12:56 ]

[Big Womly]

Volgens mij wordt serialiseren van objecten om in een DB te steken wel handig als je bijvoorbeeld een foto van een persoon mee wil opslaan in de DB, of als je een DB vol steekt met vogels, dat je hun zangpatroon mee wilt opslaan.

En als je dan toch business objects rechtstreeks wil gaan opslaan in je db, en je object wordt later uitgebreid met extra velden (crf: tussenvoegsel bij de naam) dan kan je natuurlijk nog altijd werken met afgeleide klassen...

[Gerco]

RoeLz schreef op dinsdag 06 mei 2008 @ 12:52:
Uiteraard niet, maar toch zie je een aantal databases die dergelijke xml functies ondersteunen, volgens mij doen MSSQL, Oracle ( sinds versie 9?) en postgres het sowieso. Maar dat neemt idd niet weg dat de manier waarop TS het omschrijft kansloos is

Ik doe zoiets om berichten in een database op te slaan voor track & trace doeleinden. Zodra het bericht aankomt doe ik er een paar xpath queries op voor de key velden en die sla ik direct in de tabel op. De rest van het bericht gaat dan in zijn geheel in 1 veld.

Dan kun je zoeken op de key data en als je het goede bericht gevonden hebt, kun je het herzenden, weggooien of ter referentie opgeslagen houden. Wat je maar wilt.

Xml in een database is niet altijd zinloos. Het is pas zinloos als je dat gaat gebruiken in plaats van een zinnige relationele datastructuur.

[Kettrick]

mbsaerens schreef op dinsdag 06 mei 2008 @ 13:03:
Volgens mij wordt serialiseren van objecten om in een DB te steken wel handig als je bijvoorbeeld een foto van een persoon mee wil opslaan in de DB, of als je een DB vol steekt met vogels, dat je hun zangpatroon mee wilt opslaan.

Dat is gewoon een BLOB, wat als je weetikhoeveel php serialized foto's in je db hebt staan en je migreerd naar Java ?

En als je dan toch business objects rechtstreeks wil gaan opslaan in je db, en je object wordt later uitgebreid met extra velden (crf: tussenvoegsel bij de naam) dan kan je natuurlijk nog altijd werken met afgeleide klassen...

Zodat niet je database maar je hele applicatie kansloos wordt

Gerco schreef op dinsdag 06 mei 2008 @ 13:03:
[...]

Ik doe zoiets om berichten in een database op te slaan voor track & trace doeleinden. Zodra het bericht aankomt doe ik er een paar xpath queries op voor de key velden en die sla ik direct in de tabel op. De rest van het bericht gaat dan in zijn geheel in 1 veld.

Dan kun je zoeken op de key data en als je het goede bericht gevonden hebt, kun je het herzenden, weggooien of ter referentie opgeslagen houden. Wat je maar wilt.

Xml in een database is niet altijd zinloos. Het is pas zinloos als je dat gaat gebruiken in plaats van een zinnige relationele datastructuur.

Ik heb het zelf gebruikt om B2B berichte te loggen, het is dan erg handig dat je eens per jaar xpath kan gebruiken om wat orders te zoeken , maar daar wil je je app niet op bouwen idd.

[ Voor 36% gewijzigd door Kettrick op 06-05-2008 13:07 ]

[Cloud]

mbsaerens schreef op dinsdag 06 mei 2008 @ 13:03:
Volgens mij wordt serialiseren van objecten om in een DB te steken wel handig als je bijvoorbeeld een foto van een persoon mee wil opslaan in de DB, of als je een DB vol steekt met vogels, dat je hun zangpatroon mee wilt opslaan.

Die data is toch al binair? Die hoef je niet meer te serializeren natuurlijk.

[Janoz]

ChessSpider schreef op dinsdag 06 mei 2008 @ 11:33:
[...]

k

[...]


Sorry, maar hier ben je mij kwijt.. Als je het object opgehaald hebt en geunserialized, kan je controleren of die variabele bestaat en zo niet aanmaken ( lol ).

De vraag is of je je gegevens uberhaupt nog wel kunt deserializeren omdat de klasse definitie gewijzigd is.

[Big Womly]

RoeLz schreef op dinsdag 06 mei 2008 @ 13:05:
Zodat niet je database maar je hele applicatie kansloos wordt

Dat moet je dan gaan oplossen met design patterns

[Woy]

mbsaerens schreef op dinsdag 06 mei 2008 @ 14:00:
[...]


Dat moet je dan gaan oplossen met design patterns

Je bedoelt serieus dat je vind dat als je later velden toe wilt voegen je dit maar met sub-classes moet doen?

[Jaap-Jan]

Janoz schreef op dinsdag 06 mei 2008 @ 13:55:
[...]

De vraag is of je je gegevens uberhaupt nog wel kunt deserializeren omdat de klasse definitie gewijzigd is.

Ik heb het geprobeerd met de volgende stukjes code en dat is geen probleem:

PHP:

<pre>
<?

class A {
        public $var1;
        public $var2;
}

$a = new A();
$a->var1 = 'The answer to Life, the Universe and Everything';
$a->var2 = 42;

var_dump($a);
file_put_contents('object.dat', serialize($a));

?>
</pre>

Output:

code:

object(A)#1 (2) {
  ["var1"]=>
  string(47) "The answer to Life, the Universe and Everything"
  ["var2"]=>
  int(42)
}

PHP:

<pre>
<?

class A {
        public $var1;
        public $var11;
        public $var2;
}

$a = unserialize(file_get_contents('object.dat'));
var_dump($a);

?>
</pre>

Output:

code:

object(A)#1 (3) {
  ["var1"]=>
  string(47) "The answer to Life, the Universe and Everything"
  ["var11"]=>
  NULL
  ["var2"]=>
  int(42)
}

En dat is ook niet zo raar, want php serialized het als volgt:

code:

O:1:"A":2:{s:4:"var1";s:47:"The answer to Life, the Universe and Everything";s:4:"var2";i:42;}

Met variabelennamen erbij dus.

[Cloud]

Jaap-Jan schreef op dinsdag 06 mei 2008 @ 15:04:
Ik heb het geprobeerd met de volgende stukjes code en dat is geen probleem:

Je bedoelt zeker dat het geen probleem is als je een veld toevoegt? Het lijkt me namelijk heel stug dat het bij het wijzigen van veldnamen, -typen en het verwijderen van velden even goed gaat.

Ik vind het trouwens een slechte zaak dat het mogelijk is, maar goed dat is een hele andere discussie mijn mening. Als een klasse definitie gewijzigd is, dan zijn die nieuwe instanties gewoon niet meer gelijk aan instanties van de oude definitie. Punt uit.

edit:

@ hieronder, dat is helemaal waar natuurlijk. Maar m.i. zou een runtime error niet misstaan in zo'n geval.

[ Voor 9% gewijzigd door Cloud op 06-05-2008 15:30 ]

[RobIII]

wolkje schreef op dinsdag 06 mei 2008 @ 15:09:
Ik vind het trouwens een slechte zaak dat het mogelijk is, maar goed dat is een hele andere discussie.

Je kunt jezelf in zowat elke taal (1-5GL) wel in je voet schieten; of je dat dan ook maar moet doen is een tweede.

[Kwistnix]

wolkje schreef op dinsdag 06 mei 2008 @ 15:09:
[...]
Ik vind het trouwens een slechte zaak dat het mogelijk is, maar goed dat is een hele andere discussie. Als een klasse definitie gewijzigd is, dan zijn die nieuwe instanties gewoon niet meer gelijk aan instanties van de oude definitie. Punt uit.

Mwa, dat is niet per definitie waar natuurlijk. Geserialiseerde objecten kunnen prima compatible blijven, zodra de klasse definitie van die objecten wijzigt. Het ligt er maar net aan wat de wijziging inhoudt.
In Java werkt dat net zo. Als je niet expliciet een versie identifier (serialVersionUID) opgeeft, dan loop je een goede kans dat het serialisatie mechanisme besluit dat geserialiseerde objecten niet meer compatible zijn met de nieuwe klasse definitie, terwijl dat misschien volkomen onterecht is. Daarom is het ook altijd aan te bevelen om zelf expliciet een identifier aan serialiseerbare typen te hangen. De meeste style checking tools zullen bijvoorbeeld gelijk mekkeren wanneer je dat niet doet.
Ik vind dat best een goede aanpak.

[Verwijderd]

Jaap-Jan schreef op dinsdag 06 mei 2008 @ 15:04:
[...]

Ik heb het geprobeerd met de volgende stukjes code en dat is geen probleem:
[...]

Dat zoiets in PHP mogenlijk is wil nog niet zeggen dat het een geaccepteerde methode is in programmeer-land .

Een taal als C# bijvoorbeeld zou er keihard op stukgaan .

[Woy]

Verwijderd schreef op dinsdag 06 mei 2008 @ 16:58:
[...]
Een taal als C# bijvoorbeeld zou er keihard op stukgaan .

[Mierenneuk mode]
Een taal als C# ondersteund geen Serializatie. Dat doet de library die bij het .NET Framework meegeleverd word
[/]

[Jaap-Jan]

Verwijderd schreef op dinsdag 06 mei 2008 @ 16:58:
[...]

Dat zoiets in PHP mogenlijk is wil nog niet zeggen dat het een geaccepteerde methode is in programmeer-land .

Een taal als C# bijvoorbeeld zou er keihard op stukgaan .

Het ging in de startpost over PHP, dus dan lijkt het me logisch dat je daar een codevoorbeeld voor gaat maken.

En het is ook niet iets wat ik zelf zou gaan implementeren in productie, het is alleen maar een testcase dat het wel mogelijk is, mits de variabelennamen niet wijzigen.

[PainkillA]

en hoe wil je nou wat mooie statistieken genereren of mail versturen naar al die gebruikers? Dit is toch gewoon zo onhandig? Wat heeft die gozer eigelijk voor opleiding gedaan of is het een hobbyist? En word dit serieus commercieel gebruikt?

[ChessSpider]

PainkillA schreef op dinsdag 06 mei 2008 @ 18:45:
en hoe wil je nou wat mooie statistieken genereren of mail versturen naar al die gebruikers? Dit is toch gewoon zo onhandig? Wat heeft die gozer eigelijk voor opleiding gedaan of is het een hobbyist? En word dit serieus commercieel gebruikt?

Hobyist, en ook niet voor alles, zover ik weet. Deze gebruikersklasse was eigenlijk een slecht voorbeeld omdat je natuurlijk problemen hebt met selecteren, dit was een voorbeeld van mij, niet code van hem. Ookal is dit wel de theorie van hoe hij het toepast

[Alain]

Ik ben (net) begonnen aan een studie informatica aan de open universiteit en daar wordt in de module databases gesproken over object georienteerde databases. Wordt dit in de praktijk vaak toegepast?

[Verwijderd]

AlainS schreef op dinsdag 06 mei 2008 @ 21:01:
Ik ben (net) begonnen aan een studie informatica aan de open universiteit en daar wordt in de module databases gesproken over object georienteerde databases. Wordt dit in de praktijk vaak toegepast?

Ze zijn er wel, maar ben er nog nooit echt tegengekomen.
Wat je wel ziet is een benadering hiervan via OR-mappers.

Maar dit is allebei geheel wat anders waar TS het overheeft. Dat is namelijk gewoon onzin. (en meer zeg ik er niet over)

[denyos]

RoeLz schreef op dinsdag 06 mei 2008 @ 11:37:
[...]


Je kan natuurlijk een stored procedure schrijven die de data deserialized in je db en daar een index op maken . Behalve dat dat leuk is om te doen heb je er geen zak aan, maar het kan

als in

code:

SELECT iets FROM person WHERE extract_from_serialized(iets,naam) = 'Piet'

Tja, en als hij als database bijvoorbeeld MSSQL2k5 gebruikt (wat me niet bepaald logisch lijkt) dan zou je met een managed storedprocedure gewoon lekker xpath kunnen gebruiken op je xmldocument. Maarja, als hij al php gebruikt, dan is het idee van het complete object opslaan beetje erg overbodig / raar inderdaad.

[Woy]

denyos schreef op dinsdag 06 mei 2008 @ 22:56:
[...]


Tja, en als hij als database bijvoorbeeld MSSQL2k5 gebruikt (wat me niet bepaald logisch lijkt) dan zou je met een managed storedprocedure gewoon lekker xpath kunnen gebruiken op je xmldocument. Maarja, als hij al php gebruikt, dan is het idee van het complete object opslaan beetje erg overbodig / raar inderdaad.

Als je MSSQL2k5 is het idee net zo overbodig / raar. Soms kan het handig zijn om (stukken) xml op te slaan in je database, maar dan zal je daar niet in moeten zoeken in je database, dat is gewoon niet het sterke punt van databases en dan moet je ze daar ook niet voor willen misbruiken

[kamerplant]

ChessSpider schreef op dinsdag 06 mei 2008 @ 19:48:
[...]

Hobyist, en ook niet voor alles, zover ik weet. Deze gebruikersklasse was eigenlijk een slecht voorbeeld omdat je natuurlijk problemen hebt met selecteren, dit was een voorbeeld van mij, niet code van hem. Ookal is dit wel de theorie van hoe hij het toepast

Joh hey, ik zie mijzelf ook als hobbyist maar ik heb ook wel direct door dat dit not-done is . Echt wat een vage gast. Kun je hem niet op dit topic wijzen, ik ben benieuwd welke argumenten hij gebruikt

RobIII schreef op dinsdag 06 mei 2008 @ 11:00:
* RobIII turft lijntje erbij. Weer iemand die het wiel opnieuw heeft uitgevonden in vierkante variant

[YopY]

Volgens mij wordt het bijna tijd voor "Het Grote Mensen-Die-Denken-Dat-Objecten-Serializen-En-In-Databases-Plaatsen-Slim-Is"-topic, naast een gelijksoortig topic over het plaatsen van php bestanden e.d. in een database. Of gewoon een generiek topic over database misbruik.

[Bosmonster]

Daar is het slechtste programmeervoorbeelden topic toch al voor?

Dit topic houdt pas op zodra iedereen even heeft kunnen zeggen hoe dom is het om object instanties in de database op te slaan

edit: bij deze trouwens dus nog even: Das echt wel heel dom!

[ Voor 14% gewijzigd door Bosmonster op 07-05-2008 13:14 ]

[RobIII]

Bosmonster schreef op woensdag 07 mei 2008 @ 13:14:
Dit topic houdt pas op zodra iedereen even heeft kunnen zeggen hoe dom is het om object instanties in de database op te slaan

edit: bij deze trouwens dus nog even: Das echt wel heel dom!

^^ En daarom denk ik dat het verstandig is om hier maar een einde aan te breien. De algemene consensus lijkt me duidelijk en ik zie hier verder ook niet veel nuttigs meer uit ontstaan behalve nogmaals bevestigen hoe 'minder slim' het is en 'aanvallen' op de bedenker hiervan.