[PHP/(My)SQL] voor dummies - Deel 76

quote:

Op donderdag 27 augustus 2009 12:58 schreef Swetsenegger het volgende:

[..]

35
[..]

eh sorry

Dat gezeik dat de jouwe korter is. I dont care. Als het maar doet wat het moet doen en duidelijk is.
Ik kan wel een compact script schijven van 10 regels en dat nu begrijpen. Maar ik moet het over een jaar nog steeds begrijpen als ik het weer in zie omdat er iets aangepast moet worden. Dan schrijf ik liever een duidelijk script van 20 regels wat ik na een jaar meteen weer snap door de duidelijkheid en nodige comments

quote:

Op donderdag 27 augustus 2009 13:00 schreef GlowMouse het volgende:
Ha ha, nu moet jij een nieuwe aanmaken.

Lol

tvp

quote:

Op donderdag 27 augustus 2009 12:58 schreef GlowMouse het volgende:

[..]

Beter: je returnt de data die je nodig hebt voor de output. Serieus, als ik zo'n script tegenkom als het jouwe dan begin ik liever opnieuw.

En Chandler: voorkom toepassen van functies op kolomnamen omdat dat niet indexeerbaar is.

Doel je op de date_format? kun je eens meer info geven?

@Swets; mijn class is bedoeld om de data uit te lezen en eventueel in te voeren, zo beknopt maar flexibel mogelijk. Meer heeft een poll eingelijk niet nodig.

bv.
UNIX_TIMESTAMP(date_started) < ....
omschrijven naar
date_started < FROM_UNIXTIME(...)

en
UNIX_TIMESTAMP(date_started) < NOW()
klopt niet eens: NOW() is geen unix timestamp.

quote:

Op donderdag 27 augustus 2009 11:38 schreef Swetsenegger het volgende:

Ik heb een vraagje. Ik heb een site die wat tweets naar twitter verstuurt. En i9n die tweets staat een euro teken. Nu doe ik dat met & euro; zodat ik een crossplatform euroteken krijg. Maar.... voor twitter zijn ook allerlei desktop applicaties en die zijn in de regel NIET webbased. En in plaats van een mooi teken zie die nu dus de html entity.

Zend dan gewoon het euroteken daadwerkelijk mee, maar dan heb ik het probleem dat een ¤ er op bv OSX of Linux er als æ ofzo uitziet.

Hoe krijg ik een cross platform, cross applicatie euroteken?

Twitter gebruikt UTF-8 (iig voor de website). Dan zou je dus zonder problemen ¤ moeten kunnen gebruiken en heb je geen html entity nodig.

quote:

Op donderdag 27 augustus 2009 10:34 schreef Chandler het volgende:
Mag ik commentaar op mijn class? wil nameljik leren en juist door te spelen leer ik dus.

PS ik gebruik mijn eigen mysql class, deze werkt nog niet middels PDO maar komt ooit nog
[ code verwijderd ]

Der zijn wel een hoop dingen die ik anders zou doen.
Ik ga het niet allemaal in 1 keer opneurien want heb wel meer te doen

Vandaag bij aflevering 1 van wat zou moozzie doen zullen we het hebben over je database.
Let op! Dit is wat ik zou doen, wil niet altijd zeggen dat het beter is.

Even voor de gemak jouw database erbij pakken



Jouw benaming vind ik dus ronduit bagger.
Het lijkt misschien leuk maar jij hebt in bijna elke tabel een 'id' veld.
Greaaat... dan krijg je dus dingen als dit (let op dit is je eigen query)


Nu krijg je dus tinyPoll.id, tinyPollAnswers.id etc.
En wil je die 2 velden ophalen moet je ze nog hernamen ook (tinyPollAnswers.id AS answer_id etc)

Dit is hoe ik je tabellen zou noemen



Note: ik hou er niet van om me tabellen aan elkaar te schrijven omdat als je dan een lijst hebt van 100 tabellen onder elkaar in phpmyadmin het best onoverzichtelijk lezen is. Ik doe er altijd een _ tussen als spatie wat een net iets overzichterlijker lijstje maakt in phpmyadmin. Je kan natuurlijk tinyPoll houden etc als je dat wilt. Dat is verders net zo goed. Waar het me in dit voorbeeld omgaat is de benaming van je velden en niet je tabellen.

Oke wat ik heb gedaan is voor elk veld de afkorting van de tabel gezet.
Het id van de tabel tiny_poll heet nu dus tpo_id

Als ik naar een record in de tabel tiny_poll wil refereren doe ik dus met xxx_tpo_id (xxx = de prefix van de tabel waar dit veld in staat)
De tabel tiny_poll_vote is een mooi voorbeeld.
tpv_tpi_id refereert naar tpi_id uit de tabel tiny_poll_votes_ip etc

Nu zou je query er zo uitzien



Wat vind ik de voordelen?
- Je hebt nooit dubbele velden
- Je hoeft niet de tabel naam op te schrijven als je dubbele velden hebt (zoals id bij jou)
- Het joinen van tabellen (tpa_tpo_id = tpo_id) is lekker makkelijk.
- Je kan elk veld selecten zonder dat je het hoeft te hernamen. Wat als gevolg dus heeft dat je overal in het script dus tpo_id kan gebruiken ipv dat je het in je ene script opslaat als poll_id en in je andere script als PollID.

Verders over je database
- Maak je int unsigned, dan kunnen ze langer mee en je votes, id etc kunnen toch niet negatief zijn
- Zelf ben ik meer van de Char dan varchar (waar kan, in combinatie met een text veld gaat dat natuurlijk niet) Char is inderdaad groter in vele gevallen maar je tabel blijft wel fixt length. Waardoor het zoeken dus sneller gaat

Als je dit al gemieren neuk vind laat ik me comentaar op je class wel achterwegen want dat wordt nog erger

Wat ids betreft zou ik consequent overal pollid,answerid en ipid gebruiken, maar afgezien daarvan zie ik het probleem niet.

>> Je hebt nooit dubbele velden
Zelfde veldnaam is zelfde data, geen probleem dus.
>> Je hoeft niet de tabel naam op te schrijven als je dubbele velden hebt (zoals id bij jou)
Alias
>> Het joinen van tabellen (tpa_tpo_id = tpo_id) is lekker makkelijk.
USING(id) is nog makkelijker
>> Je kan elk veld selecten zonder dat je het hoeft te hernamen. Wat als gevolg dus heeft dat je overal in het script dus tpo_id kan gebruiken ipv dat je het in je ene script opslaat als poll_id en in je andere script als PollID.
Zelfde veldnaam is zelfde data, geen probleem dus.

>> Zelf ben ik meer van de Char dan varchar (waar kan, in combinatie met een text veld gaat dat natuurlijk niet) Char is inderdaad groter in vele gevallen maar je tabel blijft wel fixt length. Waardoor het zoeken dus sneller gaat
En er minder in je geheugen past, waardoor het juist heel veel trager wordt.

quote:

Op donderdag 27 augustus 2009 13:43 schreef GlowMouse het volgende:
>> Zelf ben ik meer van de Char dan varchar (waar kan, in combinatie met een text veld gaat dat natuurlijk niet) Char is inderdaad groter in vele gevallen maar je tabel blijft wel fixt length. Waardoor het zoeken dus sneller gaat
En er minder in je geheugen past, waardoor het juist heel veel trager wordt.

Mwa dus totaal niet mee eens. Wij hebben hier tabellen met miljoenen records en hadden eerst varchar. De hele boel liep daarop vast omdat het dus dynamic tabellen werden. Door er fixt tabellen van te maken werd de tabel wel groter maar onwijs veel sneller.

quote:

Op donderdag 27 augustus 2009 13:48 schreef Swetsenegger het volgende:
Zoals hier wel weer uit blijkt is het ook een kwestie van smaak, want ik krijg dus jeuk van dit soort benamingen
[ code verwijderd ]

Als we het er dan toch over hebben dat je over een jaar terug leest, snap je in eerste instantie van dit soort afkortingen ook niets meer. ID's per tabel benoemen is met het oog op joins inderdaad wel duidelijker.

Het went vanzelf
Maar ik ga er niet over in discussie. Ik geef mijn vissie en als je het niets lijkt dan probeer je het toch niet

quote:

Op donderdag 27 augustus 2009 13:10 schreef GlowMouse het volgende:
bv.
UNIX_TIMESTAMP(date_started) < ....
omschrijven naar
date_started < FROM_UNIXTIME(...)

en
UNIX_TIMESTAMP(date_started) < NOW()
klopt niet eens: NOW() is geen unix timestamp.

Lol, ik gebruikte altijd unix_timestamp icm now() maar weet dat unix_timestamp nogal heerlijk sloom is qua functie...

dus zo zou het goed moeten zijn.


@Moozzie:
Bedankt voor je reactie, zelf vind ik jou opzet qua tabellen namen erg onoverzichtelijk, om overal maar een _ na te zetten. Je hebt wel een punt met tinyPoll_Answers etc...
Netzoals swets vind ik dat je een script over een jaar nog moet kunnen begrijpen, en in dit geval maakt het weinig uit welke namen de cellen hebben aangezien het script ze eenmalig uitleest en returned aan het script at deze class/functie aanroept. Verder zullen deze tabellen ook niet gebruikt worden anders dan via deze class.

Ook blijf ik kiezen voor varchar aangezien de velden die geinsert worden qua data niet veranderd gaan worden (ip, hostname, titel, antwoord(en) en comment) en denk dat het nogal scheelt als je 1000 votes per dag hebt.

Ik zou graag meer mierengeneuk zien op de class aangezien ik daar nog steeds niet erg handig in ben en vaak het nut en de logica er niet van snap

@GlowMouse:
Ben het dus ook aardig met jou eens m.b.t using en de tabel/cell namen

@Swets:

Dat heb ik dus ook, je moet eerst het gehele script doorlezen wil je weten waar welke afkorting voor staat

@Moozzie:

Graag zie ik meer van je visie; om zo mijn visie eventueel te versterken en of aan te passen (lijkt wel scripten zo )

[ Bericht 40% gewijzigd door Chandler op 27-08-2009 14:11:05 ]

quote:

Op donderdag 27 augustus 2009 13:48 schreef Swetsenegger het volgende:
Zoals hier wel weer uit blijkt is het ook een kwestie van smaak, want ik krijg dus jeuk van dit soort benamingen
[ code verwijderd ]

Eens.

Verder ben ik van mening dat je databasevelden moeten kloppen qua naam. Een veld met een ID noem je dus id, en niet weetikveelwat_id. Aangezien de ID in een tabel staat weet je al waar het om gaat. Ja, dan moet je het wel een je query fixen, so what?

In de praktijk maakt het weinig uit natuuriljk, net wat je gewend bent. Als het maar consequent is
In de ene tabel ID gebruiken en in de andere tabel TabelID is echt killing...

>> date_started =< FROM_UNIXTIME(NOW(), '%Y-%m-%d')
nee, het moet zijn date_started <= NOW()

>> Ook blijf ik kiezen voor varchar aangezien de velden die geinsert worden qua data niet veranderd gaan worden (ip,
ip kan (ipv6 buiten beschouwing latend) best in een int mbv INET_ATON

>> Wij hebben hier tabellen met miljoenen records en hadden eerst varchar. De hele boel liep daarop vast omdat het dus dynamic tabellen werden. Door er fixt tabellen van te maken werd de tabel wel groter maar onwijs veel sneller.
Had je een hoop updates? Het kan zijn dat je rijen gefragmenteerd werden. En als je varchar(255) gebruikte en nu char(100) omdat je wel op lengte let, maakt dat ook behoorlijk uit, bv als je in geheugen sorteert.

quote:

Op donderdag 27 augustus 2009 14:29 schreef GlowMouse het volgende:
>> date_started =< FROM_UNIXTIME(NOW(), '%Y-%m-%d')
nee, het moet zijn date_started <= NOW()

>> Ook blijf ik kiezen voor varchar aangezien de velden die geinsert worden qua data niet veranderd gaan worden (ip,
ip kan (ipv6 buiten beschouwing latend) best in een int mbv INET_ATON

>> Wij hebben hier tabellen met miljoenen records en hadden eerst varchar. De hele boel liep daarop vast omdat het dus dynamic tabellen werden. Door er fixt tabellen van te maken werd de tabel wel groter maar onwijs veel sneller.
Had je een hoop updates? Het kan zijn dat je rijen gefragmenteerd werden. En als je varchar(255) gebruikte en nu char(100) omdat je wel op lengte let, maakt dat ook behoorlijk uit, bv als je in geheugen sorteert.

Nope het ging fout bij de selects

na updates gaat het fout bij selects ja, bij rij-fragmentatie.

quote:

Op donderdag 27 augustus 2009 14:35 schreef GlowMouse het volgende:
na updates gaat het fout bij selects ja, bij rij-fragmentatie.

Nee de records werden niet geupdate
Er werden alleen inserts op uitgevoerd om um te vullen en selects om te bekijken. Maar de selects waren te traag. na de tabel fixt length te hebben gemaakt liep het gesmeerd

Tnx GlowMouse heb de aanpassingen doorgevoerd en blijkt goed te werken

Ik heb gelijk de functie createPoll en listPolls toegevoegd, weer een handige class voor mijn verzameling

quote:

Op woensdag 26 augustus 2009 10:11 schreef Swetsenegger het volgende:
Dan geef je toch een header('location:.'$_SERVER['PHP_SELF'].'); na het instellen van de sessie.

Ik neem aan dat deze voor mij bedoeld was. Begrijp alleen even niet wat je bedoeld

quote:

Op donderdag 27 augustus 2009 18:12 schreef Swetsenegger het volgende:

[..]

dat je de pagina een keer refreshed als je de sessie heb ingesteld

Dat is idd wel een oplossing, maar meer symptoombestrijding ipv probleemoplossend.

quote:

Op donderdag 27 augustus 2009 18:23 schreef Swetsenegger het volgende:

[..]

Nee dat is het niet. Cookies en Sessies (de laatste weet ik niet zeker) werken pas de volgende keer dat de pagina geladen wordt.

Hmm dat geeft weer ideeen Bedankt! Zal het sessoin verhaal wel verhuizen naar de index zelf aangezien de index minstens een keer moet reloaden voordat dit script wordt uitgevoerd.

Vind het echter wel raar dat het voor het hernoemen wel perfect werkte nadat ik ?random='.microtime(true). achter de src bij de image had gezet.

session_register niet meer gebruiken, is niet nodig.

En de eerste keer zou het al goed moeten gaan.

quote:

Op donderdag 27 augustus 2009 18:23 schreef Swetsenegger het volgende:

[..]

Nee dat is het niet. Cookies en Sessies (de laatste weet ik niet zeker) werken pas de volgende keer dat de pagina geladen wordt.

Bij sessies zeker niet; komt omdat je sessievars direct via de superglobal instelt.

quote:

Op donderdag 27 augustus 2009 18:38 schreef GlowMouse het volgende:
session_register niet meer gebruiken, is niet nodig.

En de eerste keer zou het al goed moeten gaan.
[..]

Bij sessies zeker niet; komt omdat je sessievars direct via de superglobal instelt.

Maar de eerste keer gaat het niet goed (heb nog geen tijd gehad om het een en ander naar index te verplaatsen, dus ik heb het nog over de oude situatie zoals die in de laatste post met code stond beschreven)... of komt dat doordat ik ook session_register nog een keer gebruik?

hier staat dus hoe ik een background img toevoeg.
maar wat nou als ik hem

1. niet herhalend
2. links midden uitgelijnd wil hebben

Hoe moet dat ?

Niet met PHP/MySQL.

quote:

Op donderdag 27 augustus 2009 18:23 schreef Swetsenegger het volgende:

[..]

Nee dat is het niet. Cookies en Sessies (de laatste weet ik niet zeker) werken pas de volgende keer dat de pagina geladen wordt.

Sessies niet, die kun je direct gebruiken.
Als je wilt dat ze als sessie bewaard blijven heb je wel output naar je browser nodig, anders gaan ze verloren. Gelukkig is daar session_write_close() voor, die kun je dus aanroepen voor een redirect, zodat je sessie bewaard blifjt

quote:

Op donderdag 27 augustus 2009 22:33 schreef GlowMouse het volgende:
Niet met PHP/MySQL.

Eujah moet ik mn eigen topic aanmaken dan?

quote:

Op donderdag 27 augustus 2009 22:49 schreef raaavi het volgende:

[..]

Eujah moet ik mn eigen topic aanmaken dan?

Je kunt het ook in het centrale 'ik ben zwanger'-topic posten natuurlijk, met dezelfde logica als dat je het hier postte.

quote:

Op donderdag 27 augustus 2009 22:49 schreef Xcalibur het volgende:

[..]

Sessies niet, die kun je direct gebruiken.
Als je wilt dat ze als sessie bewaard blijven heb je wel output naar je browser nodig, anders gaan ze verloren. Gelukkig is daar session_write_close() voor, die kun je dus aanroepen voor een redirect, zodat je sessie bewaard blifjt

Hij stuurt toch output? Session_write_close() heb ik echt nog nooit gezien ergens.

quote:

Op donderdag 27 augustus 2009 22:49 schreef raaavi het volgende:

[..]

Eujah moet ik mn eigen topic aanmaken dan?

css voor dummies: [CSS] voor dummies - deel 12

quote:

Op donderdag 27 augustus 2009 22:52 schreef GlowMouse het volgende:

Hij stuurt toch output? Session_write_close() heb ik echt nog nooit gezien ergens.

Ja, dat zou hier het probleem niet moeten zijn
Session_write_close gebruik ik standaard voor iedere redirect, just in case

@Moozzie: nog meer comments over m'n class?

Chandler, je gebruikt steeds date/time waarden en unix timespamp waarden door elkaar. Je moet of date/time waarden vergelijk of unix timestamps.
Dus als je een kolom als date definieerd, vergelijk 'm dan met CURDATE(), of NOW().
Als je een kolom als integer en je zet er timestamps in, vergelijk 'm dan met UNIX_TIMESTAMP().

Het prefixen van kolomnamen met een afkorting van de tabelnaam vind ik onzinnig. Alleen voor een PK id kolom is 't wel handig om er de naam van de tabel in te verwerken, maar gebruik die dan ook voor lalle kolommen die er naar verwijzen.

Probeer in ieder geval consequent te zijn. Ook in naamgeving, sommige namen zijn bij jou lowercase (votedate), andere camel case (tinyPoll) en sommige met underscores (date_started).

Wat is eigenlijk de gedachte achter de lengte van velden in machten van 2? Het ljikt me sterk dat het supergeoptimaliseerde waarden zijn. Gebruik dan ook gewoon lengtes van 50 of 100 tekens. Wel zomakkelijk, en minder vreemd voor een gebruiker. ('De titel mag maximaal 64 tekens lang zijn' )

@SuperRembo;

Ik zal het proberen te onthouden (alles over de dates)
En heb het script nu al aangepast op mijn nieuwe style testTestTest

Ennuh ja ik zal idd eens andere waarden gebruiken, maar 64/128 werkt zo fijn

session_start(); in de index erbij werkte ook niet (evenals de beide session_start(); bij het image.php en form bestand op de eerste regel zetten).

quote:

Op vrijdag 28 augustus 2009 18:38 schreef Chandler het volgende:
@SuperRembo;

Ik zal het proberen te onthouden (alles over de dates)

Je hoeft het niet allemaal te onthouden, je kan het makkelijk opzoeken.

quote:

Ennuh ja ik zal idd eens andere waarden gebruiken, maar 64/128 werkt zo fijn

Wat is er zo fijn aan 64 of 128

quote:

Op vrijdag 28 augustus 2009 17:30 schreef SuperRembo het volgende:
Het prefixen van kolomnamen met een afkorting van de tabelnaam vind ik onzinnig. Alleen voor een PK id kolom is 't wel handig om er de naam van de tabel in te verwerken, maar gebruik die dan ook voor lalle kolommen die er naar verwijzen.

Ben ik niet helemaal met je eens. Ik heb bijvoorbeeld heel vaak 'name', 'desc' en/of 'content' kolommen in verschillende tabellen. Als je deze tabellen gaat joinen dan moet je al gaan aliassen om de correcte kolom te kunnen benaderen in je code, of je moet in je daadwerkelijke query de hele tabelnaam als identifier mee gaan geven. Dan heb ik toch liever een kleine maar duidelijke prefix. Maar goed, da's weer een kwestie van voorkeur natuurlijk. Ik werk heel vaak met grote, relationele databases waar t.b.v. de normalisatie gebruik wordt gemaakt van een behoorlijk aantal stamtabellen. Ik moet er niet aan denken om dan op query-niveau te gaan aliassen.

Tevens TVP.

quote:

Op vrijdag 28 augustus 2009 21:36 schreef Tuvai.net het volgende:
Als je deze tabellen gaat joinen dan moet je al gaan aliassen om de correcte kolom te kunnen benaderen in je code, of je moet in je daadwerkelijke query de hele tabelnaam als identifier mee gaan geven. Dan heb ik toch liever een kleine maar duidelijke prefix.

ik heb dan weer een hekel aan luie programmeurs die de hele bende gaan afkorten
geef mij maar fijne aliassen en overzichtelijke namen

quote:

Op vrijdag 28 augustus 2009 22:38 schreef Xcalibur het volgende:

[..]

ik heb dan weer een hekel aan luie programmeurs die de hele bende gaan afkorten
geef mij maar fijne aliassen en overzichtelijke namen

Ik kort helemaal niks af, ik zet juist overal een prefix voor.

Aliasing is handig, maar totaal niet leuk meer in bijvoorbeeld een view waarin 20 tabellen gejoined of zo.

ik verdenk je ervan dat die prefix een afkorting is
Of dat je tabellen aliast met 1 letter

Grof gezegd is dit momenteel mijn form:



image.php:


Probleem blijft echter dat de eerste keer dat de pagina van de form bezocht wordt er nog geen text in het plaatje staat. Wel bij de print_r