Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 | Suche | FAQ

Hauptmenü
myCSharp.de
» Startseite
» Forum
» Suche
» Regeln
» Wie poste ich richtig?

Mitglieder
» Liste / Suche
» Wer ist online?

Ressourcen
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Microsoft Docs

Team
» Kontakt
» Cookies
» Spenden
» Datenschutz
» Impressum

  • »
  • Community
  • |
  • Diskussionsforum
DB Definition: Variable Felder
macmark
myCSharp.de - Member



Dabei seit:
Beiträge: 53
Herkunft: Köln

Themenstarter:

DB Definition: Variable Felder

beantworten | zitieren | melden

verwendetes Datenbanksystem: SQL-Server oder Access

Hallo zusammen,
Ihr kennt sicher auch das Problem das Ihr Masken definiert die feste DB-Felder verwenden. Name/Strasse usw... kommt in das passende Feld.
Nun passiert es ja oft das Kunden spezielle Wünsche haben und man möchte dann nicht für jeden Pups den die Kunden eingeben möchten immer DB-Patches bauen.

Bisher habe ich dies mit einer Tabelle gelöst wo im Grunde 3 Werte gespeichert werden: NameDesFeldes, TypDesFeldes, Wert als String.

Da ich die ruhigen Tage nutze um unser DB-Modell zu prüfen und zu optimieren wäre meine Frage ob euch dazu was besseres, eleganteres einfällt ???

Schönen Gruss und ein frohes Fest
Markus
private Nachricht | Beiträge des Benutzers
Razer
myCSharp.de - Member

Avatar #avatar-2389.jpg


Dabei seit:
Beiträge: 84
Herkunft: BW/DE

beantworten | zitieren | melden

Die externe Tabelle bietet eine Lösung für n benutzerdefinierte Datenfelder - inwiefern sollte da eine noch elegantere Lösung denn möglich bzw. überhaupt nötig sein?

Gruß,
Razer
private Nachricht | Beiträge des Benutzers
Thomas B
myCSharp.de - Member



Dabei seit:
Beiträge: 226

beantworten | zitieren | melden

Hi,

Aus Entwicklersicht mag die Lösung ja einfach sein, aber aus technischer Sicht ist das ja nicht das Gelbe vom Ei.
Da du alles als String speicherst verlierst du bei der DB Performance und in der Anwendung verlierst du durch das Parsen in die richtigen Datentypen Performance.
Je nach Datenmenge kann das ja bestimmt einen spürbaren Unterschied ausmachen kann ich mir vorstellen.
Ich kenne mich nicht sehr gut mit Datenbanken aus, aber wie siehts denn z.B. mit spezielleren Funktionen aus. Was ist, wenn du in deinem Wertefeld ein Datum speicherst, kannst du dann noch die speziellen Datumsfunktionen der Datenbank nutzen? Kannst du Zahlen addieren oder ähnliches bei als String gespeicherten Zahlen?

Du scheinst ja dein Geld damit zu verdienen, warum wählst du dann diesen Weg? Ich finde ihn "stümperhaft". Wenn ein Kunde ein neues Feld haben möchte, dann sollte es auch vernünftig implementiert werden, schließlich bezahlt er dafür.


Gruß Thomas
private Nachricht | Beiträge des Benutzers
Khalid
myCSharp.de - Experte

Avatar #avatar-2534.gif


Dabei seit:
Beiträge: 3627
Herkunft: Hannover

beantworten | zitieren | melden

Ich nutze ebenfalls eine weitere Tabelle für z.B. weitere Informationen von Personendaten. Diese enthält allerdings für jeden möglichen Datentyp eine extra Spalte.

Also z.B.

ZusatzID INT
ZusatzDatenTyp SMALLINT
StringWert VARCHAR
IntWert INT
DateTimeWert DATETIME
MoneyWert MONEY
usw...
Alles in einem String packen ist wirklich kein schöner Weg, weil man sonst Performance durch mögliches casten verliert.
"Jedes Ding hat drei Seiten, eine positive, eine negative und eine komische." (Karl Valentin)
private Nachricht | Beiträge des Benutzers
macmark
myCSharp.de - Member



Dabei seit:
Beiträge: 53
Herkunft: Köln

Themenstarter:

beantworten | zitieren | melden

Tach zusammen,
erstmal ein gutes neues Jahr und Danke für eure Vorschläge!

@Thomas B: Na.. ja! "Stümperhaft" ist vlt etwas übertrieben wenn man den Hintergrund nicht kennt. Kunden zahlen bei uns sicher für die Weiterentwicklung einer Software. Sind die Vorschläge der Kunden sinnvoll (Was auch wiederrum Kunden mitentscheiden) wird dies auch vernünftig implementiert. Hat aber einer den Wunsch irgendwelche Informationen zu speichern die 99,9% der anderen Kunden für sinnlos halten, haben solche Kunden trotzdem die Möglichkeit sich zu "verwirklichen". Aber mit bewußten Nachteilen bei der Performance oder Auswertbarkeit.
Leider ist es bei einer Standardsoftware nicht einfach allen gerecht zu werden! Obwohl es evtl bezahlt werden würde!!

@Kalid: Vorschlag wäre ok! Hatte ich aber bisher verworfen da man neben dem Varchar noch andere, leere Felder mitschleift.

So Feiertage sind schon ok um ggfl auch in der Anwendung aufzuräumen und zu hinterfragen welche Bereiche überhaupt genutzt werden. Und für 0,1% unserer Kunden lohnt der Aufwand derzeit nicht.
Schönen Gruss
Markus
private Nachricht | Beiträge des Benutzers