castorp
Datenbank-Guru
- Beiträge
- 616
UNIX epoch statt korrektem Datentyp timestamp?
- Ersteller castorp
- Erstellt am
- Status
Werbung:
dabadepdu
Datenbank-Guru
- Beiträge
- 1.700
OT
Dass der TE nicht anders kann, würde ich ja einfach mal glauben.
Wenn die Bemerkung zu Epoch Mania oben stimmt, kann ich nicht anders als an den ganzen noSQL Kram zu denken, an PHP vielleicht/bspw. und ein wenig auch an Linux. Wenn man die System bedingte "Typ Schwäche" einer noSQL Engine wie mongoDB nimmt, wo man eigentlich erstmal nur mit Strings und Zahlen arbeitet (und Boolean), kann ich mir gut vorstellen, dass dort eine Ursache liegt.
Wenn das Speichern eines Timestamps oder "Schlimmeres" eigentlich darauf hinaus läuft, dass immer mit JSON (oder BSON) komplexe Strukturen abgebildet werden müssen und ich bei der Weiterverarbeitung dann ebenfalls damit klar kommen muss, kommt einem eine "plumpe" Unix Epoche in Form einer Ganzzahl doch scheinbar gelegen.
Das Netz ist voll mit teilweise uralten Simpelbeispielen und die angesagte Microservice Strategie spielt da vielleicht auch rein. Schnell eine Anwendung zusammengebastelt mit einer Dokument DB, die erstmal geduldig alles schluckt. Später geht dann das Theater los mit Auswertungen, Workflows, Weiterverarbeitung, nicht zu reden von dem Müll, der sich dank Versionsupdates, Fehleingaben usw. in den Daten gesammelt hat. Würde mich nicht wundern, wenn es so ist.
Ist das wirklich so? Und wenn ja, warum?
Dass der TE nicht anders kann, würde ich ja einfach mal glauben.
Wenn die Bemerkung zu Epoch Mania oben stimmt, kann ich nicht anders als an den ganzen noSQL Kram zu denken, an PHP vielleicht/bspw. und ein wenig auch an Linux. Wenn man die System bedingte "Typ Schwäche" einer noSQL Engine wie mongoDB nimmt, wo man eigentlich erstmal nur mit Strings und Zahlen arbeitet (und Boolean), kann ich mir gut vorstellen, dass dort eine Ursache liegt.
Wenn das Speichern eines Timestamps oder "Schlimmeres" eigentlich darauf hinaus läuft, dass immer mit JSON (oder BSON) komplexe Strukturen abgebildet werden müssen und ich bei der Weiterverarbeitung dann ebenfalls damit klar kommen muss, kommt einem eine "plumpe" Unix Epoche in Form einer Ganzzahl doch scheinbar gelegen.
Das Netz ist voll mit teilweise uralten Simpelbeispielen und die angesagte Microservice Strategie spielt da vielleicht auch rein. Schnell eine Anwendung zusammengebastelt mit einer Dokument DB, die erstmal geduldig alles schluckt. Später geht dann das Theater los mit Auswertungen, Workflows, Weiterverarbeitung, nicht zu reden von dem Müll, der sich dank Versionsupdates, Fehleingaben usw. in den Daten gesammelt hat. Würde mich nicht wundern, wenn es so ist.
- Beiträge
- 494
Ein grausames Thema. Selbst die Forensoftware die wir hier aktuell im Einsatz haben speichert Datum+Zeit als int, obwohl die Software neu geschrieben wurde. Was für ein unfassbarer Krampf das ist muss ich hier nicht betonen.
Leider bekommen selbst neue Programmierer das noch von älteren Programmierern und Tutorialseiten beigebracht.
Leider bekommen selbst neue Programmierer das noch von älteren Programmierern und Tutorialseiten beigebracht.
castorp
Datenbank-Guru
- Beiträge
- 616
Schau Dir mal die Frequenz dieser Fragen auf Stackoverflow an:
Code:
https://stackoverflow.com/search?tab=newest&q=sql epoch unix timestamp(Sorry für die Code tags, aber ich habe nicht gefunden, wie man verhindert, dass die URL umgewandelt wird)
dabadepdu
Datenbank-Guru
- Beiträge
- 1.700
Die SO Suche liefert 111 Ergebnis, einen ausgeprägten Trend (es wird immer schlimmer) erkennt man über die Jahre aber nicht so recht, finde ich.
Interessant, wenn man bei der Suche "sql" gegen "mongodb" tauscht. Immerhin 55 Ergebnisse! Das obwohl der Begriff sehr viel spezifischer ist.
Es gibt keine eine andere, nennenswerte noSQL DB, die an die 55 ran kommt (hab ne Handvoll probiert).
Spricht das für die starke Verbreitung von mongoDB? Oder für die Größe des Problems?
Ich habe leider so gut wie keine Erfahrung Richtung noSQL außer mit mongoDB. Andererseits, die reichen mir eigentlich auch. Vielleicht bin ich aber auch einfach nicht tief genug eingetaucht und das RDBMS Wissen überwiegt, ich persönlich würde freiwillig ein solches System nicht einsetzen.
Wenn ich mir vorstelle, ich würde ohne RDBMS Wissen mit noSQL beginnen, dann säße ich sicher mit vielen im gleichen Boot, die epoch unix und anderen Mist anwenden. Von daher kann ich die vielen Fragen jedenfalls verstehen.
Was ich andererseits nicht verstehen könnte, wenn solche Fragen im Zusammenhang mit SQL bzw. klassischen RDBMS zunehmen. Denn hier gibt es wesentlich angenehmeren Umgang mit Date/Timestamps und diversen anderen Typen. Obwohl es da ja dank damals teuerem Speicherplatz auch eine dunkle Vergangenheit gab. Später dann die Persistenzmapper, die es sich auch teilweise recht einfach gemacht haben.
Und ja, Forensoftware basiert auf PHP/mySQL hat die Lage wahrscheinlich auch nicht verbessert.
Interessant, wenn man bei der Suche "sql" gegen "mongodb" tauscht. Immerhin 55 Ergebnisse! Das obwohl der Begriff sehr viel spezifischer ist.
Es gibt keine eine andere, nennenswerte noSQL DB, die an die 55 ran kommt (hab ne Handvoll probiert).
Spricht das für die starke Verbreitung von mongoDB? Oder für die Größe des Problems?
Ich habe leider so gut wie keine Erfahrung Richtung noSQL außer mit mongoDB. Andererseits, die reichen mir eigentlich auch. Vielleicht bin ich aber auch einfach nicht tief genug eingetaucht und das RDBMS Wissen überwiegt, ich persönlich würde freiwillig ein solches System nicht einsetzen.
Wenn ich mir vorstelle, ich würde ohne RDBMS Wissen mit noSQL beginnen, dann säße ich sicher mit vielen im gleichen Boot, die epoch unix und anderen Mist anwenden. Von daher kann ich die vielen Fragen jedenfalls verstehen.
Was ich andererseits nicht verstehen könnte, wenn solche Fragen im Zusammenhang mit SQL bzw. klassischen RDBMS zunehmen. Denn hier gibt es wesentlich angenehmeren Umgang mit Date/Timestamps und diversen anderen Typen. Obwohl es da ja dank damals teuerem Speicherplatz auch eine dunkle Vergangenheit gab. Später dann die Persistenzmapper, die es sich auch teilweise recht einfach gemacht haben.
Und ja, Forensoftware basiert auf PHP/mySQL hat die Lage wahrscheinlich auch nicht verbessert.
castorp
Datenbank-Guru
- Beiträge
- 616
Naja, die Suche in SO ist ziemlich grottig.
Wenn man Google nimmt um die Seite zu durchsuchen, wird's schon deutlicher - da gibt's über 17000 Treffern für "sql epoch site:stackoverflow.com" und über 27000 für "sql unix timestamp site:stackoverflow.com"
Gefühlt, sehe ich Fragen diesbezüglich mindestens einmal wöchentlich auf SO
Wenn man Google nimmt um die Seite zu durchsuchen, wird's schon deutlicher - da gibt's über 17000 Treffern für "sql epoch site:stackoverflow.com" und über 27000 für "sql unix timestamp site:stackoverflow.com"
Gefühlt, sehe ich Fragen diesbezüglich mindestens einmal wöchentlich auf SO
Werbung:
dabadepdu
Datenbank-Guru
- Beiträge
- 1.700
Gut, es würde mich ja auch nicht wundern. Besonders, wenn es mit z.B. noSQL und dem Wachstum in der Ecke korreliert. Genau das "gefühlte" fand ich spannend, Erfahrungswerte usw.
Ich halte nicht viel von noSQL Systemen, und ich kann verstehen, dass dort viele Fragen entstehen. Erst Recht ohne andere Einblicke gehabt zu haben.
Ich halte nicht viel von noSQL Systemen, und ich kann verstehen, dass dort viele Fragen entstehen. Erst Recht ohne andere Einblicke gehabt zu haben.
- Status