Archief - Discussie: Foreign keys in web database

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.
[

[Scratch]

Legacy Member
Maakt er hier iemand gebruik van Foreign Keys in een Mysql database die je online gebruikt?

Ik heb me wat verdiept in mysql en die Foreign Key Constraints zijn wel interessant maar ik weet niet of het echt de moeite loont om ze te gebruiken in de database van een CMS. Misschiens is het wel goed voor de consistency van de database maar misschiens ook niet?

Wat denken jullie ervan?
C

Cakeman

Legacy Member
Ik gebruik geen FK of andere constraints in een database voor een website.

Een kerel van bij mij op het werk is een genie in OOP en hij is radicaal tegen contraints. Volgens hem hebt ge daar enkel maar last mee, zelfs al is uw database goed opgebouwd. Bovendien is hij ook enorm tegen databases in het algemeen. "Die technologie is 30 jaar oud en nog steeds niet veranderd. Het is zo achterhaald als iets"

Nu moet ik toegeven dat we in de twee weken die daar nu programmeer (vakantiejob) nog niets dan problemen met foreing keys en andere constraints gehad hebben.
[

[Scratch]

Legacy Member
Databases zijn idd wel een beetje oud maar daarom niet slecht, je zou ook alles kunnen opslaan in XML maar dat is een stuk trager, wat stelt die kerel dan voor om je data in op te slaan?
0

0n3Liner

Legacy Member
Zou zeggen text files, is sneller, zoalng je geen duizenden lijnen verwacht :)
s

servi

Legacy Member
Een kerel van bij mij op het werk is een genie in OOP en hij is radicaal tegen contraints. Volgens hem hebt ge daar enkel maar last mee, zelfs al is uw database goed opgebouwd. Bovendien is hij ook enorm tegen databases in het algemeen. "Die technologie is 30 jaar oud en nog steeds niet veranderd. Het is zo achterhaald als iets"

Dus omdat het oud is is het daarom slecht ? :confused:

databases zijn inderdaad al iets oud maar voor veel data op te slaan waar weinig bewerkingen op moet gedaan worden ken ik toch niet iets beter dan een database.

Assembler is immers ook al heel oud maar om het daarom slecht te noemen vind ik toch wel eigenaardig.

Zou zeggen text files, is sneller, zoalng je geen duizenden lijnen verwacht :)

Als je heel dat tekstbestand nodig hebt kan je dat eventueel doen, als je echter slechts 1 element uit die tekst wilt dan is een gesorteerde database toch handiger in gebruik ( en vermoedelijk ook sneller )
C

Cakeman

Legacy Member
Ik weet ook niet precies hoe hij de vaste opslag regelt, maar hij zegt dat het met de huidige PC's geen enkel probleem meer is om tijdens runtime alle data in het geheugen in te laden in Objecten.

In het project waaraan we nu aan het werken zijn gebruiken we een Firebird database (tegen zijn zin :)) om gegevens definitief op te slaan, maar bij het laden van het programma wordt de benodigde data gewoon rechtstreeks in het RAM geschreven. Eens er iets nodig is of gewijzigd wordt, moet gewoon het RAM aangesproken worden. Dat gaat echt ongelooflijk snel en het is niet dat je met gigabytes aan data zit, dus dat is allemaal perfect mogelijk.

Voor zijn vervanging van databases als definitieve opslag heeft hij voor zijn vorige werkgever een compleet nieuwe technoilogie geschreven (die heet DINO ofzo geloof ik) die alles op een bepaalde manier opslaat en compresseert en sneller is dan databases.

Maar ik zeg het, die kerel is een klein genie.
[

[Scratch]

Legacy Member
I'd like to get to know him then ... where can i buy stock shares??? ;)
s

servi

Legacy Member
ah maar dat die het in cache opslaagt is niet meer als normaal natuurlijk, ge gaat dat enkel niet doen als ge wilt dat het trager verloopt :p

Voor zijn vervanging van databases als definitieve opslag heeft hij voor zijn vorige werkgever een compleet nieuwe technoilogie geschreven (die heet DINO ofzo geloof ik) die alles op een bepaalde manier opslaat en compresseert en sneller is dan databases.

Ik wil nog aannemen dat het sneller zou zijn, maar snel en gecomprimeerd gaat niet samen ( met klassieke compressiemethoden) ;)
C

Cakeman

Legacy Member
servi zei:
]Ik wil nog aannemen dat het sneller zou zijn, maar snel en gecomprimeerd gaat niet samen ;)
Klik om te vergroten...
Van die compressie ben ik niet 100% zeker aangezien ik de helft van zijn uitleg niet begrijp ;)

Ik heb wel een zoekfunctie gezien van hem, die analoog werkt met de zoekfunctie uit zijn DINO technologie. Je typt een lettertje in en nog geen halve seconde later heb je alle matching results uit een immens grote verzameling 'records'.

Ik ben echt zwaar onder de indruk van die kerel.
d

dJeez

Legacy Member
Cakeman zei:
Nu moet ik toegeven dat we in de twee weken die daar nu programmeer (vakantiejob) nog niets dan problemen met foreing keys en andere constraints gehad hebben.
Klik om te vergroten...

Dat kan aan 2 dingen liggen : ofwel zijn de constraints verkeerd ofwel scheelt er iets aan de programmatorische logica. Die constraints dienen net om je database consistent te houden, maw programmatorische fouten krijgen dan de kans niet om de DB te gaan bevuilen. Als ultieme controle zijn ze maw dus zo slecht nog niet...

Cakeman zei:
Ik weet ook niet precies hoe hij de vaste opslag regelt, maar hij zegt dat het met de huidige PC's geen enkel probleem meer is om tijdens runtime alle data in het geheugen in te laden in Objecten.
Klik om te vergroten...
Hij gaat toch wel elke wijziging direct opslaan mag 'k hopen? Anders heb je wel direct prijs bij de eerste stroompanne (en Murphy kennende is dat tijdens 't eerste uur dat je systeem live gaat :p). En alles hangt van de grootte van je datasets af uiteraard. Als je dataset 3 Tb groot is is het onbegonnen werk van die in te gaan lezen hé :p. Op PDAs worden wel dikwijls flat files gebruikt, aangezien de overhead van SQL alles daar nodeloos vertraagt en flat files er bliksemsnel op werken (alles staat dan ook eigenlijk in RAM hé :p).
[

[Scratch]

Legacy Member
dJeez zei:
Die constraints dienen net om je database consistent te houden, maw programmatorische fouten krijgen dan de kans niet om de DB te gaan bevuilen. Als ultieme controle zijn ze maw dus zo slecht nog niet...
Klik om te vergroten...
Ja maar gebruik je ze voor een online database voor een simpel CMS'je met enkel nieuws/links/articles ofzo?
d

dJeez

Legacy Member
[Scratch] zei:
Ja maar gebruik je ze voor een online database voor een simpel CMS'je met enkel nieuws/links/articles ofzo?
Klik om te vergroten...

Daar niet nee, 'k gebruik nl. MyISAM tabellen en die kennen geen foreign key constraints (btw de meeste hosting providers ondersteunen InnoDB niet, vandaar dus).

Maar in het CRM dat 'k momenteel aan 't schrijven ben (nu ja, nu heb 'k een weekje opleiding in OO analyse & design :p) gebruik 'k wel de hele reutemeteut omdat dat intern gebruikt gaat worden (maw op server in eigen beheer), er bedrijfskritische gegevens in staan en consistentie daar echt wel zeer belangrijk is. Ach ja, 'k gebruik er ook Firebird voor :p.

BTW Moest 'k InnoDB (of PostgreSQL/Firebird/SQLite) gebruiken zou 'k het wel doen denk 'k.
B

BertG

Legacy Member
servi zei:
Een kerel van bij mij op het werk is een genie in OOP en hij is radicaal tegen contraints. Volgens hem hebt ge daar enkel maar last mee, zelfs al is uw database goed opgebouwd. Bovendien is hij ook enorm tegen databases in het algemeen. "Die technologie is 30 jaar oud en nog steeds niet veranderd. Het is zo achterhaald als iets"

Dus omdat het oud is is het daarom slecht ? :confused:

databases zijn inderdaad al iets oud maar voor veel data op te slaan waar weinig bewerkingen op moet gedaan worden ken ik toch niet iets beter dan een database.

Assembler is immers ook al heel oud maar om het daarom slecht te noemen vind ik toch wel eigenaardig.
Klik om te vergroten...
:offtopic: Die vergelijking gaat niet op eh :)
"Alles" wordt uiteindelijk wel naar assembler omgezet dus is het eigenlijk de "enige" oplossing (C en varianten zijn slechts een tussenstadium)

daarentegen bestaan er wel al "betere" databases, de zogenoemde Object Databases of Post-relational...

deze databases bestaan niet langer uit tabellen, maar ui (je raad het al) objecten. je kan het zo zien... el record kan op zich zelf weer een tabel zijn of een reeks tabellen, WAT JE MAAR WIL :)
een mooi voorbeeld (doe dit zinnetje maar weg, maar is geen reclame) http://www.intersystems.com/cache/
.
s

servi

Legacy Member
BertG zei:
daarentegen bestaan er wel al "betere" databases, de zogenoemde Object Databases of Post-relational...

deze databases bestaan niet langer uit tabellen, maar ui (je raad het al) objecten. je kan het zo zien... el record kan op zich zelf weer een tabel zijn of een reeks tabellen, WAT JE MAAR WIL :)
een mooi voorbeeld (doe dit zinnetje maar weg, maar is geen reclame) http://www.intersystems.com/cache/
.
Klik om te vergroten...
een objectdatabase is nog steeds een database hé :p

en uiteraard dat c(++) en dergelijke nog "vertaald" worden naar assembler, maar dat is bij databases ook min of meer het geval : uiteindelijk leest die toch maar bestanden in.
k

killgore

Legacy Member
ehm, een database systeem is eigenlijk niet meer dan een geadvanceerd file-reading en saving systeem, bestaat mssch al lang, maar wat ga je anders gebruiken? De user vragen zen info op een papiertje op te schrijven? Data io is nu eenmaal een van de belangerijkste dingen bij het programmeren :s.

edit: oeps, heb precies zowat het grootste deel van de comments gemist :p.
B

BertG

Legacy Member
servi zei:
een objectdatabase is nog steeds een database hé :p
Klik om te vergroten...

wel niet echt :)
stel nu es dat je een profiel van een gebruiker wil halen uit een gewone database en dat in een object steken...

object
Code: 
- name
- adres
 - straat
 - nummer
 - gemeente
 - postcode
- hobbies
- ...
voor dit heb je (als je een deftige DB heb) je al 3 tot 4 tabellen nodig
met verschillende of 1 lange querry met veel inner joins...
en dan moet de omzetting naar oject nog gebeuren...

met object database, roep je gewoon de userid aan, en zit alle info er al klaar in dat object...
s

servi

Legacy Member
awel ja uiteraard zo'n objectdatabase is handiger dan een eenvoudige database, maar het blijft een database hé :)
k

killgore

Legacy Member
@BertG, servi bedoelt dat het een db blijft, een db is gewoon data opslaan, of dat nu objecten zijn of gewone variabelen.

en wat jij daar typt, dat kan ik in 1 tabel hoor.

En desnoods kan je in mysql e.d. OOK een object opslaan van een eigen geïmplenteerde klasse.
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