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
Kan je jouw code even delen hier tussen de [code] en [/code] UBB-tags voordat je afbeelding niet meer werkt en zodat we eventueel delen van je code kunnen copy/pasten?
@Merdin K wat ik je in ieder geval zou aanraden is dat je dit soort operaties verder compartimenteert in aparte acties. Nu bestaat namelijk het gevaar dat dit verzandt in een brei spaghetti-code.
Ook zul je je queries wat veiliger moeten maken zodat deze niet vatbaar zijn voor SQL-injectie. Ik neem aan dat de pagina's waarin deze bewerkingen worden ge-include ook worden afgeschermd zodat niet iedereen deze zomaar uit kan voeren?
Na een header('Location: ...') hoort overigens bijna altijd een exit te staan, zoals hier wordt uitgelegd.
Ik weet niet precies waar die functionaliteit over gaat - ruilverzoeken van diensten? - maar is de naamgeving van de kolommen ook niet een beetje apart? Er staat "dienstvan" en "overgenomendoor", maar is dat niet meer zoiets als "eigenaar" en "geinteresseerde" (of "aanbieder" en "vrager")? De kolomnamen suggereren dat het al een voldongen feit is, terwijl het meer een voorstel is? Dan zou ik eigenlijk ook een historie verwachten van wie de dienst allemaal was, en een tabel met diensten met de huidige eigenaar?
Omdat dit een administratief systeem betreft en dit soort bewerkingen als ondeelbare acties uitgevoerd dienen te worden zou ik eigenlijk hier en daar ook het gebruik van transacties verwachten.
En omdat dit een administratief systeem betreft wil je misschien deze informatie ook bewaren, als je het (geweigerd) ruilverzoek verwijdert, dan "vernietig" je in zekere zin "bewijs" dat er ooit een verzoek is ingediend. Mogelijk is het een beter idee om zo'n tabel een soort van status-kolom te geven ("active" of "deleted" ofzo) waar je op kunt filteren (WHERE active = 1 of WHERE deleted = 0). Zo kun je altijd nog de "getuigen" van zo'n verzoek terugvinden, al zijn die niet direct op het scherm te zien. Wees spaarzaam in wat je permanent verwijdert, tenzij dit voor directe capaciteitsproblemen zorgt, uiteraard.
Kan je jouw code even delen hier tussen de [code] en [/code] UBB-tags voordat je afbeelding niet meer werkt en zodat we eventueel delen van je code kunnen copy/pasten?
Deze code zou dan een rij uit de tabel moeten verplaatsen
[size=xsmall]Toevoeging op 27/07/2018 12:31:57:[/size]
Thomas van den Heuvel op 27/07/2018 11:15:05
@Merdin K wat ik je in ieder geval zou aanraden is dat je dit soort operaties verder compartimenteert in aparte acties. Nu bestaat namelijk het gevaar dat dit verzandt in een brei spaghetti-code.
Ook zul je je queries wat veiliger moeten maken zodat deze niet vatbaar zijn voor SQL-injectie. Ik neem aan dat de pagina's waarin deze bewerkingen worden ge-include ook worden afgeschermd zodat niet iedereen deze zomaar uit kan voeren?
Na een header('Location: ...') hoort overigens bijna altijd een exit te staan, zoals hier wordt uitgelegd.
Ik weet niet precies waar die functionaliteit over gaat - ruilverzoeken van diensten? - maar is de naamgeving van de kolommen ook niet een beetje apart? Er staat "dienstvan" en "overgenomendoor", maar is dat niet meer zoiets als "eigenaar" en "geinteresseerde" (of "aanbieder" en "vrager")? De kolomnamen suggereren dat het al een voldongen feit is, terwijl het meer een voorstel is? Dan zou ik eigenlijk ook een historie verwachten van wie de dienst allemaal was, en een tabel met diensten met de huidige eigenaar?
Omdat dit een administratief systeem betreft en dit soort bewerkingen als ondeelbare acties uitgevoerd dienen te worden zou ik eigenlijk hier en daar ook het gebruik van transacties verwachten.
En omdat dit een administratief systeem betreft wil je misschien deze informatie ook bewaren, als je het (geweigerd) ruilverzoek verwijdert, dan "vernietig" je in zekere zin "bewijs" dat er ooit een verzoek is ingediend. Mogelijk is het een beter idee om zo'n tabel een soort van status-kolom te geven ("active" of "deleted" ofzo) waar je op kunt filteren (WHERE active = 1 of WHERE deleted = 0). Zo kun je altijd nog de "getuigen" van zo'n verzoek terugvinden, al zijn die niet direct op het scherm te zien. Wees spaarzaam in wat je permanent verwijdert, tenzij dit voor directe capaciteitsproblemen zorgt, uiteraard.
Dit alles wat jij aangeeft is binnen 3 tellen aan te passen. Maar ik vraag hier niet om. Mijn vraag is hoe ik ervoor kan zorgen dat er een rij van de ene tabel naar een andere tabel geplaatst kan worden.
Alvast bedankt.
Waarom zou Thomas geen (security-)feedback over je code mogen geven?
Je wilt toch niet dat mensen straks via een SQL-injection in jouw database gaan graven, terwijl je mogelijk zelfs een datalek moet aangeven bij de Autoriteit Persoonsgegevens? Wees blij dat Thomas je gewaarschuwd heeft en nog wat zinvolle tips gegeven heeft over je code.
Verder zie ik maar één tabel 'geweigerd' in beide codes. Dus wat valt er over te hevelen?
Zoals Thomas al zei. Waarom wil je dit eigenlijk?
Een ruilverzoek die geweigerd is, kan je toch prima flaggen als 'geweigerd'?
Ik zie vaak weinig redenen dat je data vanuit een ene naar een andere tabel wilt overhevelen. De entiteit (ruilverzoeken, of beter gezegd items of diensten) blijft immers hetzelfde, dus het kan prima in één tabel. Ik kan me wel indenken als je een tabel juist uit wilt splitsen t.b.v. een conversie tot een betere structuur van bijv. een één-op-één relatie naar een één-op-veel, dat je dit wilt doen. Maar daar is in dit geval geen sprake van, want het blijft één entiteit en dezelfde relatie.
Maar als je echt niet anders wilt, kan je het met een SQL-code zelf overhevelen. Een sample van de MySQL-site is hierbij:
INSERT INTO tbl_temp2 (fld_id)
SELECT tbl_temp1.fld_order_id
FROM tbl_temp1 WHERE tbl_temp1.fld_order_id > 100;
Er werken meer dan 80 personen in dit bedrijf. En er zijn in de whatsappgroep constant mensen die willen ruilen.
Ik wil het splitsen zodat er een duidelijk overzicht is.
Zo kunnen mensen zien, oh, mijn ruilverzoek is geaccepteerd. Top.
Of oh mijn ruilverzoek is geweigerd, waarom? De reden staat er dan bij. Dan wordt na 1 week deze verwijderd uit de tabel in de database.
Als ik nu in 1 tabel dit ga doen, komen er steeds de zelfde ruilverzoeken met alleen een andere naam bij 'overgenomen door'. En dit brengt chaos en geen overzicht.
Dus als je me aub een code kan sturen die dit doet, dan zou dat heel fijn zijn. Ik ben namelijk niet een expert in php etc en dit is de eerste keer dat ik zo'n systeem bouw. Het security gedeelte komt later nog, want ik ga dit laten nakijken door een php-expert. Alleen is het nu vakantie, dus kan ik daar niet in contact mee komen.
Je kan toch prima met een WHERE geweigerd = 0 voorwaarde alles selecteren wat niet geweigerd is. Of met een WHERE geweigerd = 1 wat wél geweigerd is. Een reden kan je prima in een veld plaatsen. Deze kan je zelf op NULL zetten. Of als je het luxer wilt: Een speciale tabel als de redenen vaak hetzelfde zijn, waarmee je een koppeling maakt.
Ik kan me niet indenken dat het een rotzooi wordt, of laat je mensen soms direct in je database-tool (phpMyAdmin) werken zonder een custom gebouwde GUI? Je kan zelf in de gebruikersomgeving prima de reden tonen als een item geweigerd is, en niet tonen als deze niet geweigerd is. Ik weet niet waar het allemaal precies om draait, maar je kan ook een tabel bijhouden met alle transacties met de mutaties. Dan kan je prima terughalen of iets al eerder is aangepast. Uiteraard komen transactions in MySQL om de hoek kijken.
maar ik blijf hierin geen reden vinden om alles over te hevelen naar een andere tabel. Ik denk dat je PHP-expert dat ook wel zult vinden. ;-)
Als ik nu in 1 tabel dit ga doen, komen er steeds de zelfde ruilverzoeken met alleen een andere naam bij 'overgenomen door'. En dit brengt chaos en geen overzicht.
Uit database-optiek snijdt dat meer hout dan records overhevelen van tabel A naar tabel B. Maak gewoon een status-kolom aan op een of andere manier... 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?
Dit lijkt mij sowieso ff een moment om na te denken over wat je volgende stap(pen) zijn in plaats van alles er in lopen te hakken en later tot de conclusie te komen dat je toch in de eerderegenoemde chaos terecht bent gekomen.
Dus als je me aub een code kan sturen die dit doet, dan zou dat heel fijn zijn. Ik ben namelijk niet een expert in php etc en dit is de eerste keer dat ik zo'n systeem bouw.
Reden te meer om na te denken over wat je doet.
Het security gedeelte komt later nog, want ik ga dit laten nakijken door een php-expert. Alleen is het nu vakantie, dus kan ik daar niet in contact mee komen.
Zodat hij nog eens dunnetjes kan overdoen wat je nu doet? :/
Zelf zou ik lekker vakantie nemen, en de PHP-expert straks het werk laten doen. Of je vakantie te gebruiken om zelf lekker te hobby'en om PHP te leren kennen, zonder te werken aan deze toepassing in productieomgeving. Je wilt immers je PHP-expert niet opzadelen met diverse fouten en onvolkomenheden die jij tijdens zijn vakantie geprogrammeerd hebt.
Ik zou er zelf overigens niet blij van worden als ik in zijn huid zou kruipen. ;-)
