Datenumwandlung (truncated)

Hallo,

ich würde gern mit mysql 5.0.27 die Option "STRICT_TRANS_TABLES" benutzen,
damit ich eventuelle Ungereimtheiten schneller erkennen kann. Nun habe ich
ein SQL script, das nicht mehr durchgeht:

CREATE TABLE `users` (
`name` varchar(100) NOT NULL,
`changeDate` bigint(20) NOT NULL
) TYPE = InnoDB;

INSERT INTO `users` (name, changeDate) VALUES ('name1', now());

Das Ergebnis ist Data truncated for column 'changeDate' at row 1 (1265)
Ohne "STRICT_TRANS_TABLES" steht nur 2007 in der Zelle.

Welche Funktion kann ich anwenden, um den now() Wert in ein bigint
umzuwandeln? Ich gehe mal davon aus, das now() ein DateTime Object liefert,
das mit . und - formatiert wird. Kann ich das abschalten?

Danke
Per

Re: Datenumwandlung (truncated)

Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de

Re: Datenumwandlung (truncated)

Am 18.01.2007 09:59 schrieb Andreas Kretschmer:
> begin Per Newgro schrieb:
>> Hallo,
>>
>> ich würde gern mit mysql 5.0.27 die Option "STRICT_TRANS_TABLES" benutzen,
>> damit ich eventuelle Ungereimtheiten schneller erkennen kann. Nun habe ich
>> ein SQL script, das nicht mehr durchgeht:
>>
>> CREATE TABLE `users` (
>> `name` varchar(100) NOT NULL,
>> `changeDate` bigint(20) NOT NULL
>
> Warum in aller Welt tendieren MySQL User immer wieder dazu, komplett
> flasche Datentypen zu verwenden?

Keine Ahnung. Vermutlich, weil sie denken, Datenbanken seien dieselbe
Art von Spielzeug wie HTML-Seiten - schließlich gibt's beides für lau
bei ihrem Hoster?

> Ein Datum ist ein Datum und kein
> String, mit einem Datum kann man rechnen etc., nicht mit einem String.

Unbenommen - aber wo siehst Du da oben einen STRING, der als Datum
verwendet würde? Ich sehe BIGINT, und damit *kann* man rechnen, oder?

> Lies das Handbuch. Ich kenne von PostgreSQL Typen für Datum und Zeit
> (timestamp, timestamptz, date) und Dinge wie CURRENT_DATE, CURRENT_TIME,
> now() etc. zur Abfrage und Funktionen wie to_char() zur Formatierung.
> MySQL hat das auch.

Genau.

Re: Datenumwandlung (truncated)

Andreas Kretschmer wrote:

> begin Per Newgro schrieb:
>> Hallo,
>>
>> ich würde gern mit mysql 5.0.27 die Option "STRICT_TRANS_TABLES"
>> benutzen, damit ich eventuelle Ungereimtheiten schneller erkennen kann.
>> Nun habe ich ein SQL script, das nicht mehr durchgeht:
>>
>> CREATE TABLE `users` (
>> `name` varchar(100) NOT NULL,
>> `changeDate` bigint(20) NOT NULL
>
> Warum in aller Welt tendieren MySQL User immer wieder dazu, komplett
> flasche Datentypen zu verwenden? Ein Datum ist ein Datum und kein
> String, mit einem Datum kann man rechnen etc., nicht mit einem String.
String?? Ich dachte ein BigInt ist ein Integer. Die Datenbank soll für mich
einen eindeutigen Schlüssel beim Speichern generieren, damit ich nicht
immer so eine lange Zahl hinschreiben muss (Faulheit). Vom Rechnen habe ich
gar nichts geschrieben.
Sorry aber bitte lasse Deinen Frust nicht an mir aus. Wenn Du ein Problem
mit meiner Frage hast, antworte bitte einfach nicht. Danke

>
>> ) TYPE = InnoDB;
>>
>> INSERT INTO `users` (name, changeDate) VALUES ('name1', now());
>>
>> Das Ergebnis ist Data truncated for column 'changeDate' at row 1 (1265)
>> Ohne "STRICT_TRANS_TABLES" steht nur 2007 in der Zelle.
>>
>> Welche Funktion kann ich anwenden, um den now() Wert in ein bigint
>> umzuwandeln? Ich gehe mal davon aus, das now() ein DateTime Object
>> liefert, das mit . und - formatiert wird. Kann ich das abschalten?
>
> Nein. now() liefert Dir einen Zeitwert. Die Formatierung ist Aufgabe der
> Ausgabe, der Darstellung. Aber nicht der Speicherung.
>
>
> Lies das Handbuch. Ich kenne von PostgreSQL Typen für Datum und Zeit
> (timestamp, timestamptz, date) und Dinge wie CURRENT_DATE, CURRENT_TIME,
> now() etc. zur Abfrage und Funktionen wie to_char() zur Formatierung.
> MySQL hat das auch.
Danke. Das wollte ich wissen.

Cheers
Per

Re: Datenumwandlung (truncated)

Christian Kirsch wrote:

> Am 18.01.2007 09:59 schrieb Andreas Kretschmer:
>> begin Per Newgro schrieb:
>>> Hallo,
>>>
>>> ich würde gern mit mysql 5.0.27 die Option "STRICT_TRANS_TABLES"
>>> benutzen, damit ich eventuelle Ungereimtheiten schneller erkennen kann.
>>> Nun habe ich ein SQL script, das nicht mehr durchgeht:
>>>
>>> CREATE TABLE `users` (
>>> `name` varchar(100) NOT NULL,
>>> `changeDate` bigint(20) NOT NULL
>>
>> Warum in aller Welt tendieren MySQL User immer wieder dazu, komplett
>> flasche Datentypen zu verwenden?
>
> Keine Ahnung. Vermutlich, weil sie denken, Datenbanken seien dieselbe
> Art von Spielzeug wie HTML-Seiten - schließlich gibt's beides für lau
> bei ihrem Hoster?
>
OMG. Der nächste. Nur das ich auch von HTML und Hoster kein Wort geschrieben
habe. Ich meine, Entschuldigung für jeden der nicht eine Guru-Frage ins
Forum schreibt. Aber vielleicht sollten wir einfach eine Noob-NG aufmachen,
in die ihr zwei nicht unbedingt reinschauen und damit nicht auf
solche "dummen" Fragen antworten müßt. Im übrigen führen viele Wege nach
Rom - insbesondere beim programmieren. Und man sollte ein Problem nicht
komplizierter lösen als es sein muß. Die Entscheidung für oder gegen einen
Datentyp gehört m.E. nach dazu. Sonst würde es ja auch ein Tool geben, das
aus meinen Anforderungen ein SQL-Statement baut.

>> Ein Datum ist ein Datum und kein
>> String, mit einem Datum kann man rechnen etc., nicht mit einem String.
>
> Unbenommen - aber wo siehst Du da oben einen STRING, der als Datum
> verwendet würde? Ich sehe BIGINT, und damit *kann* man rechnen, oder?
>
>> Lies das Handbuch. Ich kenne von PostgreSQL Typen für Datum und Zeit
>> (timestamp, timestamptz, date) und Dinge wie CURRENT_DATE, CURRENT_TIME,
>> now() etc. zur Abfrage und Funktionen wie to_char() zur Formatierung.
>> MySQL hat das auch.
>
> Genau.

Sorry für die erboste Art.
Cheers
Per

Re: Datenumwandlung (truncated)

Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de

Re: Datenumwandlung (truncated)

Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de

Re: Datenumwandlung (truncated)

Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de

Re: Datenumwandlung (truncated)

Am 18.01.2007 10:11 schrieb Per Newgro:
> Andreas Kretschmer wrote:
>
>> begin Per Newgro schrieb:
....
>>>
>>> CREATE TABLE `users` (
>>> `name` varchar(100) NOT NULL,
>>> `changeDate` bigint(20) NOT NULL
>> Warum in aller Welt tendieren MySQL User immer wieder dazu, komplett
>> flasche Datentypen zu verwenden? Ein Datum ist ein Datum und kein
>> String, mit einem Datum kann man rechnen etc., nicht mit einem String.
> String?? Ich dachte ein BigInt ist ein Integer. Die Datenbank soll für mich
> einen eindeutigen Schlüssel beim Speichern generieren, damit ich nicht
> immer so eine lange Zahl hinschreiben muss (Faulheit).

Gute Idee, sich von der Datenbank einen eindeutigen Schlüssel
generieren zu lassen. Aber warum in aller Welt HINDERST Du sie daran?
Was ist an einem Zeitstempel in der realen Welt eindeutig?

MySQL bietet z.B. auto_increment-Spalten für genau diesen Zweck. Wenn
Dir das zu einfach ist, kannst Du m.W. auch sowas wie UUID verwenden.

> Vom Rechnen habe ich
> gar nichts geschrieben.
> Sorry aber bitte lasse Deinen Frust nicht an mir aus. Wenn Du ein Problem
> mit meiner Frage hast, antworte bitte einfach nicht. Danke

Und Dir wäre dann geholfen, wenn Dir niemand auf Deine Frage
antwortet? Warum stellst Du sie dann?

Re: Datenumwandlung (truncated)

Andreas Kretschmer wrote:

> begin Per Newgro schrieb:
>> String?? Ich dachte ein BigInt ist ein Integer. Die Datenbank soll für
>> mich einen eindeutigen Schlüssel beim Speichern generieren, damit ich
>> nicht immer so eine lange Zahl hinschreiben muss (Faulheit). Vom Rechnen
>> habe ich gar nichts geschrieben.
>
> Für sowas nimmt man dann wohl eher einen SERIAL-Typ. Autoincrement nennt
> sich das wohl bei MySQL. Und man deklariert das dann auch als primary
> key und/oder legt einen unique index drauf.
>
>
> end
> Andreas
Danke. Allerdings soll die DB mir nur beim Speichern in diesem Script einen
Schlüssel generieren. Sonst macht es die Applikation. Und was da gemacht
wird, ist m.M.n. eine andere Frage. Hier wollte ich nur ein kleines
Problem, möglichst einfach lösen. Und das einfügen von now() in die INSERT
Statements in diesem Script erschien mir einfacher als in allen INSERT
Statements 123456789012345 usw. zu schreiben. Now() ging nur leider nicht
und deshalb wollte ich das Ergebnis zu einem integer umwandeln.

Trotzdem Danke
Per

PS (OT): Bei meinem nächsten Post (sollte es nochmal eins geben) werde ich
meinen Lebenslauf, meine Appl-Anforderungen und einen Überblick über meine
gelesenen Bücher mit anhängen.

Re: Datenumwandlung (truncated)

Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de

Re: Datenumwandlung (truncated)

Per Newgro schrieb:

> Andreas Kretschmer wrote:
>
>> begin Per Newgro schrieb:

Er kann es einfach nicht lassen, der Kindskopf ...

>>> String?? Ich dachte ein BigInt ist ein Integer.

Da wird Andreas wohl etwas falsch gelesen haben.

>>> Die Datenbank soll für
>>> mich einen eindeutigen Schlüssel beim Speichern generieren

Dann sag das der Datenbank.

>> Für sowas nimmt man dann wohl eher einen SERIAL-Typ. Autoincrement nennt
>> sich das wohl bei MySQL.

AUTO_INCREMENT, um korrekt zu sein.

> Danke. Allerdings soll die DB mir nur beim Speichern in diesem Script einen
> Schlüssel generieren.

Genau dafür ist AUTO_INCREMENT da.

> Hier wollte ich nur ein kleines
> Problem, möglichst einfach lösen.

Noch einfacher als mit AUTO_INCREMENT?

> Und das einfügen von now() in die INSERT

now() erzeugt mitnichten einen eindeutigen Key.

> PS (OT): Bei meinem nächsten Post (sollte es nochmal eins geben) werde ich
> meinen Lebenslauf, meine Appl-Anforderungen und einen Überblick über meine
> gelesenen Bücher mit anhängen.

Was soll das? Ist das der Dank für ernst gemeinte Hilfe?

Wenn Du mit den Hinweisen, die Du hier bekommen hast, nichts anfangen
kannst, solltest Du einfach nochmal nachfragen. Das wäre jedenfalls
besser als solch einen polemischen Blödsinn zu schreiben!

Gruß. Claus
--
,~°O O
O ,´ / |/|\
/ |¯`. Das neue Hochzeits-Branchenbuch im Internet ,´ / | |\
/__| `~...............................................~´ /___|/ /

Re: Datenumwandlung (truncated)

Per Newgro schrieb:

>>>CREATE TABLE `users` (
>>>`name` varchar(100) NOT NULL,
>>>`changeDate` bigint(20) NOT NULL
>>
>>Warum in aller Welt tendieren MySQL User immer wieder dazu, komplett
>>flasche Datentypen zu verwenden? Ein Datum ist ein Datum und kein
>>String, mit einem Datum kann man rechnen etc., nicht mit einem String.
>
> String?? Ich dachte ein BigInt ist ein Integer. Die Datenbank soll für mich
> einen eindeutigen Schlüssel beim Speichern generieren, damit ich nicht
> immer so eine lange Zahl hinschreiben muss (Faulheit).

Was verstehst Du unter eindeutig? Wie im Fred bereits geschrieben wurde:
wenn Du bei jedem 'INSERT' einen eindeutigen Identifikator pro Zeile
benötigst, definiere eine Integer-Spalte mit hinreichend großem
Wertebereich und setze das Attribut 'auto_increment'.

Sollten bei Deiner Lösung zwei 'INSERT's in der gleichen Sekunde
abgearbeitet werden, ist auch der Wert in der Datumsspalte in beiden
Zeilen identisch.

HTH
Lars

Re: Datenumwandlung (truncated)

Per Newgro wrote:
> Welche Funktion kann ich anwenden, um den now() Wert in ein bigint
> umzuwandeln? Ich gehe mal davon aus, das now() ein DateTime Object liefert,
> das mit . und - formatiert wird. Kann ich das abschalten?

UNIX_TIMESTAMP(NOW()) - dann hast Du die Zeit in UNIX-Epoch (Sekunde
seit 1.1.1970 0h00). Das ist in der realen Welt, in der man die
Datenbank als Hilfsmittel fuer eine Applikation sieht und nicht als
Erfuellung ihrer selbst, zumeist eh die deutlich praktischere
Groesse.

Re: Datenumwandlung (truncated)

Hallo Sven Paulus,

> UNIX_TIMESTAMP(NOW()) - dann hast Du die Zeit in UNIX-Epoch (Sekunde
> seit 1.1.1970 0h00).
Genau sowas habe ich gesucht. Und funktionieren tut es auch noch ;-).

> Das ist in der realen Welt, in der man die
> Datenbank als Hilfsmittel fuer eine Applikation sieht und nicht als
> Erfuellung ihrer selbst, zumeist eh die deutlich praktischere
> Groesse.
Wenigstens einer versteht mich. Danke dafür.

Cheers
Per

Re: Datenumwandlung (truncated)

Hallo Claus,

Wozu schreibst Du alles doppelt? Alle Hinweise wurden doch vorher schon
gegeben. Das now() den eindeutigen Schlüssel nicht erzeugt ist ja
offensichtlich mein Problem gewesen. Und wie ich schon mehrfach erwähnt
habe, geht es nur um ein Feld das ich mit einem Skript füllen will. Ich
habe nie von Strings, HTML, Indexen, automatischem Inkrementieren usw.
geschrieben. Das MySQL das kann, konnte ich im Handbuch nachlesen, das ich
nach dem Hinweis im 1. und 2. Post sofort angefangen habe.

>> PS (OT): Bei meinem nächsten Post (sollte es nochmal eins geben) werde
>> ich meinen Lebenslauf, meine Appl-Anforderungen und einen Überblick über
>> meine gelesenen Bücher mit anhängen.
>
> Was soll das? Ist das der Dank für ernst gemeinte Hilfe?
Nein, nur für überflüssige Kommentare, die dann auch noch auf "Verlesern"
beruhen. Aber Schwamm drüber.

>
> Wenn Du mit den Hinweisen, die Du hier bekommen hast, nichts anfangen
> kannst, solltest Du einfach nochmal nachfragen. Das wäre jedenfalls
> besser als solch einen polemischen Blödsinn zu schreiben!
Das gilt hoffentlich nicht nur für mein Post. Im übrigen darf Satire
übertreiben :-). Und ich bin hocherfreut, das die NG auch noch von Usern
gelesen werden, die anderen wirklich helfen wollen (s. Post von Sven
Paulus).

Cheers
Per

PS: Damit würde ich den Thread gerne schliessen. Sonst müssten wir die
Diskussion wohl in eine andere NG (Ethik, Usenet-Regeln oder so)
verschieben.

Re: Datenumwandlung (truncated)

Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de

Re: Datenumwandlung (truncated)

> Du hast noch nicht verstanden, daß das knallt, wenn es 2 Ereignisse in
> derselben Sekunde gibt. Das ist also eine Zeitbombe.
Aber es knallt doch nur wenn ein Index drauf liegt. Ist aber nicht so. Ich
weiss das es knallen würde. Aber normalerweise erzeugt meine Applikation
die Werte (java: currentTimeMillis im Thread mit wait). Da ich aber nur ein
kleines Skript ausführe, mit ein paar Inserts, die auf verschiedenen
Tabellen arbeiten und ich in ein Feld einen langen Wert einfügen muss,
dachte ich nehme ich now(). Ohne strict tables ging auch alles. Nur mit
strict tables ist es mir aufgefallen, das da was schief läuft ( mit dem
Script, nicht der Appl)

Cheers
Per

Re: Datenumwandlung (truncated)

Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de

Re: Datenumwandlung (truncated)

Am 18.01.2007 13:29 schrieb Per Newgro:
>> Du hast noch nicht verstanden, daß das knallt, wenn es 2 Ereignisse in
>> derselben Sekunde gibt. Das ist also eine Zeitbombe.
> Aber es knallt doch nur wenn ein Index drauf liegt. Ist aber nicht so.

Liest Du, was Du selber schreibst? Ich zitiere Dich mal, damit Du
nicht nachgucken musst:

>> Die Datenbank soll für mich
>> einen eindeutigen Schlüssel beim Speichern generieren,

Du schreibst "eindeutig" und Du schreibst "Schlüssel". Das ist in
meiner Welt ein Unique Key, und der "knallt" schon, wenn kein "Index
drauf liegt".

> Ich
> weiss das es knallen würde. Aber normalerweise erzeugt meine Applikation
> die Werte (java: currentTimeMillis im Thread mit wait). Da ich aber nur ein
> kleines Skript ausführe, mit ein paar Inserts, die auf verschiedenen
> Tabellen arbeiten und ich in ein Feld einen langen Wert einfügen muss,
> dachte ich nehme ich now().

UUID, wie gesagt.