stukje text en maand/jaar opslaan

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Pagina: 1 2 volgende »

Ozzie PHP

Ozzie PHP

20/06/2013 15:43:31
Quote Anchor link
Ola,

Ik wil in een database tabel 'foo' 2 dingen opslaan:

1. een description van wat 'foo' is. Dit zal een korte tekst zijn van een aantal regels. Nu wil ik graag weten hoeveel tekens ik kan opslaan in het TINYTEXT data type. Ik kan het niet terugvinden.

2. de maand en het jaar waarin 'foo' gemaakt is. Het lijkt me handig dat zodra ik een nieuwe 'foo' insert de huidige maand en jaar direct worden ingevoegd in de tabel. Echter, ik wil de maand en het jaar naderhand ook nog kunnen wijzigen (via een cms). Ik wil dus dat er op een pagina komt te staan: deze 'foo' is gemaakt in juni 2013. Hoe sla ik dit het beste op in de database, dusdanig dat ik de maand en het jaar naderhand vanuit een cms nog kan wijzigen (naar bijv. augustus 2013)?
 
PHP hulp

PHP hulp

17/11/2024 17:36:58
 
Chris PHP

Chris PHP

20/06/2013 15:46:37
Quote Anchor link
Google rocks :-P
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
TINYTEXT     maximum length of 255 characters

Als je de rest wil hebben.
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
8
9
CHAR( )      fixed from 0 to 255 characters long
 VARCHAR( )   variable from 0 to 255 characters long
 TINYTEXT     maximum length of 255 characters
 TEXT         maximum length of 65535 characters
 BLOB         maximum length of 65535 characters
 MEDIUMTEXT   maximum length of 16777215 characters
 MEDIUMBLOB   maximum length of 16777215 characters
 LONGTEXT     maximum length of 4294967295 characters
 LONGBLOB     maximum length of 4294967295 characters


En als je de data wil weten.
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
TINYTEXT 256 bytes  
TEXT 65,535 bytes ~64kb
MEDIUMTEXT  16,777,215 bytes ~16MB
LONGTEXT 4,294,967,295 bytes ~4GB
Gewijzigd op 20/06/2013 15:48:38 door Chris PHP
 
Ozzie PHP

Ozzie PHP

20/06/2013 15:52:37
Quote Anchor link
Thanks Chris! Ik was aan het zoeken in de MySQL manual maar kon het niet vinden.

Wel gelijk een andere vraag... wat is dan het verschil tussen varchar(255) en een tinytext?
 
- Ariën  -
Beheerder

- Ariën -

20/06/2013 16:01:38
Quote Anchor link
Voor TINYTEXT wordt er standaard al 8 bit gereserveerd voor de inhoud, maar bij VARCHAR kan je het zelf nog bepalen. Mensen die gewoon zomaar VARCHAR (255) doen, kunnen net zo goed een TINYTEXT gebruiken.

Dit lijkt me het meest voor de hand liggende.
 
Ozzie PHP

Ozzie PHP

20/06/2013 16:07:26
Quote Anchor link
Ah oké, nu nog even uitvogelen hoeveel tekst 255 karakters eigenlijk is :-)

Iemand nog een idee over het opslaan van de datum (maand/jaar)?

Toevoeging op 20/06/2013 16:12:56:

Oh, da's maar weinig, 255 tekens voor een stukje tekst. Ik maar er een TEXT van.
 
Ward van der Put
Moderator

Ward van der Put

20/06/2013 16:30:43
Quote Anchor link
Ozzie PHP op 20/06/2013 16:07:26:
Iemand nog een idee over het opslaan van de datum (maand/jaar)?

YEAR(4) voor het jaar en een TINYINT voor de maand. Maar liever nog een volledige datum, anders bouw je bij voorbaat al een onomkeerbaar dataverlies in.
 
Ozzie PHP

Ozzie PHP

20/06/2013 16:36:08
Quote Anchor link
En die volledige datum, wat is dan de beste optie? DATE, DATETIME of TIMESTAMP? Ik zie dat ik de timestamp automatisch kan invoegen dus dat lijkt me wel handig. Maar is TIMESTAMP dan ook de juiste optie van deze 3?
 
Ward van der Put
Moderator

Ward van der Put

20/06/2013 16:44:46
Quote Anchor link
Vroeger kon je voor een automatische ON UPDATE CURRENT_TIMESTAMP per tabel maar één TIMESTAMP gebruiken. Op zich ook wel logisch: dat is de kolom waarmee je de laatste wijziging van een record registreert. Maar volgens mij kun je tegenwoordig zowel TIMESTAMP als DATETIME gebruiken.
 
Ozzie PHP

Ozzie PHP

20/06/2013 16:57:38
Quote Anchor link
Hoi Ward, ik snap niet helemaal wat je bedoelt. In PHP MyAdmin kan ik inderdaad kiezen voor ON UPDATE CURRENT_TIMESTAMP. Maar is dat ook de beste optie? Wat is het verschil met DATETIME? En met die automatische update, als ik dan een veld (bijv. de omschrijving) wijzig, dan update ie 'm dus weer. Dat is eigenlijk niet de bedoeling. Dus dan is de beste keus TIMESTAMP of DATETIME? Wat is het verschil? Welke is de beste?

(En is DATE hetzelfde als DATETIME, alleen dat je dan geen tijd erbij hebt? Dat zou in mijn geval dan toch ook nog kunnen?)
 
Ward van der Put
Moderator

Ward van der Put

20/06/2013 17:06:03
Quote Anchor link
In MySQL 5.6.5 werd de afhandeling veranderd:

http://dev.mysql.com/doc/refman/5.6/en/timestamp-initialization.html

Een TIMESTAMP wordt intern geconverteerd naar de wereldstandaardtijd in UTC en is dús wereldwijd altijd nauwkeurig/uniek (tenzij de serverklok FUBAR is). Een DATETIME is een representatie van een datum plus een tijd die afhankelijk is van de lokale klok. Of kort door de bocht samengevat: de TIMESTAMP is een "echte computertijd" en de DATETIME meer een "string" die als datum en tijd wordt behandeld.
 
Kris Peeters

Kris Peeters

20/06/2013 17:19:54
Quote Anchor link
Dus?

TIMESTAMP is een betere keuze voor een veld 'created', dat aangeeft wanneer een record is aangemaakt.

DATETIME is geschikt om een gekozen datum/tijd te geven, bv. de fuif begint om "2013-06-20 20:00:00"


Lijkt dit je terecht?
 
Ward van der Put
Moderator

Ward van der Put

20/06/2013 17:29:50
Quote Anchor link
Ja Kris, zo zou je het kunnen zeggen. Die fuif impliceert namelijk een locatie, dus dan is de DATETIME geen gegeven meer dat op zich staat. Zou je er echter bijvoorbeeld een screencast of andere live uitzending van maken die wereldwijd moet worden bekeken, dan is een TIMESTAMP meer op zijn plaats. De datum en tijd zijn dan in de database eenduidig en op het niveau van de lokale applicatie toon je vervolgens de bijbehorende lokale datum en tijd.

Wel de tijdzone in de databaseserverconfiguratie controleren, want die staat wel eens ten onrechte op bijvoorbeeld Berlijn in plaats van Amsterdam of Brussel.
 
Ozzie PHP

Ozzie PHP

20/06/2013 18:59:27
Quote Anchor link
Oké, dan lijkt een timestamp mij het meest "veilig" om te gebruiken. In mijn geval gaat het dus om de datum waarop iets gemaakt is. Hoe zou je het database veld dan noemen? Simpelweg 'timestamp' of 'creation_date'?

Oh... hoe genereer ik in PHP gemakkelijk een timestamp (van het huidige moment) die ik in het databaseveld kan knippen/plakken?
 
Ward van der Put
Moderator

Ward van der Put

20/06/2013 19:03:11
Quote Anchor link
Ozzie PHP op 20/06/2013 18:59:27:
Oké, dan lijkt een timestamp mij het meest "veilig" om te gebruiken. In mijn geval gaat het dus om de datum waarop iets gemaakt is. Hoe zou je het database veld dan noemen? Simpelweg 'timestamp' of 'creation_date'?

Liever nooit gereserveerde aanduidingen gebruiken, anders moet je aan de slag met backticks.

Ozzie PHP op 20/06/2013 18:59:27:
Oh... hoe genereer ik in PHP gemakkelijk een timestamp (van het huidige moment) die ik in het databaseveld kan knippen/plakken?

Dat gaat makkelijker met MySQL-functies en MySQL-standaardinstellingen, bijvoorbeeld NOW().
 
Kris Peeters

Kris Peeters

20/06/2013 19:31:12
Quote Anchor link
Ozzie PHP op 20/06/2013 18:59:27:
Hoe zou je het database veld dan noemen?


drupal noemt het created. Dat veld wordt niet veranderd.
Dan is er nog een extra veld modified, dat wel wordt aangepast telkens iets wordt geüpdated (node systeem).

om maar iets van inspiratie te geven.

----

Trouwens, ik bedoelde inderdaad ook meer, zoals ondertussen is aangehaald.

Soms wil je een datum/tijd echt onveranderd zien.

Neem nu als quiz-antwoord
Wanneer stopte WW1 ? "1918-11-11 11:11:00"
Hier is het absoluut niet relevant dat dit wordt aangepast aan de locatie van de server, of van de gebruiker.


Als je echter wil weten wanneer de live stream van het WK voetbal in Brazilië begint, is het wel relevant dat de gebruiker dit in zijn locale tijd kan krijgen.

Dat soort dingen zouden dus ook de keuze horen te beïnvloeden
 
Ozzie PHP

Ozzie PHP

20/06/2013 20:14:24
Quote Anchor link
Maar ik weet nu niet goed wat ik moet doen. Ik wil dus in de database zetten wanneer 'foo' is gemaakt. Gebruik ik dan TIMESTAMP of DATETIME / DATE? Uiteindelijk wil ik alleen de maand en het jaar weergeven.
 
Ward van der Put
Moderator

Ward van der Put

20/06/2013 20:19:05
Quote Anchor link
Wat is 'foo' dan? En waarom moet je per se op jaar en maand weten wanneer die 'foo' werd gemaakt? En waarom zijn de dag en tijd daarbij vervolgens data die je glad wilt vergeten? Welk exact jaar en maand, niet exact de dag: klinkt niet logisch.

In twijfelgevallen: de databaseserver instellen op de juiste tijdzone en een TIMESTAMP opslaan.
 
Ozzie PHP

Ozzie PHP

20/06/2013 20:26:35
Quote Anchor link
Foo kan van alles zijn in principe, bijv. een maandelijkse special over een of ander onderwerp. Je wil dan aangeven uit welke maand het stamt, maar het tijdstip is totaal niet relevant. Het gaat er alleen om dat diit de special van bijv. juni 2013 is. Is TIMESTAMP dan nog steeds de juiste keuze?

Hoe stel ik de database server in op de juiste tijd eigenlijk? Ik kan wel via een optie in mijn beheersysteem (WHM panel) de server tijd synchroniseren. Staat dan ook de database tijd meteen goed?
 
Ward van der Put
Moderator

Ward van der Put

20/06/2013 20:31:35
Quote Anchor link
Maar waarom leg je je nu al vast op een "maandelijkse special"? Wat nu als je daarvan een "weekly special" wilt maken? Of een "dagaanbieding"?
 
Ozzie PHP

Ozzie PHP

20/06/2013 20:35:51
Quote Anchor link
Da's een keuze. Maar al zou het een weekly of dagaanbeiding worden, dan heb ik nog steeds geen tijdstip nodig. Dus de vraag blijft wat dan de beste optie is? Ik vind het ook prima om een timestamp te gebruiken als dat de beste optie is, maar wellicht neemt dat onnodig veel ruitme in beslag tov een DATE?
 
Ward van der Put
Moderator

Ward van der Put

20/06/2013 20:41:44
Quote Anchor link
Dan zou ik nog een TIMESTAMP aanbevelen. Vergeleken met een VARCHAR(255) of TINYTEXT kun je de benodigde ruimte verwaarlozen en je benut zowel op oudere als nieuwere databaseservers de speciale functionaliteit.

Dat je de dag of tijd vervolgens (nog) niet gebruikt, maakt niet veel uit, maar sluit nauwkeurigere functionaliteit ook niet bij voorbaat al uit.
 

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.