SQL query wil niet uitvoeren
Wanneer ik de onderstaande query wil uitvoeren heeft PhpMyAdmin er moeite mee de volgende pagina te laden. Hierdoor komt er wel een tabel te staan, maar die functioneert niet naar behoren.
Kan iemand mij vertellen wat er fout is aan mijn sql? (er worden geen errors gegeven).
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
2
3
4
5
6
7
8
9
10
11
12
13
CREATE TABLE `backshotevent` (
`id` int(11) NOT NULL auto_increment,
`name` varchar(32) collate utf8_unicode_ci NOT NULL default '',
`day` varchar(32) collate utf8_unicode_ci NOT NULL default '',
`month` varchar(32) collate utf8_unicode_ci NOT NULL default '',
`year` varchar(32) collate utf8_unicode_ci NOT NULL default '',
`players` varchar(32) collate utf8_unicode_ci NOT NULL default '',
`comment` varchar(225) collate utf8_unicode_ci NOT NULL default '',
`regIP` varchar(15) collate utf8_unicode_ci NOT NULL default '',
`dt` datetime NOT NULL default '0000-00-00 00:00:00',
PRIMARY KEY (`id`),
UNIQUE KEY `name` (`name`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
`id` int(11) NOT NULL auto_increment,
`name` varchar(32) collate utf8_unicode_ci NOT NULL default '',
`day` varchar(32) collate utf8_unicode_ci NOT NULL default '',
`month` varchar(32) collate utf8_unicode_ci NOT NULL default '',
`year` varchar(32) collate utf8_unicode_ci NOT NULL default '',
`players` varchar(32) collate utf8_unicode_ci NOT NULL default '',
`comment` varchar(225) collate utf8_unicode_ci NOT NULL default '',
`regIP` varchar(15) collate utf8_unicode_ci NOT NULL default '',
`dt` datetime NOT NULL default '0000-00-00 00:00:00',
PRIMARY KEY (`id`),
UNIQUE KEY `name` (`name`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
Gewijzigd op 18/06/2011 14:45:54 door Frank O
de backtics
de default op het veld dt
de default '' op andere velden
de velden day,month,year
Note: phpmyadmin is ook niet geschikt voor dit soort zaken!! (daar kom je nu en waarschijnlijk in de toekomst ook nog wel achter)
Om een database te voorzien van tabellen gebruik je de sql-pompt, vanaf waar de scripts kan aanroepen dan wel de statements kan uittikken.
Post alle relevante informatie!! Dat jij geen errors krijgt dan wel ziet kan vele oorzaken hebben.
Leer meer over SQL en het ontwerp van databases.
Frank O op 18/06/2011 16:20:11:
Ehm. SQL is niet mijn sterkste kant. Je zegt nu waar de fouten zitten, maar wat zijn de fouten?
Waarom wil je overal '' (een lege string) als default waarde hebben? Met NOT NULL geef je aan dat een kolom niet leeg mag zijn, ofwel er moet verplicht iets in staan anders kan er geen insert gedaan worden. Als je alle velden default een lege string geeft kun je beter de kolom NULL maken.
Als je twee keer geen naam in vult, zal er 2 keer een lege string in gezet worden. Dit kan niet, want een lege string mag maar 1 keer voor komen volgens jou (unique).
Ik weet niet hoe MySQL om gaat met nullwaarden bij unique, dat zou je even moeten opzoeken.
Vormen de kolommen 'day', 'month' en 'year' samen een datum? Dan kun je er net zo goed een enkele kolom met het type 'date' van maken.
De backticks (`) zijn niet nodig (of heb je deze query uitgevoerd in PHPMyAdmin en heb je het uitgevoerde statement gekopieerd? Want PHPMyAdmin zet deze er standaard omheen geloof ik.)
Niet dus.
Ik heb van de datum 3 aparte invoervakken gemaakt, dus komt die ook 3x in de database.
Wat de uiteindelijke functie van het php script moet worden is, dat je de bovenstaande gegevens in kan voeren in een database, en dat het vervolgens zichtbaar is voor de bezoeker.
Karl Karl op 18/06/2011 16:51:07:
Datum kan je gewoon in één veld opslaan. Moet ook. Hoort zo.
Toevoeging: En die kun je er later eventueel weer gescheiden uithalen.
Ikzelf gebruikt nog liever DATETIME, kost weinig extra geheugen, en als je in de toekomst toch de tijd erbij wilt hebben, dan hoef je niet alle records na te gaan. Heeft me al veel werk gescheeld in het verleden
En waarom in hemelsnaam een id gebruiken als je 'name' uniek is? Dat heeft een aantal nadelen (ik schrijf wel een keer een tutorial er over zodat ik het niet hoef te herhalen). Kort samengevat: je slaat onnodige gegevens op, je database wordt minder beschrijvend (foreign key verwijzingen naar nietzeggende id's) en je moet vaker joins gebruiken. Gebruik alleen id's indien er geen unieke identificatie in een rij is (wat vrij uitzonderlijk is).
The Force op 18/06/2011 18:09:10:
(...)
En waarom in hemelsnaam een id gebruiken als je 'name' uniek is? Dat heeft een aantal nadelen (ik schrijf wel een keer een tutorial er over zodat ik het niet hoef te herhalen). Kort samengevat: je slaat onnodige gegevens op, je database wordt minder beschrijvend (foreign key verwijzingen naar nietzeggende id's)
En waarom in hemelsnaam een id gebruiken als je 'name' uniek is? Dat heeft een aantal nadelen (ik schrijf wel een keer een tutorial er over zodat ik het niet hoef te herhalen). Kort samengevat: je slaat onnodige gegevens op, je database wordt minder beschrijvend (foreign key verwijzingen naar nietzeggende id's)
Ik ben het hier niet helemaal mee eens, het klopt inderdaad als je je database gaat normaliseren dat dan blijkt dat je username de primary key wordt. Maar met iets als een naam kan je goed afwijken. Je wilt het liefste een primary key hebben die zegt dat deze rij uniek is, meer niet. Als je de naam als primary key gaat gebruiken dan wordt dat veld dubbel gebruikt, als primary key en als naam. Een id introduceren die alleen de primary key is kan in zo'n geval dus ook wel.
The Force op 18/06/2011 18:09:10:
en je moet vaker joins gebruiken. (...)
Deze implicatie volg ik niet, volgens mij is die nergens op gebaseerd. Als de id de primary key is gebruik je dat in andere tabellen als de foreign key, je hoeft daar geen extra joins voor 'aan te leggen'.
Karl Karl op 18/06/2011 18:51:48:
Ik ben het hier niet helemaal mee eens, het klopt inderdaad als je je database gaat normaliseren dat dan blijkt dat je username de primary key wordt. Maar met iets als een naam kan je goed afwijken. Je wilt het liefste een primary key hebben die zegt dat deze rij uniek is, meer niet. Als je de naam als primary key gaat gebruiken dan wordt dat veld dubbel gebruikt, als primary key en als naam. Een id introduceren die alleen de primary key is kan in zo'n geval dus ook wel.
The Force op 18/06/2011 18:09:10:
(...)
En waarom in hemelsnaam een id gebruiken als je 'name' uniek is? Dat heeft een aantal nadelen (ik schrijf wel een keer een tutorial er over zodat ik het niet hoef te herhalen). Kort samengevat: je slaat onnodige gegevens op, je database wordt minder beschrijvend (foreign key verwijzingen naar nietzeggende id's)
En waarom in hemelsnaam een id gebruiken als je 'name' uniek is? Dat heeft een aantal nadelen (ik schrijf wel een keer een tutorial er over zodat ik het niet hoef te herhalen). Kort samengevat: je slaat onnodige gegevens op, je database wordt minder beschrijvend (foreign key verwijzingen naar nietzeggende id's)
Ik ben het hier niet helemaal mee eens, het klopt inderdaad als je je database gaat normaliseren dat dan blijkt dat je username de primary key wordt. Maar met iets als een naam kan je goed afwijken. Je wilt het liefste een primary key hebben die zegt dat deze rij uniek is, meer niet. Als je de naam als primary key gaat gebruiken dan wordt dat veld dubbel gebruikt, als primary key en als naam. Een id introduceren die alleen de primary key is kan in zo'n geval dus ook wel.
Wat is het probleem om data te gebruiken voor een primary key? Ik heb nergens gelezen dat het aangeraden wordt om geen unieke data te gebruiken voor een primary key (wat in feite een veredelde unique constraint is). Waarom zou je een extra index moeten aanleggen? En wat is er zo bijzonder aan een naam, dat je die niet 'dubbel' mag gebruiken? Mag je daar dan ook geen foreign key op aanleggen? Daarnaast maakt het je database minder beschrijvend en vergeten veel mensen om handmatig die extra uniques aan te leggen (waardoor je opeens meerdere mensen met dezelfde username hebt). Laatste vraagje: je geeft zelf aan dat als je gaat normaliseren dat de username de primary key zou worden. Wat klopt er niet aan het normalisatieproces dat het toch beter zou zijn om een id te gebruiken?
Karl Karl op 18/06/2011 18:51:48:
Deze implicatie volg ik niet, volgens mij is die nergens op gebaseerd. Als de id de primary key is gebruik je dat in andere tabellen als de foreign key, je hoeft daar geen extra joins voor 'aan te leggen'.
The Force op 18/06/2011 18:09:10:
en je moet vaker joins gebruiken. (...)
Deze implicatie volg ik niet, volgens mij is die nergens op gebaseerd. Als de id de primary key is gebruik je dat in andere tabellen als de foreign key, je hoeft daar geen extra joins voor 'aan te leggen'.
Dat krijg je dus als ik het niet goed uitleg. Een join leg je ook niet aan. Het komt in de praktijk gewoon vaker voor dat je de unieke reeks van de tabel waarnaar verwezen wordt wil gebruiken bij een select op de child tabel. Voorbeeldje: tabel User (pk = username) en UserAction (pk = username (fk), action_on). Als je een lijstje wil met welke gebruikers welke acties hebben uitgevoerd dan kan je gewoon een select doen in UserAction. Gebruik je nietzeggende id's dan moet je een join doen met User om bij elke actie de username op te halen. Onnodig dus.
P.S. Zit tot maandag ochtend in het vliegtuig dus kan voorlopig (waarschijnlijk) niet meer reageren.
Gewijzigd op 18/06/2011 19:16:43 door The Force