HAG Produkte Datenbank

      HAG Produkte Datenbank

      Als Sammler bin ich sehr stark an einer Datenbank über die HAG-Produkte interessiert. Über lange Jahre betrieb Stefan Unholz mit grosser Akribie mit der UNUM-Datenbank DAS Nachschlagewerk der HAG Modelle. Über die Bedienung der FrameMaker-Lösung kann man diskutieren, muss aber nicht, jedoch sind diese Punkte wesentlich:

      - die UNUM-DB umfasst eigentlich nur die alten Produkte aus der Vor-HAG GmbH Zeit
      - Produkte aus der Stansstader-Produktion werden nur "pro Memoria" geführt und leider mit unnötigen und oft nur destruktiven Kommentar versehen
      - es erfolgt keine institutionalisierte oder automatisierte Aktualisierung mit Stanser Daten, die Datenbank veraltet somit sehr schnell.

      Da wie erwähnt eine möglichst vollständige HAG Produkte Datenbank betrieben werden soll, wurden einige Überlegungen angestellt. Als Ziele wurden z.B. dies formuliert:

      - Web-basierte Applikation als Bestandteil der HAG HomePage
      - eine möglichst vollständige Datensammlung aller HAG Produkte (nicht berücksichtigt werden Ersatzteile, Trafos, Modellautos und Spur N)
      - Unterhalt durch HAG und/oder bezeichnete externe Personen mit entsprechenden Mutationsberechtigungen.
      - Die Daten der Datenbank werden als Allgemeingut betrachtet und stehen allen Nutzern frei zur Verfügung.

      Das hier angehängte Dokument soll als Diskussionsgrundlage dienen. Wer immer Anregungen/Vorschläge/Kommentare anzubringen hat, wird gebeten, diese Diskussionsplattform hier zu nutzen.

      150107 HAG Produkte Datenbank.pdf
      mfg

      Roland

      Danke Roland, dass Du Dich der Sache annimmst. Vor allem für Produkte aus Stans ist für mich die Sache interessant, da leider nicht (mehr) sichergestellt ist, dass diese Daten in der sonst vorzüglichen UNUM komplett enthalten sein werden. Auch mich stören dort (zwar nicht in der Datenbank) die teilweise unfairen und herabsetzenden Kommentare zu den Produkten von New-HAG . . .

      Hallo Roland

      Finde ich grundsätzlich eine gute Idee & Sache. Zudem schon eine relativ ausführliche "Spezifikation", da könnten sich gewisse Business-Analysten in unserem Geschäft eine Scheibe abschneiden (wenig Blabla, viel Fleisch am Kochen).
      Ich kann mir, sofern es terminlich/ressourcenmässig passt, durchaus vorstellen an dem Projekt mitzuentwickeln. Das definieren der Anforderungen überlasse ich gerne den gewieften Sammlern ;)

      Idealerweise wäre die Datenbank dann auch Grundlage für die Produktseite auf der Homepage (die ja nicht gerade vor Aktualität strotz :D )

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „RoFr“ ()

      Grundsätzlich suchen wir ja (nicht gerade sehr aktiv) so etwas auch für spur-N-schweiz. Daten sind en Masse vorhanden (z.B. bei mir mehrere Tausend Datensätze Modelle und mehr als 50'000 Datensätze zu Online-Transaktionen). Was fehlt ist eine Möglichkeit, diese benutzerfreundlich online zugänglich zu machen. Bei mir zu Hause habe ich das ganze auf MS Access-Basis für mich selbst, aber bestimmt nicht in einer Version, welche ich auf die Öffentlichkeit loslassen könnte.

      UNUM finde ich grundsätzlich zwar gut, aber die Benutzerfreundlichkeit ist mir zu gering, als dass ich Lust hätte, meine Daten auf dieser Basis auf den interessierten Schnitz der Menschheit loszulassen.

      Ich werde bei Gelegenheit mal noch verlauten lassen, welche Datenfelder ich für meine Modellsachen erfasse.

      als dass ich Lust hätte, meine Daten auf dieser Basis auf den interessierten Schnitz der Menschheit loszulassen.

      Musst Du auch nicht. In Sachen Mörschwiler Produktion von HAG hat dies dankenswerter Weise Unholz (zusammen mit Zuarbeitern) sehr vollständig erledigt. Ich sehe deshalb lediglich die Notwendigkeit, für die Produkte von New-HAG (also Stans) eine solche (gerne auch erweiterte) Datei zu erstellen und zu führen . . .

      teddych schrieb:

      Hoi Roland

      Danke dass du das anreisst, es dürfte ein grosses Bedürfnis sein.

      Ist angedacht die UNUM-Daten zu übernehmen?

      Gruss
      Teddy
      _________________
      <a href="http://modellbahn.mahrer.net/lokumbau/" class="externalURL" rel="nofollow" target="_blank">Lokumbau Digital</a>


      Es ist zu wünschen, dass sich die Kontrahenten "Pro und Kontro New HAG" endlich dazu entschliessen könnten, über den eigenen Schatten zu springen; und sich an einen (den gleichen) Tisch zu setzen, um die Unstimmigkeiten auszudiskutieren und reinen Tisch zu machen :!: .

      Dann könnten eventuell bspw. Roland und Stefan mit Unterstützung von weiteren Personen gemeinsame Sache in der HAG-Datenbank machen...
      Roland bspw. für den Bereich "New HAG", Stefan bspw. den Bereich "Old HAG". Gegenseitig ergänzend und unter Mitwirkung Anderer.

      Die UNUM-DB ist eine Hausnummer für sich - es wäre schade, wenn a.) diese nun "verdoppelt" würde, und b.) irgendwann mal veraltet und rückständig liegen bleibt....

      Aber eben wie eingangs erwähnt, solange die Fronten noch verhärtet sind; und sei es auch nur die Eine, wird sich dies kaum umsetzen lassen...

      Zwei separate - losgelöst voneinander - Datenbanken zu führen, würde ich jetzt nicht befürworten.

      Was für mich als Erweiterung der Datensätze noch in Frage kommen könnte, wäre bspw. die entsprechend ausgelieferte Motorvariante (64 - 66 - 88 - ...; usw.)
      (Anmerkungen sind meine persönlichen Eindrücke und Empfindungen. Diese müssen nicht zwingend die Eindrücke und Empfindungen Anderer wiedergeben.)

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „blacknight“ ()

      Produkte-Nummer: Soll jede Version (-20, -21, -22, -31, -32) separat aufgeführt werden oder reicht nur -21 (-20 sollte ja sowieso entfallen) und -31 oder gar nur eine Version (ohne Zusätze)? EDV-technisch ist die Datenmenge kein Problem, es stellt sich die Frage nach der Übersichtlichkeit.


      Meiner Meinung nach reicht ein Datensatz pro Lokmodell völlig aus, es wird so viel übersichtlicher. Bei Modellen, die es nur in einer Stromart gibt (z.B. der alte Te oder ev. Kleinstserien) kann ja dies in den Bemerkungen notiert werden.

      Sprache: reicht ein- oder ist mehrsprachig nötig? (nur deutsch oder de/fr/en…)


      Eine mehrsprachige Datenbank (de/fr/en) würde ich begrüssen und um die Menuführung, Feldbezeichungen und Hilfe zu übersetzen, hält sich der Aufwand mutmasslich noch in Grenzen. Individuelle Texte je Datensatz zu übersetzen, wird jedoch sicher etwas schwieriger und verkompliziert die Sache. Zudem weiss ich nicht, wie es um die technische Umsetzung steht. Und was auch klar ist: lieber eine einsprachige Datenbank als keine!

      Gruess Julian
      eisenbahnfans.ch - Die Website für Eisenbahnfans!

      Mehrsprachigkeit, seriös und vollständig umgesetzt, ist immer mit einem nicht zu unterschätzenden Aufwand verbunden.
      Ich würde vorerst dafür plädieren dies nur als Option zu sehen.

      Selbst bin ich schon länger dran eine webbasierte Online-Datenbank zu erstellen, ursprünglich geplant für das persönliche Inventar. Ursprünglich als Java-Lösung geplant (MoBa-Forum-Leser mögen sich an sortyourtrains erinnern) bin ich wegen der Hosting-Kompatibilität wieder auf PHP umgestiegen. Das momentane Software-Design sieht ein sehr flexibles Modell vor, d.h. Felder zum Beispiel können dynamisch hinterlegt werden, als Text, Datum, DropDown etc.
      Viel mehr als das Design und ein grobes Gerüst steht aber noch nicht. Sobald es etwas vorzeigbares gibt stelle ich das gerne mal vor.

      Hallo Roland
      Besten Dank für Deine Bemühungen. Ich werde gerne mitmachen.

      Meine Anregungen:
      - Artikelnummer sollte im gleichen Feld vollständig sein (inkl. 21-22-31-32) macht die Suche einfacher.
      - Bis die DB mal steht und die Daten eingepflegt sind einsprachig
      - Zusatzfelder können von Vorteil sein aber müssen sich in grenzen halten. (Werde die ein Screenshot auf Dein PN stellen.

      DATENERFASSUNG:
      - Für Mutationen Anmeldung nötig: JA (gibt sonst ein Chaos. Wie weniger Leute wie besser für die DB)
      - Für reine Abfrage, als GAST
      - Datenerfassung Online manuell: JEIN (Wenn ja sollte aber vor der Freigabe von einem Moderator oder Admin kontrolliert werden.
      - Datenerfassung mit Excelsheet: Ja (es gibt 2 Varianten Excelsheet an Admin schicken und der plfegt ein oder Excelsheet via DB dem Admin zu Kontrolle schicken. Das Excelsheet Felder müsse aber mit den DB Felder übereinstimmen)
      - Mitarbeit durch Externe, z.B. Sammler
      Gruss

      Marino

      Hallo Roland

      Die nachfolgenden Zeilen sollen erst einmal nur als Ideenlieferung betrachtet werden.

      Datenherkunft

      Inwieweit das bisherige UNUM-System integriert werden sollte, könnte oder müsste mit den Autoren der UNUM-DB abgeklärt werden (Lifecycle?). Ev. wäre sogar ein elektronischer Datentransfer möglich (Excel raus, Excel rein).

      Dem steht einer definitiv neuen Erfassung der Produkte nichts im Wege. Die Mitarbeit von Besitzern / Sammlern von HAG-Modellen wären da gefordert. Dazu kann/könnte die bisherige Produkte-Nr. (wenn ohne Überschneidungen) weiter verwendet werden.
      Der Datentransfer soll nur mit einem vorgegebenen Excelsheet an den Admin zur Prüfung der Daten und anschliessenden Übernahme in die DB erfolgen. Für Produkte mit nur dreistelliger Nummer müssten gegebenenfalls eine neue Produkte-Nr. vergeben werden.
      Hier ist anzumerken, dass sich die vorhandenen Informationen auf den Produktezustand zum Auslieferungszeitpunkt beziehen sollten.

      HAG GmbH
      Der Datentransfer für die DB von neuen Produkten müsste mit bereits festgelegter Produkte-Nr. von HAG geliefert werden (denn sie wissen was sie tun). Entweder On-line oder als Info in Excel an die Verantwortlichen der DB-Wartung.

      Datenbewirtschaftung:
      DB-Verantwortliche = Admins (Achtung: Zu viele Köche …).
      Add; Neuer Datensatz (Admins).
      Read: Grundsätzliche Random-lesen mit Bezug auf die Inhalte der vorgegebenen Eingabefelder. Anzeige von allen vorhandenen Treffern. Diese Ansicht sollte, ev. mit einer Mengenbeschränkung (Seiten 1-n) scrollfähig sein. Anschliessend mit Möglichkeit für die Auswahl einer Produkte-Nr. in Detailansicht. Ein zurück zur Globalüber- bzw. Ansicht sollte möglich sein. Einzeltreffer wie bereits beschrieben. Ev. Hinweis auf ‚Lieferbar‘. (Gast, Admin).
      Read4update: Nur möglich aus der Detail-Anzeige der Produkte-Nr. (Admin).
      Upd2Archiv: Nur möglich aus der Detail-Anzeige einer Produkte-Nr. Diese Funktion ist insbesondere für ein Produkt vorzusehen das nicht mehr lieferbar ist (Admin).
      Del: Diese Funktion würde ich z. Zt. vorsehen aber nicht offiziell aktivieren. Die Verwendung mit dem löschen einer Produkte-Nr. sollte jedoch nur nach einer vorgängigen Abklärung der Auswirkungen durchgeführt werden (z.B. erwiesener Datenschrott). (Admin)

      Die Funktion ‚Copy - > Add‘ würde ich nicht unbedingt unterstützen, es sei denn, dass eine formelle und logische Prüfung nach Eingabe der Daten vor dem Add erfolgt (ev. Prüfziffer). Bei einer Masseneingabe kann die Fehlerquote u.U. relativ hoch sein. Eine leere Eingabemaske macht mit dieser Funktion nicht viel Sinn.

      Nur den Admins werden die ihnen zur Verfügung stehenden Funktionen angezeigt.

      Datenfelder
      Seite 4
      Felder
      Unterscheidung nur zwischen AC (-31) und DC (-21) Modellen. Abweichende weitere Auslieferungen mit oder ohne Decoder sind im Zusatzfeld ‚Decoder‘ angegeben.
      Im ‚Bemerkungsfeld‘ sollte das aufgedruckte Rev.-Datum vorhanden werden.
      Seite 4
      Ev. Zusatzfelder
      Im Decoderfeld könnte zu (k)einer Decoder-Angabe auch die Info zu ausgelieferten Versionen -20 /-30 vorhanden sein. Sound-Loks weisen hier die Info -22 oder -32 auf.
      Nur bei Modellen mit ‚S‘ vor der Produkte-Nr. ist das Datenfeld mit der zutreffenden Menge vorhanden.

      Zukunft
      Möglicherweise könnte ein weiteres Nebenziel das Ersatzteileverzeichnis sein (Lagerbewirtschaftung).

      Bruno
      .

      modellbahner schrieb:

      Ich finde man sollte nur die Grund-Artikelnummer erfassen und dann mit Checkboxen ausweisen, welche Versionen (-31 etc) hergestellt wurden. Es bringt nichts für jede Lok vier oder noch mehr Datensätze zu erstellen, der Informationsgehalt wird dadurch nicht höher.


      Ich bin exakt der gleichen Meinung und solche Checkboxen würde ich super finden (darauf kam ich gar nicht) :thumbsup:

      Der Datensatz selber muss wahrscheinlich trotzdem eine interne Nummer haben. Denn sonst gerät man bei Doppelbelegungen von Artikelnummern etwas in Schwierigkeiten, oder?

      Gruess Julian
      eisenbahnfans.ch - Die Website für Eisenbahnfans!

      Wichtig scheint mir folgendes: Die Datenbank soll als Produktarchiv dienen und es muss klar ersichtlich sein, dass dies nicht das lieferbare Sortiment ist. Im Idealfall kann man daraus die Produkt-Seiten der Website ableiten (in dem der Admin bei den Artikel die sich im aktuellen Programm befinden eine entsprechende Markierung setzt). Aber die Trennung sollte klar sichtbar sein.

      Zuerst mal ein ganz herzliches Dankeschön für die diversen - und durchs Band von mir als positiv und konstruktiv empfundenen - Kommentare und Rückmeldungen!

      Nachfolgend beginne ich mal mit einer ersten Zusammenfassung aufgrund der diversen bisherigen Inputs, Rückmeldungen und sogar auch noch eigenen Überlegungen ;) . Vorausschicken will ich, dass es jetzt nur um die Grundlagen geht, und zwar einzig um ein Produktearchiv, welches nichts mit den aktuell lieferbaren Produkten zu tun hat. Auf die technische Umsetzung wird später eingegangen, da sind dann die Leute vom HomePage-Unterhalt gefordert. Weiter gehende Ideen (Ersatzteil-Verzeichnis, Grundlage für Produkte Seite) - sind nicht Gegenstand dieser Überlegungen, aber es soll darauf geachtet werden, dass wir uns da nicht selber etwas verbauen.

      - aktuell macht es leider den Anschein, dass es ein Miteinander zwischen UNUM- und HAG Produkte Datenbank wohl in der angedachten Form nicht geben wird. Schade, aber das ist dennoch kein Hinderungsgrund für den Aufbau einer zukunftsgerichteten Datensammlung
      - das Ziel bleibt aber noch immer eine Datenbank für alle HAG-Epochen
      - Artikelnummer: nur ein einziges Feld, darin werden alle Versionen (280 - 28 100 - 28100) untergebracht, es müssen alle Nummern in diesem Feld gefunden werden (Anmerkung: in meiner Auktionspreis-DB ist das genau so implementiert)
      - Es gibt nur einen Datensatz je Fahrzeug, also nur die 5- (resp. 3-)stellige Artikel-Nummer
      - die Versionen werden im Anschluss gelistet, zuerst -2 (für 2-motrorig) und dann die Betriebsart: -21, -22, -31, -32 (Willkürliches und rein hypothetisches) Beispiel für eine 2-motorige Re 6/6 Cossonay:
      20022 -2 X-20 -21 -22 X-30 -31 -32 (X=markierte Checkboxen)
      Es werden also keine zwei Artikel 244 und 245 für die gleiche Lok geführt. Für Wagen gilt dasselbe, es gibt nur noch einen Record für einen Wagen, einfach mit Checkbox bei -20 und -30 (Exakte Darstellung - inkl. den 3-stelligen Artikelnummern - muss im Prototyping ermittelt werden)
      Vorangehendes Zusatzfeld S- für Sondermodelle), produzierte Stückzahl nur bei S- Artikeln
      - Mehrsprachigkeit: wünschenswert, wird im Moment aber noch als "nice to have" klassiert
      - Datenerfassung/-bewirtschaftung: Um keine Missverständnisse aufkommen zu lassen: Abfragen darf jeder Nutzer der HAG Homepage, es wird aber nur sehr wenige Verantwortliche geben, die Daten in die Datenbank schreiben dürfen, es werden aber - so hoffe ich zumindest - auch Artikel von Sammlern und Besitzern gemeldet (es haben sich in verdankenswerter Weise bereits mehrere dazu bereit erklärt!), ob das nun mittels Excel-Schnittstelle (oder was weiss ich was) erfolgt, ist im Moment noch nicht relevant
      - Fotos: es muss die Möglichkeit geboten werden mehrere Fotos anzuhängen

      Weitere Diskussionspunkte:
      - Feld Motortyp (64 -66 -88) - nötig/wünschenswert?
      - sollen auch andere (ehemalige) HAG-Produkte aufgenommen werden? Möglich wären die ganzen Spur 0 und N Produkte, Trafos, Modellautos und was HAG sonst noch je produziert hatte.

      Julian: die Artikelnummer kann kein Primärschlüssel sein, es existierten bereits in der Vergangenheit Doppelbelegungen, die Entität wird wohl über eine Art RSN-Feld gewährleistet werden müssen

      So - das wäre es mal für den Moment. Weitere Inputs sind herzlich willkommen!
      mfg

      Roland

      erzhal schrieb:

      Julian: die Artikelnummer kann kein Primärschlüssel sein, es existierten bereits in der Vergangenheit Doppelbelegungen, die Entität wird wohl über eine Art RSN-Feld gewährleistet werden müssen

      Das ist so. Primärschlüssel sollten nie, nie (ich wiederhole: nie!) einen fachlichen Wert haben, den fachliche Regeln können sich ändern.
      Das erstellen von Primärschlüsseln und Referenzen darauf sollte man der Software überlassen (Datenbank oder Applikation). Fachliche Regeln (wie z.B. das gewisse Felder unique sein müssen) kann man dann unabhängig vom Datenmodell in der Applikation oder im Datenbankschema hinterlegen.