Laden...

DB Definition: Variable Felder

Erstellt von macmark vor 15 Jahren Letzter Beitrag vor 15 Jahren 984 Views
M
macmark Themenstarter:in
53 Beiträge seit 2006
vor 15 Jahren
DB Definition: Variable Felder

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

84 Beiträge seit 2007
vor 15 Jahren

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

T
223 Beiträge seit 2006
vor 15 Jahren

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

3.511 Beiträge seit 2005
vor 15 Jahren

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)

M
macmark Themenstarter:in
53 Beiträge seit 2006
vor 15 Jahren

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