Door
Flip --
op 24-10-2012 15:17
gewijzigd op 24-10-2012 15:19
4.752 views
ik kom graag te weten:
* of hier informatie mist
* ieder ander commentaar behalve op het data-type van de kolommen
Ik heb dit grafisch ontworpen en de SQL code laten genereren.
answers.answer kan een nederlands of frans antwoord bevatten
answers.direction moet als boolean functioneren of de vraag als frans->nederlands of nederlands->frans is gesteld
het is niet nodig om het later uit te breiden naar andere talen
CREATE TABLE IF NOT EXISTS `mydb`.`dictionaries` (
`id` INT NOT NULL ,
`name` TEXT NULL ,
PRIMARY KEY (`id`) )
ENGINE = InnoDB;
CREATE TABLE IF NOT EXISTS `mydb`.`phrases` (
`id` INT NOT NULL ,
`dictionaryId` INT NULL ,
`french` TEXT NULL ,
`dutch` TEXT NULL ,
PRIMARY KEY (`id`) ,
INDEX `fk_phrases_dictionaries_idx` (`dictionaryId` ASC) ,
CONSTRAINT `fk_phrases_dictionaries`
FOREIGN KEY (`dictionaryId` )
REFERENCES `mydb`.`dictionaries` (`id` )
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;
CREATE TABLE IF NOT EXISTS `mydb`.`practiseSessions` (
`id` INT NOT NULL ,
`dictionaryId` INT NULL ,
`started` DATETIME NULL ,
PRIMARY KEY (`id`) ,
INDEX `fk_practiseSessions_dictionaries1_idx` (`dictionaryId` ASC) ,
CONSTRAINT `fk_practiseSessions_dictionaries1`
FOREIGN KEY (`dictionaryId` )
REFERENCES `mydb`.`dictionaries` (`id` )
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;
CREATE TABLE IF NOT EXISTS `mydb`.`answers` (
`id` INT NOT NULL AUTO_INCREMENT ,
`phraseId` INT NOT NULL ,
`direction` INT NOT NULL ,
`incorrect` INT NOT NULL ,
`answer` TEXT NOT NULL ,
`caseInsensitive` INT NULL ,
`ignorePunctuation` INT NULL ,
`practiseSessionId` INT NULL ,
PRIMARY KEY (`id`) ,
INDEX `fk_answers_phrases1_idx` (`phraseId` ASC) ,
INDEX `fk_answers_practiseSessions1_idx` (`practiseSessionId` ASC) ,
CONSTRAINT `fk_answers_phrases1`
FOREIGN KEY (`phraseId` )
REFERENCES `mydb`.`phrases` (`id` )
ON DELETE NO ACTION
ON UPDATE NO ACTION,
CONSTRAINT `fk_answers_practiseSessions1`
FOREIGN KEY (`practiseSessionId` )
REFERENCES `mydb`.`practiseSessions` (`id` )
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;
Op een paar kleine dingen na zit het (voor zover ik kan beoordelen) goed in elkaar.
Je geeft aan dat het altijd tot die twee talen beperkt zal blijven, dus waarom dat dan in een tabel zetten?
Je hebt in iedere tabel een id kolom, op zich niet fout, maar ik persoonlijk vind het onhandig want doen moet je straks in de query's alsnog gaan aliassen.
Ik neem aan dat er ook mensen zijn die de oefeningen gaan uitvoeren, dus ik mis nog een paar tabellen?
Je tabellen staan nu in de derde normaalvorm, je zou nog een trapje hoger kunnen door de incorrect kolom weg te halen (je kunt het antwoordt vergelijken met de phrases tabel)
Even een tipje - geen commentaar dus ;-) - over het datatype van de 'booleans', je kunt hier beter een tinyint(1) voor nemen, scheelt weer 10 bytes.
@Ger: ik zie vrijwel altijd in iedere tabel een 'id' staan. Jouw argument dat je moet gaan aliassen heb ik ook eerder gehoord. Toen zei iemand dat je eigenlijk nooit 'id' als veldnaam moet gebruiken, maar altijd een prefix moet gebruiken, bijvoorbeeld customer_id. Toch zie ik in de praktijd eigenlijk altijd dat 'id' wordt gebruikt. Is dat dan niet goed?
Het is niet fout, en als in een tabel geheel op zich zelf staat maakt het ook allemaal niet uit, maar dat is bijna nooit het geval. Ik zelf zorg er altijd voor dat de kolomnamen in tabellen altijd uniek zijn (behalve de FK natuurlijk), want ik weet zeker dat je het jezelf daarmee uiteindelijk makkelijker maakt. Ik heb wel de gewoonte om de prefixen in te korten, bv cst_ (tikje uit het programmeren met VB(A) en Delphi)
Maar van moeten is dus geen sprake.
Ik heb bewust er voor gekozen om niet uit te leggen waarvoor dit ontwerp dient, want ik hoop dat ik mijn ontwerp duidelijk genoeg kan maken dat het voor zich spreekt.
Ger van Steenderen op 28/10/2012 11:25:55
Op een paar kleine dingen na zit het (voor zover ik kan beoordelen) goed in elkaar.
Bedankt Ger in het bijzonder voor het nakijken.
Ger van Steenderen op 28/10/2012 11:25:55
Je geeft aan dat het altijd tot die twee talen beperkt zal blijven, dus waarom dat dan in een tabel zetten?
De applicatie is voor het oefenen van woordenlijsten. In plaats van phrase1 en phrase2, of linkerwoord en rechterwoord. Heb ik er voor gekozen om ze dutch en french te noemen. Omdat de eene taal niet percé aan een bepaalde kant hoeft te staan en ook niet de "1ste" is. De kolommen french en dutch bevat dus de belangrijkste data:
dutch: het kasteel
french: le château
Ger van Steenderen op 28/10/2012 11:25:55
Je hebt in iedere tabel een id kolom, op zich niet fout, maar ik persoonlijk vind het onhandig want doen moet je straks in de query's alsnog gaan aliassen.
Ik begrijp je hier niet. Misschien kan je wat meer uitleggen of een voorbeeld query maken? (ook met de verdere uitleg in vervolg post zie ik niet goed in waar nu verwarring zou kunnen optreden)
Ger van Steenderen op 28/10/2012 11:25:55
Ik neem aan dat er ook mensen zijn die de oefeningen gaan uitvoeren, dus ik mis nog een paar tabellen?
Op dit moment is het maar voor 1 gebruiker, er mist dus inderdaad nog een user tabel. Maar verder zijn er nog tabellen die zouden missen??
Ger van Steenderen op 28/10/2012 11:25:55
Je tabellen staan nu in de derde normaalvorm, je zou nog een trapje hoger kunnen door de incorrect kolom weg te halen (je kunt het antwoordt vergelijken met de phrases tabel)
Ik wist dat ik het antwoord kan vergelijken met de originele data. Er zijn drie redenen waarom ik gekozen heb voor deze kolom.
Ten eerste wordt je query iets complexer omdat je aan de kolom direction moet aflezen of het antwoord frans of nederlands was, en dus met welke van de twee kolommen je moet vergelijken.
Ten tweede het zou misschien wat sneller zijn ook al wordt er meer geheugen gebruikt. Maar ik dit niet getest.
Ten derde, en dit is de belangrijkste reden en ook gelijk de aanleiding. Is dat incorrect meer waardes kan hebben dan 0 of 1. 0 = goed, 1 = een beetje fout, 2 = iets meer fout, 3 = nog meer fout. De functie die dit bepaald is niet zo heel simpel en dus moet dit weer iedere keer berekend worden.
Ger van Steenderen op 28/10/2012 11:25:55
Even een tipje - geen commentaar dus ;-) - over het datatype van de 'booleans', je kunt hier beter een tinyint(1) voor nemen, scheelt weer 10 bytes.
Ja ik weet het, toch bedankt. Probleem is dat ik met doctrine werk nu (ben pas beginner hierin) en doctrine heeft niet ondersteuning voor alle datatypes van mysql out-of-the-box. Omdat dit project vooral als leerproject is bedoeld is dit geen harde eis van mij dat de datatypes zo goed mogelijk aansluiten, misschien nog eens achteraf.
[quote="Ger van Steenderen op 28/10/2012 11:25:55"]Je hebt in iedere tabel een id kolom, op zich niet fout, maar ik persoonlijk vind het onhandig want doen moet je straks in de query's alsnog gaan aliassen.
Ik begrijp je hier niet. Misschien kan je wat meer uitleggen of een voorbeeld query maken? (ook met de verdere uitleg in vervolg post zie ik niet goed in waar nu verwarring zou kunnen optreden)[/quote]
Door mijn manier van querieën heb ik regelmatig queries waarin ik 6+ tabellen bij elkaar join, als je dan van de helft het id nodig hebt krijg je dit
SELECT a.id AS aas_id, b.id AS bees_id, c.id AS cees_id FROM ....
Volgens mij heb je met het aliassen meer te typen dan als je van het begin die kolommen al zo genoemd hebt. Ik hoef kolommen alleen maar te aliassen bij een self join.
Ger van Steenderen op 28/10/2012 11:25:55
Ik neem aan dat er ook mensen zijn die de oefeningen gaan uitvoeren, dus ik mis nog een paar tabellen?
Op dit moment is het maar voor 1 gebruiker, er mist dus inderdaad nog een user tabel. Maar verder zijn er nog tabellen die zouden missen??
Nee
Ger van Steenderen op 28/10/2012 11:25:55
Je tabellen staan nu in de derde normaalvorm, je zou nog een trapje hoger kunnen door de incorrect kolom weg te halen (je kunt het antwoordt vergelijken met de phrases tabel)
Ik wist dat ik het antwoord kan vergelijken met de originele data. Er zijn drie redenen waarom ik gekozen heb voor deze kolom.
Ten eerste wordt je query iets complexer omdat je aan de kolom direction moet aflezen of het antwoord frans of nederlands was, en dus met welke van de twee kolommen je moet vergelijken.
Ten tweede het zou misschien wat sneller zijn ook al wordt er meer geheugen gebruikt. Maar ik dit niet getest.
Ten derde, en dit is de belangrijkste reden en ook gelijk de aanleiding. Is dat incorrect meer waardes kan hebben dan 0 of 1. 0 = goed, 1 = een beetje fout, 2 = iets meer fout, 3 = nog meer fout. De functie die dit bepaald is niet zo heel simpel en dus moet dit weer iedere keer berekend worden.
De derde normaalvorm is in deze toepassing voldoende, dingen niet moeilijker maken dan nodig is.
