AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Datenbanken Delphi Geschlecht in extra Tabelle speichern?
Thema durchsuchen
Ansicht
Themen-Optionen

Geschlecht in extra Tabelle speichern?

Ein Thema von AlexII · begonnen am 25. Nov 2014 · letzter Beitrag vom 26. Nov 2014
Antwort Antwort
Benutzerbild von DeddyH
DeddyH

Registriert seit: 17. Sep 2006
Ort: Barchfeld
27.666 Beiträge
 
Delphi 12 Athens
 
#1

AW: Geschlecht in extra Tabelle speichern?

  Alt 25. Nov 2014, 19:40
Und dann hast Du Deinen Code mal nicht zur Hand, willst in der DB etwas ändern und siehst nur "komische Zahlen". Herzlichen Glückwunsch.
Detlef
"Ich habe Angst vor dem Tag, an dem die Technologie unsere menschlichen Interaktionen übertrumpft. Die Welt wird eine Generation von Idioten bekommen." (Albert Einstein)
Dieser Tag ist längst gekommen
  Mit Zitat antworten Zitat
Benutzerbild von Mavarik
Mavarik

Registriert seit: 9. Feb 2006
Ort: Stolberg (Rhld)
4.165 Beiträge
 
Delphi 10.3 Rio
 
#2

AW: Geschlecht in extra Tabelle speichern?

  Alt 25. Nov 2014, 19:58
Und dann hast Du Deinen Code mal nicht zur Hand, willst in der DB etwas ändern und siehst nur "komische Zahlen". Herzlichen Glückwunsch.
Datenbank ändern? Die ist sowieso verschlüsselt. Da hat keiner was dran zu suchen!
  Mit Zitat antworten Zitat
vagtler

Registriert seit: 9. Jul 2010
Ort: Köln
667 Beiträge
 
Delphi 2010 Professional
 
#3

AW: Geschlecht in extra Tabelle speichern?

  Alt 26. Nov 2014, 06:12
Genau. Wartbarkeit ist was für Pussies.
  Mit Zitat antworten Zitat
Dejan Vu
(Gast)

n/a Beiträge
 
#4

AW: Geschlecht in extra Tabelle speichern?

  Alt 26. Nov 2014, 06:59
Es soll exotische Anwendungen geben, die sogenannte 'Reportingframeworks' verwenden. Gewiss, für altgediente Profis wie Mavarik ist das Kinderkram, aber Amateure wie -sagen wir- SIEMENS setzen doch tatsächlich diese Dinger ein. Da wäre es nun wirklich sinnvoll, wenn man in der Datenbank auch eine Präsentationsschicht hätte (also diese schwachsinnigen VIEW Dinger zum Beispiel), welche einem die kodierten Daten so aufbereitet, daß man die Daten mit einem Reporting-Tool deskriptiv darstellen kann (will sagen: 'Mann' statt false z.B.).

Auch absolute Nischenprodukte, wie z.B. EXCEL, könnten davon profitieren.

Nebenbei sind so bitkodierte Eingeschaften nicht gerade geeignet, um nach ihnen zu selektieren. Es geht zwar, ist aber mühselig.

Genau. Wartbarkeit ist was für Pussies.
Yeah! Gibt eben noch richtige Männerprogrammierer.
  Mit Zitat antworten Zitat
Daniel
(Co-Admin)

Registriert seit: 30. Mai 2002
Ort: Hamburg
13.920 Beiträge
 
Delphi 10.4 Sydney
 
#5

AW: Geschlecht in extra Tabelle speichern?

  Alt 26. Nov 2014, 08:53
[...]Gewiss, für altgediente Profis wie Mavarik ist das Kinderkram, aber Amateure wie -sagen wir- SIEMENS setzen doch tatsächlich diese Dinger ein. [...] Auch absolute Nischenprodukte, wie z.B. EXCEL,
?
Wenn Du das Gefühl hast, nicht zu einer sachlichen Diskussion beitragen zu können, dann verschiebe den Beitrag doch bitte auf später. Solche Beitrag sind nicht hilfreich.
Daniel R. Wolf
mit Grüßen aus Hamburg
  Mit Zitat antworten Zitat
Benutzerbild von Sir Rufo
Sir Rufo

Registriert seit: 5. Jan 2005
Ort: Stadthagen
9.454 Beiträge
 
Delphi 10 Seattle Enterprise
 
#6

AW: Geschlecht in extra Tabelle speichern?

  Alt 26. Nov 2014, 09:33
Auf SO würde diese Frage wohl als Off Topic deklariert werden wegen Primarily Opinion Based

Es ist ja wie ein Glaubenskrieg

Ok, die Frage würde sich eigentlich nicht stellen, wenn die Aufgabe komplett analysiert wäre. Nach der Analyse sollte dann feststehen, ob man eine variable Anzahl an Geschlechtern benötigt oder eben nicht.
  • Wenn die variabel sein muss, dann zwingend eine Tabelle mit den Geschlechtern und alle Referenzen in den Tabellen bekommen einen Foreign Key darauf.
  • Wenn die statisch ist, dann kann der Wert auch einfach durch die Anwendung definiert werden. Ob es dann in der DB ein BitFeld, ein Char oder eine Zahl wird ist völlig egal, die Anwendung muss es nur deuten können.
View oder nicht View

Ist auch eine Glaubensfrage, die sich allerdings nur dann stellt, wenn es direkte Zugriffe auf die Datenbank gibt. Dieses sollte eigentlich schon aus dem Sicherheitsaspekt vermieden werden. Und wenn alle Zugriffe auf den Datentopf eh durch eine Schicht laufen, dann kann diese Schicht auch die passenden Interpretationen für die einzelnen Konsumenten vornehmen.

Der eine braucht für den Mann eine 1 - gut bekommt er, und der ein M - ok und ein anderer benötigt den Wert in der gewählten Sprache - hier hast du "Mann" - und all das kann man aus dem gespeicherten Wert 42 machen und umgekehrt natürlich auch.

Natürlich ist es erheblich schneller, mal eben eine View zusammen klatschen und dann dem Report Zugriff auf diese View zu geben. Aber ist das sicher? Ist das wirklich flexibel? Ist das dann auch besser?

Es kann ausreichend für den Anwendungsfall sein, aber:

Anstatt dem Zugriff auf die View gibt man dem Reporter eine XML/JSON/CSV/was_auch_immer und der baut daraus den Report. Schon ist es dem Report egal, wo er die Daten herbekommt (frisch abgefragt/aus einer Datei/von System x mit Datenbank y und Abfrageparametern z und über die Schnittstelle xyz geliefert).

Und vernünftig programmiert kann man so eine Datenstruktur auch einfach an den Reporter schicken und der weiß, was er damit anfangen kann, bzw. welche Reports diese Daten ausgeben können:
XML-Code:
<invoice>
  ...
</invoice>
Kaum macht man's richtig - schon funktioniert's
Zertifikat: Sir Rufo (Fingerprint: ‎ea 0a 4c 14 0d b6 3a a4 c1 c5 b9 dc 90 9d f0 e9 de 13 da 60)
  Mit Zitat antworten Zitat
Antwort Antwort


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 20:12 Uhr.
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz