Kolom aanpassen met waardes

[FlippieAI]

Hallo,

Ik ben bezig om in een tabel, genaamd nieuws, een kolom aan te passen. Deze kolom heet year en heeft ook het type "year". Nu moet deze kolom veranderd worden naar het type "date" en de naam date krijgen.

Dit probeer ik met de volgende regel:

MySQL:

ALTER TABLE nieuws
 CHANGE year date date;

Hier krijg ik dus logischerwijs de foutmelding: #1292 - Incorrect date value: '2011' for column 'date' at row 1
Ik snap dat dit fout gaat omdat het formaat niet klopt met het nieuwe kolomtype. Nu vraag ik mij dus af of er een manier is om te zorgen dat de jaartallen niet verloren gaan maar dat de velden als volgt veranderen:
2010 wordt 2010-01-01
2011 wordt 2011-01-01
enz..

Is dit mogelijk?

[thof]

Kun je niet een nieuwe tijdelijke tabel aan maken, daar een INSERT INTO SELECT FROM achtige query naar laten schrijven en vervolgens de oude tabel wissen en de nieuwe tabel renamen naar de juiste naam=

[FlippieAI]

Aan zo'n soort oplossing zat ik ook al te denken, maar daarbij liep ik tegen het volgende aan. Dit had ik tot zo ver:

MySQL:

ALTER TABLE nieuws
 ADD date date;

UPDATE nieuws
 SET date = year.'-01-01';

ALTER TABLE nieuws
 DROP COLUMN year;

Nu gaat het dus fout bij de update, omdat deze manier niet mag. Ik kan alleen zo snel niet vinden hoe ik dit wel moet noteren?
Ik weet dat het bijvoorbeeld wel werkt met integers, bijvoorbeeld: veld = veld+2. Maar is dit ook mogelijk om er tekst bij aan te plakken? Of zoals in dit geval, een stukje datum op basis van het andere veld?

[Verwijderd]

http://dev.mysql.com/doc/...ions.html#function_concat

[Rotterdammertje]

Ga naar Google, zoek "mysql date function". De eerste pagina is deze. Halverwege de lijst van functies staat de functie "MAKEDATE()". Dat klinkt wel alsof het zou kunnen werken! Serieus, een halve minuut uitzoekwerk.

[TheNephilim]

Moeten er niet ` (onder tilde op tobo) om de haakjes? Alleen waar je em als naam gebruikt. Je gebruikt date als een naam voor je tabel maar het is ook een beschermde naam in MySQL XD

[ Voor 11% gewijzigd door TheNephilim op 02-02-2012 13:20 ]

[Rotterdammertje]

Het is meestal geen goed idee om gereserveerde woorden als tabel- of kolomnaam te gebruiken (vandaar dat ze ook gereserveerd zijn). Ik zou de kolom iets van 'publication_date' noemen.

Ook: gebruik de date en datetime functies van mySQL als je werkt met dates en datetimes. Je kan ook strings gebruiken en hopen dat mySQL die goed voor je vertaalt, maar het is vragen om problemen: code die wel werkt op een Nederlands systeem, maar niet op een Engels, bijvoorbeeld, omdat daar het datumformaat anders is; onduidelijkheid over datums als '2012-03-04': is dit nu 4 maart of 3 april? Door gebruik te maken van functies als MAKEDATE hef je al die onduidelijkheid op.

Een date is geen string, en een string is geen date.

[RobIII]

Rotterdammertje schreef op donderdag 02 februari 2012 @ 16:58:
Het is meestal geen goed idee om gereserveerde woorden als tabel- of kolomnaam te gebruiken (vandaar dat ze ook gereserveerd zijn). Ik zou de kolom iets van 'publication_date' noemen.

Onzin; ik vertik 't om in, bijvoorbeeld, mijn reserveringen-tabel een field reservation_date te noemen als date volstaat. Wie zegt mij dat reservation_date in de volgende versie van RDBMS-X niet ook een reserved word is? (nu zal reservation_ niet snel gebruikt worden, maar pak een event_date of ...). Kwestie van aanwennen je fields gewoon consequent te escapen; voor MySQL is dat `date` en voor MSSQL [date] en voor elk ander RDBMS zijn weer andere regeltjes. Idealiter laat je dat escapen dan ook gewoon over aan je DAL of ORM of whatever.

Rotterdammertje schreef op donderdag 02 februari 2012 @ 16:58:
Ook: gebruik de date en datetime functies van mySQL als je werkt met dates en datetimes. Je kan ook strings gebruiken en hopen dat mySQL die goed voor je vertaalt, maar het is vragen om problemen: code die wel werkt op een Nederlands systeem, maar niet op een Engels, bijvoorbeeld, omdat daar het datumformaat anders is; onduidelijkheid over datums als '2012-03-04': is dit nu 4 maart of 3 april? Door gebruik te maken van functies als MAKEDATE hef je al die onduidelijkheid op.

Of je zorgt dat je consequent werkt met ISO8601.

Rotterdammertje schreef op donderdag 02 februari 2012 @ 16:58:
Een date is geen string, en een string is geen date.

Een Customer is ook geen string maar er komt een moment dat je bepaalde zaken als een native type moet gaan opslaan; bij (de)serialisatie bijvoorbeeld en dan heb je dus net zo goed te maken met het interpreteren van strings naar dates of Customers of...

[ Voor 4% gewijzigd door RobIII op 02-02-2012 17:27 ]

[FlippieAI]

Verwijderd schreef op woensdag 01 februari 2012 @ 21:53:
http://dev.mysql.com/doc/...ions.html#function_concat

Bedankt! Hiermee is het gelukt!

Rotterdammertje schreef op donderdag 02 februari 2012 @ 09:52:
Ga naar Google, zoek "mysql date function". De eerste pagina is deze. Halverwege de lijst van functies staat de functie "MAKEDATE()". Dat klinkt wel alsof het zou kunnen werken! Serieus, een halve minuut uitzoekwerk.

Beter lezen aub...

TheNephilim schreef op donderdag 02 februari 2012 @ 13:20:
Moeten er niet ` (onder tilde op tobo) om de haakjes? Alleen waar je em als naam gebruikt. Je gebruikt date als een naam voor je tabel maar het is ook een beschermde naam in MySQL XD

Hiervan ben ik op de hoogte. In mijn geval gaf dit geen problemen.

[BtM909]

FlippieAI schreef op donderdag 02 februari 2012 @ 20:34:

Beter lezen aub...

Of jij... Er zijn meerdere wegen naar Rome

[Rotterdammertje]

RobIII schreef op donderdag 02 februari 2012 @ 17:25:
[...]

Onzin; ik vertik 't om in, bijvoorbeeld, mijn reserveringen-tabel een field reservation_date te noemen als date volstaat. Wie zegt mij dat reservation_date in de volgende versie van RDBMS-X niet ook een reserved word is? (nu zal reservation_ niet snel gebruikt worden, maar pak een event_date of ...). Kwestie van aanwennen je fields gewoon consequent te escapen; voor MySQL is dat `date` en voor MSSQL [date] en voor elk ander RDBMS zijn weer andere regeltjes. Idealiter laat je dat escapen dan ook gewoon over aan je DAL of ORM of whatever.

Dat jij het vertikt, en geen probleem hebt met generieke kolomnamen, wil niet zeggen dat het onzin is. Dat wil zeggen dat jouw voorkeur ergens anders naar uitgaat. Wat als je nu bij je reserveringen ook een aanmaakdatum en een wijzigdatum wil opslaan? Of een afzegdatum? Dan kan je al je code doorlopen om alsnog je generieke 'date' kolom om te gaan zetten naar 'reservation_date' -- of 'visit_date' of zo, om aan te geven dat het de datum is waarop de gasten langskomen.

Afgezien van technische problemen, is er ook een semantisch probleem: als ik een kolom 'date' zie in een tabel 'reservering', dan weet ik niet wat de betekenis van die datum is. Is dat de datum waarop de reservering is aangemaakt, afgezegd of gewijzigd? Of toch echt de bezoekdatum?

Door je kolommen een iets duidelijker naam te geven, voorkom je al deze problemen. "Onzin" is wel erg kort door de bocht.

Of je zorgt dat je consequent werkt met ISO8601.

En dan hoop je dat je database ook consequent werkt met die standaard. En je hoopt dat de ontwikkelaar die later je code moet onderhouden, ook op de hoogte is van die standaard. En dat hij dus weet dat '2012-03-04' niet 3 april betekent. Door date functies te gebruiken, maak je de betekenis expliciet. En dat wil niet zeggen dat je dan geen gebruik kan maken van ISO8601! Maar maak dan een functie 'DateFromISO8601', die een string in ISO formaat omzet naar een datum. Ook dan maak je expliciet duidelijk wat er gebeurt, in plaats van impliciet aan te nemen dat de database, en de ontwikkelaars na jou, begrijpen dat datums in ISO formaat moeten worden aangeleverd.

Een Customer is ook geen string maar er komt een moment dat je bepaalde zaken als een native type moet gaan opslaan; bij (de)serialisatie bijvoorbeeld en dan heb je dus net zo goed te maken met het interpreteren van strings naar dates of Customers of...

Ik neem aan dat je dan ook zorgt dat bij serialisatie de datums en andere data in hetzelfde formaat worden weggeschreven als dat je het bij de deserialisatie weer verwacht.

[RobIII]

Rotterdammertje schreef op vrijdag 03 februari 2012 @ 09:59:
Dat jij het vertikt, en geen probleem hebt met generieke kolomnamen, wil niet zeggen dat het onzin is. Dat wil zeggen dat jouw voorkeur ergens anders naar uitgaat. Wat als je nu bij je reserveringen ook een aanmaakdatum en een wijzigdatum wil opslaan? Of een afzegdatum? Dan kan je al je code doorlopen om alsnog je generieke 'date' kolom om te gaan zetten naar 'reservation_date' -- of 'visit_date' of zo, om aan te geven dat het de datum is waarop de gasten langskomen.

Afgezien van technische problemen, is er ook een semantisch probleem: als ik een kolom 'date' zie in een tabel 'reservering', dan weet ik niet wat de betekenis van die datum is. Is dat de datum waarop de reservering is aangemaakt, afgezegd of gewijzigd? Of toch echt de bezoekdatum?

Reserveringen was misschien niet 't beste voorbeeld, granted, maar soms is een date gewoon een date. Evenals dat soms een order gewoon een order is -> `order` tabel. Mijn punt was dat je toch consequent moet escapen want je weet niet wat toekomstige versies aan 'reserved words' gebruiken. En zolang je (of je DAL, ORM, whatever) consequent escaped hoef je nooit in te zitten over reserved words

Rotterdammertje schreef op vrijdag 03 februari 2012 @ 09:59:
En dan hoop je dat je database ook consequent werkt met die standaard.

AFAIK begrijpt ieder zichzelf respecterend RDBMS deze notatie. Correct me if I'm wrong.

Rotterdammertje schreef op vrijdag 03 februari 2012 @ 09:59:
En je hoopt dat de ontwikkelaar die later je code moet onderhouden, ook op de hoogte is van die standaard. En dat hij dus weet dat '2012-03-04' niet 3 april betekent.

Ik hoop inderdaad dat mijn collega's competent zijn ja

Rotterdammertje schreef op vrijdag 03 februari 2012 @ 09:59:
Door date functies te gebruiken, maak je de betekenis expliciet. En dat wil niet zeggen dat je dan geen gebruik kan maken van ISO8601! Maar maak dan een functie 'DateFromISO8601', die een string in ISO formaat omzet naar een datum. Ook dan maak je expliciet duidelijk wat er gebeurt, in plaats van impliciet aan te nemen dat de database, en de ontwikkelaars na jou, begrijpen dat datums in ISO formaat moeten worden aangeleverd.

Of je gebruikt parameterized queries, of 101 andere oplossingen. Soms moet je gewoon een string-representatie van een datum hebben die iedereen begrijpt en dan is ISO8601 de enige eenduidige standaard die (haast...) niet verkeerd te interpreteren is. Ikzelf ben iig nog nooit yyyy-dd-mm tegen gekomen.

Rotterdammertje schreef op vrijdag 03 februari 2012 @ 09:59:
Ik neem aan dat je dan ook zorgt dat bij serialisatie de datums en andere data in hetzelfde formaat worden weggeschreven als dat je het bij de deserialisatie weer verwacht.

Als je programma opeens op een andere locale draait (tussen de serialisatie en deserialisatie) bij een klant die een nl-NL systeem heeft terwijl je op en-US hebt ontwikkeld (of andersom) of... ga je de mist in als je niet expliciet bent. Dus ja, bij (de)serialisatie zul je ook expliciet moeten zijn in het formaat ja. En soms heb je helemaal niets te vertellen over serialized data: die krijg je gewoon van partij X of Y aangeleverd en dan is 't zoals 't is. Je kunt dan wel 'vertrouwen' op Date.Parse('04/03/2011') maar ik ben toch liever iets explicieter in wat dan de maand is en wat de dag
Mijn hele point being: 1) escapen 2) expliciet zijn 3) zo veel mogelijk naar 'standaarden' sturen die niet (lastig...) verkeerd te interpreteren zijn.

Having said that, ik denk dat we aardig op 1 lijn zitten en die "onzin" was misschien wat krachtiger dan bedoeld. My bad.

[ Voor 11% gewijzigd door RobIII op 03-02-2012 11:06 ]

[FlippieAI]

BtM909 schreef op donderdag 02 februari 2012 @ 20:43:
[...]

Of jij... Er zijn meerdere wegen naar Rome

I stand corrected

[Remus]

RobIII schreef op vrijdag 03 februari 2012 @ 10:53:
[...]

AFAIK begrijpt ieder zichzelf respecterend RDBMS deze notatie. Correct me if I'm wrong.

Als een database SQL compliant is wel: (uit een draft van SQL2003):

code:

<date string> ::= <quote> <unquoted date string> <quote>
<unquoted date string> ::= <date value>
<date value> ::= <years value> <minus sign> <months value> <minus sign> <days value>

en verder:

26) Within a <datetime literal>, the <years value> shall contain four digits. The <seconds integer value> and other datetime components, with the exception of <seconds fraction>, shall each contain two digits.

[dusty]

RobIII schreef op vrijdag 03 februari 2012 @ 10:53:
[...]
maar soms is een date gewoon een date. Evenals dat soms een order gewoon een order is -> `order` tabel.
[...]

En bedoel je hier dan met 'order' een bestelling of een volgorde?

Soms is een getal ook een getal; noem je de kolom dan ook integer?

Bij heel veel bedrijven is er de regel dat de naam van het kolom moet aangeven wat het doet; een generieke naam als 'date' voldoet dan niet aan de eisen, omdat het aangeeft wat het is maar niet wat het doet. "update_date" toont dat het de datum was dat het was bijgewerkt.

Dit zal ook het inwerken van een nieuwe programmeur(s) in bestaande code vermakkelijken en hoeft die persoon wat minder vaak in de (meestal niet bestaande) documentatie te kijken. Beschrijvende kolom namen maakt echter de onderhoudbaarheid van een programma door andere programmeurs een stuk makkelijker.