[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