AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren

Wozu sind Attribute gut ?

Ein Thema von OlafSt · begonnen am 10. Jul 2013 · letzter Beitrag vom 8. Aug 2013
Antwort Antwort
Medium

Registriert seit: 23. Jan 2008
3.689 Beiträge
 
Delphi 2007 Enterprise
 
#1

AW: Wozu sind Attribute gut ?

  Alt 19. Jul 2013, 09:23
Ich dagegen bin dazu übergegangen fast alles was ich an Combobox-Einträgen so brauche über meine Datenbanken "zusammenzuqueryn", dank glaube ich ganz netter Strukturen geht das sogar mit einer Standardfunktion. Erleichtert allen voran auch das Übersetzen ohne Neucompilieren. Macht aber auch nur wirklich Sinn, wenn die DB entweder eh grbraucht würde, oder embedded ist. Ich versuche so viel Daten und deren Abhängigkeiten voneinander in die DB zu gießen, und im Programm dann nur noch mittels Kreuztabellen die Dinge zu verknüpfen. Dabei ist auch praktisch, dass ich Änderungen in gewissem Umfang machen kann, und der Kunde muss nichtmals sein Programm neu starten um diese nutzen zu können.
"When one person suffers from a delusion, it is called insanity. When a million people suffer from a delusion, it is called religion." (Richard Dawkins)
  Mit Zitat antworten Zitat
Benutzerbild von Uwe Raabe
Uwe Raabe

Registriert seit: 20. Jan 2006
Ort: Lübbecke
11.751 Beiträge
 
Delphi 12 Athens
 
#2

AW: Wozu sind Attribute gut ?

  Alt 19. Jul 2013, 14:07
Ich dagegen bin dazu übergegangen fast alles was ich an Combobox-Einträgen so brauche über meine Datenbanken "zusammenzuqueryn", dank glaube ich ganz netter Strukturen geht das sogar mit einer Standardfunktion. Erleichtert allen voran auch das Übersetzen ohne Neucompilieren. Macht aber auch nur wirklich Sinn, wenn die DB entweder eh grbraucht würde, oder embedded ist. Ich versuche so viel Daten und deren Abhängigkeiten voneinander in die DB zu gießen, und im Programm dann nur noch mittels Kreuztabellen die Dinge zu verknüpfen. Dabei ist auch praktisch, dass ich Änderungen in gewissem Umfang machen kann, und der Kunde muss nichtmals sein Programm neu starten um diese nutzen zu können.
Ich weiß nicht, ob ich das so machen würde. Stimmt nicht - ich weiß, daß ich es garantiert nichts so machen würde. Genauso hat das mal vor Jahren ein frisch gebackener Diplom-Informatiker realisiert - auch mit dem Hinweis der leichten Anpassbarkeit der Texte an andere Sprachen. Problematisch wurde es allerdings, als die Anzahl der Optionen in einer neuen Programmversion erhöht wurde und dies in jeder Kundendatenbank von Hand nachgetragen werden musste. Das automatische Ergänzen war auch keine wirkliche Erleichterung und hat den Code unnötig verkompliziert. Richtig böse wird es aber dann, wenn sich die Bedeutung bestehender Einträge ändert und die vorhandenen Texte in den Kundendaten angepasst werden müssen.

Übersetzungen gehören m.E. nicht in die Datenbank - zumindest nicht in die mit den Arbeitsdaten.
Uwe Raabe
Certified Delphi Master Developer
Embarcadero MVP
Blog: The Art of Delphi Programming
  Mit Zitat antworten Zitat
Medium

Registriert seit: 23. Jan 2008
3.689 Beiträge
 
Delphi 2007 Enterprise
 
#3

AW: Wozu sind Attribute gut ?

  Alt 19. Jul 2013, 14:17
Da kommt es vermutlich auch wieder ein wenig auf die Art der Daten an. Bei uns sind das oftmals Dinge wie Rezeptbetrieb in einer intustriellen Produktionsanlage. Wenn dort z.B. ein Rezept ausgewählt wird, soll per Combobox ein Zielmischer wählbar sein. Ich habe alle Quellbehälter und Zielmischer in meiner DB, sowie deren Inhalte. Zudem eine Kreuztabelle, die mir sagt welche Quellen auf welche Ziele fahren können. Dann steht im Rezept, welche Rohstoffe nötig sind. Aus diesen Infos kann ich dann eine Liste der Zielmischer erzeugen, die von allen Quellen, die die nötigen Stoffe beinhalten erreicht werden können. Alle Behälterdaten inkl. ihrer Namen stehen auch in der DB, so dass ich meine Combobox damit gleich befülle. (Und den Index in die Objects-Property.)

Baut der Kunde dann mal einen neuen Behälter dazu, muss ich zur EInbindung in den Vollautomatikbetrieb einfach nur den neuen Tank in die Behältertabelle packen, und in der Kreuztabelle mit seinen Zielen verbinden. Und schon ist die neue Komponente "on the fly" voll einsatzfähig. Unsere Programme sind halt auch kundenspezifisch, und der Kundenstamm besteht eher aus wenigen großen als vielen kleinen. Dadurch fällt das "Breiten-Update-Problem" quasi weg. (Man hätte dieses aber auch bei in-code Daten, da muss dann eben überall das Programm getauscht werden, statt die DB angepasst.)

Bleibt am Ende fast wieder nur: Es kommt halt immer darauf an, wofür man die Dinge genau einsetzt

Edit: Jetzt erst deinen letzten Satz gesehen, wodurch mir klarer wurde, wo du das Problem siehst. Ich habe es in einem Fall so gelöst, dass ich die Übersetzungen in eine separate Tabelle mit Fremdschlüssel und Tabellenname gepackt habe. War im Programm dann eine andere Sprache gewählt, wurden die Texte aus der jeweiligen Übersetzungstabelle geholt. Zugegeben: Das war an ein bestehendes Projekt "angebaut", und ginge vermutlich besser wenn man es von Anfang an voll integriert. Bei Übersetzungen statischer Texte in der GUI, also Dingen, die nichts mit den Arbeitsdaten zu tun haben, nutzen wir ein 3rd Party Tool.
"When one person suffers from a delusion, it is called insanity. When a million people suffer from a delusion, it is called religion." (Richard Dawkins)

Geändert von Medium (19. Jul 2013 um 14:21 Uhr)
  Mit Zitat antworten Zitat
Antwort Antwort

Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

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 07:44 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