Dumme Datenbank & schlaues Programm vs. schlaue Datenbank & dummes Programm

[p80286]

Zitat:

Zitat von jobo (Beitrag 1361753)

Die dumme Datenbank hingegen wird da trotz ihres Potentials gerne ignoriert, oft schafft man es nicht mal ein Datumswert wie z.B. Geburtstag mit einem Datetyp in die Tabelle aufzunehmen...

Was bitte ist ein Datetyp? :stupid:

Gruß
K-H

[Lemmy]

Zitat:

oft schafft man es nicht mal ein Datumswert wie z.B. Geburtstag mit einem Datetyp in die Tabelle aufzunehmen...

weil z.B. auf der eGK ein Geburtsdatum auch mal als 00.00.1982 abgelegt sein kann. Viel Spaß beim Speichern in einem TDate Feld.

Zitat:

Zitat von jobo (Beitrag 1361753)

Was ich an dem Thema außerdem spannend finde, dass es so ambivalent für viele ist.

ganz einfach weil es "die" Lösung nicht gibt....

[p80286]

Zitat:

Zitat von Lemmy (Beitrag 1361760)

weil z.B. auf der eGK ein Geburtsdatum auch mal als 00.00.1982 abgelegt sein kann. Viel Spaß beim Speichern in einem TDate Feld.

Interessantes Datum, erinnert mich an Fälle in denen "Sehr geehrte Frau Müller" in der Anrede steht und unter Gender "male"....

Gruß
K-H

[Frickler]

Vielen Dank für die vielen guten Anregungen. Ihr seid echt super!

[jobo]

Zitat:

Zitat von p80286 (Beitrag 1361759)

Zitat:

Zitat von jobo (Beitrag 1361753)

Die dumme Datenbank hingegen wird da trotz ihres Potentials gerne ignoriert, oft schafft man es nicht mal ein Datumswert wie z.B. Geburtstag mit einem Datetyp in die Tabelle aufzunehmen...

Was bitte ist ein Datetyp? :stupid:

Ja, äh also, .. komm wir gehen mal nach draußen...
;)

Zitat:

Zitat von Lemmy (Beitrag 1361760)

Zitat:

oft schafft man es nicht mal ein Datumswert wie z.B. Geburtstag mit einem Datetyp in die Tabelle aufzunehmen...

weil z.B. auf der eGK ein Geburtsdatum auch mal als 00.00.1982 abgelegt sein kann. Viel Spaß beim Speichern in einem TDate Feld.

Zitat:

Zitat von jobo (Beitrag 1361753)

Was ich an dem Thema außerdem spannend finde, dass es so ambivalent für viele ist.

ganz einfach weil es "die" Lösung nicht gibt....

Ja, es gibt ja verschiedene Datumstypen, lass Dir das mal bitte von p80286 erklären. ;)
Aber wofür/gegen spricht das nun?

Und ja, DIE Lösung gibt es nicht, aber wie widersprüchlich viele mit Ihrem Code/Daten da umgehen, erschließt sich mir nicht.

[Lemmy]

Zitat:

Zitat von p80286 (Beitrag 1361763)

Zitat:

Zitat von Lemmy (Beitrag 1361760)

weil z.B. auf der eGK ein Geburtsdatum auch mal als 00.00.1982 abgelegt sein kann. Viel Spaß beim Speichern in einem TDate Feld.

Interessantes Datum, erinnert mich an Fälle in denen "Sehr geehrte Frau Müller" in der Anrede steht und unter Gender "male"....

es gibt halt Länder da wird es mit der Geburtsurkunde nicht so genau genommen. Und wenn jemand nur weiß, dass er in Jahr x geboren wurde, dann kommt so ein Datum zu Stande.

[MichaelT]

Die Welt ist grau.

In dem Zusammenhang wird tatsächlich von Business Logik gesprochen. Sobald man so in die Ecke 4GL reinschnuppert...

Eine persistente Abfrage welche ein Ergebnis liefert ist eine Query. Eine Query ist ähnlich einer View, eigentlich eine parametrierte View. Der SQL Server bildet Querys relativ exakt entlang dieser Definition ab.

In Österreich verwenden wir den Begriff Query eher im Kontext TQuery.SQL nämlich der SQL Abfrage. Delphi Query ist eine selche View, deswegen ist sie in einem Datamodule an sich ganz gut aufgehoben. Eine Query wäre dann schon Teil der Business Logik. In dem Zusammenhang kann die Verwendung einer SP, selbst wenn sie einfachste Aufgaben erfüllt (Konvertieren einer Auftragsnummer zum Zwecke der Präsentation oder dem Export) Teil der Businesslogik werden.

Sie leidet am selben Trouble der immer wieder für Diskussion sorgt. Sie schreiben in der Regel nicht im Rahmen *einer* Anwendung auf eine DB.

Fast alle Delphi DB Komponenten haben mit DB im Kontext dieser Diskussion nicht viel zu tun sondern wären Teil der Businesslogik.

Solange allein ein Informationsmodell absicher gegen den Missbrauch durch eine Applikation (Schutz des Informationsmodell) sind sie in der Regel im Umfeld der Business Logik.

Zitat:

Zitat von haentschman (Beitrag 1361714)

Zitat:

Wir haben auch recht viel der Buissineslogik in der DB

mal ne dumme Frage... :stupid:
Zählt eine SP zur Businesslogik (was man auch im Programm abarbeiten könnte) oder zur Datenbanklogik die eine Abfrage "berechnet".
Vieleicht sollte man das mal definitionstechnisch klarstellen. :wink:

[bra]

Was hier als Kriterium seltsamerweise noch gar nicht zur Sprache kam ist, welche Datenbanken überhaupt unterstützt werden. Wenn man sich nur auf eine spezielle konzentriert ist es sicher weniger ein Problem die Logik in der Datenbank unterzubringen, als wenn man verschiedene Datenbanken unterstützt.

[p80286]

Zitat:

Zitat von Lemmy (Beitrag 1361770)

Zitat:

Zitat von p80286 (Beitrag 1361763)

Zitat:

Zitat von Lemmy (Beitrag 1361760)

weil z.B. auf der eGK ein Geburtsdatum auch mal als 00.00.1982 abgelegt sein kann. Viel Spaß beim Speichern in einem TDate Feld.

Interessantes Datum, erinnert mich an Fälle in denen "Sehr geehrte Frau Müller" in der Anrede steht und unter Gender "male"....

es gibt halt Länder da wird es mit der Geburtsurkunde nicht so genau genommen. Und wenn jemand nur weiß, dass er in Jahr x geboren wurde, dann kommt so ein Datum zu Stande.

Verständlich aber trotzdem, Ja und?
wenn eine Person ihr Geburts-(Kalender)-Datum nicht kennt, also diese Information nicht vorliegt, dann wird sie auch nicht eingetragen!
Ja irgendwann 1982 geboren? Wenn diese Information abgespeichert werden soll, daran muß der Designer der DB denken! , dann eben nicht in ein DateField, sondern in ein "YearofBirth"-Feld, und "MonthofBirth" und "Dayofbirth" darf leer (NULL) bleiben.
Sind das Numerische Felder? Kommt darauf an, wenn man mit ihnen rechnen will, wäre es empfehlenswert.

Gruß
K-H

[Benedikt Magnus]

Wenn das Geburtsdatum nicht genau bekannt ist, wird dann nicht (amtlich) eines festgelegt?