Ik wil een rij verplaatsen van mijn ene tabel naar een andere(SQL).
Hij moet dus van pagina 1 naar pagina 2 en hij moet dan niet meer zichtbaar zijn op pagina 1.
Dit is wat ik nu allemaal heb:
Ik denk dat ik in deze 2 wat moet aanpassen 1 2
[quote="Thomas van den Heuvel op 27/07/2018 13:42:18"]
Stel dat je straks statistieken wilt genereren van deze informatie? "Hoeveel ruilverzoeken waren er, hoeveel zijn er geweigerd, hoeveel zijn er geaccepteerd". Je wilt dan toch niet dat je die informatie uit meerdere tabellen bij elkaar moet sprokkelen?
Ja maar dit hoef ik allemaal dus niet.
Het is gewoon een simpel systeem waar mensen een ruilverzoek kunnen doen en laten accepteren/weigeren door een manager.
Dan wordt na 1 week het verzoek verwijderd uit de tabel als hij is geweigerd. Waarom zou ik ruilverzoeken behouden, dat is hetzelfde als wanneer ik naar het restaurant bel en mijn ruilverzoek indien en zij zeggen: nee het ruilen kan niet. Dat ik dan tegen hun zeg: oh jammer, maar sla het wel op!!!
Dat is toch niet logisch.
Waarom zou je het behouden? Zodat je later nog eens statistieken kan uitdraaien.
Je weet nooit of je dat ooit nog eens nodig hebt. Zeg nooit 'nooit'.....
Later kan je er spijt van hebben dat je niet weet of je het afgelopen jaar meer of minder ruilverzoeken gehad hebt. Hieruit kan je prima rapportages opmaken of wijzigingen aan je site hebben bijgedragen aan een grotere conversie bijvoorbeeld. Zulke dingen wil je daarom al graag behouden.
Er zijn ook mensen die uit oogpunt van de grootte van de database vrezen dat de boel trager zou worden. Maar dat is allemaal schijn. De database van mijn website is momenteel al 40 MB en die van Tweakers is voor zover ik weet iets van 20 á 30 gigabyte.
Ik weet 1000% zeker dat ik die data niet nodig zal hebben.
Ik benadruk nog even:
Je weet nooit of je dat ooit nog eens nodig hebt. Zeg nooit 'nooit'.....
En lees even de rest daarna nog even. En wat kan het nou voor kwaad als je alles van de alle jaren opslaat? De overzichtelijkheid gaat echt niet verloren.
Of ik deze data nou zou willen of niet, dit is nog steeds niet het doel van mijn topic. Je kan constant hierover doorgaan, want het lijkt nu dat ik eigenwijs aan het doen ben, maar ik weet wat ik zeg.
Dus als je mij kan helpen met rijen overplaatsen naar andere tabellen dan hoor ik het graag. Het overige boeit mij niet op dit moment.
Ik en Thomas hebben al een goed gefundeerd advies gegeven en ik zelfs nog met een SQL-voorbeeld.
Ik raad het alleen niet aan, en raad je eerder aan dit even te overleggen met je PHP-expert als die terug is van zijn vakantie.
Maar stiekem ben ik nog best wel benieuwd naar je argumentatie waarom je alles niet wilt bewaren. ;-)
Maar geloof me, dit hierboven is het beste advies wat ik kan zeggen nu ik me al 12 jaar met PHP bezig houd.
Ik wil het niet bewaren, omdat er toch nooit terug naar gekeken zal worden.
De rooster van de vorige dag wordt weggegooid wanneer die niet meer nodig is, dus ruilverzoeken bewaren heeft dan ook geen zin.
Als je dat écht zo graag wilt, dan kan je de door mij geplaatste SQL-code voorbeeld prima gebruiken om de data over te hevelen. Je dient hem nog wel even aan te passen naar jouw situatie.
De rooster van de vorige dag wordt weggegooid wanneer die niet meer nodig is, dus ruilverzoeken bewaren heeft dan ook geen zin.
Als je geweigerde ruilverzoeken toch niet wilt bewaren, waarom zou je ze dan überhaupt naar een andere tabel willen overhevelen? Allemaal dubbel werk dat meer problemen introduceert dan oplost.
Ik zou inderdaad (zoals eerder gesuggereerd) gaan voor een statusveld om aan te geven dat een verzoek geweigerd is, gecombineerd met een mechanisme om regelmatig de records met status 'geweigerd' (en eventueel een datum die ouder is dan xxx dagen) te verwijderen uit de tabel. Of de gegevens gewoon laten staan. Nu worden de oude werkschema's nog weggegooid, maar woor hetzelfde geldt leest de manager volgende week een boek en vindt 'ie ineens dat alles anders moet.