---

Indledningsvis, dette indlæg bliver en smule langt og komplekst

Jeg har en tabel med konfigurationsdata. Se tabelstruktur nedenfor.
I korte træk:
key->value pairs, linkes på hinanden med config_SNO.

Dette data skal rekursivt bygges op til en hash.

Hashen skal ende med at se sådan ud (pseudo kode):

$config ['modules'] ['allowed_modules'] [0] = 'images';
$config ['modules'] ['allowed_modules'] [1] = 'sounds';

$config ['jewellery'] ['2007_collection'] ['images'] [0] = 'img01.jpg';
$config ['jewellery'] ['2007_collection'] ['images'] [1] = 'img02.jpg';
$config ['jewellery'] ['2007_collection'] ['thumbnails'] [0] = 'img01.jpg';
$config ['jewellery'] ['2007_collection'] ['thumbnails'] [1] = 'img02.jpg';


Pointen er altså at jeg kan modellere fra key->value til key->[masse
key's]->key->value.


Der er således behov for rekursivt at bygge key'eni hashen op og det er der
jeg kommer til kort.

Så vidt jeg kan gennemskue skal subben nogen gange returnere value, andre
gange key, og tilsidst en hash.

Griber jeg det helt forkert an?



CREATE TABLE `config` (
`SNO` int(10) unsigned NOT NULL auto_increment,
`config_SNO` int(10) unsigned default NULL,
`key` varchar(255) NOT NULL,
`value` text,
PRIMARY KEY (`SNO`),
KEY `config_SNO` (`config_SNO`)
) ENGINE=MyISAM AUTO_INCREMENT=11 DEFAULT CHARSET=latin1;



INSERT INTO config (SNO, config_SNO, `key`, value) VALUES
('1',NULL,'modules',NULL);
INSERT INTO config (SNO, config_SNO, `key`, value) VALUES
('2','1','allowed_modules','images');
INSERT INTO config (SNO, config_SNO, `key`, value) VALUES
('3','1','allowed_modules','sounds');
INSERT INTO config (SNO, config_SNO, `key`, value) VALUES
('4',NULL,'jewellery',NULL);
INSERT INTO config (SNO, config_SNO, `key`, value) VALUES
('5','4','2007_collection',NULL);
INSERT INTO config (SNO, config_SNO, `key`, value) VALUES
('6','5','images','img01.jpg');
INSERT INTO config (SNO, config_SNO, `key`, value) VALUES
('7','5','images','img02.jpg');
INSERT INTO config (SNO, config_SNO, `key`, value) VALUES
('8','5','thumbnails','img01.jpg');
INSERT INTO config (SNO, config_SNO, `key`, value) VALUES
('9','5','thumbnails','img02.jpg');



ps
Det er også postet i php gruppen med en lidt anden vinkel, men koncepterne
er de samme

---

"Jens Thomsen" <jt@nej.nej> writes:

> Jeg har en tabel med konfigurationsdata. Se tabelstruktur nedenfor.
> I korte træk:
> key->value pairs, linkes på hinanden med config_SNO.

Har jeg forstået det korrekt at dine data er en træstruktur hvor der
ligger simple dataelementer i bladende, men ikke i knuderne?

> Så vidt jeg kan gennemskue skal subben nogen gange returnere value, andre
> gange key, og tilsidst en hash.

Jeg kan ikke se at du har behov for tre tilfælde hvis der er tale om
en træstruktur. Så har du kun behov for to tilfælde: returner en
hashref (rekursivt trin) eller returner en simpel værdi.

//Makholm

---

"Peter Makholm" <peter@makholm.net> wrote in message
news:87hci72eud.fsf@hacking.dk...
> "Jens Thomsen" <jt@nej.nej> writes:
>
>> Jeg har en tabel med konfigurationsdata. Se tabelstruktur nedenfor.
>> I korte træk:
>> key->value pairs, linkes på hinanden med config_SNO.
>
> Har jeg forstået det korrekt at dine data er en træstruktur hvor der
> ligger simple dataelementer i bladende, men ikke i knuderne?

Ja, knuderne er blot dem der holder sammen på alle bladende.
En knude kan indeholde en anden knude.


>> Så vidt jeg kan gennemskue skal subben nogen gange returnere value, andre
>> gange key, og tilsidst en hash.
>
> Jeg kan ikke se at du har behov for tre tilfælde hvis der er tale om
> en træstruktur. Så har du kun behov for to tilfælde: returner en
> hashref (rekursivt trin) eller returner en simpel værdi.

Ender man så med en hash som man uden videre kan manipulere som normalt?

Jeg er nok i tvivl om opbygningen af hashen kan klares i een sub eller om
der skal en wrapper til?

---

"Jens Thomsen" <jt@nej.nej> writes:

>> Jeg kan ikke se at du har behov for tre tilfælde hvis der er tale om
>> en træstruktur. Så har du kun behov for to tilfælde: returner en
>> hashref (rekursivt trin) eller returner en simpel værdi.
>
> Ender man så med en hash som man uden videre kan manipulere som normalt?

Ja, prøv at læs 'perldoc perlreftut'.

//Makholm

---

2007-12-25 Jens Thomsen wrote
>
> Hashen skal ende med at se sådan ud (pseudo kode):
>
> $config ['modules'] ['allowed_modules'] [0] = 'images';
> $config ['modules'] ['allowed_modules'] [1] = 'sounds';
>
> $config ['jewellery'] ['2007_collection'] ['images'] [0] = 'img01.jpg';
> $config ['jewellery'] ['2007_collection'] ['images'] [1] = 'img02.jpg';
> $config ['jewellery'] ['2007_collection'] ['thumbnails'] [0] = 'img01.jpg';
> $config ['jewellery'] ['2007_collection'] ['thumbnails'] [1] = 'img02.jpg';

Kan der være både grene og blade på samme niveau?

Nu har du skrevet alle nøgler som ['nøgle']. I perl bruger vi normalt []
til arrays og {} til hashes.

Måske du mener {} når du skriver ['']?

Skal parseren selv gætte om der skal bruges array eller hash?

Det ser umiddelbart ud til at den skal vælge array når den finder blade.
Hvad skal den så gøre hvis der også er en grep på det punkt?

> [inddata]
> INSERT INTO config (SNO, config_SNO, `key`, value) VALUES
> ('1',NULL,'modules',NULL);
> INSERT INTO config (SNO, config_SNO, `key`, value) VALUES
> ('2','1','allowed_modules','images');
> INSERT INTO config (SNO, config_SNO, `key`, value) VALUES
> ('3','1','allowed_modules','sounds');
> INSERT INTO config (SNO, config_SNO, `key`, value) VALUES
> ('4',NULL,'jewellery',NULL);
> INSERT INTO config (SNO, config_SNO, `key`, value) VALUES
> ('5','4','2007_collection',NULL);
> INSERT INTO config (SNO, config_SNO, `key`, value) VALUES
> ('6','5','images','img01.jpg');
> INSERT INTO config (SNO, config_SNO, `key`, value) VALUES
> ('7','5','images','img02.jpg');
> INSERT INTO config (SNO, config_SNO, `key`, value) VALUES
> ('8','5','thumbnails','img01.jpg');
> INSERT INTO config (SNO, config_SNO, `key`, value) VALUES
> ('9','5','thumbnails','img02.jpg');


/Morten

---

> Kan der være både grene og blade på samme niveau?

Ja.


Her er et eksempel på en struktur der indeholder det jeg ønsker at
modellere:

Se følgende træstruktur over et galleri:
Det er en hash (gallery1), der har tre hashes på første niveau (settings,
images, active) hvis værdier henholdsvis er en hash, en liste, og en scalar.

gallery1
{
settings
{
thumbnails_width 150
thumbnails_height 200
background_color #000000
path_images /tmp/gallery/gallery1/
}

images
[
IMG_01.jpg
IMG_02.jpg
IMG_03.jpg
]

active 1
}


Kan dette mon modelleres i en database med fire felter (SNO = ID):

SNO
ref_SNO
key
value


Glem det andet vrøvl jeg havde gang i

---

2007-12-26 Jens Thomsen wrote
>> Kan der være både grene og blade på samme niveau?
>
> Ja.

Ah, jeg ser jeg spurgte upræcist...

Kan der være både blade og grene på samme punkt?

Og er f.eks. thumbnails_width et blad, hvad skal der ske hvis der er 2 af dem?

> Her er et eksempel på en struktur der indeholder det jeg ønsker at
> modellere:
>
> Se følgende træstruktur over et galleri:
> Det er en hash (gallery1), der har tre hashes på første niveau (settings,
> images, active) hvis værdier henholdsvis er en hash, en liste, og en scalar.
>
> gallery1
> {
> settings
> {
> thumbnails_width 150
> thumbnails_height 200
> background_color #000000
> path_images /tmp/gallery/gallery1/
> }
>
> images
> [
> IMG_01.jpg
> IMG_02.jpg
> IMG_03.jpg
> ]
>
> active 1
> }
>
>
> Kan dette mon modelleres i en database med fire felter (SNO = ID):
>
> SNO
> ref_SNO
> key
> value


/Morten

---

> Kan der være både blade og grene på samme punkt?
>
> Og er f.eks. thumbnails_width et blad, hvad skal der ske hvis der er 2 af
> dem?

I begge tilfælde er thumbnails_width nøglen.
Hvis der er flere identiske nøgler bliver værdierne til et array.

Inddata:
thumbnails_width 5
thumbnails_width 8


thumbnails_width
[
5
8
]


I begge indgange antages det at der ikke er en config_SNO i nogen af dem.
Hvis der havde været det kunne resultatet blive:

thumbnails_width
[
thumbnails_width
[
9
]
8
]


I virkeligheden kunne man skippe muligheden for at have strenge i bladene
men altid have hashes (hvis der er en config_SNO) eller lister med 0+
indgange.

Det er måske nok en smule komplekst at forklare, men det der ønskes er en
måde at opbevare hashes af hashes og lister i en relationel database

---

Jens Thomsen wrote:
> Det er måske nok en smule komplekst at forklare, men det der ønskes er en
> måde at opbevare hashes af hashes og lister i en relationel database

Hvis du alligevel har tænkt dig at hente al data ud hver gang du skal
bruge det så brug Storable til at smide en kompakt, binær klump ned i en
fil, det er både hurtigere og nemmere.


Hvis du vil lave et rigtigt database design så lav de tabeller med de
felter i du har brug for med foreignkey constraints og alt det andet som
en database giver.

Dit eksempel viser at du har brug for 2 tabeller:

Gallery -----------------< Image
gallery_id gallery_id (fk)
thumbnails_width name
thumbnails_height
background_color
path_images
active

Hvis du har brug for at udvide med et nyt felt er det nemt at sige noget
i stil med: "alter table Gallery add mumble int default 7".

---

"Flemming Frandsen" <ff-remove.the.last.invalid@partyticket.net.invalid>
wrote in message news:kYpdj.10$%Y3.4@news.get2net.dk...
> Jens Thomsen wrote:
>> Det er måske nok en smule komplekst at forklare, men det der ønskes er en
>> måde at opbevare hashes af hashes og lister i en relationel database
>
> Hvis du alligevel har tænkt dig at hente al data ud hver gang du skal
> bruge det så brug Storable til at smide en kompakt, binær klump ned i en
> fil, det er både hurtigere og nemmere.

Smart! Det var nemlig mit næste spørgsmål for at spare performance


> Hvis du vil lave et rigtigt database design så lav de tabeller med de
> felter i du har brug for med foreignkey constraints og alt det andet som
> en database giver.
>
> Dit eksempel viser at du har brug for 2 tabeller:

Ja, det er bare ikke så fleksibelt og skalerbart.
Med en træstruktur som den jeg sigter efter kan jeg modellere både
gallerier, brugerstrukturer, config-filer osv og det er nemlig formålet.
Eksemplet var blot for at gøre det håndterbart

Tak for hjælpen!

---

Jens Thomsen wrote:
> Smart! Det var nemlig mit næste spørgsmål for at spare performance

Hvis du vil have performance så skal du skrive dine sager så de kører i
mod_perl og kun re-loader deres config filer når de har ændret sig.

Hvis du bruger cgi (eller php) har du tabt allerede.


> Ja, det er bare ikke så fleksibelt og skalerbart.

Vrøvl, det skallerer til mange millioner entries og mange klienter (læs
web-frontends) og det er fleksibelt nok til at mange forskellige
klienter i mange forskellige sprog kan manipulere data.


> Med en træstruktur som den jeg sigter efter kan jeg modellere både
> gallerier, brugerstrukturer, config-filer osv og det er nemlig formålet.
> Eksemplet var blot for at gøre det håndterbart

Det lyder som en rigtig dårlig plan med mindre det er et lille
legetøjssystem som ikke rigtigt skal ud til et større publikum.

Hvis det er en one-off demo app, som ikke indeholder vigtige data og
ikke ret meget data så kan du sagtens bruge en stor datastruktur til det
hele.

Hvis du skal have noget der skallerer og kan holde i mange år så skal du
lave et rigtigt database design og smide det i en rigtig database (jeg
kan varmt anbefale postgresql).

---

>> Ja, det er bare ikke så fleksibelt og skalerbart.
>
> Vrøvl, det skallerer til mange millioner entries og mange klienter

Ja, helt enig.
Det var forkert ordvalg.

>og det er fleksibelt nok til at mange forskellige klienter i mange
>forskellige sprog kan manipulere data.

Helt sikkert.

Jeg sigter blot efter en generisk struktur, hvor jeg kan forme en hel masse
forskellige ting i og have samme admin system til at vedligeholde dem.


> Det lyder som en rigtig dårlig plan med mindre det er et lille
> legetøjssystem som ikke rigtigt skal ud til et større publikum.

Jo, det er rigtigt nok.
Jeg giver det nu en chance og så ser vi

---

Jens Thomsen wrote:
> Jeg giver det nu en chance og så ser vi

Well, man kan komme meget langt med Storable og et fornuftigt fil
layout, så held og lykke med det.