Archief - MYSQL: arrays

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.

Marbug

Legacy Member
Naar het schijnt zou er een oplossing moeten zijn om een array in u database te stoppen. Ik heb daar al is achter zitten zoeken, maar heb niets gevonden. Zou iemand mij misschien kunnen helpen?
Vroeger/nu doe ik het altijd met een string: ik zet alle waarden tussen horizontale lijntjes:
Code:
|id1||id2||id3|
Maar er zal dus een betere oplossing moeten zijn ...

RpR

Legacy Member
Marbug zei:
Naar het schijnt zou er een oplossing moeten zijn om een array in u database te stoppen. Ik heb daar al is achter zitten zoeken, maar heb niets gevonden. Zou iemand mij misschien kunnen helpen?
Vroeger/nu doe ik het altijd met een string: ik zet alle waarden tussen horizontale lijntjes:
Code:
|id1||id2||id3|
Maar er zal dus een betere oplossing moeten zijn ...
Ik zou het zo gedaan hebben

stel 2 tabellen
Persoon met items
persoonid, naam, ...

Tabel ids
persoonid, id

zou kan je dus perfect uw array opslaan en snel opvragen want uw oplossing gaat echt wel zeer traag zijn.

NeoNeke

Legacy Member
normaal is er idd een betere oplossing, arrays zouden nooit mogen voorkomen in een tabel. Als het voor het gemak ofzo is dat je echt een array moet opslaan dan kan je best ergens werken dat je, je data opslaat onder een bepaald vast formaat en met de explode-functie van php da oplost. Je slaat je data op als id1|id2|id3 zodat je kan exploden op de | maar dit blijft omslachtig, normaal moet je een database structuur kunnen maken (afhankelijk van het probleem, zoals RpR het voorstelt)

RpR

Legacy Member
idd want het gebruiken van zo een explode functie zal goed zijn als die ids geen relaties hebben met andere tabellen. Ook zoeken binnen dat element dat die array bevat gaat enorm traag zijn.

servi

Legacy Member
sla NOOIT maar dan ook NOOIT een array op in een databank. Als je dat wil doet is dat teken dat uw databankontwerp op niets trekt.


Als je echter koppig wil zijn en toch een array in een databank wil stoppen (en heel het idee achter databanken teniet doen )

SQL :
create tabel (
data text
);


PHP :
PHP:
<?php
//invoegen :
$tabel = array('1','2','3');
mysql_query('INSERT INTO tabel SET data="'.serialize($tabel).'" ');

//uithalen :
$query = mysql_query('SELECT data FROM tabel');
while ( $rij = mysql_fetch_array($query) ) {
  $tabel = unserialize($rij['data']);
}
?>

killgore

Legacy Member
servi zei:
sla NOOIT maar dan ook NOOIT een array op in een databank. Als je dat wil doet is dat teken dat uw databankontwerp op niets trekt.


Als je echter koppig wil zijn en toch een array in een databank wil stoppen (en heel het idee achter databanken teniet doen )
'nuff said!

Naast alle arguenten omtrent zoeken, db ontwerp, .. vind ik dit pesoonliijk ook vrij belangerijk: Uw mysql data moet je in mysql zelf kunnen beheren, dus moet je er geen vreemde types van andere talen in steken, zoals hier dus een php array een vreemd type is.

Zelfde waarom je geen objecten in je db steekt: Je maakt een db saver (al dan niet binnen de klasse) die de data binnen je object in een db steekt, niet eentje die je object in de db steekt.

RpR

Legacy Member
killgore zei:
'nuff said!

Naast alle arguenten omtrent zoeken, db ontwerp, .. vind ik dit pesoonliijk ook vrij belangerijk: Uw mysql data moet je in mysql zelf kunnen beheren, dus moet je er geen vreemde types van andere talen in steken, zoals hier dus een php array een vreemd type is.

Zelfde waarom je geen objecten in je db steekt: Je maakt een db saver (al dan niet binnen de klasse) die de data binnen je object in een db steekt, niet eentje die je object in de db steekt.
Zou ik ook niet zeggen.
Je kan perfect objecten in databanken steken!
De naam ontgaat mij nu maar er is een technologie die het mogelijk maakt om objecten op te slaan.

Marbug

Legacy Member
RpR zei:
Ik zou het zo gedaan hebben

stel 2 tabellen
Persoon met items
persoonid, naam, ...

Tabel ids
persoonid, id

zou kan je dus perfect uw array opslaan en snel opvragen want uw oplossing gaat echt wel zeer traag zijn.
Ik had het ook al gedacht om zo te doen, dan zal ik maar meer tabellen gebruiken, en een JOIN functie gebruiken vor de plaatsen waar ik het nodig em? Want ik voerde soms een query uit voor iedere id da'k ophaalde.

servi

Legacy Member
RpR zei:
Zou ik ook niet zeggen.
Je kan perfect objecten in databanken steken!
De naam ontgaat mij nu maar er is een technologie die het mogelijk maakt om objecten op te slaan.

yep dat zijn object-georïenteerde databanken op ( in tegenstelling tot de traditionele relationele databanken )

Maar object-geörienteerde databanken zijn eigenlijk contradictorisch, vermits de bedoeling van een databank is om non-redundant bij te houden. Bij object-geörienteerde omgevingen is dat niet echt een haalbare strategie.

Om even een analogie te trekken die mischien veel zal duidelijk maken : arrays in een databank gebruiken is als divs in plaats van tables gebruiken om tabulaire data weer te geven. Het gaat misschien wel maar er zijn genoeg redenen om dit niet te doen.

dJeez

Legacy Member
RpR zei:
De naam ontgaat mij nu maar er is een technologie die het mogelijk maakt om objecten op te slaan.
Object Relational Mapping ofte ORM wellicht.

En uiteraard sla je objecten op die manier (via een vertaalslag object -> relationeel model) wel op in een DB, ik vermoed dat killgore eerder doelde op het streamen (via serialize vb.) van een PHP object naar vb. een TEXT veld in MySQL.

killgore

Legacy Member
yup, dat was wat ik bedoelde :p., uw object "raw" opslaan zonder dat je er eigenlijk veel mee kan doen.
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan