Review GUI + Data model

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Pagina: 1 2 volgende »

Mark PHP

Mark PHP

04/06/2008 16:18:00
Quote Anchor link
Momenteel ben ik bezig een voetbal(statistieken) site te maken. Ik ben hier al een tijdje mee bezig en het vorderd gestaag, en ik vind het tijd geworden om wat commentaar te krijgen op wat ik tot nu toe gedaan heb.

GUI
Allereerst, de GUI (Graphical User Interface). Aangezien ik nog niet alles in XHTML en CSS heb staan, zullen jullie het moeten doen met wat screenshots. Ik zou graag willen weten wat jullie vinden van onder andere het kleurgebruik, positionering en algemene indruk. De 4 screenshots:
klik #1
klik #2
klik #3
meest recente versie
De vierde afbeelding bevat nog een layer onder de footer, dit is een layer die bijvoorbeeld in de linker- of rechterbalk gepositioneerd kan worden.

Ik snap dat er nog vrij weinig content op de site te vinden is, maar dit komt later nog. Momenteel is elk commentaar op wat ik tot nu toe heb zeer welkom.

Data model
Natuurlijk hoort er een database achter een systeem als dit. Ik heb deze al ontworpen, volgens mij klopt 'ie aardig (qua normalisatie etc.). Voor het gemak heb ik even een schemaatje gemaakt: klik!
De veldtypes heb ik hier weggelaten (behalve bij Enumerated). Volgens mij zijn de types in orde, id's zijn INT, date(time) DATE(TIME) en verder nog vanzelfsprekende velden als title (VARCHAR) en content (TEXT).
Het gaat mij dus meer om het relationele gedeelte. Ook elk commentaar is hier welkom.

Het is een beetje lang verhaal geworden, maar ik hoop dat ik wat (beargumenteerde) commentaren binnenkrijg, zodat ik er wat mee kan. Voor een overzicht van het project zelf, check het eerste project op m'n site: klik!
Bvd!
Gewijzigd op 01/01/1970 01:00:00 door Mark PHP
 
PHP hulp

PHP hulp

15/07/2024 14:24:05
 
Huig

huig

05/06/2008 21:41:00
Quote Anchor link
Voor dat ik begin: als je verwacht dat je site veel bekeken word denormaliseer de boel, normalisatie is imho ouwe meuk van vroeger.

Je ontwerp:
De 2e prefereer ik. Waarom, omdat je je niet veel verschillende kleuren gebruikt.

Bij de andere heb je groen en blauw gebruikt. Ik vind dat verloopje met dat code achtige font(de header) niks. De site moet meer spreken vind ik. Doe een beetje inspiratie op bij andere foe-bal statestieken sites, kan je een hoop uithalen.
Op http://www.defencemechanism.com/color/ is een handig tooltje voor kleurgebruik. Ik gebruik het vaak, gewoon omdat het lekker makkelijk is.

Succes!
 
- -

- -

05/06/2008 21:58:00
Quote Anchor link
Normaliseren heeft niets met de UI interface te maken, puur met de database. Aan je reactie te horen weet je dus totaal niet waarover je spreekt. Natuurlijk moet je normaliseren!

Over die lay-out: begin eens opnieuw, dit spreekt echt niet aan...
 
Robert Deiman

Robert Deiman

05/06/2008 22:13:00
Quote Anchor link
Ik heb niet je hele schema bekeken, maar ik zie dat je bij de competities aangeeft wat voor type een club is. Een club is altijd OF een nationaal elftal, OF een clubteam. Deze informatie zet je dus bij het team.

Een status zou ik ook een tabel van maken, dus niet met ENUM werken daar. Je hebt nu "gestaakt", "afgelast", "uitgesteld". Je database wordt sneller en kleiner op het moment dat je dit koppelt via een andere tabel. Misschien gebeurt er ook ooit iets waar je geen rekening mee gehouden hebt. Dit is dan ook eenvoudig toe te voegen.

Ook formats zou ik echt in een aparte tabel droppen, en een koppeltabel maken. De competitie "champions league" heeft zowel een competitie als knockoutfase, en ook nog verschillende pouls. Dit zou je ook in je datamodel moeten verwerken.

Kortom: Loop je hele datamodel nog eens door, zorg dat de juiste gegevens in de juiste tabel staan, probeer redundantie te voorkomen, door dan maar wat meer tabellen te maken, maar alleen een id opslaan (en opzoeken) is sneller dan de hele naam elke keer opslaan. (In jou gevallen de ENUM velden)

Qua GUI, moet je echt nog wel wat aan doen. Zorg ervoor dat eruitspringt dat het over voetbal gaat, zorg voor een goed en duidelijk kleurgebruik, en ook dat het niet te druk wordt.
 
Hipska BE

Hipska BE

05/06/2008 22:21:00
Quote Anchor link
Ik zal enkel over het datamodel iets vertellen omdat ik niet zoveel van design ken.

1) Bij events lijkt het mij overbodig om nog een clubid in te vullen als je toch al een spelerid hebt, welke maar bij 1 club hoort (of ik snap iets niet van voetbal dat een andere club rode kaart zou kunnen krijgen bv.)

2) je tabel competitions snap ik niet helemaal. er wordt gelust merk ik, maar ik denk niet dat het helemaal genormaliseerd is. (graag wat meer uitleg aub)

3) nogal verwarrend dat je voor competitionid en countryid beide de naam 'cid' gebruikt, hier zal je hoogstwaarschijnlijk fouten mee maken ooit.

voor de rest mooi model ;)
 
Frank -

Frank -

05/06/2008 22:32:00
Quote Anchor link
huig schreef op 05.06.2008 21:41:
Voor dat ik begin: als je verwacht dat je site veel bekeken word denormaliseer de boel, normalisatie is imho ouwe meuk van vroeger.
Inderdaad, vroeguh liepen er nog mensen met kennis en kunde rond...

Hoeveel problemen wil je hebben? Wanneer je niet gaat normaliseren, ga dan ook geen database gebruiken, dat wordt dan toch niks. Of is een snelle corrupte database handiger dan een (mogelijk) iets langzamere die wél werkt?
 
Jurgen assaasas

Jurgen assaasas

05/06/2008 22:40:00
Quote Anchor link
Heb je dat datamodel met een proggie gemaakt of gewoon in photoshop? Ik zoek nog een mooi tooltje daarvoor. Verder, het datamodel ziet er goed uit en er aan te zien dat je er genoeg kennis van hebt dus daar zul je niet zomaar op stuk lopen, de layout vind ik echter niet echt mooi te veel gradient en een beetje saai. Probeer eens een wat modernere site te maken of laten maken, zelf ben ik ook niet zo'n designer dus ik laat dat doen :)
 
Marien xD

Marien xD

05/06/2008 23:45:00
Quote Anchor link
Als ik zo naar het geheel kijk krijg ik de indruk dat je meer een coder bent dan een designer. Ik mag je stijl wel hoe je projecten aanpakt, alleen hier en daar klopt er nog iets niet.

Design is zo te zien niet echt je sterkste punt. Doe het dan op de manier zoals heel veel mensen het doen: beter goed gejat dan slecht verzonnen. Oftwel ga niet opnieuw het wiel uitvinden. Kijk naar andere sites. Kijk hoe die het doen.

Nog een aanmerking op je 'portfolio' website, ik weet niet of jij het zo noemt ;). Maar bepaalde zinnen kunnen echt niet. Kijk ze nog even na, of gooi ze in de Engelse grammatica controle :)

Verder goed bezig! Probeer voor jezelf het design niveau omhoog te schroeven dan kom je er wel :)
 
- -

- -

06/06/2008 06:26:00
Quote Anchor link
Hipska schreef op 05.06.2008 22:21:
1) Bij events lijkt het mij overbodig om nog een clubid in te vullen als je toch al een spelerid hebt, welke maar bij 1 club hoort (of ik snap iets niet van voetbal dat een andere club rode kaart zou kunnen krijgen bv.)
Deels snap je het misschien niet, een speler kan namelijk naast zijn gewone club ook in een nationaal elftal zitten. Daarnaast kan een speler getransferd worden, maar je wil je data nog wel heel houden, dus daar zul je toch iets op moeten bedenken...
 
Hipska BE

Hipska BE

06/06/2008 08:34:00
Quote Anchor link
@Jonathan: maar het id van de match staat er dan toch ook al bij? via daar weet je welke club het was en waar die speler toen bij hoorde.

Ik zie dat je niet rekening houdt met transfers idd (tenzij die teamid bij events daarvoor bedoeld was)
 
Huig

huig

06/06/2008 10:56:00
Quote Anchor link
Jonathan schreef op 05.06.2008 21:58:
Normaliseren heeft niets met de UI interface te maken, puur met de database. Aan je reactie te horen weet je dus totaal niet waarover je spreekt. Natuurlijk moet je normaliseren!

Over die lay-out: begin eens opnieuw, dit spreekt echt niet aan...

Jonathan, ga is even lezen... Tuurlijk weet ik dat normaliseren niks te maken heeft met de GUI, maar agirre begon er zelf over. Bovendien had ik het erover of hij een enorme site gaat maken en dan moet je zeker denormaliseren. Heb je het Twitter verhaal gehoord?
http://fox.wikis.com/wc.dll?Wiki~SpecificReasonsToDenormalize~SoftwareEng
http://mjtsai.com/blog/2008/05/22/denormalize-to-scale/
http://www.sqlteam.com/article/denormalize-for-performance
http://www.slideshare.net/al3x/scaling-twitter-railsconf-2007/
(lees vooral de laatste maar even, de slide van de makers van twitter over hoe ze de boel hebben geoptimaliseerd)
Beste jonathan, stop dus gelijk met oordelen en wacht daarmee tot je meer ervaring hebt, maar hier leer je ook weer van;-).
 
Frank -

Frank -

06/06/2008 11:11:00
Quote Anchor link
huig schreef op 06.06.2008 10:56:
Bovendien had ik het erover of hij een enorme site gaat maken en dan moet je zeker denormaliseren. Heb je het Twitter verhaal gehoord?
http://fox.wikis.com/wc.dll?Wiki~SpecificReasonsToDenormalize~SoftwareEng
http://mjtsai.com/blog/2008/05/22/denormalize-to-scale/
http://www.sqlteam.com/article/denormalize-for-performance
http://www.slideshare.net/al3x/scaling-twitter-railsconf-2007/
(lees vooral de laatste maar even, de slide van de makers van twitter over hoe ze de boel hebben geoptimaliseerd)
Er zijn nog andere manieren om je database te optimaliseren, daarvoor hoef echt niet te denormaliseren.

Ik heb gisteren nog even aangetoond dat slimme queries een héél stuk sneller zijn! Wat normaal in 70 uur (!!!) werd ingevoerd, deed ik binnen 5 minuten.

Daarnaast zou je ook gewoon voor een snelle database kunnen kiezen, wanneer je voor MySQL kiest, kies je daar duidelijk niet voor. Een database die niet (goed) met multicore processors uit de voeten kan, daar heb je weinig aan wanneer je veel performance nodig hebt. Dat heeft niets met een datamodel te maken, dat is allemaal native performance.

Denormaliseren doe je pas wanneer je problemen hebt die niet op een andere manier zijn op te lossen. Dankzij de overvloedige aanwezigheid van onkunde, is het voor veel prutsers echter de enige oplossing/workaround, ze hebben geen idee hoe ze indexen, cache, etc. moeten toepassen.

Edit: En inderdaad, die presentatie gaat over een MySQL-database die niet vooruit is te branden. 8 cores, leuk en aardig, maar daar doet MySQL dus niets mee. 200 tot 300 connections? Dat wordt dus één grote rij wachtenden, daar kan MySQL namelijk niet goed mee uit de voeten.

Zie ook deze serie artikelen: Tweakers.net. Hier wordt hun zwaar geoptimaliseerde MySQL-database vergeleken met een eenvoudig opgezette PostgreSQL-database met dezelfde data. PostgreSQL rent rondjes om MySQL... Wanneer je de pgSQL-database dan ook nog eens gaat optimaliseren, dan wordt het verschil helemaal idioot groot. Maar goed, dan zul je even een DBA aan het werk moeten zetten, dat viel buiten de scope van hun tests.
Gewijzigd op 01/01/1970 01:00:00 door Frank -
 
Mark PHP

Mark PHP

06/06/2008 11:38:00
Quote Anchor link
Om te beginnen, iedereen bedankt voor de reacties.

Allereerst, zoals terecht opgemerkt, ben ik (veel) meer coder dan designer. Ikzelf vond de GUI er wel aardig uitzien, afgezien van de gradient, die beviel mij zelf ook niet. Mijn voornaamste inspiratiebron is hier te vinden. Ik zal er nog eens goed naar kijken, maar het blijft gewoon niet mijn sterkste kant.

@Robert_Deiman
Ik geef bij de competitie aan wat voor type de competitie is, met teamclubs of met nationale teams. Indien het type club 1 is, zal ik in PHP een JOIN maken met de tabel teams, anders met de tabel countries. Dat is het idee erachter.
EDIT: ik heb hier even over nagedacht, er komt dan een probleem met de FK op 'home' en 'away', deze verwijzen nu naar teams, maar dat klopt in sommige gevallen dus niet. Maar hier twee dezelfde tabellen voor één verschil maken staat me ook niet aan.

Die aparte tabellen voor status en formats zit inderdaad wel wat in, daar zal ik even naar kijken. Het competitiemodel ben ik zelf ook nog niet echt uit wat het handigst is, op het moment gaat het als volgt:
- een hoofdcompetitie wordt aangemaakt (bv. Champions League)
- childcompetities worden aangemaakt (bv poule A met type comp, semifinals met type knockout). Dit kan onbeperkt diep gaan.

@Hipska
Gisteren heb ik de event table sowieso al aan de lineup table gelinkt, immers een speler die scoort staat altijd in de lineup.
De mogelijkheid om bij te houden welke clubs een speler allemaal heeft gehad, is in dit model onmogelijk, ik houd per speler slechts bij wat de meest recente club is. Ik besef mij nu dat dit totaal niet past bij een statistiekensite, ik zal het vanmiddag aanpassen. De kolom 'tid' kan dan ook verdwijnen. De 'cid' naamgeving zal ik ook even aanpassen.

@Jurgen
Ik schaam het om te zeggen, maar ik heb het gewoon met Excel gemaakt:P. Aangezien ik recentelijk colleges Database op de VU heb gehad waar de opmaak er zo uitzag, heb ik dit overgenomen.

@Marien
Die 'portfolio'-website heb ik in één middag online geknalt, ik zou het inderdaad eens rustig over moeten lezen.

@pgFrank
Over PostgreSQL zit ik na te denken, ik ken de nadelen van MySQL. Desondanks houd ik het voorlopig bij MySQL, of ik zet beide databases naast elkaar om met beide compatible te blijven.

Ik hoop weer wat reacties te krijgen.
Gewijzigd op 01/01/1970 01:00:00 door Mark PHP
 
Frank -

Frank -

06/06/2008 11:47:00
Quote Anchor link
Jurgen schreef op 05.06.2008 22:40:
Heb je dat datamodel met een proggie gemaakt of gewoon in photoshop? Ik zoek nog een mooi tooltje daarvoor.

Clay Database Modeling, bevalt mij uitstekend. (Eclipse op OSX-gebruiker)
 
Jurgen assaasas

Jurgen assaasas

06/06/2008 12:45:00
Quote Anchor link
Ik heb de plugin geinstalleerd in Eclipse maar ik moet persee een connectie maken terwijl ik gewoon een opzet wil maken voor iets.
 
Joren de Wit

Joren de Wit

06/06/2008 12:56:00
Quote Anchor link
Wat betreft je datamodel, daar moet je nog wel even goed over nadenken. Zo heb je bijvoorbeeld een tabel 'substitutes', maar dit is eigenlijk ook gewoon een 'positie'. Ok niet in het veld, maar een bankzitter behoort ook tot het team.

In de lineups tabel heb je zeker een aparte tabel nodig voor de verschillende posities. Denk ook aan verschillende opstellingen (4-3-3, 4-4-2, etc) die je kunt spelen. Die mogelijkheid moet je zeker inbouwen.

Verder mis ik een tabel 'clubs'? Een team is vaak (maar niet per se) onderdeel van een club. Zo niet dan heb je dus bijvoorbeeld een competitie tussen nationale teams of bijvoorbeeld een competitie tussen vrienden teams. Dit bepaal je uiteraard niet via een kolom in de competities tabel, maar laat je afhangen van waar een team onderdeel van is.

Ook laat jouw huidige datamodel nog niet toe dat een speler in meerdere teams (e.g. club en nationaal) speelt. Een koppeltabel zul je hier echt nodig hebben.

Verder heb je ook nog geen rekening gehouden met transfers? Door eenvoudig in de koppeltabel van teams en spelers twee datumstempels op te nemen kun je precies zien wanneer een speler in een team kwam en wanneer hij eruit ging.

Ik heb even een opzetje gemaakt. Uiteraard zul je dit model nog verder aan willen passen en uit willen breiden met alle gegevens die jij erin wilt hebben, maar het geeft je een idee hoe je zoiets aan zou kunnen pakken.

Afbeelding
 
Arend a

Arend a

06/06/2008 13:12:00
Quote Anchor link
Beste Huig,

doorgaans geld de vuistregel dat als je geen nerd bent met 2cm dikke glazen je gewoon moet normaliseren. Maar even zonder grappen:


Twitter is een zeer uitzoderlijk geval natuurlijk. De vrienden wisten van gekheid niet wat ze moesten doen, en dus hebben ze maar een ontzettend lelijke hack uitgevoerd zodat het ietsje sneller gaat.

De volgende links:
http://fox.wikis.com/wc.dll?Wiki~SpecificReasonsToDenormalize~SoftwareEng
http://www.sqlteam.com/article/denormalize-for-performance

Stellen het volgende:
Wanneer je erg veel joins nodig hebt om een factuur samen te stellen, en je hebt het erg vaak nodig, overweeg om het de dupliceren. Dupliceren wil zeggen: maak een kopie die snel toegankelijk is. Niet: defenestreer het hele idee van normalisatie. Dit zou bijvoorbeeld een kopie kunnen zijn waarbij aanpasseingen in het genormaliseerde model komen, en dat na het aanpassen er een gedenormaliseerde versie gemaakt wordt voor snelle(re) toegang. Een soort van hardcoded indexes.

Zulke grappen heb je natuurlijk niet nodig zolang je niet 100.000 bezoekers per dag hebt. En als je dat wel hebt, kan je eens na gaan denken over hoe je caching en dergelijke het slimst zou kunnen aanpakken.
 
Frank -

Frank -

06/06/2008 13:49:00
Quote Anchor link
Aanvulling op Arend: Dit gedenormaliseerde model laat je onderhouden door triggers vanuit het genormaliseerde model. Alle INSERT-, UPDATE- en DELETE-acties doe je op het genormaliseerde model en de SELECT's voer je uit op het gedenormaliseerde model. Mits je de juiste indexen en VIEW's hebt aangemaakt, kun je hier wel wat voordeel mee behalen.

Maar zoals je ziet, heb je nog steeds een genormaliseerde database nodig, die dwingt correcte data af. En dat is nog steeds één van de allerbelangrijkste functies van een database, je hebt namelijk helemaal niets aan een snelle maar onbetrouwbare database. En een gedenormaliseerd model leidt altijd tot onbetrouwbare data, je gaat data dubbel opslaan. Daar kunnen na updates dus verschillen in gaan ontstaan.

Ik heb het nog nooit nodig gehad en heb m'n databases toch al flink op hun donder gegeven. 1 grote complexe query kun je namelijk ook opknippen in meerdere eenvoudige queries. Met een paar simpele lusjes in een stored procedure kun je dan razendsnel dezelfde gegevens opvragen, maar dan ineens een stuk sneller. Tevens is het eenvoudiger te bouwen, ook de simpele ziel snapt het dan. Ik werk er niet voor niets mee... ;)
 
Jacco Engel

Jacco Engel

06/06/2008 13:57:00
Quote Anchor link
Quote:
Tevens is het eenvoudiger te bouwen, ook de simpele ziel snapt het dan. Ik werk er niet voor niets mee


Jij geeft hier dus eigenlijk gewoon publiekelijk toe dat je een simpele ziel bent :P
 
Klaasjan Boven

Klaasjan Boven

06/06/2008 13:59:00
Quote Anchor link
Aanvulling op Frank en Arend, zoiets maak je bijvoorbeeld door gebruik te maken van genormaliseerde tabellen en daar een view overheen te leggen. Deze view kan je materialized maken daardoor is hij net zo snel als een tabel. Je kan er voor kiezen dat te doen met een refreshrate van bijv 2 minuten waardoor die view elke twee minuten wordt bijgewerkt.

Als je dit ook nog doet op basis van een prebuilt table dan kan je ook nog de juiste index aanmaken en dergelijke. Veel sneller wordt het niet...

@TS
Quote:
@pgFrank
Over PostgreSQL zit ik na te denken, ik ken de nadelen van MySQL. Desondanks houd ik het voorlopig bij MySQL, of ik zet beide databases naast elkaar om met beide compatible te blijven.

gebruik een databaseclass bijv PDO

Ik zelf werk momenteel aan webapplicatie op basis van een oracle database waarbij gegevens tabellen uit 4 verschillende databases middels een databaselink opgehaald worden. De gegevens staan binnen een seconde op je scherm waarvoor oracle denk ik ongeveer drie keer 7000 rijen door moet
Gewijzigd op 01/01/1970 01:00:00 door Klaasjan Boven
 
Robert Deiman

Robert Deiman

06/06/2008 14:55:00
Quote Anchor link
@Klaasjan
Dat valt nog wel mee, ik ben nu bezig aan een systeem, waarbij *helaas gebruiken ze dan weer wel MySQL, omdat het systeem reeds bestond voor ik ermee ging werken, en ze dat graag zo houden* zo'n 50000 records doorlopen worden in 1 tabel, en ongeveer 10 keer zoveel in een daaraan gekoppelde tabel.
Deze tabellen zijn wel met indexen en dergelijke ge-optimaliseert.

Het betreft een tabel met alle mogelijke hypotheken hier in Nederland (worden ingelezen middels een csv bestand) en een andere tabel met de daarbij behorende rentestanden inclusief de gehele (bij ons bekende) rente historie.
 

Pagina: 1 2 volgende »



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.