mysqli probleem

    • Dan is het nog de vraag wat verstandiger is: Voorborduren op de oude code, of gewoon van grond aan opnieuw beginnen.

      Dan kan je meteen een flinke opruiming houden in de code, en de code scheiden van HTML en PHP.

      Nogmaals: Het is zeker niet afkrakend bedoeld, maar een motivatie om je op het goede pad te brengen.

      Met de gegeven adviezen moet je al op pad komen om een betere code te bouwen.
    • Bedrijfsportaal wrote:

      Komt het niet bij je op dat je beter kan aangeven wat er mis mee is in fatsoenlijk geschreven tekst?
      Tot op zekere hoogte. Maar kijk eens naar het codefragment op de eerste pagina. Serieus, wtf is dit? Ik denk dat het mij minder tijd kost om iets nieuws te schrijven dan om uit te leggen wat hier allemaal aan mankeert.

      Er zijn situaties waarin nog recht te buigen valt wat krom is, en in sommige situaties is het gewoon beter om hier niet meer aan te beginnen. Dit project lijkt mij toch een beetje een gevalletje uit de laatstgenoemde categorie.

      Neemt niet weg dat dit een leerzame (doch redelijk nutteloze) exercitie kan zijn, maar daarbij moet je je wel goed realiseren dat ondanks het feit dat straks alles mogelijk "werkt" als je alles hebt omgeschreven naar de moderne uitvoering van verouderde functies en/of constructies, dat de algehele structuur van dit ding waarschijnlijk een complete incoherente gribus was, is en blijft.

      Bedrijfsportaal wrote:

      Je helpt hem totaal niet, je kraakt alles wat hij doet/probeert af en zegt "gooi in de prullenbak" .
      Dit zou ook mijn advies zijn. Van slechte code leer je meestal alleen hoe iets niet moet. Het hangt er ook maar net vanaf hoe je denkt een vragensteller te "helpen". Op het moment dat je een antwoord geeft heb je ook een zekere verantwoordelijkheid om te adviseren en niet alleen maar het kortste pad te tonen wat naar een directe oplossing voor het directe probleem leidt. Dat laatste is meestal wat gebeurt op forums. En daarmee help je mensen op weg op een verkeerd pad.

      Stel dat jij een huizenbeheerder bent en je staat op het punt om een of andere bouwval van de hand te doen. Zou je dan mensen adviseren om de muren maar een keer over te sauzen om het wat beter te laten ogen, of zou je ze toch beter kunnen adviseren om het pand maar om te trekken omdat er eigenlijk een direct en permanent instortingsgevaar dreigt?

      Post werd 1x aangepast, het laatst door FangorN ().

    • Ik neem aan dat je dus je code wilt omzetten van MySQL naar MySQLi?

      Als je niet echt veel ervaring hebt met code schrijven kun je een converter gebruiken.

      Nee ik zeg niet dat dit geheel veilig is, omdat deze gebruik maken van $GLOBALS maar, je kunt hiermee wel je code weer werkend krijgen op nieuwere versies van PHP :-)!

      github.com/philip/MySQLConverterTool

      Deze ergens uploaden (kan ook lokaal).
      Je maakt een map aan, plaatst daar je code in en via de converter kun je de gehele map laten converten (alle PHP bestanden).

      Maak wel een backup natuurlijk ;)


      Daar komt wel bij dat ik het met de rest eens ben. Als je de tijd en kennis hebt, raad ik je aan om het van de grond af opnieuw te bouwen, hiervoor kun je een framework gebruiken, maar dat hoeft niet.
    • @mugaru dit is mogelijk best een handige tool voor het werk wat het doet, maar lost andere (bijvoorbeeld de eerder genoemde) problemen niet op (denk aan algehele opbouw en werkwijze van pagina's / stukken code).

      Daarnaast bega je in zekere zin dezelfde "fout" opnieuw: vanaf PHP 7 is de oorspronkelijke MySQL-driver verdwenen, en hiermee alle mysql_* functies. Het is logisch dat als je dan met dezelfde codebase verder wilt dat deze functies vervangen moeten worden. Maar wat doe je dan als je deze tool gebruikt? Je verandert daarmee alle instanties van mysql_* naar een mysqli_* variant, mogelijk met extra of verwisselde parameters.

      Maar wat je hier wederom doet is hardcoding van de databaseoplossing. Dit zal natuurlijk altijd in zekere mate het geval zijn omdat en zolang je rechtstreeks (mogelijk database-specifieke) SQL in je code zet, en dus geen gebruik maakt van een Database Abstraction Layer (DAL). Toch valt er iets te zeggen om -op zijn minst- een Database Access Abstraction Layer (DAAL) te gebruiken. Want wie zegt dat er op den duur niet opnieuw dingen veranderen in MySQL-land?

      Het voordeel hiervan is een -weliswaar gedeeltelijke- ontkoppeling van specifieke database-gerelateerde functies en methoden zodat wanneer (niet als maar wanneer :)) er iets wijzigt, je -in het ideale geval uiteraard- enkel de implementatie van deze code hoeft te veranderen, en verder inhoudelijk geen letter applicatiecode hoeft aan te passen.

      Een ander voordeel is dat je dingen kunt vereenvoudigen en opdrachten kunt bundelen zodat je gemakkelijker kunt werken met de desbetreffende database. Dit bespaart je dus op den duur ook tijd.

      Wat ik in wezen voorstel is dat je, en eigenlijk iedereen die van plan is om met MySQL te werken, er verstandig aan doet om een soort van wrapper om je database-interactie te schrijven (maar misschien nog beter is een DAL uiteraard, omdat je daarmee dit helemaal loskoppelt van het gebruik. Dit is wel een tradeoff, het introduceert overhead, abstractie en complexiteit, en de vraag is of het dat waard is).

      Als je uitsluitend MySQL gebruikt is MySQLi eigenlijk de beste driver, omdat PDO niet geschreven is voor MySQL, daarvoor is de PDO_MYSQL driver, en daar zit een aanzienlijke brok configuratie die je goed onder de knie moet hebben voor foutvrije operatie. De vraag is ook, wanneer je PDO gebruikt, of je deze abstractie ooit echt nodig hebt. Als je nooit van plan bent om te schakelen van database in een applicatie (ik heb hier eigenlijk nog nooit van gehoord in applicaties) dan kun je net zo goed MySQLi gebruiken omdat deze expliciet is geschreven en geoptimaliseerd voor gebruik van MySQL.

      Deze wrapper dient uiteraard niet triviaal te zijn, simpelweg een soort van MyDB class bakken waarbij je vervolgens direct met een mysqli-object kunt werken is te kort door de bocht - dit stuk code moet echt werk uit handen nemen en daardoor een zekere meerwaarde creëren. Met dus als bijkomend voordeel dat je de omgang met je MySQL-database in afzondering van de rest van je code kunt behandelen.

      Het belangrijkste hier is eigenlijk dat je hardcoding (zoveel mogelijk) voorkomt en niet in herhaling treedt met wat in wezen al eerder misging.