Mijn huidige schaatsdatabase is een nogal aan verbetering toe, vooral omdat ik 5 jaar geleden volledig nieuw was in databaseland. Nu heb ik al een goede uitgangspositie gevonden via de YaHoo-speedskating mailinglist, nl. http://www.wcsc.nl/skatedb.htm Toch mis ik hierin een aantal tabellen/mogelijkheden. Bijvoorbeeld extra informatie over schaatsers en een aantal dingen die bij de world cups terugkomen zoals A/B-groep, worldcup punten en klassementen. Maar ook links naar wedstrijdvideo's en opnemen van familierelaties is er niet in opgenomen. Ik ben al aardig onderweg, al zeg ik het zelf. Structuur van de tabellen: database_design.xlsx (Excel) Nu vroeg ik me af of er een aantal van jullie zijn die naar het ontwerp willen kijken en feedback willen geven. Alvast bedankt.
Het ontwerp in het Excel bestand ziet er goed uit. Sommige tabellen zijn niet strikt noodzakelijk: zo zou je alles van de tabel skater_name ook binnen skater kunnen vastleggen. En de records zou je ook kunnen halen uit de tabel result door daar velden op te nemen voor WR, PR, NR enz. Het ligt er aan of dit handig is waarvoor je het gaat gebruiken. Zelf heb ik voor de resultaten per afstand een tabel gemaakt voor zowel heren als dames. Jij doet alles in één tabel, voor beide valt wat te zeggen. Verder nog wat algemene opmerkingen: - de tabel skater is de enige waar je geen id gebruikt. - je gebruikt steeds een 3 letterige afkorting van de tabelnaam in alle veldnamen. Dat vind ik erg lelijk. Ik heb genoeg databases gezien waar men dat ook deed... Wel netjes dat je alles meteen in het Engels doet. - je zou underscores in namen kunnen gebruiken om ze leesbaarder te maken - veldnamen zou ik altijd uitschrijven i.p.v. af te korten.
mooi en uitgebreid concept! ik ga volledig akkoord met @SprintMaster en zeker die prefix van de tabelnaam hoeft niet, onnodig en onoverzichtelijk verder paar kleine vraagjes, - wat ga je in sks_gender steken? Is 1 karakter niet genoeg (man/vrouw/onbepaald/trans/... ?) - wat komt er in teammember? Dat is toch gewoon een andere skater neem ik aan? Als dat zo is is een linktabel met teamid-skaterid toch voldoende ipv alle kolominfo te dupliceren, of gaat het hier om team staff? - 'record' als tabelnaam is misschien beetje fishy, in elke table zitten records. Meestal is record geen reserved word, dus strikt genomen kan het meestal wellicht wel, maar het leunt er wel dicht tegenaan. Als je andere naam hebt dan is die mss wenselijker?
- De prefix heb ik gedaan om te zorgen dat alle velden een unieke titel hebben. Misschien niet heel mooi, maar het voorkomt bij joint queries identieke namen en anders lange titels als ik de velden een unieke naam wil geven. Hebben jullie een andere oplossing? - Het klopt dat ik het geslacht met 1 karakter bijhoud. Ik houd echter graag een extra karakter vrij voor een mogelijke * of ? - Teammembers zijn managers, coaches, fysio's. Kan een oud-schaatser zijn, maar niet noodzakelijk. - De tabel met records had ik aangemaakt naar voorbeeld van degene die ik via de YaHoo-mailinglist vond. Inmiddels heb ik naar aanleiding van de reactie van SprintMaster de inhoud van de tabel samengevoegd met de tabel result en de tabel records niet meer opgenomen in het ontwerp.
Als je een join hebt van 2 of meerdere tabellen dan geef je die een alias in de 'from' van je query. zie bv het alias as a table stukje op http://www.techonthenet.com/sql/alias.php bv Code: stel dat je volgende 2 tables en columns hebt: resultsamalog id skatercode eventcode eventsamalog ... event code name type gender ... Code: SELECT sam.id, sam.skatercode, sam.eventcode, ev.name, ev.gender FROM resultsamalog sam INNER JOIN event ev ON sam.eventcode = ev.code WHERE sam.id = 123; - je kan als PK ipv id en code ook voluit voor resultsamalogid en eventcode gaan als je dat liever wil - het is soms duidelijker te CamelCasen of om underscores te gebruiken in samenstellingen van column names, maar dat is maar wat jij prettig vindt - je kan die alias ook gebruiken in je select om alles van een table te selecteren met '*', net zoals je met de tablename voluit zou doen (SELECT sam.*, ev.name, ev.gender ...)
Je gebruikt op (vrijwel) alle tabellen ID's die je ook als PK definieert. Wat ik daarbij mis is het hergebruik van de ID's. Anders gezegd, wat ga je met die dingen doen? Bij het dimensioneel modelleren stel je een aantal dimensies op (dim_skater, dim_country, dim_event) en feiten (bijvoorbeel fact_results). In het feit verwijs je naar de ID's van de dimensies. Gegevens van een rijder hoef je dan maar één keer op te slaan en kan je gemakkelijk hergebruiken. Voor het bewaren van historie kan je verschillende dimensie-types gebruiken. Als je de PK op het ID definieerd, zal je een unieke index op de tabel moeten maken om te voorkomen dat je dubbele rijen in je database gaat invoeren. Laatste wat je wilt is dat je drie Leo Vissers in je database hebt zitten die allemaal uit Amsterdam komen en aan het WK in 1987 hebben meegedaan. Naamgeving van je kolommen is iets van jezelf. Doe wat voor jou logisch is en wat over een jaar nog te snappen is zonder het excel formulier. SAP gebruikt geweldige kolomnamen als EINA, EINE, PRST etc. Echt hopeloos...
De techniek kan ik niet helemaal volgen, maar ik zou het prettig vinden als het mogelijk is ook iets te kunnen zeggen over de trainers. Wie is de succesvolste coach bijvoorbeeld op de OS? Als ik het goed begrijp, zou dat kunnen omdat de schaatser per seizoen aan een team is gekoppeld en er ook een coach aan het team gekoppeld is. Dat betekent in de praktijk wel dat de koppeling schaatser-team-coach wel gemaakt moet worden, ook al is er geen "officieel team". Bijvoorbeeld de Zweedse nationale ploeg. Qua koppeling schaatser-coach kan ik voor de Nederlanders overigens wel input aanleveren.
Dit is exact de reden waarom ik de tabellen met teams en coaches wil aanmaken. Input is altijd welkom. Voorlopig is de database nog niet up-and-running, maar ik kom graag bij je terug over dit onderwerp.
Het ID veld gebruiken als PK is inderdaad wat lui omdat ie altijd werkt. Gevolg is wel dat er bij het invoerprogramma op de echte (betekenisvolle) unieke sleutel gecontroleerd moeten worden.
