🚀 go-pugleaf

Passero:
>Ik heb nogal snel de neiging om een database te gebruiken om data in op te
>slaan. OP school hebben we nogal veel gezien over bestandsbenadering en nog
>niets over DB benadering. Toch gebruik ik het enorm veel omdat ik beter met
>DB's overweg kan dan met bestanden.

Databases, bestanden, wat zijn dat toch voor rare artefacten uit het
computermuseum?

Gebruik liever persistente objecten, dan ben je van een hoop gezeur af.
Kijk toch eens hoe elegant dat kan zijn. Een paar regels code en klaar ben
je.
http://www.zope.org/Wikis/ZODB/guide/
http://www.prevayler.org/wiki.jsp (3.000 x sneller dan MySQL)

-- 
Ren� Pijlman

Wat wil jij leren?  http://www.leren.nl

Passero wrote:

> Ik heb nogal snel de neiging om een database te gebruiken om data in op te
> slaan. OP school hebben we nogal veel gezien over bestandsbenadering en nog
> niets over DB benadering. Toch gebruik ik het enorm veel omdat ik beter met
> DB's overweg kan dan met bestanden.
> Nu vroeg ik me eigenlijk af of er tegenwoordig richtlijnen bestaan van wat
> in een Db moet en wat in een externe file die je zelf maakt? Dingen zoals
> instellingen enzo weet ik dat je beter in een .ini steekt ofzo in plaats van
> een Db maar zijn er zo nog dingen?

"the document is the database.."

groetjes, su.

"Passero" <bla@bla.bla> schreef in bericht
news:_et1c.22284$SL3.1605761@phobos.telenet-ops.be...
> Ik heb nogal snel de neiging om een database te gebruiken om data in op te
> slaan. OP school hebben we nogal veel gezien over bestandsbenadering en
nog
> niets over DB benadering. Toch gebruik ik het enorm veel omdat ik beter
met
> DB's overweg kan dan met bestanden.
> Nu vroeg ik me eigenlijk af of er tegenwoordig richtlijnen bestaan van wat
> in een Db moet en wat in een externe file die je zelf maakt? Dingen zoals
> instellingen enzo weet ik dat je beter in een .ini steekt ofzo in plaats
van
> een Db maar zijn er zo nog dingen?
>
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.600 / Virus Database: 381 - Release Date: 28/02/2004
>

Die keuze maak je als ontwikkelaar/programmeur zelf. Aangenomen dat er geen
sprake is van een opdrachtgever die daar beperkingen aan stelt. De criteria
voor de keuze tussen een db en flat files zijn voornamelijk: portabiliteit,
hoeveelheid data, lees/schrijffrequentie, snelheid en natuurlijk de
validatie. Een dbms (of dat nou relationeel, object georienteerd of wat dan
ook is) zorgt ook voor het echte lees- en schrijfwerk (caching), beveiliging
& autorisatie en is over het algemeen beter te onderhouden.
Als dit antwoord niet voldoet moet je je vraag even wat specifieker maken.

"Suzan Foster" <su@islief.nl> schreef in bericht
news:40467604$0$568$e4fe514c@news.xs4all.nl...
> Passero wrote:
>
> > Ik heb nogal snel de neiging om een database te gebruiken om data in op
te
> > slaan. OP school hebben we nogal veel gezien over bestandsbenadering en
nog
> > niets over DB benadering. Toch gebruik ik het enorm veel omdat ik beter
met
> > DB's overweg kan dan met bestanden.
> > Nu vroeg ik me eigenlijk af of er tegenwoordig richtlijnen bestaan van
wat
> > in een Db moet en wat in een externe file die je zelf maakt? Dingen
zoals
> > instellingen enzo weet ik dat je beter in een .ini steekt ofzo in plaats
van
> > een Db maar zijn er zo nog dingen?
>
> "the document is the database.."
>
> groetjes, su.

Nou, daar kan 'ie vast wel iets mee.

"Rene Pijlman" <reply.in.the.newsgroup@my.address.is.invalid> schreef in
bericht news:o7pc40515um0omqo4hnb2aqc2bb62d8028@4ax.com...
> Passero:
> >Ik heb nogal snel de neiging om een database te gebruiken om data in op
te
> >slaan. OP school hebben we nogal veel gezien over bestandsbenadering en
nog
> >niets over DB benadering. Toch gebruik ik het enorm veel omdat ik beter
met
> >DB's overweg kan dan met bestanden.
>
> Databases, bestanden, wat zijn dat toch voor rare artefacten uit het
> computermuseum?
>
> Gebruik liever persistente objecten, dan ben je van een hoop gezeur af.
> Kijk toch eens hoe elegant dat kan zijn. Een paar regels code en klaar ben
> je.
> http://www.zope.org/Wikis/ZODB/guide/
> http://www.prevayler.org/wiki.jsp (3.000 x sneller dan MySQL)
>
> --
> Ren� Pijlman
>
> Wat wil jij leren?  http://www.leren.nl

Hij vraagt om een vliegenmepper, jij geeft hem een tank.
Overigens: een database is een geordende verzameling data. Ook als daar een
objectgeorienteerde dbms op draait is het nog steeds een database.
Ongetwijfeld wordt deze data ergens opgeslagen. Vermoedelijk ook wel eens op
een harddisk. In een of meerdere bestanden. Het klinkt heel stoer wat je
zegt, maar het zijn nog steeds databases en bestanden.

"Rene Pijlman" <reply.in.the.newsgroup@my.address.is.invalid> wrote in
message news:o7pc40515um0omqo4hnb2aqc2bb62d8028@4ax.com...

> Gebruik liever persistente objecten, dan ben je van een hoop gezeur af.
> Kijk toch eens hoe elegant dat kan zijn. Een paar regels code en klaar ben
> je.

zie ook www.hibernate.org voor een heel mooi open-source product voor
persistence.

Ben

Rene Pijlman <reply.in.the.newsgroup@my.address.is.invalid>:
 > Databases, bestanden, wat zijn dat toch voor rare artefacten uit het
 > computermuseum?
 >
 > Gebruik liever persistente objecten, dan ben je van een hoop gezeur af.
 > Kijk toch eens hoe elegant dat kan zijn. Een paar regels code en klaar
 > ben je.
 > http://www.zope.org/Wikis/ZODB/guide/

"...that the ZODB is a Python-specific object-oriented database..."

Was een database niet een raar artefact uit het computermuseum?

 > http://www.prevayler.org/wiki.jsp (3.000 x sneller dan MySQL)

Persistente objecten en relationele databases zijn niet 1-op-1
inwisselbaar, dus '3.000 x sneller dan MySQL' zegt niet zo heel veel.

-- 
                                                                    robert

"Karel de Andere" <kdan@slimvisje.nl> writes:

...

> Die keuze maak je als ontwikkelaar/programmeur zelf. Aangenomen dat er geen
> sprake is van een opdrachtgever die daar beperkingen aan stelt. De criteria
> voor de keuze tussen een db en flat files zijn voornamelijk: portabiliteit,
> hoeveelheid data, lees/schrijffrequentie, snelheid en natuurlijk de
> validatie.

Op nr 1 staat 'is het wel praktisch'. Soms wil je helemaal niet dat je product
of applicatie afhankelijk is van een externe database. De andere punten die je
noemt zijn daar vrijwel altijd ondergeschikt aan.

 S.

robert:
>Rene Pijlman:
>"...that the ZODB is a Python-specific object-oriented database..."
>
>Was een database niet een raar artefact uit het computermuseum?

Eh ja... beetje een rottige formulering :-)

> > http://www.prevayler.org/wiki.jsp (3.000 x sneller dan MySQL)
>
>Persistente objecten en relationele databases zijn niet 1-op-1
>inwisselbaar, dus '3.000 x sneller dan MySQL' zegt niet zo heel veel.

Da's waar. Maar om de nieuwsgierigheid te prikkelen werkt het wel aardig.

-- 
Ren� Pijlman

Wat wil jij leren?  http://www.leren.nl

Karel de Andere:
>Rene Pijlman:
>> Gebruik liever persistente objecten

>Hij vraagt om een vliegenmepper, jij geeft hem een tank.

Integendeel. Bij goed gebruik van persistente objecten is het zeer elegant
en is er een minimaal aantal regels code nodig in de applicatie om
persistentie te bereiken. Ik zie geen enkele reden om dat een tank te
noemen.

>Overigens: een database is een geordende verzameling data. Ook als daar een
>objectgeorienteerde dbms op draait is het nog steeds een database.
>Ongetwijfeld wordt deze data ergens opgeslagen. Vermoedelijk ook wel eens op
>een harddisk. In een of meerdere bestanden. Het klinkt heel stoer wat je
>zegt, maar het zijn nog steeds databases en bestanden.

Yep, uiteindelijk is alles een rij bits. Het gaat om de keuze van het
optimale abstractieniveau.

Mijn stelling: als je OO-programmeren in de vingers hebt, dan is het model
van persistente objecten in veel gevallen eleganter dan expliciet coderen
van database- of file-I/O, al dan niet met mapping layers.

Mogelijk ligt het anders als je een database gebruikt zoals een database
oorspronkelijk bedoeld is: om de data te queryen. Het zal nog wel even
duren voordat een OO-vraagtaal op een OO-database met persistente objecten
net zo gemeen goed is als de relationele database met SQL nu is.

-- 
Ren� Pijlman

Wat wil jij leren?  http://www.leren.nl

Rene Pijlman <reply.in.the.newsgroup@my.address.is.invalid>:
 > robert:
 >>Persistente objecten en relationele databases zijn niet 1-op-1
 >>inwisselbaar, dus '3.000 x sneller dan MySQL' zegt niet zo heel veel.
 >
 > Da's waar. Maar om de nieuwsgierigheid te prikkelen werkt het wel
 > aardig.

Zeker, voor sommige taken is het prima bruikbaar :)

-- 
                                                                  robert

Toen ik Rene Pijlman kietelde, kwam er dit uit:

> Het zal nog wel even
> duren voordat een OO-vraagtaal op een OO-database met persistente
> objecten net zo gemeen goed is als de relationele database met SQL nu
> is.

Met PostgreSQL gaat dat al best goed.

-- 
Affijn, Ruud

Dr.Ruud ('t.leven.is.fijn@life.i$.great) wrote:
> Toen ik Rene Pijlman kietelde, kwam er dit uit:
> 
>> Het zal nog wel even
>> duren voordat een OO-vraagtaal op een OO-database met persistente
>> objecten net zo gemeen goed is als de relationele database met SQL nu
>> is.
> 
> Met PostgreSQL gaat dat al best goed.

Ik vind van niet. Probleem is dat foreign keys opeens niet meer
werken als je object georienteerd gaat werken in postgres:

CREATE TABLE cities (
     name            text,
     population      float,
     altitude        int     -- (in ft)
 );
 
 CREATE TABLE capitals (
     state           char(2)
 ) INHERITS (cities);

Dat komt gewoon uit de manual van postgres.

Voeg aan de table cities een primaire sleutel toe. Bijvoorbeeld:
IDcity serial PRIMARY KEY

Goed, die sleutel zit dus ook in capitals. Dan nu een table state
maken, met een referentie naar z'n hoofdstad:

CREATE TABLE state (
	IDstate		serial PRIMARY KEY,
	name		varchar(255),
	abbr		char(2),
	IDcity		integer NOT NULL REFERENCES capitals
);

Oeps. Dat werkt dus niet:
ERROR:  PRIMARY KEY for referenced table "capitals" not found

Dat maakt het voor mij onwerkbaar. Of ik moet iets fundementeels
niet snappen.

-- 
Erik Hensema (erik@hensema.net)                             ICQ# 8280101
Tussman's Law:
	Nothing is as inevitable as a mistake whose time has come.

Erik Hensema <usenet@smac.hensema.net>:
 > Ik vind van niet. Probleem is dat foreign keys opeens niet meer werken
 > als je object georienteerd gaat werken in postgres:
 >
 > CREATE TABLE cities (
 >      name            text,
 >      population      float,
 >      altitude        int     -- (in ft)
 >  );
 >
 >  CREATE TABLE capitals (
 >      state           char(2)
 >  ) INHERITS (cities);
 >
 > Dat komt gewoon uit de manual van postgres.
 >
 > Voeg aan de table cities een primaire sleutel toe. Bijvoorbeeld:
 > IDcity serial PRIMARY KEY

Met ALTER TABLE krijg ik die niet toegevoegd:
ERROR:  Adding columns with defaults is not implemented.
        Add the column, then use ALTER TABLE SET DEFAULT.

-- 
                                                                   robert

"Stefan Arentz" <stefan@tiSateh.local> schreef in bericht
news:m27jy1ko89.fsf@tiSateh.local...
> "Karel de Andere" <kdan@slimvisje.nl> writes:
>
> ...
>
> > Die keuze maak je als ontwikkelaar/programmeur zelf. Aangenomen dat er
geen
> > sprake is van een opdrachtgever die daar beperkingen aan stelt. De
criteria
> > voor de keuze tussen een db en flat files zijn voornamelijk:
portabiliteit,
> > hoeveelheid data, lees/schrijffrequentie, snelheid en natuurlijk de
> > validatie.
>
> Op nr 1 staat 'is het wel praktisch'. Soms wil je helemaal niet dat je
product
> of applicatie afhankelijk is van een externe database. De andere punten
die je
> noemt zijn daar vrijwel altijd ondergeschikt aan.
>
>  S.

Inderdaad, ook wel portabiliteit genoemd...

"Karel de Andere" <kdan@slimvisje.nl> writes:

> "Stefan Arentz" <stefan@tiSateh.local> schreef in bericht
> news:m27jy1ko89.fsf@tiSateh.local...
> > "Karel de Andere" <kdan@slimvisje.nl> writes:
> >
> > ...
> >
> > > Die keuze maak je als ontwikkelaar/programmeur zelf. Aangenomen dat er
> geen
> > > sprake is van een opdrachtgever die daar beperkingen aan stelt. De
> criteria
> > > voor de keuze tussen een db en flat files zijn voornamelijk:
> portabiliteit,
> > > hoeveelheid data, lees/schrijffrequentie, snelheid en natuurlijk de
> > > validatie.
> >
> > Op nr 1 staat 'is het wel praktisch'. Soms wil je helemaal niet dat je
> product
> > of applicatie afhankelijk is van een externe database. De andere punten
> die je
> > noemt zijn daar vrijwel altijd ondergeschikt aan.
> >
> >  S.
> 
> Inderdaad, ook wel portabiliteit genoemd...

Dependencies & Portability zijn twee verschillende dingen. Hoewel ze wel
met elkaar te maken hebben.

 S.

robert ({n.c.p}@allyourbass.org.invalid) wrote:
> Erik Hensema <usenet@smac.hensema.net>:
> > Ik vind van niet. Probleem is dat foreign keys opeens niet meer werken
> > als je object georienteerd gaat werken in postgres:
> >
> > CREATE TABLE cities (
> >      name            text,
> >      population      float,
> >      altitude        int     -- (in ft)
> >  );
> >
> >  CREATE TABLE capitals (
> >      state           char(2)
> >  ) INHERITS (cities);
> >
> > Dat komt gewoon uit de manual van postgres.
> >
> > Voeg aan de table cities een primaire sleutel toe. Bijvoorbeeld:
> > IDcity serial PRIMARY KEY
> 
> Met ALTER TABLE krijg ik die niet toegevoegd:
> ERROR:  Adding columns with defaults is not implemented.
>         Add the column, then use ALTER TABLE SET DEFAULT.

Nee, inderdaad, dat is niet echt prettig in postgres :-(

In dit geval kun je beter de tabel droppen en opnieuw maken ;-)

-- 
Erik Hensema (erik@hensema.net)                             ICQ# 8280101
Quoting-HOWTO: http://www.leerquoten.nl

Erik Hensema <usenet@smac.hensema.net>:
 > robert ({n.c.p}@allyourbass.org.invalid) wrote:
 >> Met ALTER TABLE krijg ik die niet toegevoegd:
 >> ERROR:  Adding columns with defaults is not implemented.
 >>         Add the column, then use ALTER TABLE SET DEFAULT.
 >
 > Nee, inderdaad, dat is niet echt prettig in postgres :-( In dit geval
 > kun je beter de tabel droppen en opnieuw maken ;-)

Maar ik kan cities niet droppen zonder eerst capitals te droppen, vanwege
de afhankelijkheid. En als ik daarna de zaak opnieuw aanmaak, met
aangepaste cities tabel, werkt het vast wel :)

-- 
                                                                   robert

Karel de Andere wrote:

> Nou, daar kan 'ie vast wel iets mee.

ask a silly question..

groetjes, su.

robert ({n.c.p}@allyourbass.org.invalid) wrote:
> Erik Hensema <usenet@smac.hensema.net>:
> > robert ({n.c.p}@allyourbass.org.invalid) wrote:
> >> Met ALTER TABLE krijg ik die niet toegevoegd:
> >> ERROR:  Adding columns with defaults is not implemented.
> >>         Add the column, then use ALTER TABLE SET DEFAULT.
> >
> > Nee, inderdaad, dat is niet echt prettig in postgres :-( In dit geval
> > kun je beter de tabel droppen en opnieuw maken ;-)
> 
> Maar ik kan cities niet droppen zonder eerst capitals te droppen, vanwege
> de afhankelijkheid. En als ik daarna de zaak opnieuw aanmaak, met
> aangepaste cities tabel, werkt het vast wel :)

In dat geval:

alter table cities add IDcity integer;
create sequence cities_idcity_seq;
alter table cities alter IDcity set default nextval('cities_idcity_seq');
alter table cities alter IDcity set not null;
alter table cities add primary key (IDcity);

-- 
Erik Hensema (erik@hensema.net)                             ICQ# 8280101
Quoting-HOWTO: http://www.leerquoten.nl

Erik Hensema <usenet@smac.hensema.net>:
 > robert ({n.c.p}@allyourbass.org.invalid) wrote:
 >> Erik Hensema <usenet@smac.hensema.net>:
 >> > robert ({n.c.p}@allyourbass.org.invalid) wrote:
 >> >> Met ALTER TABLE krijg ik die niet toegevoegd:
 >> >> ERROR:  Adding columns with defaults is not implemented.
 >> >>         Add the column, then use ALTER TABLE SET DEFAULT.
 >> >
 >> > Nee, inderdaad, dat is niet echt prettig in postgres :-( In dit geval
 >> > kun je beter de tabel droppen en opnieuw maken ;-)
 >>
 >> Maar ik kan cities niet droppen zonder eerst capitals te droppen,
 >> vanwege de afhankelijkheid. En als ik daarna de zaak opnieuw aanmaak,
 >> met aangepaste cities tabel, werkt het vast wel :)
 >
 > In dat geval:
 >
 > alter table cities add IDcity integer;
 > create sequence cities_idcity_seq;
 > alter table cities alter IDcity set default nextval('cities_idcity_seq');
 > alter table cities alter IDcity set not null;
 > alter table cities add primary key (IDcity);

Daarna bevat capitals bij mij het volgende:

 idcity    | integer | not null default nextval('cities_idcity_seq'::text)

-- 
                                                                      robert

robert ({n.c.p}@allyourbass.org.invalid) wrote:
> Erik Hensema <usenet@smac.hensema.net>:
> > robert ({n.c.p}@allyourbass.org.invalid) wrote:
> >> Erik Hensema <usenet@smac.hensema.net>:
> >> > robert ({n.c.p}@allyourbass.org.invalid) wrote:
> >> >> Met ALTER TABLE krijg ik die niet toegevoegd:
> >> >> ERROR:  Adding columns with defaults is not implemented.
> >> >>         Add the column, then use ALTER TABLE SET DEFAULT.
> >> >
> >> > Nee, inderdaad, dat is niet echt prettig in postgres :-( In dit geval
> >> > kun je beter de tabel droppen en opnieuw maken ;-)
> >>
> >> Maar ik kan cities niet droppen zonder eerst capitals te droppen,
> >> vanwege de afhankelijkheid. En als ik daarna de zaak opnieuw aanmaak,
> >> met aangepaste cities tabel, werkt het vast wel :)
> >
> > In dat geval:
> >
> > alter table cities add IDcity integer;
> > create sequence cities_idcity_seq;
> > alter table cities alter IDcity set default nextval('cities_idcity_seq');
> > alter table cities alter IDcity set not null;
> > alter table cities add primary key (IDcity);
> 
> Daarna bevat capitals bij mij het volgende:
> 
>  idcity    | integer | not null default nextval('cities_idcity_seq'::text)

Dat klopt, en ook nog:

Indexes: cities_pkey primary key btree (idcity)

Probleem is dat die primary key niet in de child tables zit en je
er dus ook geen foreign keys naartoe kunt laten verwijzen.
-- 
Erik Hensema (erik@hensema.net)                             ICQ# 8280101
[Prime Minister Joseph] Chamberlain loves the working man -- he loves
to see him work.
		-- Winston Churchill

"Suzan Foster" <su@islief.nl> schreef in bericht
news:404719cf$0$570$e4fe514c@news.xs4all.nl...
> Karel de Andere wrote:
>
> > Nou, daar kan 'ie vast wel iets mee.
>
> ask a silly question..
>
> groetjes, su.

Veel mensen zeggen dat domme vragen niet bestaan. Over het algemeen kan ik
me daar wel in vinden. Sommige vragen worden misschien wat onhandig gesteld,
maar als je echt wilt helpen probeer je het toch te begrijpen.
Domme vragen bestaan niet, arrogante antwoorden wel.

Karel de Andere:
>Veel mensen zeggen dat domme vragen niet bestaan. Over het algemeen kan ik
>me daar wel in vinden. 

Hoezo? Nieuwsgroepen staan vol met domme vragen.

-- 
Ren� Pijlman

Wat wil jij leren?  http://www.leren.nl

Erik Hensema <usenet@smac.hensema.net>:
 > robert ({n.c.p}@allyourbass.org.invalid) wrote:
 >>
 >> Daarna bevat capitals bij mij het volgende:
 >>
 >>  idcity    | integer | not null default nextval('cities_idcity_seq'::text)
 >
 > Dat klopt, en ook nog:
 >
 > Indexes: cities_pkey primary key btree (idcity)

Die zit er bij mij niet tussen (ik heb het over 'capitals', niet 'cities').

 > Probleem is dat die primary key niet in de child tables zit en je er dus
 > ook geen foreign keys naartoe kunt laten verwijzen.

Het vreemde is dat als ik idcity voor cities een primary key maak, dat
capitals w�l een 'serial' genaamd idcity krijgt, alleen voor capitals is
het niet automatisch een primary key.

Als ik achteraf idcity een primary maak, kan ik daarna gewoon die state
tabel aanmaken.

Kortom:
- CREATE TABLE voor 'oude' cities
- CREATE TABLE voor capitals
- ALTER TABLE voor cities; toevoegen 'idcity' en die primary key voor
  cities maken
- ALTER TABLE voor capitals; 'idcity' primary key maken (ik hoef 'em niet
  expliciet toe te voegen aan capitals)
- CREATE TABLE state

Dat werkt bij mij.

-- 
                                                                        robert

robert ({n.c.p}@allyourbass.org.invalid) wrote:
> Erik Hensema <usenet@smac.hensema.net>:
> > robert ({n.c.p}@allyourbass.org.invalid) wrote:
> >>
> >> Daarna bevat capitals bij mij het volgende:
> >>
> >>  idcity    | integer | not null default nextval('cities_idcity_seq'::text)
> >
> > Dat klopt, en ook nog:
> >
> > Indexes: cities_pkey primary key btree (idcity)
> 
> Die zit er bij mij niet tussen (ik heb het over 'capitals', niet 'cities').
> 
> > Probleem is dat die primary key niet in de child tables zit en je er dus
> > ook geen foreign keys naartoe kunt laten verwijzen.
> 
> Het vreemde is dat als ik idcity voor cities een primary key maak, dat
> capitals w�l een 'serial' genaamd idcity krijgt, alleen voor capitals is
> het niet automatisch een primary key.
> 
> Als ik achteraf idcity een primary maak, kan ik daarna gewoon die state
> tabel aanmaken.
> 
> Kortom:
> - CREATE TABLE voor 'oude' cities
> - CREATE TABLE voor capitals
> - ALTER TABLE voor cities; toevoegen 'idcity' en die primary key voor
>   cities maken
> - ALTER TABLE voor capitals; 'idcity' primary key maken (ik hoef 'em niet
>   expliciet toe te voegen aan capitals)
> - CREATE TABLE state
> 
> Dat werkt bij mij.

Slimme! Volgende keer dat ik een database ontwerp zal ik kijken
of ik hier wat mee kan. Voor m'n huidige project heb ik al een
andere oplossing gevonden :-)

-- 
Erik Hensema (erik@hensema.net)                             ICQ# 8280101
Quoting-HOWTO: http://www.leerquoten.nl

Erik Hensema <usenet@smac.hensema.net>:
 > robert ({n.c.p}@allyourbass.org.invalid) wrote:
 >>
 >> Kortom:
 >> - CREATE TABLE voor 'oude' cities
 >> - CREATE TABLE voor capitals
 >> - ALTER TABLE voor cities; toevoegen 'idcity' en die primary key voor
 >>   cities maken
 >> - ALTER TABLE voor capitals; 'idcity' primary key maken (ik hoef 'em niet
 >>   expliciet toe te voegen aan capitals)
 >> - CREATE TABLE state
 >>
 >> Dat werkt bij mij.
 >
 > Slimme! Volgende keer dat ik een database ontwerp zal ik kijken of
 > ik hier wat mee kan.

De volgende keer zorg je er natuurlijk voor dat je databaseontwerp niet
achteraf nog aangepast moet worden ;)

-- 
                                                                       robert

Toen ik robert kietelde, kwam er dit uit:
> Erik Hensema:
>> robert:

>>> Kortom:
>>> - CREATE TABLE voor 'oude' cities
>>> - CREATE TABLE voor capitals
>>> - ALTER TABLE voor cities; toevoegen 'idcity' en die primary key
>>> voor cities maken
>>> - ALTER TABLE voor capitals; 'idcity' primary key maken (ik hoef
>>>  'em niet >>   expliciet toe te voegen aan capitals)
>>> - CREATE TABLE state
>>>
>>> Dat werkt bij mij.

>> Slimme! Volgende keer dat ik een database ontwerp zal ik kijken of
>> ik hier wat mee kan.

> De volgende keer zorg je er natuurlijk voor dat je databaseontwerp niet
> achteraf nog aangepast moet worden ;)

En beiden bedankt voor het mogen meelezen.

-- 
Affijn, Ruud

robert ({n.c.p}@allyourbass.org.invalid) wrote:
> Erik Hensema <usenet@smac.hensema.net>:
> > robert ({n.c.p}@allyourbass.org.invalid) wrote:
> >>
> >> Kortom:
> >> - CREATE TABLE voor 'oude' cities
> >> - CREATE TABLE voor capitals
> >> - ALTER TABLE voor cities; toevoegen 'idcity' en die primary key voor
> >>   cities maken
> >> - ALTER TABLE voor capitals; 'idcity' primary key maken (ik hoef 'em niet
> >>   expliciet toe te voegen aan capitals)
> >> - CREATE TABLE state
> >>
> >> Dat werkt bij mij.
> >
> > Slimme! Volgende keer dat ik een database ontwerp zal ik kijken of
> > ik hier wat mee kan.
> 
> De volgende keer zorg je er natuurlijk voor dat je databaseontwerp niet
> achteraf nog aangepast moet worden ;)

Nah, ik heb een tabel die een vhost voorstelt (van een webhoster).
Die tabel heeft 1-op-1 relaties met een tabel voor apache
vhosting, dns hosting en url forwarding hosting.
Veel andere tabellen, zoals de tabel waarin domeinnamen staan,
verwijzen naar de vhost tabel. Anderen, zoals een tabel waarin
database namen staan, verwijzen naar een specifieke tabel (in dit
geval de apache tabel).

Met overerving zou je gewoon select * from apache; kunnen doen en
dan ook de rest van de vhost gegevens krijgen. Nu doe ik dat
gewoon met een join.
Bij het inserten van data is dat wat lastiger, maar dat doe ik
gewoon binnen een transactie, is er nog niks aan de hand.

Kortom: ik heb gewoon een 'klassieke' oplossing gekozen, terwijl
nu achteraf een object georienteerde misschien ook had gekund.

-- 
Erik Hensema (erik@hensema.net)                             ICQ# 8280101
Quoting-HOWTO: http://www.leerquoten.nl

Erik Hensema <usenet@smac.hensema.net>:
 > Met overerving zou je gewoon select * from apache; kunnen doen en dan
 > ook de rest van de vhost gegevens krijgen. Nu doe ik dat gewoon met een
 > join.  Bij het inserten van data is dat wat lastiger, maar dat doe ik
 > gewoon binnen een transactie, is er nog niks aan de hand.
 >
 > Kortom: ik heb gewoon een 'klassieke' oplossing gekozen, terwijl nu
 > achteraf een object georienteerde misschien ook had gekund.

Ik weet uberhaupt niet of die OO-extensie van Postgres wel SQL-conform is.
Als je ooit de zaak wilt migreren naar iets anders kan je bij het gebruiken
van die OO-dingen in de problemen komen.

-- 
                                                                     robert

Erik Hensema wrote:
[Over ProgreSQL]
> alter table cities alter IDcity set default nextval('cities_idcity_seq');

Hoe vaak ik al niet gewenst heb dat dit in Oracle mogelijk zou zijn...
Op zich al reden genoeg om ProgreSQL eens te bekijken.

Dank voor de tip!

Sjoerd

De bedoeling van mijn vraag gaat hier dus helemaal de mist in grrr.
IK vroeg NIET wat ik kan gebruiken in plaats van een DB of file maar ik
vroeg wel wanneer je nu het best een db gebruikt of een file. De rest
intresseert mij niet. Wij zien op dit moment op school db en filemanagement
en niet persistente objecten of what ever dus op dit moment heb ik die ook
niet nodig. Volgend jaar gaan we ons daar meer op toeleggen en dan zal ik
mss mijn vraag aanpassen maar dat is hier nu niet het geval.


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.600 / Virus Database: 381 - Release Date: 28/02/2004

Passero:
>De bedoeling van mijn vraag gaat hier dus helemaal de mist in grrr.
>IK vroeg NIET wat ik kan gebruiken in plaats van een DB of file maar ik
>vroeg wel wanneer je nu het best een db gebruikt of een file. De rest
>intresseert mij niet.

Je bent niet alleen in de nieuwsgroep. En wij zijn jouw knechtjes niet.
Het zijn juist die andere dingen die ONS WEL interesseren. Probeer het
anders eens in news:huiswerk.kant-en-klaar

Msar goed, ik zal je helpen. In de virtuele machine is een database een
hoger-niveau concept dan een file. De basisregels zijn dus:
- Alles wat met een database kan, kan ook met een file.
- Als een file voldoende is, dan heb je geen database nodig.

-- 
Ren� Pijlman

Wat wil jij leren?  http://www.leren.nl

Rene Pijlman wrote:
> 
> Passero:
> >De bedoeling van mijn vraag gaat hier dus helemaal de mist in grrr.
> >IK vroeg NIET wat ik kan gebruiken in plaats van een DB of file maar ik
> >vroeg wel wanneer je nu het best een db gebruikt of een file. De rest
> >intresseert mij niet.
> 
> Je bent niet alleen in de nieuwsgroep. En wij zijn jouw knechtjes niet.
> Het zijn juist die andere dingen die ONS WEL interesseren. Probeer het
> anders eens in news:huiswerk.kant-en-klaar

Helemaal mee eens. Ik vond het een interessante discussie.

> Msar goed, ik zal je helpen. In de virtuele machine is een database een
> hoger-niveau concept dan een file. De basisregels zijn dus:
> - Alles wat met een database kan, kan ook met een file.
> - Als een file voldoende is, dan heb je geen database nodig.

Mee eens. Een DB is een hoger nivo dat een file.

Maar pas op! Als je besluit dat een database "overkill" is en een file
gebruikt, dan bestaat er in de praktijk een sterke neiging om steeds
meer te willen kunnen voor nieuwe versies. Het begint met simpele updates.
Later wordt de file groter en moeten er indices komen. Ondertussen heb je
al een aantal bugs moeten oplossen. Weer later is de file zo groot dat een
enkele delete niet tot het compleet wegschrijven van een file moet leiden
en er dus maar een "delete marker" overheen wordt geschreven. Dan komt op
den duur natuurlijk ook een "compact" operatie in beeld. En tegen die tijd
heb je al een volledige DB3 systeem geschreven, en heb je veel tijd en dus
geld zitten in iets dat je ook zo kant en klaar in de vorm van een database
had kunnen installeren.

Vanwege de ingebouwde neiging om steeds complexer te worden, zullen
diverse mensen hier adviseren om gelijk maar een DB te nemen. Dat
lijkt misschien voor versie 1.0 overkill, maar bij versie 3.0 ben
je blij dat je het gedaan hebt.

Als je zeker weet dat het bij een versie 1.0 blijft, bijvoorbeeld
omdat het een opdracht voor school is, dan is een file zeker een optie.

Maar in het bedrijfsleven hoop je dat het niet bij versie 1.0 blijft
want voor versie 1.1, 1.2, 2.0, 2.1 en 3.0 krijg je steeds opnieuw geld.
En dus wordt die database gelijk maar geinstalleerd. Het kost maar
een beetje extra moeite maar kan een boel frustratie in de toekomst voorkomen.

Sjoerd Schreuder

Sjoerd A. Schreuder <sa_schreuder@wanadoo.nl>:
 > Vanwege de ingebouwde neiging om steeds complexer te worden, zullen
 > diverse mensen hier adviseren om gelijk maar een DB te nemen. Dat lijkt
 > misschien voor versie 1.0 overkill, maar bij versie 3.0 ben je blij dat
 > je het gedaan hebt.

Mooie tussenstap is SQLite, een embedded SQL database. Ondanks een beperkte
footprint is de ondersteunde SQL-subset prima te noemen, evenals de
snelheid.

-- 
                                                                     robert

"Passero" <bla@bla.bla> schreef in bericht
news:mfJ1c.22820$DN3.1715301@phobos.telenet-ops.be...
| De bedoeling van mijn vraag gaat hier dus helemaal de mist in grrr.
| IK vroeg NIET wat ik kan gebruiken in plaats van een DB of file maar ik
| vroeg wel wanneer je nu het best een db gebruikt of een file. De rest
| intresseert mij niet. Wij zien op dit moment op school db en filemanagement
| en niet persistente objecten of what ever dus op dit moment heb ik die ook
| niet nodig. Volgend jaar gaan we ons daar meer op toeleggen en dan zal ik
| mss mijn vraag aanpassen maar dat is hier nu niet het geval.

Ik dacht ook al dat ze hier behoorlijk uit de bol aan het gaan zijn. Enfin. Op
de keper beschouwd is een database natuurlijk ook een file, maar we gaan niet
zeuren. Je bedoelt waarschijnlijk simpel bestand tegenover databestand.
Persoonlijk zal ik gewone bestanden gebruiken voor alles wat ten eerste simpel
is. Dus genre dingen die gebruikelijk in een INI-file terechtkomen. Simpel
betekent niet te veel gegevens en ook niet te veel soorten gegevens. Met een
"comma-delimited" (of ander scheidingsteken) bestand kun je wel een reeksje van
5-6 gegevens achter elkaar plakken, maar meer wordt al snel onoverzichtelijk.
Tweede voorwaarde is dat ik al die gegevens in ��n keer wil inlezen, in een
array-struktuur of iets dergelijks. Sorteren is dan nog altijd mogelijk op de
gegevens in het geheugen. Een derde indicatie om een gewoon bestand te gebruiken
is als je de mogelijkheid wil hebben om snel gegevens aan te passen, buiten het
programma om. Eventjes een gewone editor starten en je basisgegevens zijn zo
aangepast. Wanneer wordt het zeker een database-struktuur. Wanneer je het warm
water niet opnieuw wil uitvinden. Met andere woorden : als het nodig is om
verschillende gegevens uit verschillende tabellen aan elkaar te linken op een
bestuurbare manier. Als je snel door een grote hoeveelheid gegevens moet werken,
...

Alex

"Rene Pijlman" <reply.in.the.newsgroup@my.address.is.invalid> schreef in
bericht news:v9oe40ddv6nnl4kdhs3bvb7s0b21g7416o@4ax.com...

>
> Je bent niet alleen in de nieuwsgroep. En wij zijn jouw knechtjes niet.
> Het zijn juist die andere dingen die ONS WEL interesseren. Probeer het
> anders eens in news:huiswerk.kant-en-klaar
>

Grapjas, als je echt denkt dat ze in het hoger onderwijs afkomen met zo
"huiswerk"? Zoek eens op wat in een Db past en wat in een gewone file pfff.
We hebben wel andere projecten aan ons been hoor.
Voor zover ik weet stelt iemand een vraag op de NG en proberen de mensen dan
een zo goed mogelijk PASSEND antwoord te geven en niet uit te wijden over
dingen die er onrechtstreeks mee te maken hebben.
Als iemand aan mij vraagt hoe je in java objecten toevoegd aan een vector ga
ik niet zeggen dat hij beter een arrayList moet gebruiken omdat die
performanter is en nieuwer maar ik zou dan gewoon zeggen hoe het moet.
Waarom zo moeilijk doen om gewoon een antwoord te proberen krijgen op iets
wat ik me afvroeg. Waarom moet je denken dat zo iets als huiswerk moet
gebeuren? Mag een leerling geen dingen meer afvragen zonder dat anderen
denken dat het huiswerk is? Of is dat tegenwoordig verboden?

> Msar goed, ik zal je helpen. In de virtuele machine is een database een
> hoger-niveau concept dan een file. De basisregels zijn dus:
> - Alles wat met een database kan, kan ook met een file.
> - Als een file voldoende is, dan heb je geen database nodig.
>
> --
> Ren� Pijlman
>
> Wat wil jij leren?  http://www.leren.nl


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.600 / Virus Database: 381 - Release Date: 28/02/2004

"Sjoerd A. Schreuder" <sa_schreuder@wanadoo.nl> wrote in message
news:40474818.6EFC2982@wanadoo.nl...
> Erik Hensema wrote:
> [Over ProgreSQL]
> > alter table cities alter IDcity set default
nextval('cities_idcity_seq');
>
> Hoe vaak ik al niet gewenst heb dat dit in Oracle mogelijk zou zijn...

Dat is toch met 1 klein triggertje gepiept?
Kleine moeite, lijkt me.

Theo

"Passero" <bla@bla.bla> wrote in message
news:NqK1c.23078$LM3.1660980@phobos.telenet-ops.be...
>
> Voor zover ik weet stelt iemand een vraag op de NG en proberen de mensen
dan
> een zo goed mogelijk PASSEND antwoord te geven en niet uit te wijden over
> dingen die er onrechtstreeks mee te maken hebben.

Jij draait zeker nog niet zo lang mee op Usenet? :-)

Theo

Rene Pijlman <reply.in.the.newsgroup@my.address.is.invalid> schreef:

> Msar goed, ik zal je helpen. In de virtuele machine is een database een
> hoger-niveau concept dan een file. De basisregels zijn dus:
> - Alles wat met een database kan, kan ook met een file.
> - Als een file voldoende is, dan heb je geen database nodig.

Een file wordt meestal opgeslagen in een filesystem.
En een filesystem is een (hi�rarchische) database...   ;-)

-- 
JanC

"Be strict when sending and tolerant when receiving."
RFC 1958 - Architectural Principles of the Internet - section 3.9

"Passero" <bla@bla.bla> schreef:

> Ik heb nogal snel de neiging om een database te gebruiken om data in
> op te slaan. OP school hebben we nogal veel gezien over
> bestandsbenadering en nog niets over DB benadering. Toch gebruik ik
> het enorm veel omdat ik beter met DB's overweg kan dan met bestanden.
> Nu vroeg ik me eigenlijk af of er tegenwoordig richtlijnen bestaan van
> wat in een Db moet en wat in een externe file die je zelf maakt?
> Dingen zoals instellingen enzo weet ik dat je beter in een .ini steekt
> ofzo in plaats van een Db maar zijn er zo nog dingen?

De beste richtlijn is gezond verstand, aangevuld met & gebaseerd op 
ervaring.

Trouwens, als je Microsoft's regels voor Windows-applicaties volgt, moet je 
je instellingen in een database opslaan (de registry).

-- 
JanC

"Be strict when sending and tolerant when receiving."
RFC 1958 - Architectural Principles of the Internet - section 3.9

"JanC" <usenet_spam@janc.invalid> schreef in bericht
news:Xns94A3EBE4F4907JanC@213.119.4.35...

- knip -
> Een file wordt meestal opgeslagen in een filesystem.
> En een filesystem is een (hi�rarchische) database...   ;-)

Briljant! :-)

"JanC" <usenet_spam@janc.invalid> schreef in bericht
news:Xns94A3EE52533D1JanC@213.119.4.35...
-knip-
> De beste richtlijn is gezond verstand, aangevuld met & gebaseerd op
> ervaring.
>
> Trouwens, als je Microsoft's regels voor Windows-applicaties volgt, moet
je
> je instellingen in een database opslaan (de registry).

Da's tegenstrijdig!

Theo wrote:
> "Sjoerd A. Schreuder" <sa_schreuder@wanadoo.nl> wrote in message
> news:4047cc7d$0$2414$4a441750@news.euronet.nl...
> 
>>>>[Over ProgreSQL]
>>>>
>>>>>alter table cities alter IDcity set default
> 
> nextval('cities_idcity_seq');
> 
>>>>Hoe vaak ik al niet gewenst heb dat dit in Oracle mogelijk zou zijn...
>>>
>>>Dat is toch met 1 klein triggertje gepiept?
>>>Kleine moeite, lijkt me.
>>
>>Dacht ik ook. Totdat bleek dat je vanuit een 'before insert' trigger
>>geen nextval op sequences mag aanroepen. :-(
> 
> Nou, dan weet ik niet welke Oracle versie je gebruikt, maar volgens mij
> heeft dat altijd gemogen. In ieder geval vanaf 7.3.

Wij werken met 8i, maar nog liever 9i, dus dat zou dan ook moeten kunnen.
Ik zal het maandag nog eens proberen. Bedankt voor het voorbeeld.

Sjoerd

"JanC" <usenet_spam@janc.invalid> schreef in bericht
news:Xns94A3EE52533D1JanC@213.119.4.35...
| "Passero" <bla@bla.bla> schreef:

<snip>

| Trouwens, als je Microsoft's regels voor Windows-applicaties volgt, moet je
| je instellingen in een database opslaan (de registry).
|
| --
| JanC

En door het feit dat iedereen dat doet wordt de registry in de kortste keren ��n
grote troep. Ik weet het niet zeker, maar ik denk niet dat de aanwijzingen van
Micro$oft steeds de beste zijn voor computer-gezondheid en -hygi�ne.

Alex

AHA:
>JanC:
>| Trouwens, als je Microsoft's regels voor Windows-applicaties volgt, moet je
>| je instellingen in een database opslaan (de registry).

>En door het feit dat iedereen dat doet wordt de registry in de kortste keren ��n
>grote troep. 

Hoezo? Er staan gewoon allerlei instellingen in. Niks troep. Het is niet
anders dan de .ini etc. files in het bestandssysteem.

-- 
Ren� Pijlman

Wat wil jij leren?  http://www.leren.nl

"Rene Pijlman" <reply.in.the.newsgroup@my.address.is.invalid> schreef in bericht
news:lbmj40l1j7banj5g8euukbr37ekbcm92iu@4ax.com...
| AHA:
| >JanC:
| >| Trouwens, als je Microsoft's regels voor Windows-applicaties volgt, moet je
| >| je instellingen in een database opslaan (de registry).
|
| >En door het feit dat iedereen dat doet wordt de registry in de kortste keren
��n
| >grote troep.
|
| Hoezo? Er staan gewoon allerlei instellingen in. Niks troep. Het is niet
| anders dan de .ini etc. files in het bestandssysteem.
|
| --
| Ren� Pijlman

In een "gezond" register niet, nee. Maar als je een pjoeter hebt die al een
aantal jaren meedraait, waarop wat software ge�nstalleerd wordt en (niet
noodzakelijk op de ge�igende manier) verwijderd wordt, waarop wat trial-versies
gedraaid worden, waarop wat malware zijn weg vindt, ... dan wordt het
uiteindelijk wel een beetje een troep.

Alex

Passero wrote:

> De bedoeling van mijn vraag gaat hier dus helemaal de mist in

Welcome to USENET.

> grrr.

*iiih*

-- 
Nicolas Barbier
Protecting innovation against patent inflation <url:http://swpat.ffii.org/>

AHA:
>Rene Pijlman:
>| Niks troep. Het is niet anders dan de .ini etc. files in het bestandssysteem.

>In een "gezond" register niet, nee. Maar als je een pjoeter hebt die al een
>aantal jaren meedraait,[...] dan wordt het uiteindelijk wel een beetje een troep.

Ach ik hoor dat wel vaker, maar ik kijk nooit in het register, dan is het
geen probleem :-)

-- 
Ren� Pijlman

Wat wil jij leren?  http://www.leren.nl

Rene Pijlman <reply.in.the.newsgroup@my.address.is.invalid> schreef:

>>En door het feit dat iedereen dat doet wordt de registry in de kortste
>>keren ��n grote troep. 
> 
> Hoezo? Er staan gewoon allerlei instellingen in. Niks troep. Het is
> niet anders dan de .ini etc. files in het bestandssysteem.

Een probleem met de registry is dat je het niet of moeilijk kan 
defragmenteren en dat het inlezen ervan daardoor erg traag kan worden als 
die een tijdje meegaat...

-- 
JanC

"Be strict when sending and tolerant when receiving."
RFC 1958 - Architectural Principles of the Internet - section 3.9