[ASP] Relationele mySQL database

[Verwijderd]

Ik heb een database met hierin 3 tabellen:
In elke tabel heb ik een primaire sleutel aangemaakt: id

In tabel1 staan bedrijfsgegevens.
In tabel2 en tabel3 staan gegevens die bij tabel 1 horen.
Nu heb ik de id's van tabel2 en tabel3 dmv. een foreign key (FK) gekoppeld aan de id van tabel1.

On Delete, On Update staat bij alle 2 de FK's op Restrict omdat ik ze ook niet kan zetten op iets anders, zoals: Cascade of Set Null.

Ik wil wanneer tabel1 gevult wordt met gegevens, dat in tabel2 en tabel3 een record wordt toegevoegd met dezelfde id als in tabel1, zodat ik die lege records van tabel2 en tabel3 kan Updaten met gegevens die ik pas later laat toevoegen dmv. formulieren in ASP.

Hoe krijg ik dit in godsnaam voor elkaar, ben al heel de middag an het zoeken

[Verwijderd]

Je zult dat in je ASP code moeten afhandelen. Ik schrijf zelf PHP en geen ASP, maar het principe s natuurlijk hetzelfde. Op het moment dat je een INSERT query uit gaat voeren op tabel 1, prop je het ID dat ge-INSERT is ook in tabel 2 en 3 met twee aparte queries (of misschien kan het in 1 query, weet ik niet).

[Verwijderd]

Moet dat echt zo omslachtig, zoiets had ik ook al bedacht, maar dit leek me niet juist.

Ik krijg met geen mogelijkheid die FK aangepast, ik wil hem bij On Update op Cascade hebben.

ALTER TABLE `tabel1`.`websitesdata` DROP FOREIGN KEY `FK1`,
ADD CONSTRAINT `FK1` FOREIGN KEY `FK1` (`id`)
REFERENCES `tabel2` (`id`)
ON DELETE CASCADE
ON UPDATE CASCADE;

Maar ik krijg steeds een error:
MYsQL error number: 1005
Can't create table

[ Voor 68% gewijzigd door Verwijderd op 17-01-2006 17:45 ]

[Noork]

Laatste id van tabel 1 opvragen met "mysql_insert_id();" en dan een insert query in tabel 2 en 3 met als foreign key de mysql_insert_id();

Verwijderd schreef op dinsdag 17 januari 2006 @ 17:43:
Moet dat echt zo omslachtig, zoiets had ik ook al bedacht, maar dit leek me niet juist.

Valt wel mee toch?

[ Voor 47% gewijzigd door Noork op 17-01-2006 17:45 ]

[dusty]

Of je gebruikt een genormaliseerd data-model.

[Verwijderd]

Waaruit maak je op dat-ie dat niet doet dan?

[Verwijderd]

@TS: Je zult dus het laatst ge-INSERTe id moeten opvragen uit tabel 1 en dat in tabel 2 en tabel 3 proppen.

Voor die foreign key regels kun je hier kijken.

@Noork: mysql_insert_id() is een PHP ding. Misschien is er zoiets in ASP?

[Noork]

Oke, misschien last_insert_id(); ? Dit is een mysql functie.

[danielsrje]

Verwijderd schreef op dinsdag 17 januari 2006 @ 17:31:
Ik wil wanneer tabel1 gevult wordt met gegevens, dat in tabel2 en tabel3 een record wordt toegevoegd met dezelfde id als in tabel1, zodat ik die lege records van tabel2 en tabel3 kan Updaten met gegevens die ik pas later laat toevoegen dmv. formulieren in ASP.

Ik snap het niet. Waarom zou je dat willen doen? Je kunt toch in je formulier eenvoudig checken of er al een tabel2/tabel3 record is voor het tabel1 id, en zoniet: aanmaken?

[dusty]

Verwijderd schreef op dinsdag 17 januari 2006 @ 17:50:
Waaruit maak je op dat-ie dat niet doet dan?

Geef eens een voorbeeld waar je informatie in tabel 1 zet, en dan die id die daar gemaakt wordt ook altijd (meteen) nodig hebt in tabel 2 en 3.

[Verwijderd]

poging:

Je vraagt een dienstverlenend bedrijf de bedrijfsgegevens (bedrijfsnaam, adres, etc) in te vullen in een formulier en daarbij de provincies in welke het bedrijf actief is. Normale bedrijfsgegevens gaan in tabel 1, maar die provincies komen in een bedrijf_provincie tabel.

edit: het kan natuurlijk wel zo zijn dat dit geval veroorzaakt wordt door een niet genormaliseerd datamodel, ik kan het alleen niet uit de posts van de TS opmaken.

[ Voor 28% gewijzigd door Verwijderd op 17-01-2006 19:11 ]

[Verwijderd]

Ik heb het nu opgelost op de manier die Rubenski vertelde, de 1e reply.

Na het toevoegen van een record in tabel1, selecteer ik datzelfde record en pak ik het ID uit dat record.

Dat ID stop ik dan in Tabel2 en Tabel3.


Er zit nog wel ergens een fout, want wanneer ik een record toevoeg aan tabel2, voegt hij een nieuw record toe, en alle oude records update hij met de gegevens van dit nieuwe record....
Opgelost

@Dusty, ik heb dat id niet meteen nodig. Maar bij het toevoegen van andere formulieren wel.

@Rubenski, daar komt het op neer inderdaad.

Bedankt voor de hulp iig.!!

[ Voor 12% gewijzigd door Verwijderd op 17-01-2006 19:06 . Reden: Om te bedanken ]

[dusty]

Verwijderd schreef op dinsdag 17 januari 2006 @ 19:00:
poging:

Je vraagt een dienstverlenend bedrijf de bedrijfsgegevens (bedrijfsnaam, adres, etc) in te vullen in een formulier en daarbij de provincies in welke het bedrijf actief is. Normale bedrijfsgegevens gaan in tabel 1, maar die provincies komen in een bedrijf_provincie tabel.

Dart voorbeeld voldoet niet aan zijn beschrijving:

Ik wil wanneer tabel1 gevult wordt met gegevens, dat in tabel2 en tabel3 een record wordt toegevoegd met dezelfde id als in tabel1, zodat ik die lege records van tabel2 en tabel3 kan Updaten

Een bedrijf provincie tabel heeft een n:m relatie met tabel1, zoals de TS in zijn topic start heeft geschreven komt het neer op een 1:1 relatie. ( wat dus met zijn reactie hierboven blijkt dat hij dat dus niet bedoeld.) Hij wilt informatie INSERTEN en mogelijk DELETEN, en niet zozeer alleen 'UPDATEN'.

Verwijderd schreef op dinsdag 17 januari 2006 @ 19:02:
[..]
Dat ID stop ik dan in Tabel2 en Tabel3.
[..]

als dat ID in Tabel2 of Tabel3 uniek is ben je dus verkeerd bezig en heb je geen genormaliseerd database model.

[ Voor 15% gewijzigd door dusty op 17-01-2006 19:13 ]

[Verwijderd]

@Dusty: Goed punt. Hij heeft het over 'een' record in tabel 2 en 3.

Remco, als er zoals Dusty zegt een 1 op 1 relatie is tussen de records van tabel 1, 2 en 3 (voor elk record in tabel 1 is er precies 1 record in tabel 2 en precies 1 record in tabel 3) dan is je datamodel idd niet genormaliseerd. Je kunt (moet) dan beter alles in tabel 1 opslaan. Anders moet je later JOINS gaan schrijven over 3 tabellen terwijl dit in feite onnodig is.

[ Voor 3% gewijzigd door Verwijderd op 17-01-2006 19:19 ]

[Verwijderd]

als dat ID in Tabel2 of Tabel3 uniek is ben je dus verkeerd bezig en heb je geen genormaliseerd database model.

Het ID van Tabel1, Tabel2 en Tabel3 is hetzelfde....is dat niet goed dan?

Ik dacht net dat ik goed bezig was.....

@Dusty: Goed punt. Hij heeft het over 'een' record in tabel 2 en 3.

Remco, als er zoals Dusty zegt een 1 op 1 relatie is tussen de records van tabel 1, 2 en 3 (voor elk record in tabel 1 is er precies 1 record in tabel 2 en precies 1 record in tabel 3) dan is je datamodel idd niet genormaliseerd. Je kunt (moet) dan beter alles in tabel 1 opslaan. Anders moet je later JOINS gaan schrijven over 3 tabellen terwijl dit in feite onnodig is

Zit wat in, dat wist ik, dat ik met JOINS moest gaan werken.
Maar 1 tabel vol met gegevens dat is toch ook niet netjes?
Zo blijft het een beetje overzichtelijk.

[ Voor 57% gewijzigd door Verwijderd op 17-01-2006 19:21 ]

[kenneth]

Voor overzichtelijkheid heb je formulieren
Een datamodel moet vooral correct zijn

[Verwijderd]

Wat is dan het verschil tussen:
1. Een database met 3 tabellen met elk hetzelfde ID
2. Een database met 1 tabel

Naast dat de ene db 3 tabellen heeft en de ander 1.
Kan het kwaad dat het 3 tabellen zijn met hetzelfde ID?
Is het langzamer?

[engelbertus]

ik denk dat het langzamer is, omdat je met join moet gaan werken en twee tabellen moet doorpluizen. en dus ook drie indexen etc. het zijn steeds drie bewerkingen die de server moet doen. met 1 tabel hoeft hij maar een keer een selectie te maken uit 1 tabel en daar iets mee te doen. dat si denk ik sneller, omdat je zoals jij het nu min of meer doet voorkomen. alle data uit de drie tabellen ook steeds nodig is, ds dat het niet zo is dat in het vervolg alleen tebal 1 wordt gebruikt, en tabel 2 en 3 slechts af en toe.

als e het in 1 tabel netjes kunt oplossen is dat denk ik altijd beter.

als je geen 1:1 koppellingen meer hebt wordt dat een beetje moeilijk in 1 tabel, om overzichtelijk te houden.

maar met bedrijfsgegevens en een tabel met in welke provincies ze actief zijn, lijkt het me geen 1:1 tabel meer.
tabel 1
id | bedrijfsnaam | adres | whatever

tabel 2

id | provincie en dan??
hoe stop je verschillend provincies in 1 tabel met slechts 1 id? (hetzelfde als het id van tabel 1. als dat eenvoudig was /( bijvoorbeeld slechts 1 provincie per bedrijf) kan het gemakkelijk in 1 tabel

of is tabel 2 als volgt

id | friesland | groningen | drenthe| etc?

dat is dan een beetje een rare tabel, maar daarnaast kan die gewoon in tabel in worden opgenomen.


ik zat zelf wel eens te denken, stel dat je allemaal personen hebt. die stop je in een tabel
en allemaal bedrijven ->tabel 2

tabel 3 koppelt dan id persoon aan id bedrijf en zo weet je wie waar werkt.
daar kun je dan zijn telefoonnummer op de zaak bij zetten en andere bedrijfs en persoonsafhankelijke gegevens.

dan maak je een tabel 4 met projectnummers, en daar kopel je dan contactpersonen aan, en de bedrijfsnamen kun je dan eenvoudig erbij laten zoeken.
of zonde personen meteen een bedrijf, en later een persoon.

in die tabel met werknummers kun je dan ook documentlijsten en dergelijke opnemen

of is zoiets ook niet juist?
elke id in tabel 3 en vier stelt dan een koppeling voor.
een koppeling van een project aan een persoon, een bedrijf of een document of product.

of moet je dan juist voor elk soort koppeling een apparte tabel maken?

(project-persoon) (project bedrijf) (project-product) en bijvoorbeeld ook ( project-gewerkte uren-medewerker) (project afdrukken voor rekening van)

wat wil het dus eigenlijk zeggen, een genormaliseerde database ?

[dusty]

Verwijderd schreef op dinsdag 17 januari 2006 @ 20:05:
Wat is dan het verschil tussen:
1. Een database met 3 tabellen met elk hetzelfde ID
2. Een database met 1 tabel

Naast dat de ene db 3 tabellen heeft en de ander 1.
Kan het kwaad dat het 3 tabellen zijn met hetzelfde ID?
Is het langzamer?

Simplistisch:

code:

1.
 UserID | Voornaam
2.
 UserID | Achternaam
3.
 UserID | Getrouwd
4.
 UserID | Woonplaats
5.
 UserID | TelefoonNummer
6.
 UserID | GeboorteDatum

vs

code:

1.
  UserID | Voornaam | Achternaam | Getrouwd | Woonplaats | TelefoonNummer | Geboortedatum

Wat denk jij dat makkelijker/sneller/effectiever is?

[Verwijderd]

Duidelijk.


Dat wordt dus weer alles wijzigen....achja, beter in 1 keer alles goed.
Het zal een grote database worden dus moet hij snel werken. Bedankt voor alle input!

[Verwijderd]

dusty schreef op dinsdag 17 januari 2006 @ 20:33:
[...]

Simplistisch:

code:

1.
 UserID | Voornaam
2.
 UserID | Achternaam
3.
 UserID | Getrouwd
4.
 UserID | Woonplaats
5.
 UserID | TelefoonNummer
6.
 UserID | GeboorteDatum

vs

code:

1.
  UserID | Voornaam | Achternaam | Getrouwd | Woonplaats | TelefoonNummer | Geboortedatum

Wat denk jij dat makkelijker/sneller/effectiever is?

Ik kom hier toch nog even op terug, mijn database heeft nu inmiddels al 70 kolommen, het wordt er allemaal niet overzichtelijker op. Ik wil toch nog eens de vraag stellen of het niet verstandig is de database te normaliseren.

Na de normalisatie zullen er dan ipv. 1 tabel met 70 kolommen, misschien wel 10 tabellen zijn met elk 7 kolommen. Dat normaliseren begrijp ik wel, maar hoe het nu werkt als je bijvoorbeeld een tabel gebruikers en een tabel producten hebt:

Gebruikers <--> Producten

Elke gebruiker kan meerdere produkten hebben, elk produkt kan gekocht worden door meerdere gebruikers. Hoe zorg je er nou voor dat je weet welk produkt de gebruiker kiest? Door elke keer het gebruikers id mee te geven in elke rij van het gekozen produkt? Wie kan mij dit eens duidelijk uitleggen...

[kenneth]

Begin eens met een goed boek erover, want volgens mij snap je het begrip normaliseren niet echt.

http://www.utexas.edu/its.../datamodeling/rm/rm7.html

[Verwijderd]

kenneth schreef op zondag 29 januari 2006 @ 15:43:
Begin eens met een goed boek erover, want volgens mij snap je het begrip normaliseren niet echt.

http://www.utexas.edu/its.../datamodeling/rm/rm7.html

Heb veel gelezen, voor dit topic ook al. Vandaag nog meer gelezen in een boek en online en op de website die jij me gaf.

Schijnbaar is het niet nodig om mijn database te normaliseren omdat alle velden maar één keer voorkomen. Maar omdat ik het overzicht wil bewaren en om ervoor te zorgen dat ik niet al te complexe sql querys moet gaan maken wil ik graag de tabel met 70 kolommen opslitsen.

Er zullen dan ongeveer 5 tabellen komen ipv. 1, nu is mijn vraag, zal de database hierdoor juist sneller of juist trager werken?

[kenneth]

Complexe query's krijg je juist als je tabellen onnodig gaat opsplitsen.

Wat voor soorten velden heb je in die tabel met 70 kolommen dan?

[Creepy]

70 kolommen is redelijk wat ja. Ik gok erop dat je het normaliseren toch nog niet helemaal snapt.

Als je een n:m relatie hebt (gebruikers <-> produkten) dan kan je dit opsplitsen in 2 keer een 1:n relatie. Je voegt een extra koppeltabel toe. Dus 1 tabel met gebruikers, 1 tabel met produkten en 1 tabel waarin je een gebruikers aan ene produkt kan koppelen. Zo heb je dus niet voor elke gebruiker een extra kolom bij produkt nodig (of andersom). De koppeltabel bestaat minimaal uit twee velden, het ID van de gebruiker en het ID van het produkt.

[Verwijderd]

Creepy schreef op zondag 29 januari 2006 @ 18:11:
70 kolommen is redelijk wat ja. Ik gok erop dat je het normaliseren toch nog niet helemaal snapt.

Als je een n:m relatie hebt (gebruikers <-> produkten) dan kan je dit opsplitsen in 2 keer een 1:n relatie. Je voegt een extra koppeltabel toe. Dus 1 tabel met gebruikers, 1 tabel met produkten en 1 tabel waarin je een gebruikers aan ene produkt kan koppelen. Zo heb je dus niet voor elke gebruiker een extra kolom bij produkt nodig (of andersom). De koppeltabel bestaat minimaal uit twee velden, het ID van de gebruiker en het ID van het produkt.

Ik zal eens wat gaan lezen over die koppeltabellen, maar eigenlijk bereik je dit toch ook dmv. een query?

En de vraag staat nog steeds, wordt de database trager wanneer ik de ene tabel met 70 kolommen opsplits in 5 tabellen?

[ludo]

Verwijderd schreef op zondag 29 januari 2006 @ 19:06:
[...]


Ik zal eens wat gaan lezen over die koppeltabellen, maar eigenlijk bereik je dit toch ook dmv. een query?

En de vraag staat nog steeds, wordt de database trager wanneer ik de ene tabel met 70 kolommen opsplits in 5 tabellen?

De database zal niet (noemenswaaridg) trager worden, maar ook niet sneller. Wat wel een stuk trager zal worden is je applicatie, omdat je nu voor het verzamelen van de benodigde informatie waarschijnlijk steeds meerdere queries uit moet voeren en/of complexere queries dan noodzakelijk. Ook loop je tegen het probleem op waaruit dit topic is ontstaan.

Een tabel met 70 kolommen hoeft geen probleem te zijn voor MySQL, als je er maar voor zorgt dat je de juiste indexen aanmaakt en zoveel mogelijk de gegevens selecteert die je nodig hebt (geen SELECT * dus, maar SELECT a, b, c). Als die tabel met 70 kolommen goed genormaliseerd is zou ik altijd voor die oplossing gaan.

Zou je je huidige databasemodel hier kunnen tonen? Dan is waarschijnlijk wat beter in te schatten of je de goede kant op gaat of juist niet

[Verwijderd]

ludo schreef op zondag 29 januari 2006 @ 19:39:
[...]

De database zal niet (noemenswaaridg) trager worden, maar ook niet sneller. Wat wel een stuk trager zal worden is je applicatie, omdat je nu voor het verzamelen van de benodigde informatie waarschijnlijk steeds meerdere queries uit moet voeren en/of complexere queries dan noodzakelijk. Ook loop je tegen het probleem op waaruit dit topic is ontstaan.

Een tabel met 70 kolommen hoeft geen probleem te zijn voor MySQL, als je er maar voor zorgt dat je de juiste indexen aanmaakt en zoveel mogelijk de gegevens selecteert die je nodig hebt (geen SELECT * dus, maar SELECT a, b, c). Als die tabel met 70 kolommen goed genormaliseerd is zou ik altijd voor die oplossing gaan.

Zou je je huidige databasemodel hier kunnen tonen? Dan is waarschijnlijk wat beter in te schatten of je de goede kant op gaat of juist niet

Ok bedankt, helaas kan ik het databasemodel niet openbaar maken.
Wat ik ga doen is voor 1 iets uitgebreider deel een aparte tabel maken, hierdoor krijg ik dus 2 tabellen. Mijn prioriteit ligt echt bij de snelheid.

[dusty]

De onderhoudbaarheid bij een genormaliseerd model is veel beter dan bij een tabel met 70 kolommen. Zodra jij een tabel hebt met 70 kolommen heb je gewoon een slecht database model.

[kenneth]

Verwijderd schreef op zondag 29 januari 2006 @ 20:56:
Ok bedankt, helaas kan ik het databasemodel niet openbaar maken.

Maar toch wel een idee geven wat in die zeventig kolomstabel staat? Louter persoonsgegevens oid? Staan er herhaalde velden in? (product1, product2, product3)

Mijn prioriteit ligt echt bij de snelheid.

Premature optimization is the root of all evil. En dat is niet grappig bedoeld. Zorg eerst nou maar dat je model klopt, anders loop je continu achter de feiten aan.

[Verwijderd]

kenneth schreef op maandag 30 januari 2006 @ 09:20:
Maar toch wel een idee geven wat in die zeventig kolomstabel staat? Louter persoonsgegevens oid? Staan er herhaalde velden in? (product1, product2, product3)

Ten eerste staan er bedrijfsgegevens in.
Dat bedrijf kan een website toevoegen.
Datzelfde bedrijf kan ook nog uitgebreide statistieken toevoegen van hun website.
Dat is het eigenlijk wel.

Premature optimization is the root of all evil. En dat is niet grappig bedoeld. Zorg eerst nou maar dat je model klopt, anders loop je continu achter de feiten aan.

Ik hoop dat mijn model klopt, eerst werd mij hier verteld dat het beste was om het in 1 tabel te zetten, maar ik kom nu toch dingen tegen waardoor die ene tabel wel erg onhandig wordt. Daarom begon ik zelf te twijfelen en stelde ik nogmaals de vraag ivm. 70 kolommen.

Nu heb ik inmiddels een tweede tabel aangemaakt met een uniek id, het bedrijfsid en verdere gegevens. De gegevens die vaak opgevraagd zullen worden wil ik in een aparte tabel zetten, zodat niet de grote tabel helemaal doorzocht dient te worden.

[ Voor 9% gewijzigd door Verwijderd op 30-01-2006 09:30 ]

[kenneth]

Een tabel moet je niet opsplisen alleen omdat hij veel velden heeft. Zo'n DBMS heeft daar veel slimmere dingen voor (indexes, views)

Maar waarom heb je dan geen tabellen bedrijf -> website -> stats ?
Een bedrijf kan vast meer dan één website hebben, en statistieken worden vaker dan één keer gegenereerd, toch?

[Verwijderd]

kenneth schreef op maandag 30 januari 2006 @ 09:43:
Een tabel moet je niet opsplisen alleen omdat hij veel velden heeft. Zo'n DBMS heeft daar veel slimmere dingen voor (indexes, views)

Maar waarom heb je dan geen tabellen bedrijf -> website -> stats ?
Een bedrijf kan vast meer dan één website hebben, en statistieken worden vaker dan één keer gegenereerd, toch?

Omdat die maar één keer voor gaan komen. Daarom staan ze in dezelfde tabel en niet in 3 verschillende.