|
Datenbank: Absolute Database (ABS) • Version: 7.91 • Zugriff über: SQL
Datenbankstruktur - wie speichern?
Liste der Anhänge anzeigen (Anzahl: 1)
(Absolute_Database (
 http://www.componentace.com) ist eine Embedded DB, welche ohne Treiber o.ä. auskommt.)Mein Szenario ist wie folgt: In verschiedene TStringGrids werden Eingaben gemacht, diese sind Uhrzeitgebunden. Die Taktung ist frei skalierbar, ob der Intervall nun 15 Minuten pro Stunde, stündlich oder minütlich erfolgt, ist dem Anwender überlassen. Im Nachhinein kann der Anwender diesen Intervall nun auch wieder ändern, wobei die Datenstruktur sich aber anpassen müsste. Alternativ müsste ich die DB neu erstellen und die Zeiten korrigieren. Daher suche ich einen Weg, die anfallenden Daten unabhängig der GUI zu speichern. Beispiel:
(Warum funktioniert die Tabelle nicht? / Siehe Screenshot) Die Zeiten sind momentan Basis der Speicherung. Datum+Uhrzeit+ID des StringGrids z.B. verwende ich für die Speicherung in der DB. Wird es nun umgestellt auf einen anderen Intervall, weil die Bestellzyklen sich ändern, sollten die Daten in der DB auch flexibel sein, und sich anpassen. Bei einem Wechsel von 15 Minuten auf 10 Minuten wäre in meinem Fall auch die zweite Datenzeile weg, weil es kein 7:15 Uhr mehr gäbe. Gibt es dazu eine Idee? LG Mathias |
AW: Datenbankstruktur - wie speichern?
Also die Tabellenstruktur kann man nicht so gut lesen, vielleicht kannst Du das korrigieren.
Laut Schaubild muss Deine Tabellenstruktur nicht geändert werden, nur die Zeitangaben. Du suchst also keine Strukturänderung, sondern ein Update Statement. Wie Du genau mit Datensätzen umgehen willst, wo mehrere Ereignisse in ein Intervall fallen, musst Du überlegen. Mir ist der Sinn des Intervalls auch nicht klar. Nur mal als Gedanke: Wenn du ganz schlicht die echte Zeit der Erfassung speicherst, notfalls mit Sekunden und Hundertstel oder noch genauer, hast Du beste Genauigkeit. Daraus kannst Du jedes beliebige Intervall machen, wenn Du draufschaust und abfragst und die erfasste Realzeit gegen eine definierte Intervallzeit verrechnest. Das kann z.B. als berechnete Spalte erfolgen im Select Statement. P.S: Nochmal zum Intervall, was hat es mit dem Grid / GUI zu tun? Und: gibt es in abs sowas wie Trigger oder Defaultwerte für Spalten (also dann z.B. für die echte Erfassungszeit)? |
AW: Datenbankstruktur - wie speichern?
Zitat:
Nur habe ich noch nicht verstanden, was Du eigentlich erreichen willst. Ich vermute eine Art Terminkalender. Und da verstehe ich nicht warum Du Tabelleneinträge "korrigieren" willst. Wenn Du einmal 12.34 als Startzeitpunkt eingegeben hast, dann kanns Du das doch nicht auf 13.00 bei 30Minuten-Taktung ändern, um dann bei 5Minuten-Taktung auf ???? zu ändern?? Was willst Du damit erreichen? Gruß K-H @Jobo Ich vermute es geht um die "Auflösung" der Darstellung. |
AW: Datenbankstruktur - wie speichern?
Danke für eure Antworten.
Ich habe mich unklar ausgedrückt. Die Zeiten sind fest vorgegeben, die Intervalle auch. Jedoch können die im Programmsetup geändert werden. So ist es vorstellbar, dass ein Anwender 2 Jahre lang die Daten im 15-Minuten-Rhythmus einträgt und auf einmal auf einen 10 minütigen Takt umstellt. Dadurch wäre der Vorlauf der Termine inkonsistent und es würden viele aus der Ansicht verschwinden, wären aber in der DB noch enthalten. Hierzu suche ich eine Lösung der Speicherung, damit die Einträge in der DB skalierbar sind. (OT: wie funktioniert die BBCode-Tabelle?) |
AW: Datenbankstruktur - wie speichern?
Also viel klarer ist es jetzt nicht.
Wie stellst Du Dir denn die Änderung der alten Intervalle vor? Du weißt doch gar nicht, wie ein alter Eintrag in das neue Intervall gehört. Wie gesagt, Du musst ein Update auf alle alten Einträge ausführen. Für mich ist das keine Strukturänderung der Daten. (OT BBCode googlen oder einen Beitrag mit bestehender Tabelle zitieren, da kannst Du es ablesen- wahrscheinlich hast Du nur irgendwo einen / vergessen oder sowas) |
AW: Datenbankstruktur - wie speichern?
Du speicherst doch bestimmt die Gültigkeitszeiträume der Intervallinformation, oder?
So kannst du dann dafür sorgen das ältere Daten mit dem seinerzeit geltenden Intervall angezeigt werden, und neue mit dem neuen Intervall. |
AW: Datenbankstruktur - wie speichern?
Wenn ich das richtig verstanden habe, geht es nur um die Darstellung.
Für die Erfassung wird die aktuelle Taktung übernommen und der Termin entsprechend gespeichert. Für die Wiedergabe nuß dann der Termin "gerundet" werden, um in das erwünschte Zeitraster zu passen. Gruß K-H |
AW: Datenbankstruktur - wie speichern?
Zitat:
Zitat:
LG Mathias |
AW: Datenbankstruktur - wie speichern?
Welcher Art soll das Fehlverhalten sein?
Du änderst nur die Darstellung. z.b. Datensatz: 12.13 xxxx Darstellung1: 12.00 Stunde/30Min Darstellung2: 12.15 15Minuten/5Minuten Darstellung3: 12.10 10Minuten Darstellung4: 12.13 1Minute Gruß K-H |
AW: Datenbankstruktur - wie speichern?
Liste der Anhänge anzeigen (Anzahl: 1)
Hallo,
ich weiß nicht, wie Du Deine Daten strukturiert hast, daher habe ich für Dich auf die Schnelle eine mir zweckmäßig erscheinende Struktur gebastelt und diese graphisch dargestellt. Ich würde dazu gemäß Bild im Anhang 5 miteinander verknüpfte Tabellen führen. Damit hättest Du die gewünschte Flexibilität. Der Preis dafür ist allerdings ein komplizierter Datenzugriff. Erklärung zum Bild: =============== Die gelben Tabellen sind die Stammdaten (= „Detail“ oder „Kind“), die blauen Tabellen stellen die abhängigen Tabellen („Master“, oder „Mutter“) dar. Die roten Feldinhalte in den Master-Tabellen sind die Fremdlinks zu den jeweiligen Stammdaten. Begriffserklärung: ============= Kind = Detail = Stammdatenbank Kind = hat EINE Mutter Mutter hat ein Kind oder mehrere Kinder, d.h. der Master hat den/die Fremdschlüssel! Mutter zeigt auf Kind = Master zeigt auf Detail Das Löschen eines Datensatzes ist nur erlaubt, wenn KEIN Pfeil auf den Datensatz in der Tabelle zeigt! Anmerkung: Manche Literaturstellen benutzen die Begriffe „Master“ und „Detail“ genau umgekehrt. Aber meine obige Darstellung paßt zur Pascal-Philosophie und zur Nomenklatur der zur Absolute-DB. Vielleicht hilft es Dir weiter. Gruß Andreas |
AW: Datenbankstruktur - wie speichern?
Zitat:
Vielleicht habe ich einen Denkfehler, jedoch ist, z.B. die Vorgabe im 10-Minuten-Takt und es wird auf 30-Minuten erhöht, fallen durch Rundung jeweils 2 Termine weg. 10-Minutentakt: 12:00 = 1. termin 12:10 = 2. termin 12:20 = 3. termin 12:30 = 4. termin 30-Minutentakt: 12:00 = 1. termin ODER 2.termin ? 12:30 = 3. termin ODER 4.termin ? Das meinte ich mit Fehlverhalten durch Rundung. LG Mathias |
AW: Datenbankstruktur - wie speichern?
Zitat:
Hallo Andreas, wie erstellst Du dieses Diagramm? Ich mache das immer auf Papier, mit Stift :-D Jedenfalls hilft mir diese Ansicht auch schon weiter, auch wenn ich mich mit der Idee der Skalierung per Intervallspeicherung in der DB schon angefreundet habe, wie es Jumpy empfohlen hat. Sollte das nicht praktikabel sein, mische ich einfach etwas aus den Ideen zusammen und würde bei Gelegenheit noch einmal nachfragen :-) Vielen Dank für die Hilfe! LG Mathias |
AW: Datenbankstruktur - wie speichern?
Zitat:
12:00 Termin1 12:00 Termin2 12:30 Termin3 12:30 Termin4 Mir scheint es sinnvoller alle Termine mit 12:00 anzuzeigen, da meist Termine nicht zu spät wargenommen werden sollten. Aber das ist Ansichtsache,im wahrsten Sinne des Wortes. Gruß K-H |
AW: Datenbankstruktur - wie speichern?
Zitat:
man kann professionelle DB-Diagramme mit der älteren (!) Version Visio 2010 Professional erstellen. Die aktuelle Version wurde im Leistungsumfang deutlich abgespeckt. Die "Alte" hat außerdem eine direkte Anbindung an Access: sie kann die DB-Struktur erkennen und automatisch Diagramme generieren. Das ist in der neuen Version nicht mehr enthalten. Bei Visio 2010 muß man allerdings alle Feldtypen & die Indizes kennen und angeben. Für den Vor-Entwurf der DB, wo vieles noch nicht festgelegt ist, ist es also nicht so gut. Daher verwende ich hierfür – wie für Dein Strukturdiagramm – Excel und PowerPoint. PowerPoint dient nur zum bequemen Positionieren und Verbinden der Kästchen mittels Pfeile. Gruß & viel Erfolg bei Deinem Projekt! Andreas |
AW: Datenbankstruktur - wie speichern?
Zitat:
Da es fraglich ist, ob Deine Anforderungen damit abgedeckt werden können, wäre ein "richtiges" Datenmodell sicher besser, als zu basteln. Die Basis wäre m.E., das ein Termin für sich genommen eine eindeutige ID erhält und einen Timestamp. Das kann man dann beliebig rastern. |
AW: Datenbankstruktur - wie speichern?
Zitat:
Mein Timestamp war die vorgegebenen Daten aus Datum+Uhrzeit+Grid. LG Mathias |
AW: Datenbankstruktur - wie speichern?
Ich weiß nicht, ob wir jetzt aneinander vorbei reden.
Dein Grid zeigt einen gerasterten Wert, der ist ja offenbar ok, solange nichts geändert werden muss. Statt dessen also lieber einen Echtwert, wie immer der sich dann auch zusammensetzt anhand von realen Tätigkeiten (Events im Programm) Nochmal die Frage, wie soll ein Intervallwert überhaupt geändert werden? Besonders wenn das alte Raster größer war als das neue? |
AW: Datenbankstruktur - wie speichern?
Wofür soll das eigentlich gut sein?
Bisher betreiben wir hier nur spökenkiekerei Gruß K-H |
AW: Datenbankstruktur - wie speichern?
Ich habe vor einigen Jahren ein Freewareprogramm geschrieben, ein Bestellbuch für diverse Einsatzzwecke. [1]
Als Hobbyprogrammierer hatte und habe ich wenig Erfahrung. Ich nutzte ich die Datenbank TDbf [2]. Damit klappte alles wunderbar, es gibt aber immer noch Ehrgeiz, dass ich etwas neues Lernen und ausprobieren möchte. Autodidaktisch. Mittlerweile bin ich mit der GUI der Version 4 sehr weit vorangekommen und würde irgendwann die Datenbank mit einbringen. Um hier aber nun den Anwendern eine freiere Nutzung des Programms zu ermöglichen, versuche ich die Art und Weise einer Datenbankanbindung zu lernen. Hier habe ich sehr große Probleme, mir das abstrakt vorstellen zu können, da ich eher sequentiell denke. Deshalb suche ich nach Antworten. Um zum Problem des Intervalls zurückzukommen, mehrfach habe ich schon erwähnt, warum das für mich wichtig ist. Ich skizziere das noch einmal. Die Daten werden jeden Tag in ein Grid eingetragen und gespeichert. Der Intervall lag pro Spalte bei 15 Minuten. Als Bestellbuch muss auch für die Zukunft eingetragen werden. Nun werden die Zeiten geändert, weil bemerkt wurde, dass die Zeiten optimiert werden können oder, weil neue Anforderungen bezüglich Aufklärung der Patienten in den Arbeitsalltag Einzug gehalten haben. Somit wird der Intervall dann um 5 Minuten pro Gridzeile erhöht, also einen 20 Minutenintervall. [1] https://www.nogad.de/bestellbuch-3/[2] https://sourceforge.net/projects/tdbf/ |
AW: Datenbankstruktur - wie speichern?
Gut, das macht es etwas klarer, aber ich habe leider immer noch nicht verstanden, was es mit dem Takt auf sich hat.
In ein Bestellbuch trage ich eine Bestellung ein, vollkommen egal wann, ich freue mich dann, wenn das bestellte endlich ankommt. Darum wird es also wohl nicht gehen. Vielleicht könntest Du einfach mal den Vorgang beschreiben, wie ein oder 2 solche Eintrage in dem Buch landen und was mit den Einträgen geschieht. Wenn Dein Anliegen verstanden wird, kann man auch verbindlichere Vorschläge zur Problemlösung liefern. |
AW: Datenbankstruktur - wie speichern?
Wenn die Termine nun also in der Datenbank liegen, der Intervall geändert werden muss, sollten diese Termine im Prinzip chronologisch wieder eingebunden werden.
12:00 T1 / 12:15 T2 / 12:30 T3 = 15 Minutentakt Nun wie oben schon erwähnt, wird der Intervall (z.B. nach 1 Jahr) umgestellt, die Termine sollten aber wieder in die neue Struktur geladen werden. 12:00 T1 / 12:20 T2 / 12:40 T3 = 20 Minutentakt Wird jetzt der Intervall nach einem weiteren Jahr wieder umgestellt, weil es doch praktischer gewesen ist,.. 12:00 T1 / 12:15 T2 (war vorher 12:20) / 12:30 T3 (war vorher 12:40) = 15 Minutentakt Und hier nun meine Eingangsfrage: Wie sollte das Modell der Datenspeicherung aussehen, damit auch (z.B.) solche Fälle abgedeckt werden können. (Dass die Bestellten über eine Terminänderung informiert werden müssen ist mir in diesem Fall egal.) LG und danke für eure Ausdauer :-) Mathias |
AW: Datenbankstruktur - wie speichern?
Dieses Intervall ist mir weiterhin unverständlich!
Angenommen ich wollte etwas bestellen, dann tue ich das jetzt (19.44Uuhr). Wenn Dein Intervall zur Verfügung stellst, nehmen wir an 5Minuten, dann trage ich meine Bestellung in der Zeile 19.40Uhr oder 19.45Uhr ein? Da ich sehr langsam an der Tastatur bin kommt die nächste Bestellung um 19.47Uhr. Die trage ich dann in 19.50Uhr ein, weil ja 19.45Uhr schon belegt ist? Wenn ich ein 15Minuten Intervall wähle, dann steht mir 19.30Uhr, 19.45Uhr und 20.00Uhr zur Verfügung, was dann mit den realen Bestellzeiten so gut wie nichts mehr zu tun hat!? Können den zwei oder drei Bestellungen zur gleichen Zeit aufgegeben werden? also 19.45Uhr Bestellung1 19.45Uhr Bestellung2 19.45Uhr Bestellung3 bzw. ist eszulässig, daß die Anzeige mir vorgaukelt alle drei Bestellungen wären zur gleichen Zeit erfolgt? Und ansonsten verweise ich auf die ersten Beiträge "was in der DB steht und was angezeigt wird, sind zwei unterschiedliche Schuhe". Und nochmals die Frage "wofür ist das gut", denn eine Bestelldokumentation im 15Minutentakt erlaubt gerade einmal 4 Bestellungen pro Stunde, das wäre dan nicht so sportlich. Gruß K-H Oh gerade nochmal durchgelesen. Geht es darum eine "Lieferzeit" zu definieren? also um 12.15 soll eine Raumpflegerin in Abteilung A zur Verfügung stehen? |
AW: Datenbankstruktur - wie speichern?
Zitat:
Du hast noch nie einen Arzttermin in einer Praxis bekommen, nehme ich an. :roll: Das Bestellbuch, welches per Stift und Hand benutzt wird, ist ähnlich einem Notizbuch. Ein Eintrag wird gemacht, wenn man das Datum kennt, an welchem der Termin stattfinden soll. Das ganze hat nichts mit Versandbestellungen zu tun. LG Mathias |
AW: Datenbankstruktur - wie speichern?
Also handelt es sich um einen Terminplaner, und Dein Problem sind Termine, die in der Vergangenheit vergeben wurden, die nicht mehr in das aktuelle Raster passen. Ist das soweit richtig?
Wenn ja, wo ist das Problem? Liegt der Termin in der Vergangenheit sollte er nicht mehr soo interessant sein. Liegt er in der Zukunft, hat man ein Problem da die vereinbarten Einbestellungen nicht mehr in das aktuelle Raster passen, insbesonders wenn das Raster vergrößert wurde. In diesem Falle wurden mehr Termine vergeben als in das akuelle Raster passen. Wenn diese Abweichungen korrigiert wurden, interessiert es dann noch welcher Termin ursprünglich vergeben wurde? Wenn ja, wie oft kann eine solche Korrektur durchgeführt werden? Gruß K-H |
AW: Datenbankstruktur - wie speichern?
Zitat:
Sorry aber wenn man Dir mehrfach sagt, dass man mit Deinen Beschreibungen nicht klar kommt, machts ein Augenrollen nicht besser. Zum Problem Warum muss rückwirkend alles angepasst werden, wenn das Intervall verändert wird? Wenn die Termine so lagen, wie eingetragen, dann ist es halt so. Hat ja mit neuen Terminen nichts zu tun. Wenn ein Intervall scheinbar ungünstig ist und ein anderes scheinbar besser, und dann doch wieder nicht, wieso benutzt man dann überhaupt Intervalle? Ein Computer braucht die Intervalle nicht, eine Software braucht sie auch nicht. Mir wurde neulich noch von einer Ärztin das Phänomen "Wartezeiten" "erklärt". Eigentlich gibt es eine Taktung von 30 Minuten, aber dann kommen Notfälle und Mitleidsfälle und was weiß ich und dann ist alles im Eimer, und die Leute mit "Termin" warten 3h, dass sie dran kommen. Ja und ich hör schon die Arzthelferin "man kann es ja auch gar nicht anders eintragen" Reden wir davon? Also nehmen wir mal an, jemand hat entschieden, Intervalle zur Termingestaltung zu nehmen, aber Abweichugnen zu gestatten, nach Bedarf, wäre das denkbar? Wäre es außerdem denkbar, meinetwegen jeden Tag andere Intervalle zu nehmen und die vergangenen einfach wie eingetragen zu belassen? |
AW: Datenbankstruktur - wie speichern?
Ich habe mir selber für exakt diesen Zweck einen Terminplaner für die Sprechstunde geschrieben. Das Problem mit der Taktung habe ich mir auch überlegt. Für mich spielt das keine so große Rolle, da der Planer ja nur für mich verwendet wird. Aber ich werde mir dafür auch eine Lösung einbauen.
Möglichkeit 1: Wenn die Taktung geändert wird werden einfach alle Termine, welche in dem Intervall liegen eingetragen. Dabei ändert sich eben die Anzahl der Termine pro Zeiteinheit. Möglichkeit 2 (das werde ich machen): In der Datenbank eine extra Tabelle für Taktungen einschließlich der Gültigkeit (Datum) anlegen. Z.B. Taktung|DatumVon|DatumBis Wenn jetzt ein Datum zur Termineintragung ausgewählt wird, dann wird die entsprechende Taktung aus der Datenbank (respektive ObjectList, die Objekte werden vom Server an die Clients beim Login übertragen) ausgelesen und die Anzeige des Planers entsprechend angepasst. Vergangene Termine spielen ja keine Rolle, aber auch hier könnte man die Taktung „schönheitshalber“ angleichen. |
AW: Datenbankstruktur - wie speichern?
Die Möglichkeit 2 und einen neuen Datensatz für die neue Taktung.
Und den Datensatz mit einem Verweis auf den Vorgängerdatesatz versehen. Das sollte eine grobe Struktur sein. Interessant ist die Frage, wie man den Bestand vernünftig anpasst. Denn wenn statt 5 Terminen in einer Stunde nur noch 4 (oder 3) abgearbeitet werden sollen, hat man schon eine Aufgabe. Ganz besonders wenn der Terminplaner verbindlich ist und nicht wie bei Dir (und einigen anderen) eher Empfehlungscharakter hat. Davon hängt auch ab ob Doppeltermine zulässig sind oder ob für einen Zeitraum die Vergabe von Neuterminen nicht möglich ist. Hier sollten beide Möglichkeiten oder eine sowohl als auch Lösung ins Auge gefasst werden. Gruß K-H |
AW: Datenbankstruktur - wie speichern?
Zitat:
@p80286: Warum einen Verweis auf den Vorgänger-Datensatz? |
AW: Datenbankstruktur - wie speichern?
Zitat:
Was die Korrektur bei einem Intervallwechsel angeht, sollte so viel wie möglich automatisiert erfolgen. Im ungüstigsten Falle eine Einzelkorrektur jedes relevanten Eintrags. Und wenn möglich wenigstens hier eine TeiAutomatisierung durch Vorschläge. Einfach weil die rein manuelle Bearbeitung zu fehleranfällig ist. Gut die Erfassung ist auch rein manuell (sieht man von dem vorgegebenen Intervall ab) aber man sollte jede Möglichkeit der (Teil-)Automatisierung ergreifen um Fehler zu vermeiden. Und vielen Dank für den Hinweis, dß die Taktung in die Daten gehört und natürlich mit der Oberfläche nur mittelbar zu tun hat. Das ist für mich so selbsverständlich, daß ich nicht immer darauf hinweise. Gruß K-H |
AW: Datenbankstruktur - wie speichern?
Wie gesagt, man speichert einen ganz normalen Timestamp.
Da (mir) nun klar ist, wie das eingesetzt wird, sehe ich keine Probleme bei neuer Taktung. Es wird einfach gemäß aktueller Vorgabe angezeigt bzw. neu eingetragen. Ich finde es allerdings sehr unmodern (vorsichtig ausgedrückt), eine starre Taktung zu haben. Ich kann in meinem Spreadsheetprogramm seit Jahrzehnten "Zellteilung" machen wie ich will (oder Zusammenfassung). Aus fachlicher Sicht: Wenn ich weiß, dass die eingeplanten Fälle schnell abzuarbeiten sind, dann kann ich doch einen weiteren dazunehmen oder umgekehrt, bei komplexen Fällen weniger Taktung vorsehen. EDV soll eine Hilfe sein. P.S./OT: Wem ist noch bewusst, dass das Zwölfer System die besten Teilungsmöglichkeiten bietet? Das gilt natürlich auch für ein Vielfaches von 12, 60 Minuten z.B.. Könnte man ja munter nutzen diese Möglichkeit. Alternativ einfach Termine machen, nach den Abrechnungsvorgaben der Krankenkasse, das wäre bestimmt "lustig" ;-) |
AW: Datenbankstruktur - wie speichern?
Zitat:
|
AW: Datenbankstruktur - wie speichern?
Also die Taktung ist ein gern genutztes "Korsett", nach meinen Recherchen. Und wenn der Kunde das wünscht soll er es auch bekommen.
@Jobo Wie willst Du das mit einem Timestamp realisieren? Nach meinem Verständnis wird das z.B. bei der Erfassung generiert und hat mit einem Termin recht wenig zu tun. Oder meinst Du damit den Feldtyp für den Termin? Gruß K-H |
AW: Datenbankstruktur - wie speichern?
Im Ernst:
Ich glaube der TE hat (meiner Meinung nach) ein Logikproblem bei seinen Überlegungen, da er den Intervall = Anzeige setzt. Ein eingestellter Intervall für (neue) Termine sollte keine Auswirkungen in der Ansicht der bestehenden Termine haben. Es gilt zwischen Terminerstellung und Terminkalender (Ansicht) zu unterscheiden. 1. Beim generieren des Termins wird ein (voreingestellter, in den Programmeinstellungen vom Benutzer festgelegter) Wert für den Intervall angezeigt. Beim erstellen des Termins wird dieser also berücksichtigt und entsprechend eingetragen, was nur in den Intervallen möglich ist. Der Termin wird entsprechend in die Datenbank geschrieben. 2. Die Terminanzeige (Kalender) jedoch sollte UNI sein. Im Klartext so eingestellt sein, das sie vom (Grob-)Raster zwar den Intervall anzeigt, jedoch alle Termine anzeigt unabhängig vom Intervall. Bedeutet: Ist der Intervall kleiner als die Terminlänge (weil vorher anderer Intervall eingestellt war), wird der Termin über mehrere Intervalle angezeigt. Ist der Termin kürzer als der Intervall (und ggf. mehrere Termine in einem Intervall), werden diese in einem Intervall angezeigt. Tipp: Unterscheide zwischen Terminerstellungsintervall und Terminanzeigeintervall. Lasse beides als "default" vom Nutzer wählen, ihm aber die Freiheit zur Laufzeit das jederzeit zu ändern, ohne das sich der "default" ändert (sofern der Kunde das nicht blockieren will). |
AW: Datenbankstruktur - wie speichern?
@Moombas: Genau das meinte ich. Ein Termin hat eine Startzeit (mit Datum natürlich) sowie eine Endzeit (oder eine Dauer). Diese werden in der Datenbank gespeichert. Punkt.
Die Anzeige gehört davon komplett entkoppelt und lässt sich problemlos an neue Einstellungen anpassen. Ja nach Termindauer und Intervallgrössen erstreckt sich der Termin dann eben über mehr oder weniger Intervalle. Ich verwende übrigens den TMS Planner, der kümmert sich komplett selbst um die Anzeige wenn Start- bzw. Endzeit bekannt sind. Das Intervall kann quasi auf Knopfdruck angepasst werden. |
AW: Datenbankstruktur - wie speichern?
@scrat
Nach meiner bescheidenen Kenntnis, sind die virtuellen Punkte, die für Termine beim Arzt von den gesetzlichen Kassen angerechnet werden, oft recht bescheiden im Vergleich zur reinen Dauer des Termins. (Mal abgesehen von der nicht direkt zu beziffernden monetären Höhe dieser Punkte) Die Termine würden also daran gemessen u.U. recht kurz und natürlich nicht gerastert ausfallen. @p80286 Ja, erst mal ist es ein Timestamp als Datentyp. Taktung ist meinetwegen ok, aber sie führt so wie sie praktiziert wird und durch Software unterstützt wird ja offensichtlich mit (nicht allein) dazu, dass Arzttermine oft ein Glücksspiel sind- was die Wartezeit angeht. Gedanken: Das Raster ist virtuell und findet ohne vergebene Termine keine Ausprägung Ein gegebenes Raster definiert sich (hier) dann durch (Stunden) Anteile, z.B.: 1, 2, 3, 4, 5, 6 Also umgerechnet volle Stunde, halbe -, 20 Minuten, 15 -, 12-, 10, - Vorgabe wäre meinetwegen 20 Minuten als Standardaufteilung. aber eigentlich egal, denn: auf Stundenebene gilt die dann festgelegte Uhrzeit primär als Reihenfolge oder als konkrete Angabe von (kleineren) Intervallblöcken, ein Termin = 1-n explizite, exakt angegebene Intervalle Das Ändern eines Rasters (als Ausnahme oder dauerhaft) wirkt sich nur bedingt auf bestehende Termine aus. Im einfachen Fall „kleineres Intervall“ wird „irgendwo“* innerhalb der Stunde ein weiterer Termin erfasst, im schwierigeren Fall „größeres Intervall“ fliegt ein Termin aus der Stunde raus. Beides sind natürlich Verschiebungen und man muss definieren, wie damit umgegangen werden soll. a) bestehende Termine behalten einfach das alte Raster, nur neue Termine werden nach neuen Vorgaben vergebenen b) „Reinquetschen“: aus Terminen 10:00 Uhr und 10:30 Uhr wird 10:00, 10:20, 10:40 c) „Strecken“: aus 10:00, 10:20, 10:40 wird 10:00 und 10:30, ein Termin braucht einen neuen Platz (manueller Vorgang, Absprache) .. Für diese Fälle muss man entsprechende Update Statements bauen. *Wahrscheinlich wäre ein „loses“ Modell -ganz ohne Raster- mit einigen Problemchen in der technischen Handhabung verbunden, auch wenn es ein paar Updates spart. (nicht notwendig im Sinne der Last) Fall b) würde mit einem Insert zwischen bestehenden Terminen auskommen, wobei hinreichend wäre, dass die neue Terminzeit „irgendwo“ zwischen 2 bestehenden Terminen liegt. Die Anwendung muss die Rasterung grafisch sowieso variabel beherrschen, nur eben nicht abhängig von einer Grundeinstellung, sondern abhängig von der tatsächlichen Datenlage in der jeweiligen Stunde. Denkbar für eine Rasterumstellung wäre ggf. auch, dass man sie nicht akut durchführt, sondern in der Zukunft, also ab einem Zeitpunkt x in 4 Monaten. Liegt er weit genug in der Zukunft (keine Termine vergeben oder wenige die man manuell neu vergibt), kann man wahrscheinlich mit einfacheren Verfahren operieren. Ändert aber auch nichts an der Speicherung als Timestamp. Das ist m.E. alles eine Frage davon, welchen Aufwand der TE in die Änderung stecken will. Die Ausführungen von @Moombas bringen eigentlich recht deutlich raus, wie es normalerweise laufen sollte. Die Rasterung ist eine reine Darstellungssache. |
AW: Datenbankstruktur - wie speichern?
Zitat:
Gruß K-H |
AW: Datenbankstruktur - wie speichern?
Liste der Anhänge anzeigen (Anzahl: 1)
so macht es z.B. Outlook:
|
| Alle Zeitangaben in WEZ +1. Es ist jetzt 18:31 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz