"Best practice" Gebruikers profiel updaten MYSQL, PHP, ...

[Verwijderd]

- Moet natuurlijk "Best Practice" zijn -

Hi,

Ik zit er al een tijdje mee te struikelen dus vond ik het tijd de vraag even te stellen aan personen die ook veel bezig zijn met ontwikkeling.

Stel je volgende situatie eens voor:

Klant registreert zich op een website geeft al zijn persoonlijke gegevens in (NAAM, VOORNAAM, TEL.NR., EMAIL, WOONPLAATS, LEEFTIJD, ...) Na een tijdje klopt zijn woonplaats niet meer en moet enkel zijn WOONPLAATS aangepast worden, mijn vraag gaat hierover... Hoe doe je dit nu het best?

Voorbeeld code:

PHP:

<?php    
   $userquery = $db->prepare("SELECT * FROM users");    
   $userquery->execute();    
   $userrow = $userquery->fetch(PDO::FETCH_ASSOC)
?>
      <div class="row">
         <div class="col-lg-6">
            <h5><?php echo htmlspecialchars($userrow['user_name'], ENT_COMPAT, 'UTF-8'); ?></h5>
         </div>    
         <div class="col-lg-6">
            <input type="text" name="<?php echo $userrow['user_name']; ?>" class="form-control" />
         </div>
      </div>     
      <div class="row">
         <div class="col-lg-6">
            <h5><?php echo htmlspecialchars($userrow['user_city'], ENT_COMPAT, 'UTF-8'); ?></h5>
         </div>    
         <div class="col-lg-6">
            <input type="text" name="<?php echo $userrow['user_city']; ?>" class="form-control" />
         </div>
      </div> 

Wat heb ik al gedaan:
1.
Ik heb mijn input veranderd naar dit

PHP:

<input type="text" name="<?php echo $userrow['user_city']; ?>" class="form-control" value="<?php echo $userrow['user_city']; ?>"/>

- Namelijk een value aan gekoppeld die hij uit mijn query haalt en als er geen veranderingen gebeuren en ik doe een submit dan controleert hij eerst of de value gelijk is en indien niet zal hij een update uitvoeren. Nadeel = veel code en nogal omslachtig volgens mij.

2.
submit knoppen naast ieder veld geplaatst en dan bovenaan in mijn php code een controle gedaan welke submit ingedrukt geweest is en dan ook nog eens een controle gedaan of de value weldegelijk veranderd is geweest. Nadeel = terug veel code maar iets overzichtelijker.

Mijn vraag van hierboven komt hier nu terug. Hoe lossen jullie dergelijk iets op? Werken jullie hier misschien met jQuery en Ajax? of is er een gouden tussenweg in PHP?

Bedankt om jullie werking te delen!

[stijnhau]

En waarom zou je niet alle gewoon mee updaten?
nu check je of het hetzelfde is of niet.
Ik persoonlijk zie het nut van deze 'conrole' niet.
Oke je database moet minder werken maar je moet wel eerst zelf controle doen.
Laat je database doen waar die goed is is en bespaar jezelf werk.

[P.O. Box]

volgens mij voegen die controles weinig toe. je database doet dezelf ook al controles namelijk. Doe maar eens een update tabel set name="A" where name = "A". De workbench geeft dan iets terug van: 1 row involved, 0 rows changed.
weet eerlijk gezegd niet wat hij in zo'n geval met timestamp velden doet maar dat kun je eenvoudig testen.

[EnnaN]

Een van de redenen die ik wel eens gehoord heb om te controleren is dat je geen 'regressie' wil in data, als in: iemand verwijdert z'n achternaam, en dat wil je dan natuurlijk niet zomaar opslaan: je controleert dus op 'zinnige' veranderingen.

Dat is in mijn ogen overigens geen goede redenatie: je doet validate, en als de data daar aan voldoet, dan sla je alles op, simple as that.

[Gomez12]

@EnnaN : Als je regressie wilt voorkomen dan kan je beter helemaal geen updates toestaan maar enkel inserts en 1 extra veldje erbij : Actief.

Dan sla je gewoon meerdere records op en applicatie technisch gebruik je enkel de actieve (of laatst opgevoerde) en mocht iemand dan zijn achternaam weggooien dan kan je handmatig in de oude records kijken wat het was en of je het terug wilt zetten.

[Verwijderd]

Wel dat zijn mij direct 3 antwoorden waarop ik zeker iets mee ben! Bedankt hiervoor!

Ik weet dat het amper scheelt als ik nu 1 veld update of gewoon alles maar ik ben nogal een "less resource" man en wou het gewoon doen zoals het eigenlijk hoort met zo weinig mogelijk resource verbruik zo correct mogelijk te werk gaan (al mijn websites draaien namelijk op een eigen redelijk duur aangekochte server).

Ik ben iemand die wel degelijk kijkt of er geen spatie teveel staat waardoor een "bit" onnodig gebruikt wordt dus kan dit mijn vraag wel verklaren. Natuurlijk ben ik niet goed bezig door veel code te gebruiken en te controleren of de velden wel effectief upgedate zijn en daarom mijn vraag hierboven of het niet korter kon )

[ Voor 4% gewijzigd door Verwijderd op 17-02-2015 09:05 ]

[Fish]

Ik ben van de soft deletes. dus compleet nieuwe row aanmaken met de juiste data, en de oude vlaggen als deleted. Zo hou je je historie intact

[ Voor 11% gewijzigd door Fish op 17-02-2015 09:09 ]

[Verwijderd]

Fish schreef op dinsdag 17 februari 2015 @ 09:09:
Ik ben van de soft deletes. dus compleet nieuwe row aanmaken met de juiste data, en de oude vlaggen als deleted. Zo hou je je historie intact

Met andere woorden je maakt dynamisch een nieuwe tabel erbij en renamed de oudere met prefix old_, old_1, old_2, ... ?

[Fish]

Nee

Je voegt een kolom toe aan je huidige tabel "Deleted" en een tijdstip is ook wel een pre "TimeInserted" en/of "TimeDeleted"

Wanneer er iets aangepast wordt zet je bij de originele row de deleted flag aan. en maak je een nieuwe row.
Je moet hier natuurlijk wel al je queries op aanpasssen. Maar een goeie basis is wel een pre

[Janoz]

Verwijderd schreef op dinsdag 17 februari 2015 @ 09:03:
Ik weet dat het amper scheelt als ik nu 1 veld update of gewoon alles maar ik ben nogal een "less resource" man en wou het gewoon doen zoals het eigenlijk hoort met zo weinig mogelijk resource verbruik zo correct mogelijk te werk gaan (al mijn websites draaien namelijk op een eigen redelijk duur aangekochte server).

Euhm, 1x data ophalen en vervolgens controleren wat er aangepast moet worden en vervolgens een enkel veld aanpassen is niet minder resources dan gewoon alles aanpassen, ondanks dat er misschien wel helemaal geen wijzigingen tussen zitten .

Verwijderd schreef op dinsdag 17 februari 2015 @ 09:22:
[...]


Met andere woorden je maakt dynamisch een nieuwe tabel erbij en renamed de oudere met prefix old_, old_1, old_2, ... ?

Geen nieuwe tabel, maar een nieuwe row. Alhoewel ik zelf nooit het audittrail en de live data in dezelfde tabel zou bijhouden.

[Verwijderd]

Ok duidelijk genoeg. Bedankt voor de tips!

[Cartman!]

Eens met Janoz, logs bijhouden van data kan soms nuttig zijn maar doe dat lekker in n losse tabel. Ik gebruik er Gedmo Versionable voor, een extension voor Doctrine 2, werkt erg relaxt

[BLACKfm]

ik vind het maar een hoop gemits en gemaar voor een actie die zelden wordt uitgevoerd.

Of je website draait om profielen, maar anders zou ik me niet druk maken om een paar 'bits' meer of minder.

Daarbij zou ik het als gebruiker niet op prijs stellen als je mijn profielgeschiedenis bijhoud wat een beveiligingsrisico is.

Wat heb je er als beheerder aan dat je ziet wat iemands oude adres is (of wat er dan ook veranderd is)?

[ajakkes]

Waarom wil je mijn typefout jarenlang bewaren? Lijkt me nogal wat onnodige bits.

Misschien wil je onthouden met welke woonplaats ik een bepaalde actie heb uitgevoerd, maar zonder tussentijdse actie kan je de wijzigingen best vergeten.

Als de input niet gewijzigd is kan je dus best opslaan. Als de input leeg is misschien niet maar dat is een keuze.

[ Voor 1% gewijzigd door ajakkes op 22-02-2015 19:12 . Reden: gramm fout ]

[Fish]

ajakkes schreef op zondag 22 februari 2015 @ 19:11:
.....

edit:
ajakkes wijzigde deze reactie 22-02-2015 19:12 (1%)
Reden: gramm fout

Kun je ook aan tweakers vragen , omdat het soms handig is, en vaak onnodig
kan iig dicussies voorkomen

[Janoz]

BLACKfm schreef op zaterdag 21 februari 2015 @ 21:55:
Wat heb je er als beheerder aan dat je ziet wat iemands oude adres is (of wat er dan ook veranderd is)?

Voor een profielensite is het inderdaad nogal overdreven. Er zijn echter situaties waarin dit wel van belang is. Echter moet er dan wel onderscheid gemaakt worden tussen twee verschillende histories.

Als eerste heb je het audittrail. Daarin hou je je eigen wijzigingen bij. Daarin weet je dat je vorige week A als woonplaats in de database had staan terwijl dat vandaag B is. Erg handig wanneer een klant klaagt dat zijn verzending van vorige week helemaal niet bij B aangekomen is. Dan kun jij zien dat je op dat moment een ander adres opgeslagen had.

Het audittrail is de registratie van hoe je opgeslagen data door de tijd veranderd. Je hebt echter ook de werkelijkheid. Dit sla je op als temporal properties. Dat is eigenlijk de modellering van de werkelijkheid. Als jij over 2 weken gaat verhuizen dan is vanaf die dag je adres anders.

Dit alles is best ingewikkeld en zeker voor een profielensite complete overkill. Echter moet men goed beseffen dat dit twee verschillende dingen zijn. Bij het GBA is het bijvoorbeeld al een stuk belangrijker (en daar hebben ze het vervolgens NIET goed gedaan. Hopelijk wordt het beter met de BRP)