[Php/mysql]Table aanmaken lukt niet

[Verwijderd]

Ben inmiddels een paar dagen bezig geweest met php en databases (sql eigenlijk), dit als skillsblok op school. Nu moet ik een eindopdracht maken, in mijn geval een nieuwssysteem met admin control etc.
Alleen nu stuit ik op een probleempje en doordat ik nog maar kort ermee bezig ben weet ik er niet mee overweg.

Dit is de query die ik met phpmyadmin probeer uit te voeren. (ik heb het in phpcode brackets gezet, lag het dichste bij mysql).

PHP:

CREATE TABLE `tmbb_berichten` ( 

`id` SMALLINT NOT NULL AUTO_INCREMENT , 
`datum` VARCHAR( 00 : 00 - 00 / 00 / 00 ) NOT NULL , 
`onderwerp` VARCHAR NOT NULL , 
`bericht` VARCHAR NOT NULL , 
`gebruiker` VARCHAR NOT NULL , 
`icon_id` SMALLINT NOT NULL , 
UNIQUE ( 
`id` , 
`bericht` 
), 
FULLTEXT ( 
`bericht` 
) 
)

De error die ik krijg is deze:

code:

You have an error in your SQL syntax near ':00 - 00/00/00) NOT NULL, 
`onderwerp` VARCHAR NOT NULL, `bericht` VARCHAR NOT NU' at line 1

Ik denk dus dat die 00:00 00/00/00 niet mag o.i.d. maar kan iemand mij misschien helpen en een beetje uitleggen, waarom niet als dit het geval is.
Misschien begin al helemaal fout, maar ik kan alleen te korte of onduidelijke informatie vinden. En bij de boekenwinkel was er ook niks duidelijks
Alvast hartstikke bedankt!

[ Voor 1% gewijzigd door curry684 op 20-09-2003 22:31 . Reden: layout ]

[PrisonerOfPain]

bij een varchar moet je de groote tussen de haakjes zetten dus bijvoorbeeld varchar(100)

edit:

BTW voor data/tijd hebben we de timestamp he.

zie ook, http://www.developerfusion.com/show/3998/4/

[ Voor 41% gewijzigd door PrisonerOfPain op 20-09-2003 22:51 ]

[Verwijderd]

Hey super bedankt man, ik ga er meteen mee aan de slag. Dat ik dat niet gezien heb zeg. Heb m'n werkbladen erbij nageslagen en daar stond dat idd ook. (stom stom stom)
Hij kan dus weer dicht tenzij iemand nog goede tips voor me heeft. (geen bijdehande dingen)

[ Voor 23% gewijzigd door Verwijderd op 20-09-2003 22:57 ]

[rik]

Grappig dat je id met bericht als uniek hebt, op die manier is het makkelijk dubbele <enter>s ondervangen

[Verwijderd]

Ja ik wist niet zeker of het zou werken maar ik dacht ik probeer het gewoon.
En het is enkel aan te passen in het admin gedeelte. Het ondervangt dus gewoon een dubbel klik die je per ongeluk zou kunnen maken.

[dArtagnan]

Je hebt in je tabel geen primary key aangegeven. Deze is belangrijk bij een relationele database.

Primary key:
• Een primary key mag niet NULL zijn.
• Een primary key moet uniek zijn in de tabel.
• Iedere tabel mag slechts 1 primary key hebben.
• Iedere tabel moet een primary key hebben.

[PrisonerOfPain]

Een korte toelichting over het waarom van een Primary key zou ook niet misstaan want belangrijk mag het wel zijn, maar waarom?

[vinnux]

Binnen MySql is een Primary Key feitelijk gezien niet heel belangrijk.
Een Primary Key geeft aan waarmee de rij unique te indetificeren is. Dit kan een enkel veld zijn, maar ook een combinatie van velden.
Binnen MySql is er weinig verschil tussen een unique en een primary key, aangezien er binnen MySql geen Foreign Keys (geeft het onderlinge verband aan tussen tabellen) gemaakt kunnen worden, die gebruik maken van deze Primary Key. Het enig handige is dat het zowel een unque als een index is en dat het eem auto_increment veld kan bevatten.

Althans zo dacht ik dat het in elkaar zat.

[ Voor 7% gewijzigd door vinnux op 20-09-2003 23:31 . Reden: typos ]

[dArtagnan]

Voor het identificeren van een rij is een primaire sleutel belangrijk. Met behulp van de foreign key kan je verbanden leggen tussen tabellen. Dit kan gedeeltelijk met mysql als je het tabeltype innodb kiest.

Starting from version 3.23.43b InnoDB features foreign key constraints. InnoDB is the first MySQL table type which allows you to define foreign key constraints to guard the integrity of your data.

mySQL maakt van het eerste voorkomende unieke veld een primaire sleutel als deze nog niet eerder is aangegeven.

[Verwijderd]

Ik vond nog meer info:

PRIMARY KEY
Met de uitdrukking PRIMARY KEY geven we aan dat de waarde in deze kolom maar één keer voorkomt in alle rijen van de tabel.
Een PRIMARY KEY wordt ook wel het "identificerende" veld van een tabel genoemd.

Met de waarde van dit veld onderscheidt deze tabelrij zich van de andere rijen - het maakt deze rij UNIEK.
Kolommen van dit type moeten altijd ingevuld worden (en zijn dus automatisch "NOT NULL").
Het is verstandig om in elke tabel een primaire sleutel aan te maken. Deze kolomeigenschap ziet er volledig als volgt uit:

userid INT(10), <-- eerst dient het veld aangemaakt te worden
...
PRIMARY KEY(userid) <- vervolgens geven we aan dat dit veld de primaire sleutel is

Dus als ik het goed begrijp moet ik een primaire sleutel aangeven, zodat elke rij van deze toekomstige tabel zichzelf kan onderscheiden?
Dit is dus belangrijk omdat je straks meerdere tabellen hebt en die elkaar moeten kunnen 'vinden'?
Ben benieuwd of ik het zo goed heb begrepen.

[dArtagnan]

Verwijderd schreef op 21 September 2003 @ 10:40:
Ik vond nog meer info:

[...]

Dus als ik het goed begrijp moet ik een primaire sleutel aangeven, zodat elke rij van deze toekomstige tabel zichzelf kan onderscheiden?
Dit is dus belangrijk omdat je straks meerdere tabellen hebt en die elkaar moeten kunnen 'vinden'?
Ben benieuwd of ik het zo goed heb begrepen.

Klopt.

[whoami]

Waarom ga je een datum gaan opslaan in een VARCHAR veld? Dat is om problemen vragen, als je het mij vraagt.

Wat als je nu eens records wilt opvragen vanaf een bepaalde datum ofzo?

Over die primary key:
Om goed te zijn moet iedere tabel een primary key-veld hebben. Ieder record moet nl. uniek te onderscheiden zijn binnen een tabel. Een primary key zorgt daar voor.
Door middel van primary keys (en foreign keys), kan je relaties in je databank gaan leggen.

[ Voor 46% gewijzigd door whoami op 21-09-2003 13:47 ]

[Suepahfly]

Van het veld id zou ik int maken.
smallint gaat niet verder als 127

Dat houd in dat je met je huidige tabel structuur dus niet meer als 127 nieuws berichten kan opslaan

[ Voor 44% gewijzigd door Suepahfly op 21-09-2003 13:49 ]

[dArtagnan]

Dan moet je ook voor het bericht een tekst veld gebruiken. Varchar kan niet verder gaan dan 255 tekens. Icon_id moet dan ook een integer worden en eventueel gebruiker ook als je de gebruikers in een andere tabel hebt staan.

Tinyint gaat van -127 tot 127 en als je hem tinyint unsigned gebruikt kun je van 0 tot 255 berichten nummeren. Smallint gaat van -32768 tot 32767 en smallint unsigned gaat van 0 tot 65535. Maar het kan nooit kwaad om een normale integer (int) te gebruiken. Een normale integer gaat van -2³¹ tot 2³¹ -1 en dat lijkt me toch wel goed voor heel wat nieuwsberichten.

[ Voor 14% gewijzigd door dArtagnan op 21-09-2003 14:03 . Reden: typo ]

[whoami]

Koraalduivel schreef op 21 september 2003 @ 13:59:
Tinyint gaat van -127 tot 127 en als je hem tinyint unsigned gebruikt kun je van 0 tot 255 berichten nummeren. Smallint gaat van -32768 tot 32767 en smallint unsigned gaat van 0 tot 65535. Maar het kan nooit kwaad om een normale integer (int) te gebruiken. Een normale integer gaat van -2³¹ tot 2³¹ -1 en dat lijkt me toch wel goed voor heel wat nieuwsberichten.

Zeker als je weet dat een auto-incr. waarde nooit zal hergebruikt worden.
Als je bv het record met id 129 deleted, dan zal er nooit meer een record in de tabel komen met record 129. Die waardes gaan dus verloren en worden niet meer opgevuld.
Tenzij je natuurlijk die auto-incr. reset oid.