Voor archief een nieuwe tabel aanmaken?
Nou ben ik met een archief bezig maar zit ik met een vraag wat de beste optie is:
Kan je beter een record verplaatsen naar een tabel Archief, of kan je beter in je huidige tabel de active op 0 zetten? Ik heb nu gekozen (heb het al gedaan) om het over te zetten naar een aparte tabel, zodat je huidige helemaal fris blijft. Graag jullie mening!
Groeten
Not Moose op 15/12/2012 10:58:04:
Nee, in een foreign key en dan waarschijnlijk parent-child relatie hoef je alleen maar een active in de parent op te nemen en op 0 te zetten. @Donny: Zolang je niet in de miljoenen records geraakt zou ik zeker geen archief tabellen aanmaken. Verder kan je na een jaar ofzo je tabel schonen, delete alles wat al langer dan een jaar op active=0 staat. Uiteraard tenzij het om financiele zaken gaat die je conform belastingregels 5 jaar moet bewaren.active op 0. Stel je voor dat een record een foreign key heeft naar een andere tabel, dan moet je die ook aanpassen. En zo blijf je doorgaan
Gewijzigd op 15/12/2012 11:31:23 door John D
John D op 15/12/2012 11:05:05:
Not Moose op 15/12/2012 10:58:04:
Nee, in een foreign key en dan waarschijnlijk parent-child relatie hoef je alleen maar een active in de parent op te nemen en op 0 te zetten.active op 0. Stel je voor dat een record een foreign key heeft naar een andere tabel, dan moet je die ook aanpassen. En zo blijf je doorgaan
Kun je dit uitleggen?
@Ledfan Leesbaarder??? In de tabellen hoeft dat echt leesbaar te zijn en 0 is drie karakters minder dan true/false en in beide gevallen moet je het vriendelijk tonen als actief/niet actief. Of kent MySQL boolean velden?? Nee toch??
Gewijzigd op 15/12/2012 14:20:51 door John D
Als jij een record in je Post tabel helemaal gaat overzetten naar een andere tabel Archief, moet je dus ook je Reacties tabel bijstellen.
Not Moose op 15/12/2012 14:46:30:
@Moose: Onzin, je hebt niet veel begrepen van datamodellering. Je hoeft nooit een active=0/1 in andere tabellen toe te voegen als het bijvoorbeeld in de user of in het geval van Donny de portfolio tabel opgenomen is. Alles wat dan bij de user hoort zoals bijvoorbeeld reacties is terug te relateren (manytomany of onetomany maakt niet uit) aan die user. Daarom heten de datamodellen en databases tegenwoordig relationele modellen/databases. Wordt dat niet meer geleerd tegenwoordig?Als je tabel geen enkele manytomany of onetomany relatie heeft met een andere tabel, zou het in principe kunnen. Maar met het oog op de toekomst (misschien wil je wel ooit reactie's gaan toevoegen?) lijkt mij alsnog een extra kolom `active` beter. Niet moeilijk doen als het ook makkelijk kan.
@Danny: Tuurlijk archief tabellen maken. Lekker heen en weer kopieren. Je had je vraag net zo goed niet kunnen stellen hier. Misschien heb je 6 records in je portfolio tabel en 3 records in je archief-portfolio tabel?? Ik zou toch gaan voor active=0/1 als ik jou was.
Gewijzigd op 15/12/2012 15:23:16 door John D
John D op 15/12/2012 15:14:21:
Not Moose op 15/12/2012 14:46:30:
@Moose: Onzin, je hebt niet veel begrepen van datamodellering. Je hoeft nooit een active=0/1 in andere tabellen toe te voegen als het bijvoorbeeld in de user of in het geval van Donny de portfolio tabel opgenomen is. Alles wat dan bij de user hoort zoals bijvoorbeeld reacties is terug te relateren (manytomany of onetomany maakt niet uit) aan die user. Daarom heten de datamodellen en databases tegenwoordig relationele modellen/databases. Wordt dat niet meer geleerd tegenwoordig?Als je tabel geen enkele manytomany of onetomany relatie heeft met een andere tabel, zou het in principe kunnen. Maar met het oog op de toekomst (misschien wil je wel ooit reactie's gaan toevoegen?) lijkt mij alsnog een extra kolom `active` beter. Niet moeilijk doen als het ook makkelijk kan.
Ik kan je niet goed volgen. Waarom zou je een active kolom willen toevoegen in meerdere tabellen?
John D op 15/12/2012 15:33:07:
@Moose zie: 15/12/2012 10:58:04
Even een voorbeeldje:
tabel newspost
tabel likes
tabel reacties
Een newspost kan geliked worden door verschillende users, en kan verschillende reacties hebben. Stel, je wilt een newspost archiveren, maar natuurlijk niet je data verliezen zoals de likes en de reacties. Als je dan je record gaat verplaatsen naar een andere tabel krijg je zo'n opstapeling:
1. verplaatsen van record naar nieuwe tabel (id veranderd)
2. je koppeltabel met likes aanpassen (je wilt nu niet refereren naar newspost_id maar archief_id)
3. reacties tabel aanpassen, zie bovenstaande
Drie extra stappen, voor iets wat je ook gewoon simpel kunt oplossen door `active` op nul te zetten. Dan kun je bij je query daar rekening mee houden (WHERE `active` = 1)
Hoe jij dan bij een `active` kolom op meerdere tabellen komt, kan ik niet helemaal volgen.
Edit: laat maar ik zie het al. Ik zei foreign key vanaf je post tabel, ik bedoelde natuurlijk naar je post tabel toe :) Hoef je niet meteen zo aanvallend te doen
Gewijzigd op 15/12/2012 17:04:43 door Moose -