nicht angemeldet
TimeStamp - Verwendung im Programm / Gut oder schlecht?
suitSchönen guten Morgen an alle
Wie einige sicher schon wissen, bin ich an einer Datenbank-Entwicklung dran. Momentan gibt es drei Dateien:
Eine key-guard.csv (zwei Werte free/busy)
Eine KDB-A (Kundendatenbank - Adressen)
Eine KDB-B (Kundendatenbank - Bestände)
Da die Bestände in der KDB-B anhand ihrer Kundennummer dem Kunden zugeordnet werden, gibt es logischerweise auch mehrere Verträge die zu einer Kundennummer gehören.
Das bedeutet, daß die Datensätze in der KDB-B (Bestände), zwar an anhand der Kundennummer selektiert werden, aber trotzdem jeder einzelne Vertrag einen eigenen absoluten Schlüssel braucht, falls dieser Vertrag editiert und in die DB zurückgeschrieben werden muss.
Um diesen schlüssel geht es:
Ich dachte ich nehme den Timestamp als solchen absoluten identifizierer. Erstens wird das eine Stans-Alone -DB, so daß zwei Einträge zur selben Zeit unmöglich wären. Zweitens ist immer nur ein Datensatz in der Maske editierbar. Drittens wäre ein versehentliches Doppelstarten der DB durch die Verwendung der key-guard.csv ausgeschlossen.
Was mir jetzt sorgen bereitet:
Laut wiki soll es 2038 zu einem Problem bei Programmen kommen, die den Timestamp in irgendeiner form nutzen. Gut, das sind noch 28 Jahre - wer weis ob ich da noch lebe bzw. ob das Programm dann noch eingesetzt wird. Aber ist an diesem Datum wirklich was dran? Kann die Variable, die diese Sekunden Zählt nicht vergrößert werden, damit sie nicht überläuft?
Grüße Gary
-
Im wesentlichen: es wird zu einem Überlauf kommen - man muss immer nur lange genug warten. Allerdings werden moderne Systeme im Jahr 2038 wahrscheinlich bereits darauf vorbereitet sein, dass nicht mehr der 01.01.1970 als Startpunkt für Time Stamps verwendet wird, sondern einfach ein späteres Datum.
Trotzdem ist ein Timestamp als Information genauso gut oder schlecht wie eine eindeutige Zufallszahl oder ein Hochzählen der Kundennummern. Die Zufallszahl hat den Vorteil, dass man nicht einfach die Kundennummern durchgehen kann, um ggf. bei anfälligen Systemen eine Sitzung zu kapern.
Gruß, LX
--
RFC 1925, Satz 2: Egal, wie fest man schiebt, ganz gleich, wie hoch die Priorität ist, man kann die Lichtgeschwindigkeit nicht erhöhen.-
Im wesentlichen: es wird zu einem Überlauf kommen - man muss immer nur lange genug warten. Allerdings werden moderne Systeme im Jahr 2038 wahrscheinlich bereits darauf vorbereitet sein, dass nicht mehr der 01.01.1970 als Startpunkt für Time Stamps verwendet wird, sondern einfach ein späteres Datum.
Ich würde eher davon ausgehen, dass man inzwischen auf einen 64-Bit-Timesamp wird :)
-
Moin!
Ich würde eher davon ausgehen, dass man inzwischen auf einen 64-Bit-Timesamp wird :)
Genau. Sonst gäbe es nämlich einen Haufen seltsamer Rentenbescheide: Einige Rentner würden zu ganz jungen Spunden erklärt und denen würde die Rente entzogen (nebst automatisch eingeleiteten und der schieren Masse wegen mit Strafbefehl endendem Betrugsverfahren und einem wegen Rückforderung der erlangten Rente) und andere, längst verstorbene, bekämen Rente bis zum (in der Zukunft liegenden und angeblich durch Sterbeurkunde bereits bekannten) Tag des Ablebens gewährt. Und weil das alles so teuer wird müssten unsere Nachkommen ein Stück länger arbeiten. Aber das wäre darin ja gleich impliziert, weil alle Sozialversicherten automatisch ein paar Jahre jünger würden.
Etwas Konfusion könnte auch bei den Banken herrschen, weil deren Computer Überweisungen, Geldabhebungen und vor allem Handelsgeschäfte nicht mehr eindeutig einem Zeitpunkt zuweisen können.
Allerdings mache ich mir Sorgen: die 64 bit reichen, wenn man eines für ein Vorzeichen abzieht (um endlich vernünftig in die Vergangenheit rechnen zu können) nur für etwa 17 Billionen Jahre. Das könnte dazu führen, dass sich Tilgungsfristen für jene Staatskredite, die aufgenommen werden um Banken zu erhalten, nicht mehr berechnen lassen. Aber ich schätze dieses Problem wird anders gelöst: Man erklärt das zum Problem anderer Leute und sieht nicht hin, also wird es auch nicht auftreten. Ohnehin dürften die Rechner bei der nächsten Bankenkrise die Zahlen nicht mehr verarbeiten können, es sei denn man stellt auf bc um.
MFFG (Mit freundlich- friedfertigem Grinsen)
fastix
-
Hi!
Ich würde eher davon ausgehen, dass man inzwischen auf einen 64-Bit-Timesamp wird :)
Genau. Sonst gäbe es nämlich einen Haufen seltsamer Rentenbescheide:Es ist zwar immer wieder zu sehen, dass Dilletanten Datenbanksysteme entwerfen. Trotzdem, wer einen Timestamp mit einer Auflösung von Sekunden zum Speichern eines Geburtsdatums, für das nur der Tag benötigt wird, verwendet, dem ist nicht mehr zu helfen. Außerdem ist der Timestamp nur ab 1970 definiert und damit schon von vorn herein unbrauchbar. (Wenn man die negativen Zahlen noch mit dazunimmt, reicht es "nur" bis 1901.)
Etwas Konfusion könnte auch bei den Banken herrschen, weil deren Computer Überweisungen, Geldabhebungen und vor allem Handelsgeschäfte nicht mehr eindeutig einem Zeitpunkt zuweisen können.
Das kann ich mir nicht vorstellen, dass sie solch einen unbrauchbaren Datentyp für ohre Datumsangaben verwenden. Sie bekämen damit nicht erst im Jahre 2038 Probleme sondern auch schon viel früher mit dem Berechnen von langfristigen Geschichten.
Allerdings mache ich mir Sorgen: die 64 bit reichen, wenn man eines für ein Vorzeichen abzieht (um endlich vernünftig in die Vergangenheit rechnen zu können) nur für etwa 17 Billionen Jahre.
Meinst du, ich hätte auch die beiden obigen Aussagen als ironisch gemeint auffassen sollen?
Lo!
-
Moin!
Meinst du, ich hätte auch die beiden obigen Aussagen als ironisch gemeint auffassen sollen?
Keinesfalls! Ich bin nämlich - soweit meine EDV das noch feststellen kann - 1963 geboren und somit ein Kind des letzten Jahrzehnts der Pre-Timestamp-Ära. Diese würden sich - als unzweifelhaft fossile Objekte der Datenarchäologie - ganz gewiss niemals ironisch oder gar sarkastisch ausdrücken.
MFFG (Mit freundlich- friedfertigem Grinsen)
fastix
-
Keinesfalls! Ich bin nämlich - soweit meine EDV das noch feststellen kann - 1963 geboren und somit ein Kind des letzten Jahrzehnts der Pre-Timestamp-Ära. Diese würden sich - als unzweifelhaft fossile Objekte der Datenarchäologie - ganz gewiss niemals ironisch oder gar sarkastisch ausdrücken.
Der 01.01.1970 ist beginn der "Unix-Epoche" und nicht zwangsläufig der anbeginn von Zeitstempeln ;)
Selbst einvorzeichenbehafteter POSIX time_t kann Zeitpunkte vor dem 01.01.1970 abbilden :p
-
-
-
-
-
-
Moin!
Das bedeutet, daß die Datensätze in der KDB-B (Bestände), zwar an anhand der Kundennummer selektiert werden,
Selektiert heißt nicht identifiziert. Morgen kommt eine Tabelle Rechnungen hinzu die sich auf einen Vertrag bezieht. Wäre besser, dieser hätte dazu eine eigene ID. Übermorgen eine Tabelle Zahlungen, die einen Bezug zu Rechnungen und Verträgen hat...
Ich dachte ich nehme den Timestamp als solchen absoluten identifizierer. Erstens wird das eine Stans-Alone -DB, so daß zwei Einträge zur selben Zeit unmöglich wären.
Dies ist der Zustand heute. Wie das morgen ist weißt Du nicht. Aber es geht um Verträge und Kunden. In der Wirtschaft gilt: Unternehmen wachsen (oder gehen ein). Demnach könnte eine Anwendung, welche die Daten Deiner gegenwärtigen Anwendung weiter verarbeiten muss, zukünftig also anderen, höheren Ansprüchen genügen müssen. Es wäre hierfür gut, wenn die Daten für einen import eine brauchbare Struktur hätten - und dazu zählt die ID der jeweiligen Datensätze. Es wäre aber auch gut, wenn sich Deine Anwendung erweitern ließe. Auch dazu wird die ID voraussichtlich gebraucht.
MFFG (Mit freundlich- friedfertigem Grinsen)
fastix
-
hi,
Um diesen schlüssel geht es:
Ich dachte ich nehme den Timestamp als solchen absoluten identifizierer.
Bei der Realisierung meines letzten Auftrages habe ich wiederholt festgestellt, dass es keine gute Idee ist, einen (nunmerischen) Schlüssel in den Datenbestand einzubeziehen (*Anm.). Numerischer Schlüssel 'ja', aber unabhängig von Daten, ein solcher Schlüssel gehört funktional zur Datenhaltung und nur da.
Anm.: Kd. wollte es so, Zeit war knapp, es tut auch, es gibt jedoch Abhängigkeiten, die einen weiteren Ausbau erschweren.
Hotti
-
Hallo
Erstens wird das eine Stans-Alone -DB, so daß zwei Einträge zur selben Zeit unmöglich wären.
Also das stimmt so nicht.
1. In der Umstellung - Sommer-Winter-Sommerzeit - fällt einmal eine Stunde aus und ein anderes mal wird eine Stunde "wiederholt".
2. Es können durchaus unterschiedliche Rechner auf das System zugreifen mit unterschiedlichen Uhrzeiten. Time-Stamp würde einen funktionierenden Zeitserver voraussetzen auf allen angeschlossenen Rechnern.Herzlcihe Grüße
Wolfgang-
Hi!
- In der Umstellung - Sommer-Winter-Sommerzeit - fällt einmal eine Stunde aus und ein anderes mal wird eine Stunde "wiederholt".
Das interessiert den Unix-Timestamp aber nicht, denn der basiert auf UTC.
GUID wäre mein Favorit. Das ergibt "höchstwahrscheinlich" weltweit eindeutige Werte.
Lo!
-
-
hi,
Um diesen schlüssel geht es:
Jetzt mal unabhängig von der interessanten Timestamp-Diskussion... zum Gernerieren unabhängiger forlaufender Nummern (numierisch) oder auch eindeutiger MD5-Strings (hex => 32 byte) habe ich kürzlich zwei kleine Perlmodule geschrieben:
http://rolfrost.de/perlcode_allgemein.html
Mit dem Ticket-Modul kannst Du außer md5-Strings auch numerische Werte (fortlaufdende Nummern) ziehen, das Modul ist so geschrieben, dass bei der Objekterstellung hochgezählt wird und beim Beenden (DESTRUCTOR) werden die neuen Werte in die Datei zurückgeschrieben. Mit dem eingebauten LOCK_EX ist der Prozess atomar, d.h., nicht mehr teilbar, die Nummer und auch die Checksumme ist also eindeutig.
Hotti
-
Hi Leute, hi hotti
Jetzt mal unabhängig von der interessanten Timestamp-Diskussion... zum Gernerieren unabhängiger forlaufender Nummern [...]
Die Nummern, die ich von Timestamp beziehe (gerade eben war es die 1282147953) muss nicht fortlaufend sein. Sie soll lediglich die einzelnen Datensätze in den Beständen identifizieren, die zu einer Kundennummer gehöhren.
Beispiel:
KDB-A ->Max Mustermann Kd.Nr 100100
KDB-B:
100100, kfz,data,data...
100101, data,data,data...
100102, data,data,data...
100100, UV,data,data...
100100, UV,data,data...Ergibt beim Selektieren:
100100, kfz,data,data...
100100, UV,data,data...
100100, UV,data,data...Wenn jetzt eine der drei Verträge editiren will, brauche ich einen eindeutigen Schlüssel um die Position in der Datenbank zu bestimmen bzw. den Wert zurück zu schreiben.
Also füge ich den Tiemstamp von mir aus auch roh ein:
100100, 1282147953, kfz,data,data...
100100, 1282147955, UV,data,data...
100100, 1282147960, UV,data,data...Dieser bleibt unverändert stehen und wird nur bei der Neuanlage eines Vertrages/Datensatzes generiert und fest eingeschrieben.
Hoffe ihr versteht wie ich das meine.
Gruß Gary
-
hi,
Also füge ich den Tiemstamp von mir aus auch roh ein:
100100, 1282147953, kfz,data,data...Sag mal, Deine Datenhaltung, willst Du das wirklich in CSV-Dateien halten!? Strukturierungen auf Textebene fressen RAM und Rechenleistung und haben auch noch den Nachteil, dass in den Datenfeldern der Delimiter maskiert werden muss, falls der darin vorkommt, sonst geht die Struktur kaputt.
Selbst, wenn Du eine solche Datei zeilenweise einlesen tust, es muss gesplittet werden, also hast Du in dem Moment die Daten doppelt im RAM, bis das Array fertig ist. Bei einigen tausend Zeilen wird das dann auch spürbar langsamer.
Mein Vorschlag geht in Richtung Rohdaten (binary) und Serialisierung, das ist RAM und CPU gefällig, ist sehr performant und es ist dann auch völlig Wurscht, in welcher Codierung die Zeichen vorliegen und ob da ein Komma drin vorkommt, es gibt keine Delimiter, die maskiert werden müssen.
Wenn eine Binärdati eingelesen wird, entfällt auch das splitten, es werden beim Deserialisieren nur noch bytes gelesen und gleich das Array im RAM gefüllt. Zeilen "\n" gibt es auch nicht mehr, aber einen Nachteil hats: Binärdateien sind nicht mehr von Hand editierbar, jedenfalls nicht so ohne Weiteres.
Hotti
-
你好 hotti,
Selbst, wenn Du eine solche Datei zeilenweise einlesen tust, es muss gesplittet werden, also hast Du in dem Moment die Daten doppelt im RAM, bis das Array fertig ist.
Eine CSV-Datei (was auch nur eine Art der Daten-Serialisierung ist) kann genau so gelesen werden ohne doppelt im Speicher vorzuliegen. Die Art zu lesen und zu parsen hat erstmal nichts mit dem Datenformat zu tun.
Mein Vorschlag geht in Richtung Rohdaten (binary) und Serialisierung, das ist RAM und CPU gefällig, ist sehr performant und es ist dann auch völlig Wurscht, in welcher Codierung die Zeichen vorliegen und ob da ein Komma drin vorkommt, es gibt keine Delimiter, die maskiert werden müssen.
Ein Binär-Format *kann* schneller sein als ein Plaintext-Format, muss es aber nicht. Eine einfache binäre Serialisierung von Daten ist ähnlich schnell wie eine Plaintext-Serialisierung. Auch hier muss die vollständige Datei bis zu der Stelle gelesen werden, die ich haben will. Erst das Einführen von Indizes kann den Zugriff schneller gestalten.
Wenn eine Binärdati eingelesen wird, entfällt auch das splitten,
Das stimmt natürlich nicht. Auch das binäre Format muss geparsed werden.
es werden beim Deserialisieren nur noch bytes gelesen und gleich das Array im RAM gefüllt.
Das gleiche gilt für ein Plaintext-Format. Auch hier werden nur Bytes gelesen und gleich in das Array im RAM gefüllt.
Binäre Datenformate können große Vorteile (und auch große Nachteile) haben und können deutlich schneller zu parsen sein als andere Formate. Aber deine Argumentation ist unsinnig, und das einfache binäre serialisieren macht das lesen von Daten noch nicht schneller. Ich kann mir höchstens vorstellen, dass dein Algorithmus zum parsen von Binär-Daten effektiver ist als der zum Parsen von Plaintext-Daten.
Bei Script-Sprachen musst du natürlich auch darauf achten, dass du das gleiche Interface verwendest: ein in C geschriebener Programmteil ist üblicherweise schneller als ein Script-Pendant (gilt nicht immer, aber oft).
再见,
克里斯蒂安-
hi,
... Ich kann mir höchstens vorstellen, dass dein Algorithmus zum parsen von Binär-Daten effektiver ist als der zum Parsen von Plaintext-Daten.
Das ist das Mindeste, was Du Dir vorstellen darfst ;-)
Freilich könnten wir uns trefflich streiten über den Begriff "Parsen". Für meine Begriffe ist das Lesen einer bestimmten Anzahl bytes aus einem Handle jedoch kein "Parsen" sondern "Serialisierung" bzw. die Umkehrung davon und mehr mache ich beim Einlesen meiner binaries nicht.
Parsen wäre beispielsweise die Zerlegung eine multipart Mesg. nach dem MIME-Standard (boundary) in Eizelteile oder die Wiederherstellung der Komponenten aus einem QUERY_STRING.
Nicht streiten müssen wir unter meinen o.g. begrifflichen Aspekten über Performance, RAM- und CPU-Gefälligkeit was den Unterschied zwischen Parsen und Serialisieren betrifft.
Schönen Abend,
Hotti-
你好 hotti,
Freilich könnten wir uns trefflich streiten über den Begriff "Parsen".
Es ist egal, wie du es nennst. Sachlich bleibt es das selbe. Nur das Format ist anders. Von mir aus kannst du auch deserialisieren sagen. Es ändert nichts an meinen Aussagen.
Nicht streiten müssen wir unter meinen o.g. begrifflichen Aspekten über Performance, RAM- und CPU-Gefälligkeit was den Unterschied zwischen Parsen und Serialisieren betrifft.
Was willst du mir damit sagen?
再见,
克里斯蒂安
-
-
-
-
-
-
Hi!
Ich dachte ich nehme den Timestamp als solchen absoluten identifizierer. Erstens wird das eine Stans-Alone -DB, so daß zwei Einträge zur selben Zeit unmöglich wären. Zweitens ist immer nur ein Datensatz in der Maske editierbar.
Wie lange braucht man denn für das Editieren eines Datensatzes und wie wahrscheinlich ist folgendes Szenario?
Rechner-Uhren sind nicht gerade Präzisionsinstrumente und tendieren mitunter dazu, der wirklichen Zeit davonzulaufen oder hinterherzuhinken. Deshalb gibt es Synchronisationsmechanismen wie NTP. Die synchronisieren aber nicht ständig mit dem Zeit-Server, denn das bedeutet auch Netzlast. Also wird nur aller X Zeiteinheiten die Rechner-Uhr korrigiert, was zu Zeitsprüngen und damit fehlenden oder doppelt durchlaufenen Bereichen führt. Ich hatte es neulich auf einer virtuellen Maschine gesehen, die lief recht deutlich davon.
Lo!
-
你好 dedlfix,
Deshalb gibt es Synchronisationsmechanismen wie NTP. Die synchronisieren aber nicht ständig mit dem Zeit-Server, denn das bedeutet auch Netzlast. Also wird nur aller X Zeiteinheiten die Rechner-Uhr korrigiert, was zu Zeitsprüngen und damit fehlenden oder doppelt durchlaufenen Bereichen führt.
Naja, eine korrekte Implementation von NTP sieht vor, dass die Zeit auf dem Rechner langsamer vergeht, bis die richtige Zeit erreicht wurde (im Falle eines Vorgehens) oder halt zum richtigen Zeitpunkt schneller vergeht. So macht es z. B. die Referenz-Implementation ntpd des NTP-Projekts. So können zwei Zeitpunkte nie doppelt auftreten (theoretisch).
再见,
克里斯蒂安-
Hi!
Naja, eine korrekte Implementation von NTP sieht vor, dass die Zeit auf dem Rechner langsamer vergeht, bis die richtige Zeit erreicht wurde (im Falle eines Vorgehens) oder halt zum richtigen Zeitpunkt schneller vergeht. So macht es z. B. die Referenz-Implementation ntpd des NTP-Projekts. So können zwei Zeitpunkte nie doppelt auftreten (theoretisch).
Gilt das auch für Rückführungen extremer Abweichungen, also 15 Minuten beispielsweise?
Lo!
-
你好 dedlfix,
Gilt das auch für Rückführungen extremer Abweichungen, also 15 Minuten beispielsweise?
Theoretisch ja. Praktisch hat halt der Sysadmin irgendwann die Nase voll (oder versteht die Problematik nicht) und setzt die Zeit von Hand. Oder so.
Um nochmal klarzustellen: ich wollte dir bei deiner Skeptik gegenüber der Zeit als einziges Unique-Kriterium nicht widersprechen. Darauf würde ich mich auch nicht verlassen.
再见,
克里斯蒂安
-
-
-
Hi dedlfix
Rechner-Uhren sind nicht gerade Präzisionsinstrumente und tendieren mitunter dazu, der wirklichen Zeit davonzulaufen oder hinterherzuhinken. Deshalb gibt es Synchronisationsmechanismen wie NTP. Die synchronisieren aber nicht ständig mit dem Zeit-Server, denn das bedeutet auch Netzlast. Also wird nur aller X Zeiteinheiten die Rechner-Uhr korrigiert, was zu Zeitsprüngen und damit fehlenden oder doppelt durchlaufenen Bereichen führt. Ich hatte es neulich auf einer virtuellen Maschine gesehen, die lief recht deutlich davon.
Guter Einwand an den ich nicht dachte. Nur das Prorgamm läuft lokal auf meinem bzw. dann auf nem Firmenrechner. Dort hängt die Zeit wohl an der Batterie auf dem Mainboard - denke ich.
Andere Frage:
Wie "Gut" oder "Schlecht" wäre für dich die Tatsache, daß du in einer DB nur nach Kundennummern die Kundendaten aufrufen kannst? Ist es "schlimm", nicht direkt nach dem Familiennamen suchen zu können?Solch eine Abfrage wäre zwar praktikabel, der Aufwand hierfür aber verdammt hoch. Da beispielsweise "Schmidt" oder "Meier" gleich mehrfach auftreten können, müsste ich eine Auswahltabelle generieren. Mal ganz abgesehen von der weiteren Verarbeitung einer solchen Tabelle.
Wenn ich so was umsetzte, wäre ich für ein i-Frame in der "Meldungsmaske" meines bisherigen Frontends - Scrollbar versteht sich *g*
Um sich das bildlich vor zu stellen...
Sonst noch Ideen, Funktionen, die bei der Bedienug fehlen?
Noch ein paar Worte zur Auflösung/Breite:
Da die Datensätze recht lang sind, und diese auch noch auf einen Blick in einer Reihe stehen müssen, bin ich so um die 1250 pix in der Breite. Ich denke , da die meisten Schirme und neueren Computer eh 1280X irgendwas haben, bin ich gut drunter geblieben. Ich selber sehe das Problem hier jetzt weniger - habe 1920x1080 pix - von daher noch massig Platz auf der rechten Seite.Und immer daran denken - es ist keine Webseite für das Internet, sondern ein reines Ausgabemedium für die DB.
Gruß Gary
-
Hi!
Wie "Gut" oder "Schlecht" wäre für dich die Tatsache, daß du in einer DB nur nach Kundennummern die Kundendaten aufrufen kannst? Ist es "schlimm", nicht direkt nach dem Familiennamen suchen zu können?
Das musst du die Anwender fragen, die mit dem System arbeiten sollen. In der Praxis reicht das oft nicht, weil die Kunden ihre Kundennummer grad nicht parat haben oder $anderer_grund.
Solch eine Abfrage wäre zwar praktikabel, der Aufwand hierfür aber verdammt hoch. Da beispielsweise "Schmidt" oder "Meier" gleich mehrfach auftreten können, müsste ich eine Auswahltabelle generieren. Mal ganz abgesehen von der weiteren Verarbeitung einer solchen Tabelle.
So hoch ist der Aufwand nun auch wieder nicht. Du hast ja schon eine Möglichkeit zur Abfrage der Daten über die Kundennummer, also GET daten?kdnr=... Nun brauchst du nur eine Suchmaske und die Ausgabe der Ergebnisse in Tabellenform. In der verlinkst du die Zeilen oder auch nur eine Zelle der Zeile mit dem daten?kdnr=... Fertig. Für's erste. Weitere Funktionalität wie seitenweises Anzeigen mit Blättern und Sortieren kannst du schrittweise hinzufügen.
Sonst noch Ideen, Funktionen, die bei der Bedienug fehlen?
Frag deine Anwender. Mitunter kommen Wünsche auch erst beim Arbeiten, wenn die feststellen, das irgendwas fehlt oder umständlich zu bedienen ist.
Noch ein paar Worte zur Auflösung/Breite:
Da die Datensätze recht lang sind, und diese auch noch auf einen Blick in einer Reihe stehen müssen, bin ich so um die 1250 pix in der Breite. Ich denke , da die meisten Schirme und neueren Computer eh 1280X irgendwas haben, bin ich gut drunter geblieben.Auch dazu kann ich dir kein Patentrezept geben. Mobile Geräte sind derzeit bei ca. 800px maximale Breite und die auch noch mit einer hohen dpi-Zahl, also ohne Zoom oftmals unbrauchbar, was die "800px" auf quasi "400px" oder ähnliche Werte bringt. Wenn das ein Szenario ist oder werden könnte, wären deine 12..px zu viel.
Zum Bearbeiten würde ich Daten nicht unbedingt in Tabellenform anordnen. Irgendwann kommen neuen Felder hinzu und die Tabelle wird immer breiter. Nach unten wachsendes Eingabemasken und dabei gegebenenfalls zu scrollen ist angenehmer zu bedienen.
Und immer daran denken - es ist keine Webseite für das Internet, sondern ein reines Ausgabemedium für die DB.
Das sagt nicht viel aus. Auch im Internet können sich "reine Ausgabemedien für die DB" befinden.
Lo!
-
Hi dedlfix
Das musst du die Anwender fragen, die mit dem System arbeiten sollen. In der Praxis reicht das oft nicht, weil die Kunden ihre Kundennummer grad nicht parat haben oder $anderer_grund.
Da hast du recht. Ich werde erst mal die bisherige Variante zusammenbauen und dann versuchen die Namenssuche zu implementieren.
Frag deine Anwender. Mitunter kommen Wünsche auch erst beim Arbeiten, wenn die feststellen, das irgendwas fehlt oder umständlich zu bedienen ist.
Jep - leider... würd mich auch wundern wenn es anders wäre...
Zum Bearbeiten würde ich Daten nicht unbedingt in Tabellenform anordnen. Irgendwann kommen neuen Felder hinzu und die Tabelle wird immer breiter. Nach unten wachsendes Eingabemasken und dabei gegebenenfalls zu scrollen ist angenehmer zu bedienen.
Auch da hast du recht. Aber da alle Felder eigene ID's haben, dürfte sich ein späterer Umbau leicht gestalten. Momentan sollen das mal die relevanten Felder sein.
Danke für dein Post.
Gruß Gary
-
-
-