CSV Export Stücklisten - Frage an die Community
Moderator: ft-Datenbank-Team
Forumsregeln
Bitte beachte die Forumsregeln!
Bitte beachte die Forumsregeln!
CSV Export Stücklisten - Frage an die Community
Hallo!
Wir haben ja mittlerweile den CSV Export der Stücklisten in der Datenbank drin.
Derzeit wird Ánzahl, Bezeichnung, Farbe ausgeben in der CSV Datei.
Wäre es sinnvoll hier auch die Artikelnummer auszugeben?
Ich geben hier bei zu bedenken das die Artikelnummern ja nicht eindeutig sind, da ft ja Artikelnummern teilweise mehrfach verwendet.
Daher müsste man schon Jahr+Artikelnummer ausgeben.
Wie denkt Ihr darüber?
Gruß
Sven
Wir haben ja mittlerweile den CSV Export der Stücklisten in der Datenbank drin.
Derzeit wird Ánzahl, Bezeichnung, Farbe ausgeben in der CSV Datei.
Wäre es sinnvoll hier auch die Artikelnummer auszugeben?
Ich geben hier bei zu bedenken das die Artikelnummern ja nicht eindeutig sind, da ft ja Artikelnummern teilweise mehrfach verwendet.
Daher müsste man schon Jahr+Artikelnummer ausgeben.
Wie denkt Ihr darüber?
Gruß
Sven
Dieses Posting gibt ganz allein meine persönliche Meinung wieder!
- steffalk
- ft:pedia-Herausgeber
- Beiträge: 1794
- Registriert: 01 Nov 2010, 16:41
- Wohnort: Karlsruhe
- Kontaktdaten:
Re: CSV Export Stücklisten - Frage an die Community
Tach auch!
Ergänzend zu Sven: Die Fragen sind:
* Braucht überhaupt jemand .CSVs aus der ftdb?
* Was genau wird denn gebraucht? Artikellisten? Dokumentlisten? Bild-Informationen? Stücklisten?
Gruß,
Stefan
Ergänzend zu Sven: Die Fragen sind:
* Braucht überhaupt jemand .CSVs aus der ftdb?
* Was genau wird denn gebraucht? Artikellisten? Dokumentlisten? Bild-Informationen? Stücklisten?
Gruß,
Stefan
Re: CSV Export Stücklisten - Frage an die Community
Hallo zusammen,
ich bin einer von denen, die sich einen Stuecklisten-Export gewuenscht haben. Zweck: Ich habe meine eigene Inventar-Datenbank (da bin ich ja sicher nicht der einzige) bei der die Stuecklisten der Baukaesten die Grundlage bilden. Um jetzt Neuerungen aus der ftcdb importieren zu koennen, hatte ich mir damals einen Export als CSV gewuenscht (und umgekehrt auch die andere Richtung angeboten, dass ich Datensaetze aus meiner DB so aufbereiten kann, dass sie in die ftcdb importiert werden koennen). Ein Abtippen der Listen aus der ftcdb ist unpraktikabel. Ohne die Informationen der ftcdb irgendwie maschinell verarbeiten zu koennen, ist die ftcdb daher zwar ein nettes Nachschlagewerk aber fuer mich nicht wirklich sinnvoll.
Was ich brauchen kann: Alles
: Artikellisten, Stuecklisten, Bilder. Allerdings ist der Export der Liste pro Baukasten auch wieder unpraktikabel, eigentlich wuerde ich mir einen Export des gesammten Datenbestandes auf einmal wuenschen.
Ohne Artikelnummern ist eine solche Liste auf jeden Fall nicht viel wert. Das Thema mit den doppelt verwendeten Artikelnummern ist auch schon oft diskutiert worden. In der Datenbank gibt es ja aber sicher einen eindeutigen Artikel-Index, der sich ja wohl hoffentlich nach Vergabe eines Wertes nicht mehr nachtraeglich aendert. Ich werde daher vorschlagen, sowohl die (nicht eindeutige) Artikelnummer als auch den eindeutigen Index zu exportieren, dann waere alles enthalten, was man benoetigen kann.
Gruesse
Alfred
ich bin einer von denen, die sich einen Stuecklisten-Export gewuenscht haben. Zweck: Ich habe meine eigene Inventar-Datenbank (da bin ich ja sicher nicht der einzige) bei der die Stuecklisten der Baukaesten die Grundlage bilden. Um jetzt Neuerungen aus der ftcdb importieren zu koennen, hatte ich mir damals einen Export als CSV gewuenscht (und umgekehrt auch die andere Richtung angeboten, dass ich Datensaetze aus meiner DB so aufbereiten kann, dass sie in die ftcdb importiert werden koennen). Ein Abtippen der Listen aus der ftcdb ist unpraktikabel. Ohne die Informationen der ftcdb irgendwie maschinell verarbeiten zu koennen, ist die ftcdb daher zwar ein nettes Nachschlagewerk aber fuer mich nicht wirklich sinnvoll.
Was ich brauchen kann: Alles
![Zwinkern ;)](./images/smilies/icon_e_wink.gif)
Ohne Artikelnummern ist eine solche Liste auf jeden Fall nicht viel wert. Das Thema mit den doppelt verwendeten Artikelnummern ist auch schon oft diskutiert worden. In der Datenbank gibt es ja aber sicher einen eindeutigen Artikel-Index, der sich ja wohl hoffentlich nach Vergabe eines Wertes nicht mehr nachtraeglich aendert. Ich werde daher vorschlagen, sowohl die (nicht eindeutige) Artikelnummer als auch den eindeutigen Index zu exportieren, dann waere alles enthalten, was man benoetigen kann.
Gruesse
Alfred
Re: CSV Export Stücklisten - Frage an die Community
Hallo!
@alfred.s:
Also csv export der einzelnen Stücklisten geht ja jetzt schon.
Export von Bildern und Dokumenten wie Anleitungen wäre Wahnsinn.
Die Sachen liegen ja nicht im Dateisystem sondern sind alle in der Datenbank selber gespeichert.
DIe Datenbank hat derzeit rund 5GB und wächst immer weiter.
Solche Datenmengen als Download anbieten wäre Wahnsinn und halte ich auch gar nicht für sinnvoll.
Oder wie woll Deiner Meinung nach so eine csv-Datei mit dem gesammten Datenbestand aussehen?
Was relativ einfach realisierbar wäre, wäre z.B. csv export aller Baukästen (Artikelnummer, Name, ...), Einzelteile, Dokumente (Artikelnummer,Name, aber nicht das Dokument selber.
Export von allen Stücklisten ist sicherlich auch problematisch, zu mal man hier ja auf Knopfdrucken hunderte, tausende oder wie auch immer wieviele Dateien erzeugen müssten. In einer CSV untereinander weg alle Stücklisten bringts ja auch nicht.
Mit dem eindeutigen Index wirst Du kaum was anfangen können. Das sind hier sogenannte guids.
Die sehen beispielsweise so aus: adc86685-2078-4996-81cf-1b292bad9864
Gruß
Sven
@alfred.s:
Also csv export der einzelnen Stücklisten geht ja jetzt schon.
Export von Bildern und Dokumenten wie Anleitungen wäre Wahnsinn.
Die Sachen liegen ja nicht im Dateisystem sondern sind alle in der Datenbank selber gespeichert.
DIe Datenbank hat derzeit rund 5GB und wächst immer weiter.
Solche Datenmengen als Download anbieten wäre Wahnsinn und halte ich auch gar nicht für sinnvoll.
Oder wie woll Deiner Meinung nach so eine csv-Datei mit dem gesammten Datenbestand aussehen?
Was relativ einfach realisierbar wäre, wäre z.B. csv export aller Baukästen (Artikelnummer, Name, ...), Einzelteile, Dokumente (Artikelnummer,Name, aber nicht das Dokument selber.
Export von allen Stücklisten ist sicherlich auch problematisch, zu mal man hier ja auf Knopfdrucken hunderte, tausende oder wie auch immer wieviele Dateien erzeugen müssten. In einer CSV untereinander weg alle Stücklisten bringts ja auch nicht.
Mit dem eindeutigen Index wirst Du kaum was anfangen können. Das sind hier sogenannte guids.
Die sehen beispielsweise so aus: adc86685-2078-4996-81cf-1b292bad9864
Gruß
Sven
Dieses Posting gibt ganz allein meine persönliche Meinung wieder!
- steffalk
- ft:pedia-Herausgeber
- Beiträge: 1794
- Registriert: 01 Nov 2010, 16:41
- Wohnort: Karlsruhe
- Kontaktdaten:
Re: CSV Export Stücklisten - Frage an die Community
Tach auch!
* Eigenen Bestand einpflegen
* Eigene Klebe- oder Einlegeetiketten drucken für genau "meinen" Bestand und "meinen" Einsortierplan
Was ist noch ein Grund, eine eigene Datenbank fahren zu wollen? Wäre es sinnvoll, nützlich, und überhaupt erwünscht, solche Dienste direkt von der ftdb anzubieten (z. B. dass jeder seine eigenen Stücklisten darin halten kann)? Eure Wünsche und Gedanken dazu könnten für die Weiterentwicklung der ftdb ein interessanter Input sein.
Zu Artikeln, Bildern und Dokumenten könnten wir neben den Stammdaten auch direkte Links zu den jeweiligen Fotos bzw. Dokumenten anbieten. Wer also mag, könnte dann also auch seine eigene Bestands-Datenbank nutzen und per Eigenprogrammierung dafür sorgen, dass auch ein Bild aus der ftdb angezeigt wird, ohne gleich 5 GB runterladen zu müssen.
Noch ein Gedanke zu eigenen Datenbanken - aber noch mit Vorbehalt wegen Lizenzrecht an Bildern u. dgl.: Fredy wird ja "demnächst" die Pflege der Datenbank übernehmen, mit einer lokalen Installation von SF Parts mit einer lokalen Installation eines Microsoft SQL Server 2008 R2 Express. Auch bei der Pflege wollen wir wohl nicht wegen jedem kleinen Update immer die vollen ~5 GB zum ftc-Server hochladen, sondern einen inkrementellen Upload ermöglichen. Die Pflege online ist auf absehbare Zeit unrealisitisch, weil niemand für die Datenbank in angemessener Zeit Pflegeseiten schreibt. Es wäre aber ganz vorsichtig andenkbar, dass auch SF Parts an die Community gegeben werden könnte, sofern Leute das plus einen MS SQL Server installieren wollen. Die könnten dann eventuell auch irgendwie mit inkrementellen Updates versorgt werden. SF Parts würde dann sozusagen ein "Produkt" sein wie der SF ft Community Publisher, nur mit deutlich höheren Voraussetzungen. Bevor wir uns aber damit auseinandersetzen, ob und wie das ermöglicht werden könnte, wäre auch hier die Frage zu stellen: Gibt's dafür überhaupt Bedarf? Will sowas jemand? Wie viele würden das wollen und können?
Wir könnten auch .CSV oder .XML mit allen Inhalten (außer den Bildern und Dokumenten selbst, die aber per Link) bereitstellen, sodass jemand die ganze Datenbank selber nachbauen kann. Auch hier: Würde das jemand wollen? Hinreichend viele? Und vor allem: Wozu? Wäre das wirklich der beste Weg, wenn jeder eine lokale Kopie der ftdb hält, anstatt dass wir bestimmte Dienste für alle online anbieten, und man braucht zur Nutzung nichts weiter als einen Browser?
Gruß,
Stefan
Das ist ein interessanter Punkt. Ich bange ja auch schon für den Tag, an dem ich die "Masterkopie" der Datenbank bei mir an Fredy zur Pflege abgebe. Die Frage ist: Warum? Was genau will man mit einer lokalen ftdb machen? Als erstes kämen mir da in den Sinn:Ich habe meine eigene Inventar-Datenbank (da bin ich ja sicher nicht der einzige) bei der die Stuecklisten der Baukaesten die Grundlage bilden.
* Eigenen Bestand einpflegen
* Eigene Klebe- oder Einlegeetiketten drucken für genau "meinen" Bestand und "meinen" Einsortierplan
Was ist noch ein Grund, eine eigene Datenbank fahren zu wollen? Wäre es sinnvoll, nützlich, und überhaupt erwünscht, solche Dienste direkt von der ftdb anzubieten (z. B. dass jeder seine eigenen Stücklisten darin halten kann)? Eure Wünsche und Gedanken dazu könnten für die Weiterentwicklung der ftdb ein interessanter Input sein.
Full ack. Wenn man schon eigene DBs führen will, will man nicht pro Kasten einen Download anstoßen. Und natürlich müssen die Artikel eindeutig gekennzeichnet werden. Mindestens müssen dazu ArtNr und Jahr mit ausgegeben werden. Die Primärschlüssel in der Datenbank, eben diese etwas eklig aussehenden langen GUIDs, sind aber vielleicht auch nützlich für irgendwelche Synchronisations-Szenarien zwischen eigener und ft-db. Das wäre aber auch alles kein Problem.Allerdings ist der Export der Liste pro Baukasten auch wieder unpraktikabel
Zu Artikeln, Bildern und Dokumenten könnten wir neben den Stammdaten auch direkte Links zu den jeweiligen Fotos bzw. Dokumenten anbieten. Wer also mag, könnte dann also auch seine eigene Bestands-Datenbank nutzen und per Eigenprogrammierung dafür sorgen, dass auch ein Bild aus der ftdb angezeigt wird, ohne gleich 5 GB runterladen zu müssen.
Noch ein Gedanke zu eigenen Datenbanken - aber noch mit Vorbehalt wegen Lizenzrecht an Bildern u. dgl.: Fredy wird ja "demnächst" die Pflege der Datenbank übernehmen, mit einer lokalen Installation von SF Parts mit einer lokalen Installation eines Microsoft SQL Server 2008 R2 Express. Auch bei der Pflege wollen wir wohl nicht wegen jedem kleinen Update immer die vollen ~5 GB zum ftc-Server hochladen, sondern einen inkrementellen Upload ermöglichen. Die Pflege online ist auf absehbare Zeit unrealisitisch, weil niemand für die Datenbank in angemessener Zeit Pflegeseiten schreibt. Es wäre aber ganz vorsichtig andenkbar, dass auch SF Parts an die Community gegeben werden könnte, sofern Leute das plus einen MS SQL Server installieren wollen. Die könnten dann eventuell auch irgendwie mit inkrementellen Updates versorgt werden. SF Parts würde dann sozusagen ein "Produkt" sein wie der SF ft Community Publisher, nur mit deutlich höheren Voraussetzungen. Bevor wir uns aber damit auseinandersetzen, ob und wie das ermöglicht werden könnte, wäre auch hier die Frage zu stellen: Gibt's dafür überhaupt Bedarf? Will sowas jemand? Wie viele würden das wollen und können?
Wir könnten auch .CSV oder .XML mit allen Inhalten (außer den Bildern und Dokumenten selbst, die aber per Link) bereitstellen, sodass jemand die ganze Datenbank selber nachbauen kann. Auch hier: Würde das jemand wollen? Hinreichend viele? Und vor allem: Wozu? Wäre das wirklich der beste Weg, wenn jeder eine lokale Kopie der ftdb hält, anstatt dass wir bestimmte Dienste für alle online anbieten, und man braucht zur Nutzung nichts weiter als einen Browser?
Gruß,
Stefan
Re: CSV Export Stücklisten - Frage an die Community
Hallo zusammen,
. Was hier Sinn machen wuerde ist ein Web-Link mit einem Datum der letzten Aenderung des Docs, dann kann man zumindest automatisch die neuen Docs finden.
Zuordnung noetig (und das sollte, nachdem hoffentlich keine Mehrfachverwendungen von ArtNrn. hinzukommen werden, eine einmalige Sache).
- Stuecklisten von Modellen einpflegen
- Vergleich von Modellstuecklisten und Bestand um herauszufinden, welche Teile einem fehlen
Das ist es zumindest was meine DB kann.
.
Gruesse
Alfred
Da gebe ich dir recht, in einer CSV wuerden sich Binaerdaten auch nicht so gut machensven hat geschrieben:Export von Bildern und Dokumenten wie Anleitungen wäre Wahnsinn.
Oder wie soll Deiner Meinung nach so eine csv-Datei mit dem gesammten Datenbestand aussehen?
![Zwinkern ;-)](./images/smilies/icon_e_wink.gif)
Warum??? Wenn ein Feld der Tabelle die ArtNr. des Kastens ist (oder eine sonstige eindeutige ID) habe ich eine einzige Tabelle mit allen Stuecklisten. In meiner DB ist das auch nicht anders geloest. Sind das in der ftcdb denn mehrere Tabellen?sven hat geschrieben:In einer CSV untereinander weg alle Stücklisten bringts ja auch nicht.
Doch, doch, damit fange ich schon etwas an, unter der Voraussetzung, dass sich die guid eines Artikels nie aendert. Denn dann ist die Zuordnung zum richtigen Artikel-Datensatz eine einmalige Sache, die bei eindeutiger ArtNr. auch automatisch gemacht werden kann, nur bei den "wenigen" doppelt vergebenen ArtNrn. ist eine haendischesven hat geschrieben:Mit dem eindeutigen Index wirst Du kaum was anfangen können. Das sind hier sogenannte guids.
Zuordnung noetig (und das sollte, nachdem hoffentlich keine Mehrfachverwendungen von ArtNrn. hinzukommen werden, eine einmalige Sache).
- Eigenen Bestand einpflegen (schon genannt)steffalk hat geschrieben:Was genau will man mit einer lokalen ftdb machen?
- Stuecklisten von Modellen einpflegen
- Vergleich von Modellstuecklisten und Bestand um herauszufinden, welche Teile einem fehlen
Das ist es zumindest was meine DB kann.
Aus meiner Sicht ist das nicht erwuenscht. Meine persoehnlichen Daten halte ich lieber lokal als, dass ich sie irgendwo im Netz abstelle.steffalk hat geschrieben:Wäre es sinnvoll, nützlich, und überhaupt erwünscht, solche Dienste direkt von der ftdb anzubieten (z. B. dass jeder seine eigenen Stücklisten darin halten kann)?
Meiner Meinung nach haengt das davon ab, was man macht. Nur zum Halten von Baukaesten-Stuecklisten macht einen lokale Kopie nicht viel Sinn, da gebe ich dir recht. Aber wenn man die Daten eben auf eigene Art und Weise verarbeiten will und/oder mit eigenen Daten verknuepfen will (wie z.B. eine Bestandsliste) kommt man um eine lokale Kopie nur schwer herum. Ausserdem sollte man bedenken, dass es auch noch Rechner gibt, die nicht allways-on oder sogar never-on sind, die fangen dann mit einem Online-Service halt auch nur bedingt etwas ansteffalk hat geschrieben:Wäre das wirklich der beste Weg, wenn jeder eine lokale Kopie der ftdb hält?
![Zwinkern ;-)](./images/smilies/icon_e_wink.gif)
Gruesse
Alfred
- steffalk
- ft:pedia-Herausgeber
- Beiträge: 1794
- Registriert: 01 Nov 2010, 16:41
- Wohnort: Karlsruhe
- Kontaktdaten:
Re: CSV Export Stücklisten - Frage an die Community
Tach auch!
Vielen Dank für die ausführliche Antwort, Alfred.
- Ist das Zeugs auf der ftdb auch wirklich sicher gespeichert und geht nicht beim nächsten Stromausfall hops?
- Ist auch wirklich sichergestellt, dass keiner meine Daten ändert?
- Kann ich das nur über ein dröges unkomfortables html-Formular einpflegen?
- Kommt da nichts besseres als eine html-Tabelle als Ausgabe raus?
Dann könnte man weiterdenken: Die Dienste zentral, die Daten zentral, aber ich kann jederzeit meine eigenen Daten runterladen zur Datensicherung oder um noch was eigenes zu machen, was die ftdb nicht anbietet. Oder, falls hinreichend viele das wollen, tatsächlich eine Community-Anwendung, die man lokal installieren kann. Sooo viel Sinn macht es ja nun auch nicht, wenn jeder, der das gerne lokal nutzen würde, anfangen muss, selber was zusammen zu zimmern. Naja, das wird die Zukunft noch alles zeigen. Sammeln wir erst mal möglichst viele Stimmen hier.
Ich glaube aber, einen Export der Daten in 1 CSV je Tabelle oder als 1 XML oder so würde den Interessierten ja schon helfen, und schwer zu realisieren ist das auch nicht.
Gruß,
Stefan
Vielen Dank für die ausführliche Antwort, Alfred.
Nein, das ist natürlich genau so wie bei Dir auch eine Tabelle. Sven sah wohl vermutlich Deinen Einsatzzweck nicht bei seiner Antwort, aber wir würden natürlich schon die gesamte Stückliste aller Kästen in einem Block zur Verfügung stellen.Sind das in der ftcdb denn mehrere Tabellen?
Sobald ich an Fredy übergeben habe, wird sich kein Primärschlüssel mehr einfach so ändern.damit fange ich schon etwas an, unter der Voraussetzung, dass sich die guid eines Artikels nie aendert
Gute Ideen. Erzählt doch mal ein bisschen mehr über Deine Anwendung. Wie ist sie gemacht, wie sieht die Oberfläche aus, was kann sie alles?Stuecklisten von Modellen einpflegen, Vergleich von Modellstuecklisten und Bestand um herauszufinden, welche Teile einem fehlen. Das ist es zumindest was meine DB kann.
Das genau sind auch meine Bedenken. Allerdings frage ich mich gerade, warum eigentlich. Und da fallen mir folgende Zweifel ein:Meine persoehnlichen Daten halte ich lieber lokal
- Ist das Zeugs auf der ftdb auch wirklich sicher gespeichert und geht nicht beim nächsten Stromausfall hops?
- Ist auch wirklich sichergestellt, dass keiner meine Daten ändert?
- Kann ich das nur über ein dröges unkomfortables html-Formular einpflegen?
- Kommt da nichts besseres als eine html-Tabelle als Ausgabe raus?
Dann könnte man weiterdenken: Die Dienste zentral, die Daten zentral, aber ich kann jederzeit meine eigenen Daten runterladen zur Datensicherung oder um noch was eigenes zu machen, was die ftdb nicht anbietet. Oder, falls hinreichend viele das wollen, tatsächlich eine Community-Anwendung, die man lokal installieren kann. Sooo viel Sinn macht es ja nun auch nicht, wenn jeder, der das gerne lokal nutzen würde, anfangen muss, selber was zusammen zu zimmern. Naja, das wird die Zukunft noch alles zeigen. Sammeln wir erst mal möglichst viele Stimmen hier.
Ich glaube aber, einen Export der Daten in 1 CSV je Tabelle oder als 1 XML oder so würde den Interessierten ja schon helfen, und schwer zu realisieren ist das auch nicht.
Gruß,
Stefan
Re: CSV Export Stücklisten - Frage an die Community
Hallo!
CSV Export aller Stücklisten in einer Datei sollte dann kein großes Problem darstellen.
Evtl. guck ich nacher mal direkt danach.
Vermutlich wird es hier aber sinnvoller sein, eine .csv nach jedem Update auf den Server zum download zu legen.
Immer "on the fly" erzeugen ist so eine Sache bei so einer großen Tabelle.
Was ist wenn jemand einen Angriff startet und immer wieder automatisch den Export startet.
Das zwingt dann irgendwann den Server in die Knie.
Genauso ist es ja mit den csv Dateien alle Baukästen, Einzelteile, ...
Aber da werden wir schon eine gute Lösung finden.
Gruß
Sven
CSV Export aller Stücklisten in einer Datei sollte dann kein großes Problem darstellen.
Evtl. guck ich nacher mal direkt danach.
Vermutlich wird es hier aber sinnvoller sein, eine .csv nach jedem Update auf den Server zum download zu legen.
Immer "on the fly" erzeugen ist so eine Sache bei so einer großen Tabelle.
Was ist wenn jemand einen Angriff startet und immer wieder automatisch den Export startet.
Das zwingt dann irgendwann den Server in die Knie.
Genauso ist es ja mit den csv Dateien alle Baukästen, Einzelteile, ...
Aber da werden wir schon eine gute Lösung finden.
Gruß
Sven
Dieses Posting gibt ganz allein meine persönliche Meinung wieder!
Re: CSV Export Stücklisten - Frage an die Community
Meine DB ist eine MS Access 2002 Datenbank, darin lassen sich simple Oberflaechen sehr einfach gestalten und, wenn man sich mal ein wenig auskennt, auch zu recht komplexen Oberflaechen ausbauen. Die wesentlichen Tabellen sind Artikel-Daten, Teilelisten und Inventar. Jedes Objekt, egal ob Bauteil, Baukasten oder Modell oder sonstwas, hat eine eindeutige Artikelnummer und einen Eintrag in der Artikel-Tabelle (die doppelt vergebenen Artikelnummern wurden einfach durch ein angehaengtes A oder B geloest). Jeder Artikel kann eine Teileliste haben, somit kann ich Teilelisten von Baukaesten und von Modellen ueber einen Kamm scheren, sprich in einer einzigen Teilisten-Tabelle vereinen. Natuerlich kann jedem Artikel auch ein Bild zugewiesen werden, das wird allerdings, da die Bilder die DB ziehmlich aufblaehen, in einer eigenen Datenbankdatei gespeichert (wenn ich endlich die Zeit finde und die DB auf Access 2007 umbaue, kann ich die Bilder aus einfachen und platzsparenden JPGs nehmen).steffalk hat geschrieben:Gute Ideen. Erzählt doch mal ein bisschen mehr über Deine Anwendung. Wie ist sie gemacht, wie sieht die Oberfläche aus, was kann sie alles?
Die Oberflaeche besteht im wesentlich aus Formularen zur Eingabe von Artikel mit dazugehoeriger Teileliste und fuer Baukaesten mit Inventardaten (ich kann mal bei Gelegenheit Bilder davon machen und ins Netz stellen). Weiters gibt es natuerlich Hilfsformulare z.B. zum Suchen von Artikeln. Die wesentliche Maechtigkeit der Datenbank besteht aber in den Abfragen (Queries) die z.B.:
- aus der Inventartabelle und den Teilelisten fuer Baukaesten (plus einer kleinen Tabelle, wo die ueberzaeligen Teile eines Kastens abgelegt sind) eine komplette Inventarliste aufbauen
- aus der Modellliste plus Teileliste die verbauten Teile bestehender Modelle zusammenrechnet
- aus der Modellliste plus Teileliste die Liste der benoetigten Teile fuer die zu bauenden Modelle aufbaut
- aus den 3 obrigen Tabellen die Liste der zum Bauen der Modelle fehlenden Teile ausspuckt.
Natuerlich gibt's auch noch Abfragen zum einfachen Importieren von Artikeldaten aus Knoblochs Bestell-XLS oder von Teilelisten von der frueheren ftcdb. Inzwischen ist auch eine Verwaltung von Bauanleitungen und wo sie im Web zu finden sind hinzugekommen.
Wirklich aktive Verwendung findet bei mir derzeit eigentlich nur die Inventar-Auflistung, die Sache mit den Modellen hatte ich von Anfang an vorgesehen, ich hatte aber den Aufwand, Teilelisten von verschiedenen Modellen zu erstellen, unterschaetzt. Und inzwischen ist mein ft-Inventar soweit angewachsen, dass ich mir nur mehr bei Spezialteilen Sorgen um die Verfuegbarkeit machen muss und das laesst sich freihaendig im Kopf verwalten
![Zwinkern ;-)](./images/smilies/icon_e_wink.gif)
Gruesse
Alfred
Re: CSV Export Stücklisten - Frage an die Community
Genau das würde ich auch machen um Angriffe besser verkraften zu können. Nachdem mein Server geplättet wurde, habe ich die selbe Methode angewandt.sven hat geschrieben:Hallo!
CSV Export aller Stücklisten in einer Datei sollte dann kein großes Problem darstellen.
Evtl. guck ich nacher mal direkt danach.
Vermutlich wird es hier aber sinnvoller sein, eine .csv nach jedem Update auf den Server zum download zu legen.
Immer "on the fly" erzeugen ist so eine Sache bei so einer großen Tabelle.
Was ist wenn jemand einen Angriff startet und immer wieder automatisch den Export startet.
Das zwingt dann irgendwann den Server in die Knie.
Genauso ist es ja mit den csv Dateien alle Baukästen, Einzelteile, ...
Aber da werden wir schon eine gute Lösung finden.
Gruß
Sven
Re: CSV Export Stücklisten - Frage an die Community
Für die Leute mit ihrer eigenen DB und Vorbehalten gegen die Datenspeicherung auf dem Server könnte man villeicht ein Client-Programm entwickeln, dass die Daten aus der FT DB bei Bedarf lädt und es erlaubt Daten zu Teilevorrat zu speichern, Stücklisten zu drucken...
http://py4ft.weebly.com Programmiere Fischertechnik mit Python
- steffalk
- ft:pedia-Herausgeber
- Beiträge: 1794
- Registriert: 01 Nov 2010, 16:41
- Wohnort: Karlsruhe
- Kontaktdaten:
Re: CSV Export Stücklisten - Frage an die Community
Tach auch!
Dazu braucht man tatsächlich gar nicht extra etwas zu entwickeln - das gibt's schon!
SF Parts, das Programm, was die ftdb "füllt", kann bereits sämtliche öffentlichen Daten in einen Satz von CSV-Dateien schreiben. Darin ist dann der komplette Datenbankinhalt der ftdb mit Ausnahme der Bilder und Dokumente selbst enthalten, in derselben Struktur wie die Datenbank selbst. Die Metadaten über Bilder und Dokumente sind dabei, nur die echten Bytes halt nicht. Gezippt sind das derzeit knapp 2,4 MB.
Wer sowas für eigene Versuche haben möchte, kann mich einfach kurz ansprechen, und ich schicke ihm den aktuellen Satz CSV-Dateien mitsamt Dokumentation. Das sind derzeit 12 CSV-Dateien.
Gruß,
Stefan
Dazu braucht man tatsächlich gar nicht extra etwas zu entwickeln - das gibt's schon!
SF Parts, das Programm, was die ftdb "füllt", kann bereits sämtliche öffentlichen Daten in einen Satz von CSV-Dateien schreiben. Darin ist dann der komplette Datenbankinhalt der ftdb mit Ausnahme der Bilder und Dokumente selbst enthalten, in derselben Struktur wie die Datenbank selbst. Die Metadaten über Bilder und Dokumente sind dabei, nur die echten Bytes halt nicht. Gezippt sind das derzeit knapp 2,4 MB.
Wer sowas für eigene Versuche haben möchte, kann mich einfach kurz ansprechen, und ich schicke ihm den aktuellen Satz CSV-Dateien mitsamt Dokumentation. Das sind derzeit 12 CSV-Dateien.
Gruß,
Stefan