MySQL, hoe krijg ik deze dingen voor elkaar?

[kmf]

Ik ben net nieuw met MySQL, normaal gesproken werk ik op school met INGRES.

Nou moet ik een database ontwerpen op MySQL voor m'n stage, maar nou blijkt dat een hoop functies die in INGRES vanzelfsprekend zijn, (nog) niet geimplementeerd zijn in MySQL.
Is er dan nog mogelijk om een serieus goede EERD om te implementeren in MySQL?

Wat me vooral flink veel zorgen over maakt: foreign keys.

MySQL ondersteunt deze nog niet zo te zien, hoe kan ik dan nog de referentiele integriteit van de database waarborgen (ik kan dus gewoon een klant weghalen, terwijl hij wel een schuld heeft lopen)

En qua performance: met welke oplossing voor mysql kan ik eventueel fragments gaan creeeren?

(moet ik sowieso wel MySQL beschouwen als serieuze vervanger voor Ingres of Oracle? Ondersteunt Access wel deze dingen?)

[mulder]

Euhm, ik ben geen guru, en ik snap heel veel niet, maar ik snap wel dat niemand een duidelijk antwoord op je vraag kan geveb: dit is een totaal wazig verhaal. Leg eens uit wat je wil van je db.

[chem]

neem dan postgresql ipv mysql, als je dergelijke tools wilt gebruiken.

[80000]

Misschien niet een antwoord op je vraag (weet niks
over mysql en ingress, maar wel oracle),
maar het is misschien handig om op je stage hun te
overtuigen dat de dingen die ze willen niet kan met Mysql
als jij denkt dat het niet kan. Overtuig ze dat een
andere db, zoals Oracle nodig hebben.
Het voordeel is dat dit ook leuk op je CV staat voor later.

Toendertijd dat ik met access werkte, ondersteunde
dit geen "concurrent transactions", dat is toch
wel het minste wat je van een database moet verwachten.

[kmf]

Op zondag 13 januari 2002 05:20 schreef El_Mundo het volgende:
Euhm, ik ben geen guru, en ik snap heel veel niet, maar ik snap wel dat niemand een duidelijk antwoord op je vraag kan geveb: dit is een totaal wazig verhaal. Leg eens uit wat je wil van je db.

Tja, kijk, bij database-ontwikkeling moet je meestal ervoor zorgen dat alle data binnen een database correct blijft.
Een belangrijk deel daarvan komt bij het ontwerp kijken.

Stel, een winkel heeft 2 tabellen:
Een tabel klant en een tabel schuld.
de tabel klant ziet er als volgt uit klantnummr, naam
de tabel schuld -> schuldnummer, klantnummer, bedrag
Primary keys zijn dus de bold-gedrukte dingen.

Nou is het zo dat klantnummer in schuld refereert aan klantnummer in klant. Zo kan je dus weten dat die schuld bij die klant hoort.

Stel dat een klant nou komt en zegt: "ik wil geen klant meer zijn, haal me uit je klantenbestand!"

Maar hij heeft nog wel een schuld lopen! Je wilt natuurlijk niet dat zijn gegevens weg worden gehaald, want dan kan je niet meer achterhalen bij die schuld hoort!

Onder ingris of oracle kan je dan zeggen dat klantnummer in schuld een zogenaamde foreign key is. En dan gaat de DBMS bij een delete-statement eerst even de tabellen langs om te kijken of er geen andere tabellen zijn die daar van afhankelijk zijn.

In dit geval, als een klant komt om z'n gegevens weg te laten halen, dan gaat de DBMS even de tabel schuld checken of de klant geen schuld heeft lopen. is dit niet het geval dan kan de gegevens weggehaald worden.
Maar als hij dus schuld heeft, dan wordt er keihard gezegd "je hebt nog een schuld lopen, betaal dat maar eerst en dan praten we wel verder".


Deze beveiliging zie ik dus niet zitten in MySQL (of je moet een speciale tabeltype Innodb gebruiken maar dan zit je weer vast aan dat type, dus ik vraag me af of er nog andere mogelijkheden zijn om dit te doen.


PS> als dit ook niet met access kan, dan hebben we geen probleem, want er wordt nu namelijk met access gewerkt

PPS> ik ben juist verplicht te kiezen voor een "gratis" dbms, dus....
Ik zou ook graag Oracle of Ingres willen gebruiken, dan kan ik tenminste ook nog performance dingen zoals fragmentatie en zo gebruiken, maar ja, die DBMSsen kosten weer flink veel geld denk ik en dat mag dus niet in een budgetstageopdracht

[kmf]

Op zondag 13 januari 2002 09:33 schreef chem het volgende:
neem dan postgresql ipv mysql, als je dergelijke tools wilt gebruiken.

Thanks. ik zou er even naar kijken.

Maar postgres is toch heel wat trager dan mysql?

(misschien komt het omdat ze die dingen ondersteunt )

Ik hoop dat MySql snel klaar is met versie 4, want die ondersteunt foreign keys wel zeiden ze.

[Zwelgje]

dan gebruik je toch voor de time being de alpha versie? dan kun je er gelijk mee leren werken,

[MikeN]

Sorry hoor, maar foreign keys zijn vooral handig voor programmeurs die te lui zijn hun tabellen zelf te checken. Als jij nou gewoon eerst in je programma een check uit zou voeren of de klant niet nog schulden heeft, kun je net zo goed MySQL gebruiken.

[kmf]

Op zondag 13 januari 2002 12:58 schreef MikeN het volgende:
Sorry hoor, maar foreign keys zijn vooral handig voor programmeurs die te lui zijn hun tabellen zelf te checken. Als jij nou gewoon eerst in je programma een check uit zou voeren of de klant niet nog schulden heeft, kun je net zo goed MySQL gebruiken.

Het is de taak van de DB-bouwer om ervoor te zorgen dat z'n tabellen consistent blijven. Zulke dingen moeten tijdens het ontwerp van een database al over nagedacht worden. Hoe kun je dat nou gaan verplaatsen naar de programmeur toe die alleen maar een schilletje om de DB bouwt?

Je kan toch ook niet zeggen dat USB-support in linux door de fabrikanten gedaan moet worden en niet de zorg hoort te zijn van de kernelbouwer?


Maar ik begrijp wel wat je bedoeld ermee. aangezien ik in dit gevaal zowel db-bouwer als codetikker ben kan ik dit natuurlijk wel doorvoeren.
maar stel dat ze later willen upgraden naar iets wat dat wel support, dan moeten ze dus wel complete database even opnieuw gaan bouwen, en m'n applicatie weggooien. Want die testjes mbv. queries gaan wel wat trager dan foreign keys.

[kmf]

Op zondag 13 januari 2002 12:52 schreef zwelgje2 het volgende:
dan gebruik je toch voor de time being de alpha versie? dan kun je er gelijk mee leren werken,

dat wil ik als allerlaatste optie doen, is natuurlijk wel voor stage, dus als de alphaversie niet binnen 4 maanden afgerond is, dan krijgt stagebedrijf en dus ik ook een probleem

(ik weet niet hoe stabiel de alphaversie is, maar ik neem het risico dus niet)

[MikeN]

Op zondag 13 januari 2002 13:20 schreef athlonkmf het volgende:

[..]



Het is de taak van de DB-bouwer om ervoor te zorgen dat z'n tabellen consistent blijven.

Dat vindt ik dus niet....
Ik vind dat een RDBMS er is om gegevens op te slaan, niet om ze op z'n eigen houtje te gaan controleren.

[kmf]

Op zondag 13 januari 2002 13:24 schreef MikeN het volgende:

[..]

Dat vindt ik dus niet....
Ik vind dat een RDBMS er is om gegevens op te slaan, niet om ze op z'n eigen houtje te gaan controleren.

Een RDBMS is er om gegevens op te slaan EN goed te bewaren.

En met foreign keys, etc werken gaat heel wat sneller dan met queries zulke consistentietesten uitvoeren.

En... tja.. ik heb die dingen niet voor niks geleerd hoop ik. Zulke dingen horen nou eenmaal bij database-ontwerp. Als je al die praktijkvoorbeelden heeft gezien wat een niet deugend ontwerp kan veroorzaken...
In een kleinschalig omgeving heeft het weinig invloed, maar als het bij een bank gebeurd. Je kan dan wel met die queries op programma-niveau zulke dingen checken, maar wil JIJ 15 minuten wachten voordat je je geld uit de pinautomaat komt rollen?

edit>
Ik heb al even bij postgres gekeken, en die ondersteunen het idd, dus ik heb nog wel een keus extra.

Even quoten wat zij vinden dat een RDBMS is (ik ben met hun eens)

The Purpose of an RDBMS
An RDBMS exists for the purpose of providing a reliable permanent storage mechanism with very strict properties embodied in the ACID test. I will quote directly from Philip Greenspun's great explanation

Atomicity
Results of a transaction's execution are either all committed or all rolled back. All changes take effect, or none do. Suppose that a user is editing a comment. A Web script tells the database to "copy the old comment value to an audit table and update the live table with the new text". If the hard drive fills up after the copy but before the update, the audit table insertion will be rolled back.
Consistency
The database is transformed from one valid state to another valid state. A transaction is legal only if it obeys user-defined integrity constraints. Illegal transactions aren't allowed and, if an integrity constraint can't be satisfied the transaction is rolled back. For example, suppose that you define a rule that postings in a discussion forum table must be tied to a valid user ID. Then you hire Joe Novice to write some admin pages. Joe writes a delete-user page that doesn't bother to check whether or not the deletion will result in an orphaned discussion forum posting. Oracle will check, though, and abort any transaction that would result in you having a discussion forum posting by a deleted user.
Isolation
The results of a transaction are invisible to other transactions until the transaction is complete. For example, suppose you have a page to show new users and their photographs. This page is coded in reliance on the publisher's directive that there will be a mugshot for every user and will present a broken image if there is not. Jane Newuser is registering at your site at the same time that Bill Olduser is viewing the new user page. The script processing Jane's registration does inserts into several tables: users, mugshots, users_demographics. This may take some time if Jane's mugshot is large. If Bill's query starts before Jane's transaction commits, Bill won't see Jane at all on his new-users page, even if Jane's insertion into some of the tables is complete.
Durability
Once committed (completed), the results of a transaction are permanent and survive future system and media failures. Suppose your ecommerce system inserts an order from a customer into a database table and then instructs CyberCash to bill the customer $500. A millisecond later, before your server has heard back from CyberCash, someone trips over the machine's power cord. Oracle will not have forgotten about the new order. Furthermore, if a programmer spills coffee into a disk drive, it will be possible to install a new disk and recover the transactions up to the coffee spill, showing that you tried to bill someone for $500 and still aren't sure what happened over at CyberCash.

[MikeN]

http://www.mysql.com/doc/A/N/ANSI_diff_Foreign_Keys.html

Daar staan ook redenen om geen Foreign Keys te gebruiken. Ik vind niet dat ze een nut hebben.

[ACM]

Op zondag 13 januari 2002 12:51 schreef athlonkmf het volgende:
Maar postgres is toch heel wat trager dan mysql?

Postgresql is wat trager dan mysql, maar tegenwoordig niet "heel wat".

Op zondag 13 januari 2002 12:52 schreef zwelgje2 het volgende:
dan gebruik je toch voor de time being de alpha versie? dan kun je er gelijk mee leren werken,

Lijkt me niet verstandig een applicatie te ontwikkelen op een alpha versie... Als je een bug tegenkomt weet je niet eens of die in je eigen app zit of in mysql...

Op zondag 13 januari 2002 12:58 schreef MikeN het volgende:
Sorry hoor, maar foreign keys zijn vooral handig voor

Dat is inderdaad de verklaring die mysql geeft toch?

Wat een onzin, waarom zou je 100 checks op dubbele waarden etc etc uitvoeren terwijl de database dat makkelijk, efficient en veel eenvoudiger voor je kan doen?

In mysql is het volkomen legaal om voor bijvoorbeeld een forum een topic te plaatsen in een niet bestaande categorie met een niet bestaande user.

Wil je dat allemaal elke keer zelf handmatig na gaan lopen?

Oracle en elke andere respectabele database biedt het met graagte aan om dat voor je te doen...

[Janoz]

Als ze voor een gratis dbms gaan, dan kun e natuurlijk niet de kwaliteit verwachten die bv oracle biedt. Persoonlijk zou ik voor ProgreSQL gaan. Met de traagheid schijnt het bij de nieuwere versies wel mee te vallen..

IMHO zijn mysql en ook access meer oplossingen voor het MKB en de hobbyist (nofi)

* Janoz denkt dat MikeN nog niet vaak met echt grote db systemen gewerkt heeft zodat hij het nut van FK's, maar ook van bijvoorbeeld rollback nog niet op hun volledige waarde kan inschatten (nog steeds nofi)

[MikeN]

A properly written application will make sure internally that it is not violating referential integrity constraints before proceding with a query. Thus, additionaly checks on the database level will only slow down performance for such application.

Dat is mijn reden....
Het is net alsof nu de RDBMS jouw fouten moet opvangen. Ik vindt niet dat hij dat moet doen. Ik vind dat de programmeur moet leren redelijk te programmeren en je ervan bewust moet zijn dat je goed op je database moet letten. Dat dit misschien wat extra queries kost, dat moet dan maar.

[Glock]

Op zondag 13 januari 2002 13:33 schreef MikeN het volgende:
een overtuigende conclusie

En ik ben het hier compleet mee eens

hoewel andere mensen hier een andere mening over kunnen hebben. lijkt me een onderwerp waar geen echt leuk antwoord uit te krijgen is

make your own decision what you think is important

edit: typo

[kmf]

Op zondag 13 januari 2002 13:33 schreef MikeN het volgende:

[..]

Dat is mijn reden....
Het is net alsof nu de RDBMS jouw fouten moet opvangen. Ik vindt niet dat hij dat moet doen. Ik vind dat de programmeur moet leren redelijk te programmeren en je ervan bewust moet zijn dat je goed op je database moet letten. Dat dit misschien wat extra queries kost, dat moet dan maar.

Zoals ik al zei. Als je kleinschalig werkt, dan kan je dit nog gaan doen, maar als het DB door meer users wordt gebruikt, dan wordt dit het bottleneck EN het zorgt, zoals ik al zei, voor flinke upgrade problemen als ze ooit besluiten om over te stappen op een wat proffesionele DBMS.

Maar IIG. een DBMS hoort zulke dingen te kunnen, dat is gewoon de taak van een DBMS, dat is wel wat je zult leren alsje als databasebouwer wilt werken (daarom zitten ze dan ook te werken aan foreignkey-support)

[MikeN]

Of dat checken nu door de DB gebeurt of door je programma, daar moet geen snelheidsverschil tussen zijn.

En als jij praat over meerdere users, heb je het over transactions, en ik dacht dat het hier ging over foreign keys.

[ACM]

Op zondag 13 januari 2002 13:33 schreef MikeN het volgende:
Het is net alsof nu de RDBMS jouw fouten moet opvangen.

Wat is dat nou voor iets?

Een RDBMS moet de relationele integriteit toch bewaken?

Dat KAN ie niet zonder foreign keys en dergelijke.

Sterker nog allerlei database modellen die niet het Relationele principe volgen (bijv semantische model) beschikken soms nog over veel betere manieren om die integriteit te controleren. En verplichten je zelfs in veel gevallen dat door de DB te laten doen.

[kmf]

Op zondag 13 januari 2002 13:29 schreef ACM het volgende:

[..]

Postgresql is wat trager dan mysql, maar tegenwoordig niet "heel wat".
[..]

Dat denk ik ook, daarom denk ik dat ik maar eens flink moet gaan discusieren met stagebedrijf

Maar.. als tweaker ben je natuurlijk geneigd om te gaan voor een wat snellere oplossing
Dus maar hopen dat MySQL4 snel klaar is, of dat er aan Postgres flink gesleuteld kan worden om performance te verbeteren

Lijkt me niet verstandig een applicatie te ontwikkelen op een alpha versie... Als je een bug tegenkomt weet je niet eens of die in je eigen app zit of in mysql...
[..]

IDD. maar even testen kan geen kwaad. Als ze nou binnen 2-3 maanden daarmee komen... dan kan ik het alsnog gebruiken.

Dat is inderdaad de verklaring die mysql geeft toch?

Nou nee, ze zeggen, net als Mikey dat het op te lossen valt door het te verschuiven naar de applicatie toe.

The FOREIGN KEY syntax without ON DELETE ... is mostly used for documentation purposes. Some ODBC applications may use this to produce automatic WHERE clauses, but this is usually easy to override. FOREIGN KEY is sometimes used as a constraint check, but this check is unnecessary in practice if rows are inserted into the tables in the right order.

In MySQL Server, you can work around the problem of ON DELETE ... not being implemented by adding the appropriate DELETE statement to an application when you delete records from a table that has a foreign key. In practice this is as quick (in some cases quicker) and much more portable than using foreign keys.

Wat een onzin, waarom zou je 100 checks op dubbele waarden etc etc uitvoeren terwijl de database dat makkelijk, efficient en veel eenvoudiger voor je kan doen?

In mysql is het volkomen legaal om voor bijvoorbeeld een forum een topic te plaatsen in een niet bestaande categorie met een niet bestaande user.

Wil je dat allemaal elke keer zelf handmatig na gaan lopen?

Oracle en elke andere respectabele database biedt het met graagte aan om dat voor je te doen...

That's what I'm trying to say all the time

[MikeN]

Ik vind gewoon niet dat een database voor mij de integriteit hoeft te bewaken. Wat ik vind is dat een relationele database, relaties moet kunnen leggen tussen de data, niet dat hij mij relaties checked.

Maar dat is mijn mening.

[ACM]

Op zondag 13 januari 2002 13:41 schreef MikeN het volgende:
Of dat checken nu door de DB gebeurt of door je programma, daar moet geen snelheidsverschil tussen zijn.

Wat nou als 5 programma's tegelijk controleren of er een bepaalde entry wel bestaat...
(laten we mysql nemen... die kent tenslotte geen foreign key's) vervolgens zien ze allemaal dat het niet bestaat...

Daarna plaatst app 1 het in de tabel, app 2 ook, app 3 etc.
Want ze zagen toevallig tegelijkertijd dat iets niet bestond.

Of andersom.

Wat als er een entry in de DB is?
Ze zien allemaal dat ie bestaat, app2-app5 willen een "entry die daar op leunt bij plaatsen" en app1 wil hem verwijderen.

Ook dat is volkomen legaal met jouw uitleg...

[ACM]

Op zondag 13 januari 2002 13:44 schreef MikeN het volgende:
Ik vind gewoon niet dat een database voor mij de integriteit hoeft te bewaken. Wat ik vind is dat een relationele database, relaties moet kunnen leggen tussen de data, niet dat hij mij relaties checked.

Dan ben jij dus een tevreden mysql gebruiker

Echter is het geloof ik niet echt de mening van de grotere DB-denkers (enzo ) magoed, ook die is niet altijd duidelijk.

Echter moet je niet vergeten dat een relationele integriteit belangrijk is om op je relaties te kunnen vertrouwen... Maar jij hebt dat blijkbaar niet nodig?

[Janoz]

Op zondag 13 januari 2002 13:41 schreef MikeN het volgende:
Of dat checken nu door de DB gebeurt of door je programma, daar moet geen snelheidsverschil tussen zijn.

kom kom kom, dat geloof je toch zelf ook niet. Ik durf er mijn handen voor in het vuur te steken dat een FK check door de DB zelf altijd sneller is dan een FK-check die in de eromheen geprogrameerde schil is gemaakt. Immers, je DBMS heeft rechtstreeks contact met de data (niet via sql queries) en daarnaast kunen de FK restricties simpel in de interne datastructuren worden opgeslagen waardoor de verwerking heel snel kan gebeuren. Hier heb je in je omliggende schil helemaal geen toegang toe.

En als jij praat over meerdere users, heb je het over transactions, en ik dacht dat het hier ging over foreign keys.

Als je zelf FK-checks gaat doen, komen er al heel snel meerdere queries om de hoek kijken. Waneer je 1 actie in meerdere queries uit gaat voeren wordt ineens het 'meerdere users' aspect een stuk belangrijker. Stel dat er tussen je controle of een klant een schuld heeft en het verwijderen van een klant, een andere user net een nieuwe schuld invoerd? Zeg maar dag tegen je integriteit.

[kmf]

Op zondag 13 januari 2002 13:41 schreef MikeN het volgende:
Of dat checken nu door de DB gebeurt of door je programma, daar moet geen snelheidsverschil tussen zijn.

En als jij praat over meerdere users, heb je het over transactions, en ik dacht dat het hier ging over foreign keys.

Geen snelheidsverschil?

Als je met queries werkt, moet de DBMS de query gaan compilen, de database doorlopen, z'n conclusies trekken en dan gaat ie pas verder.

Als je het ingebouwd hebt m.b.v. foreign keys, dan gaat de DBMS gewoon eventjes in de datadictionary kijken (die gewoon tijdens het starten van de database al in de cache staat).

Wat is dan sneller?

Praktijkvoorbeeld weer:
Je zoekt een hoofdstuk uit twee boeken over laten we zeggen "foreign keys" en kijkt of ze hetzelfde zijn.

Wat gaat sneller, twee boeken doorbladeren tot je er iets over ziet.
Of even in de index kijken?

[MikeN]

Owkee, owkee, owkee.

Laat ik het iets genuanceerder zeggen: Ik vind niet dat in MySQL foreign keys nodig zijn.

Ze kunnen nut hebben, maar alleen in dergelijk grote applicaties, dat er ook een grote RDBMS bij hoort, zoals bijvoorbeeld Oracle.

Maar ik geloof toch niet dat we eruit komen.

[ACM]

Op zondag 13 januari 2002 13:51 schreef MikeN het volgende:
Laat ik het iets genuanceerder zeggen: Ik vind niet dat in MySQL foreign keys nodig zijn.

Ze kunnen nut hebben, maar alleen in dergelijk grote applicaties, dat er ook een grote RDBMS bij hoort, zoals bijvoorbeeld Oracle.

Mja, ook voor GoT zou ik het wel es nuttig gevonden hebben

Zo ruimde ik laatste de notes-tabel wat op, omdat ik ontdekte dat er iets van 6000 notes voor de gebruiker met het userid 0 bestonden...
Alleen bestaat die user helemaal niet (en heeft nooit bestaan) dat zou met een goede foreign-key nooit hebben kunnen gebeuren (ok, met goede checks in de software ook in dit geval )

[kmf]

Op zondag 13 januari 2002 13:51 schreef MikeN het volgende:
Owkee, owkee, owkee.

Laat ik het iets genuanceerder zeggen: Ik vind niet dat in MySQL foreign keys nodig zijn.

Ze kunnen nut hebben, maar alleen in dergelijk grote applicaties, dat er ook een grote RDBMS bij hoort, zoals bijvoorbeeld Oracle.

Maar ik geloof toch niet dat we eruit komen.

tja.. als je er later ooit interesse in hebt en in die omgeving wilt gaan werken en dus daarvoor wilt gaan studeren dan zou je het ook met ons over eens zijn.

en laten we er voorlopig maar bij houden dat als je MySQL gebruikt, je geen foreign keys nodig hebt, omdat je dan weinig met ref. integriteit te maken krijgt.


BACK ON TOPIC DAN MAAR WEER

Ik moet maar eens even flink veel onderzoek gaan doen wat ik dan beter moet gebruiken.

Weet iemand dan of Access zulke dingen wel ondersteunt?

Ik had ergens gelezen dat GOT ook MySQL gebruikt, hoe hebben ze dit soort dingen dan opgelost? (hoewel... het schijnt dat het weleens gebeurt dat een user wordt weggeschopt terwijl hij nog postings heeft lopen in een forum )

[MikeN]

Op zondag 13 januari 2002 13:55 schreef ACM het volgende:

[..]

Mja, ook voor GoT zou ik het wel es nuttig gevonden hebben

Zo ruimde ik laatste de notes-tabel wat op, omdat ik ontdekte dat er iets van 6000 notes voor de gebruiker met het userid 0 bestonden...
Alleen bestaat die user helemaal niet (en heeft nooit bestaan) dat zou met een goede foreign-key nooit hebben kunnen gebeuren (ok, met goede checks in de software ook in dit geval )

Notes voor userid 0 zijn duidelijk een fout van het programma.... Dit soort dingen zou je foreign-keys niet voor moeten gebruiken, want als je een note kan maken voor user 0 moet je toch is bij jezelf gaan denken wat er fout zich in je programma.

[edit]

Op zondag 13 januari 2002 13:56 schreef athlonkmf het volgende:
Weet iemand dan of Access zulke dingen wel ondersteunt?

Ik heb gelezen van wel, maar ik weet het niet zeker.

Ik had ergens gelezen dat GOT ook MySQL gebruikt, hoe hebben ze dit soort dingen dan opgelost?

Soms niet, soms door een gewone check door het programma. Dit is makkelijk te doen voor een forum.

(hoewel... het schijnt dat het weleens gebeurt dat een user wordt weggeschopt terwijl hij nog postings heeft lopen in een forum )

Gebruikers worden niet van GoT 'verwijderd', hooguit gebanned. Anders zou je topics krijgen die niet meer 'lopen'. Juist al zou je al z'n berichten wissen.

[kmf]

Op zondag 13 januari 2002 13:56 schreef MikeN het volgende:

[..]

Notes voor userid 0 zijn duidelijk een fout van het programma.... Dit soort dingen zou je foreign-keys niet voor moeten gebruiken, want als je een note kan maken voor user 0 moet je toch is bij jezelf gaan denken wat er fout zich in je programma.

Nee, daar zijn foreign keys idd niet voor, maar wel weer iets anders dat er mee te maken heeft, constraints

Is databaseontwikkeling niet leuk? Ik heb er flink mee moeten huilen toen ik het kreeg, begreep er geen niks van
Maar als je het eenmaal begrijpt is het

[..]

Ik heb gelezen van wel, maar ik weet het niet zeker.
[..]

even navragen...
Notitie gemaakt in m'n toekomstige pda

Gebruikers worden niet van GoT 'verwijderd', hooguit gebanned. Anders zou je topics krijgen die niet meer 'lopen'. Juist al zou je al z'n berichten wissen.

Was maar een

[ACM]

Op zondag 13 januari 2002 13:56 schreef athlonkmf Ik had ergens gelezen dat GOT ook MySQL gebruikt, hoe hebben ze dit soort dingen dan opgelost? (hoewel... het schijnt dat het weleens gebeurt dat een user wordt weggeschopt terwijl hij nog postings heeft lopen in een forum )

Users worden "gebanned" nooit "gedelete" dus dat komt niet voor

Magoed, ik geloof dat Access het ook ondersteund, maar als ik moest kiezen tussen access en postgres zou ik toch echt voor postgres gaan.

Op zondag 13 januari 2002 13:56 schreef MikeN het volgende:
Notes voor userid 0 zijn duidelijk een fout van het programma.... Dit soort dingen zou je foreign-keys niet voor moeten gebruiken, want als je een note kan maken voor user 0 moet je toch is bij jezelf gaan denken wat er fout zich in je programma.

Weet ik wel Was ook slechts een voorbeeld, er bestaan ook vast wel notes van gebruikers die niet (meer) bestaan.

Maarja, ik heb topix niet gemaakt he?

[dusty]

Op zondag 13 januari 2002 13:47 schreef ACM het volgende:
[..]
Dan ben jij dus een tevreden mysql gebruiker
[..]

*poke*

MySQL = DBMS

DBMS != RDBMS.

i.e. je geeft hem gelijk dat hij met MYSQL een RDBMS gebruikt terwijl dit niet het geval is

[dusty]

Op zondag 13 januari 2002 12:58 schreef MikeN het volgende:
Sorry hoor, maar foreign keys zijn vooral handig voor programmeurs die te lui zijn hun tabellen zelf te checken. Als jij nou gewoon eerst in je programma een check uit zou voeren of de klant niet nog schulden heeft, kun je net zo goed MySQL gebruiken.

Toch maar ook eens serieus reageren:

Foreign Keys zijn functies die GEGARANDEERD werken. (althans als de database FK's ondersteunt:+ )

Hierdoor kan je de correctheid van je database garanderen, terwijl dit onafhankelijk is van je applicatie, Immers kan de applicatie wel eens veranderen, er kunnen andere ontwikkelaars bezig zijn met nieuwe applicaties, en dan wil je toch echt dat er niets fout gaat met de database, bijvoorbeeld zoals notes van een gebruiker die niet bestaat ( lees:GOT )

Ook door de concurency van de meeste applicaties zou client side controle erg slecht zijn (zie voorbeeld hierboven) een heel goed voorbeeld hiervan is bijna elk druk forum die op MYSQL draait. Er komt dan altijd wel een keertje een BRAK thread die compleet leeg is, een topic die iemand heeft getikt en zijn topic is opeens weg. (gaat meestal in combinatie met de BRAKKE topic)

Vaak wordt de database gedeelte de verantwoordelijkheid van een DBA-er. En heel vaak heeft een DBA-er geen verstand van programmeren.

Door gebruik te maken van FK's in je programma hoef je alleen de foutmeldingen van je database af te vangen, Hierdoor wordt de fout afhandelijk vermakkelijkt, en bovendien wordt de applicatie sneller doordat er minder informatie over het netwerk gestuurd hoeft te worden (minder queries), Je kan de correctheid van je applicatie duidelijker in beeld brengen omdat je verschillende zaken als Database Integriteit aan de database over kan laten ( aangezien een relationele database daar in is gespecialiseerd. )

Als jij zegt dat een programmeur lui is omdat hij Foreign Keys gebruikt, moet ik je toch teleurstellen dat jouw mening fout is,

Volgens mij zie jij niet in dat met gebruik van Foreign Keys je eigen applicatie stabieler kan krijgen, en dat het uiteindelijk ook de ontwikkeltijd van je applicatie ontzettend zal verkorten, er kunnen namelijk verschillende problemen dan NOOIT meer voordoen. Betekent ook dat de kosten van het onderhouden ervan verlaagd wordt, en dat willen de meeste bedrijven toch uiteindelijk wel.

Maarja, wat weet ik nou van datbases? Gelukkig heb ik meer verstand van uhm... andere dingen

[MikeN]

Op zondag 13 januari 2002 15:00 schreef dusty het volgende:
Als jij zegt dat een programmeur lui is omdat hij Foreign Keys gebruikt, moet ik je toch teleurstellen dat jouw mening fout is.

Als jij zegt dat een mening fout is, dan klopt er iets niet

[dusty]

Op zondag 13 januari 2002 15:02 schreef MikeN het volgende:
[..]
Als jij zegt dat een mening fout is, dan klopt er iets niet

Een mening die niet klopt naar de waarheid = een foute mening = een mening die fout is.

[MikeN]

Op zondag 13 januari 2002 15:12 schreef dusty het volgende:

[..]

Een mening die niet klopt naar de waarheid = een foute mening = een mening die fout is.

Laten we het maar een (in jouw ogen) onjuiste mening noemen.

[dusty]

Op zondag 13 januari 2002 15:13 schreef MikeN het volgende:
[..]
Laten we het maar een (in jouw ogen) onjuiste mening noemen.

Heb ik maar een antwoord op : Date.

[_JGC_]

Je kunt voor foreign keys InnoDB gebruiken, maar dan is ie niet meer zo portable als met MyISAM tables

[Femme]

InnoDB heeft idd foreign keys en dat werkt op zich goed, alleen verdwijnen de keys na het veranderen van een tabel structuur met ALTER TABLE en worden ze vergeten door mysqldump.

code:

CREATE TABLE parent(id INT NOT NULL, PRIMARY KEY (id)) TYPE=INNODB;
CREATE TABLE child(id INT, parent_id INT, INDEX par_ind (parent_id),
            FOREIGN KEY (parent_id) REFERENCES parent(id)) TYPE=INNODB;

mysqldump maakt ervan:

code:

CREATE TABLE child (
  id int(11) default NULL,
  parent_id int(11) default NULL,
  KEY par_ind (parent_id)
) TYPE=InnoDB;

Dat suckt natuurlijk. Als ze er nou even voor zorgen dat mysql ook weet dat InnoDB foreign key constraints ondersteunt dan kunnen we dit in de praktijk gaan toepassen. Nu is het zo dat de foreign keys de integriteit van de database bewaken maar dat er geen integriteit is van de foreign key constraints, die kunnen zomaar verdwijnen.

[Verwijderd]

Wat me een beetje verbaasd:

Topicstarter vraagt of Access dit ondersteund maar ze gebruiken nu MySQL omdat dit gratis is. Ze gebruiken Oracle niet omdat dit niet gratis is.

Access is ook niet gratis... Ok, niet zo duur als Oracle maar toch zeker niet gratis.

Maar Access ondersteund wel FK's.

En dan mijn mening t.o.v. FK's:

Waar gewerkt wordt, worden fouten gemaakt. En dat blijkt bij uitstek bij programmeren. Terwijl je wel over de dingen hebt nagedacht maak je toch de fouten die je voor wou zijn, zeg maar pure slordigheid. Als die slordigheid er toe leidt dat het geld gaat kosten dan kun je jezelf wel voor de köpfe slaan als je het met FK's voor had kunnen zijn. Immers, je had er al over nagedacht en een FK is sneller geïmplementeerd dan allerlei checks door je applicatie.

Bovendien zijn FK's nog sneller ook, denk hierbij alleen al aan het netwerkverkeer.

Mijn mening: vindt je FK's niks, gebruik dan een File System en geen Relational Database Management System want Managen is heel iets anders als het alleen opslaan van data.

[kmf]

Op maandag 14 januari 2002 12:16 schreef hvdberg het volgende:
Wat me een beetje verbaasd:

Topicstarter vraagt of Access dit ondersteund maar ze gebruiken nu MySQL omdat dit gratis is. Ze gebruiken Oracle niet omdat dit niet gratis is.

Access is ook niet gratis... Ok, niet zo duur als Oracle maar toch zeker niet gratis.

Heheh, topicstarter was daar niet zo duidelijk over, dus even uitleggen dan maar.

Bedrijf heeft NU een Accessdatabase draaien.
Microsoft doet niet zo aardig met licenties (vreemd he?) dus ze willen een ander DBMS hebben. In elk geval niet duurder dan Acess, dus Ingres of Oracle zijn geen goede keuzes.

Dus komen we bij de gratis DBMSsen. MySQL of DBMS.

Nou heeft MySQL geen standaard FK-support dus, dus vroeg ik me af of Access nou wel of geen FK-support heeft. Is dat niet zo, dan heb ik geen probleeem, want slechter maak je het dan dus niet.

Maar aangezien er hier dus wordt gezegd dat access wel FK-support heeft, moet ik dus toch eentje vinden dat dat ook ondersteunt

Ik ben nog verder aan het onderzoeken dus...