Praktikums Projekt Java vs MySQL

[Meniskusschaden]

Hab ich bisher anders erlebt - die nötigen Tabellen und Verknüpfungen werden eben oft erst spät klar.

Da haben wir wahrscheinlich einfach unterschiedliche Erfahrungen gemacht (oder die Grundlagen der verschiedenen Technologien in umgekehrter Reihenfolge gelernt). Ich schätze es bei meinem Ansatz, dass man - obwohl man bereits implementiert - beim Entwurf der DB noch sehr unabhängig von Implementierungsdetails arbeiten kann und einfach nur die Daten strukturiert, wie es (hoffentlich) richtig ist. Wenn man mit Textdateien beginnt, besteht z.B. die Gefahr, dass man nicht vernünftig normalisiert, weil man sich (als Anfänger vielleicht unbewußt) durch deren Limitierungen beeinflussen lässt. Wenn man zu früh mit der Programmierung oder dem Programmentwurf beginnt, besteht auch das Risiko, dass man fehlerhaft strukturiert, weil es für das aktuelle Detailproblem gerade einen scheinbar einfachen Weg gibt.
Grundsätzlich stimme ich dir natürlich zu, dass es ideal wäre, das Konzept im Vorfeld komplett fertig zu haben. Ich halte es hier - vor dem Hintergrund des Zeitfensters und der Vorkenntnisse - aber einfach für unrealistisch.

Ihr solltet bedenken, diese Daten stehen zur Zeit in einer Excel-Tabelle. Welche Tabellen und Verknüpfungen sollten da in der DB schon vorkommen ? Ein Tabelle "Blenden" ... fertig. Attribute sind wahrscheinlich so ziemlich 1:1 durch die Spalten der Exceltabelle vorgegeben

Ich vermute ganz stark, dass das denormalisierte Daten sind und zusätzliche Tabellen nötig sind. Es ist ja offenbar sogar eine Bestandsführung vorgesehen und da ist schon die Frage, ob es genügt, einfach ein Mengenfeld im Blendenstammsatz fortzuschreiben. Normalerweise würde ich da schon Bewegungsdaten haben wollen. Es wird auch weitere Attribute geben, bei denen man sich überlegen muß, ob sie einfach frei eingegeben oder in einem eigenen Stammsatz definiert werden sollen. Dafür wären vielleicht Hersteller und Blendencode mögliche Kandidaten.

 

[truesoul]

Hallo allerseits,

bei manchen habe ich das Gefühl das die nie was in kurzer Zeit für einen Kunden entwickelt haben.
Jeder Kunde (und so sehe ich auch der Arbeitgeber des TE) will was angezeigt bekommen.
Und wenn dann der TE mit der Datenbank beginnt, und dann nach 1 1/2 Wochen feststellt dass die DB super steht und läuft aber dann feststellt dass nur noch 5 Tage für die Oberfläche, für das auslesen der Daten aus der Datei, für das Anzeigen/Bearbeiten der Daten (Stehts anfänglich gegen Mocks) übrig bleibt, das wird ein Spaß.

Und dann nach den 2 1/2 Wochen es heißt ja, ich habe die Datenbank total klasse Designed. Ich kann mich auch mit dieser über Java Verbinden, aber ich kann leider nichts anzeigen, da ich mit der GUI oder das auslesen nicht fertig geworden bin. Dann steht man ausgesprochen doof da.

Wenn man in größeren Projekten arbeiten, wo die Entwicklerteams unterschiedlich aufgeteilt sind in DB, Backend ("hier die DB") und Frontend warten auch nicht die Entwickler vom Frontend bis die Datenbank/Backend endlich Daten liefert.

Lieber erst die Oberfläche entwickeln, das auslesen der Datei implementieren und diese dann auch anzeigen und bearbeiten (Mock). Und dann weiß man auch wie die Datenbank auszusehen hat. Und in der Regel tauscht man eine Klasse aus. Die Mockimplementierung gegen die DB Implementierung.

Sorry, normalisierung bei dieser Aufgabe, ein bisschen übertrieben. Wenn die Daten in einer Exceltabelle stecken reicht es auch diese in der DB abzubilden.

Ich vermute ganz stark

Vermuten heißt nicht wissen.

Ich vermute ganz stark, dass das denormalisierte Daten sind und zusätzliche Tabellen nötig sind. Es ist ja offenbar sogar eine Bestandsführung vorgesehen und da ist schon die Frage, ob es genügt, einfach ein Mengenfeld im Blendenstammsatz fortzuschreiben. Normalerweise würde ich da schon Bewegungsdaten haben wollen. Es wird auch weitere Attribute geben, bei denen man sich überlegen muß, ob sie einfach frei eingegeben oder in einem eigenen Stammsatz definiert werden sollen. Dafür wären vielleicht Hersteller und Blendencode mögliche Kandidaten.

Und ganz ehrlich, dass gehört alles nicht zur Aufgabenstellung.

Aufgabestellung lautet. Datei einlesen. Daten anzeigen. Daten bearbeiten. Datenbank einsetzen. Nichts mit, es könnten ja Händler und Stammsatz und und und ....

Bitte bedenkt. Praktikum. Sonst keine Praktische Erfahrung.

Grüße

 

[JStein52]

Sehe ich genau wie @truesoul und auch @Meniskusschaden hat sich ja oben schon mal ähnlich geäussert. Und ich finde jetzt ist der TE dran endlich mal konkret zu werden falls er weitere Fragen hat

 

[mrBrown]

nur so nebenbei zum Thema mehrbenutzerfähig ...

Spricht für Einzel-Benutzer

Gerade wolltest du ihm noch verkaufen er solle das ganze doch in einer csv-Datei erledigen ? Da hat er auch nur eine Tabelle Blenden mit ihren diversen Spalten ...

Nein, dann hat er Objekte etc, ob die aus der CSV kommen oder nicht ist wie gesagt egal.
Aber wenn man schon eine Datenbank nutzt, sollte man die Daten zumindest in ein passendes Format bringen.

Eine Datenbank im gleichen Format wie die CSV ist völlig überflüssig...

Und ganz ehrlich, dass gehört alles nicht zur Aufgabenstellung.

Für ihn (und für mich auch) offensichtlich schon

Da haben wir wahrscheinlich einfach unterschiedliche Erfahrungen gemacht (oder die Grundlagen der verschiedenen Technologien in umgekehrter Reihenfolge gelernt).

Das kann durchaus gut sein ;D

Ich schätze es bei meinem Ansatz, dass man - obwohl man bereits implementiert - beim Entwurf der DB noch sehr unabhängig von Implementierungsdetails arbeiten kann und einfach nur die Daten strukturiert, wie es (hoffentlich) richtig ist. Wenn man mit Textdateien beginnt, besteht z.B. die Gefahr, dass man nicht vernünftig normalisiert, weil man sich (als Anfänger vielleicht unbewußt) durch deren Limitierungen beeinflussen lässt. Wenn man zu früh mit der Programmierung oder dem Programmentwurf beginnt, besteht auch das Risiko, dass man fehlerhaft strukturiert, weil es für das aktuelle Detailproblem gerade einen scheinbar einfachen Weg gibt.

Das schätze ich auch Nur schieb ich eben das Strukturieren der Daten für die Datenbank auf, bis sie im Programm strukturiert sind.
Wenn dabei im Programm mehrere Modelle heraus kommen, ist das kein Problem - man muss es am Ende nur in eine Datenbank-Repräsentation überführen.
Ob die Daten in der Textdatei liegen oder nicht ist da egal, auch die Normalisierung - weil das Programm eben unabhängig davon ist. Deshalb würde ich sogar erstmal einfach nur mit im Programm gemocken Objekten arbeiten, und das ersetzt man später durch die echte Datenquelle - ob CSV oder DB ist dann egal.

vor dem Hintergrund des Zeitfensters und der Vorkenntnisse

Die beiden seh ich als Hauptproblem...

 

[mrBrown]

Sehe ich genau wie @truesoul und auch @Meniskusschaden hat sich ja oben schon mal ähnlich geäussert.

Also ich les in euren drei Beiträgen drei verschiedene Ansätze

Der letzte Beitrag von @truesoul ist quasi das Gegenteil von @Meniskusschaden...

 

[JStein52]

ist quasi das Gegenteil von @Meniskusschaden...

ich meine Post #43 von @Meniskusschaden

Edit: ... und bin jetzt erst mal raus, es sei denn es gibt neue Erkenntnisse/Fragen vom TE

 

[truesoul]

Wenn dabei im Programm mehrere Modelle heraus kommen, ist das kein Problem - man muss es am Ende nur in eine Datenbank-Repräsentation überführen.

Meine Rede bzw mein Gedanke. Während der Entwicklung kommt raus, wie die Datenbank am Ende aussehen kann.

 

[mrBrown]

ich meine Post #43 von @Meniskusschaden

Ich auch. Für mich sind die genau gegensätzlich. (Außer du siehst die Gemeinsamkeit da, dass beide mit etwas anfangen)

Lieber erst die Oberfläche entwickeln, das auslesen der Datei implementieren und diese dann auch anzeigen und bearbeiten (Mock).

@truesoul: Erst Programm, dann DB.

Ich würde auf jeden Fall mit der DB anfangen und mich um den Datenimport kümmern.

@Meniskusschaden: Erst DB, dann Programm.

 

[JStein52]

Außer du siehst die Gemeinsamkeit da, dass beide mit etwas anfangen

Da sehe ich allerdings eine starke und wichtige Ähnlichkeit. Anfang der Woche waren es 2 1/2 Wochen Zeit. Falls der TE inzwischen noch nichts konkretes angefangen hat sind es jetzt noch 2 Wochen.

 

[JStein52]

Spricht für Einzel-Benutzer

Du hast aber schon bemerkt dass er dabei den Plural verwendet ?

 

[mrBrown]

Du hast aber schon bemerkt dass er dabei den Plural verwendet ?

Den Smiley hast du schon überlesen?
Excel ist auch Einzelnutzer, obwohl viele das auf ihrem Rechner installieren

 

[JStein52]

Den Smiley hast du schon überlesen?

Ok hatte ich tatsächlich nicht richtig interpretiert. Und eben weil alle ihre eigene ExcelDatei verwenden wird das ja vermutlich ein Anstoss für diese Arbeit sein.

Edit: wahrscheinlich haben zur Zeit alle Dateien namens EmilsBlenden.xls, OttosBlenden.xls, HugosBlenden.xls und irgendein Depp sitzt da und führt die einmal pro Woche zusammen

 

[Meniskusschaden]

Es ist natürlich insgesamt viel Spekulation im Thread. Vielleicht ist die Excel-Datei ja bereits eine perfekt normalisierte Lösung. Hier weiß ja höchstens einer, wie viele Tabellen die enthält.
Die Vielfalt der möglichen Lösungen macht es für den TE auch nicht unbedingt einfacher. Wahrscheinlich fährt er am besten damit, sich einfach für irgendeine zu entscheiden, anstatt zu versuchen, heraus zu finden, welche die beste ist.

Der Dissenz ist vielleicht auch nicht ganz so groß, wie er erscheint, weil sich auch die Diskussionen über das "grundsätzlich richtige" und das "noch machbare" vermischen. Ich finde z.B. das Mocking-Konzept grundsätzlich gut, glaube hier aber nicht mehr daran.

bei manchen habe ich das Gefühl das die nie was in kurzer Zeit für einen Kunden entwickelt haben.
Jeder Kunde (und so sehe ich auch der Arbeitgeber des TE) will was angezeigt bekommen.

Ich verstehe das Argument, habe aber eher andere Erfahrungen gemacht. Ich glaube die Ursache ist, dass Arbeitgeber und Arbeitnehmer praktisch identische Interessen haben, was für Auftraggeber und Auftragnehmer sehr viel weniger gilt. Ich finde deshalb auch, dass Inhouse-Programmierung und Auftragsprogrammierung ganz unterschiedlich geführt werden müssen. Kommt aber auch darauf an, ob es ein "Inhaber-Chef" oder ein "Manager-Chef" ist. Ersterer interessiert sich dafür, ob es einen Fortschritt gab, Letzterer ob es wie ein Fortschritt aussieht.

Wenn man in größeren Projekten arbeiten, wo die Entwicklerteams unterschiedlich aufgeteilt sind in DB, Backend ("hier die DB") und Frontend warten auch nicht die Entwickler vom Frontend bis die Datenbank/Backend endlich Daten liefert.

Ja, aber ich finde den Maßstab für diese Aufgabe nicht angemessen.

@truesoul: Erst Programm, dann DB.

@Meniskusschaden: Erst DB, dann Programm.

Wenn man eine abgeschlossene Anwendung programmiert, kann man den ersten Weg gehen. Bei der Inhouse-Programmierung ist es aber doch meistens (außer bei der ersten Anwendung) ohnehin so, dass bereits große Teile der DB vorgegeben sind. Da kommt meines Erachtens hauptsächlich der zweite Weg vor.

 

[truesoul]

Ja, aber ich finde den Maßstab für diese Aufgabe nicht angemessen.

Was ich mit "Wenn man in größeren Projekten arbeiten, wo die Entwicklerteams unterschiedlich aufgeteilt sind in DB, Backend ("hier die DB") und Frontend warten auch nicht die Entwickler vom Frontend bis die Datenbank/Backend endlich Daten liefert." eigentliche meine ist, dass es ganz normal sein kann, ohne fertige Datenbanken zu beginnen.

Bei der Inhouse-Programmierung ist es aber doch meistens (außer bei der ersten Anwendung) ohnehin so, dass bereits große Teile der DB vorgegeben sind. Da kommt meines Erachtens hauptsächlich der zweite Weg vor.

Bei der Inhouse Entwicklung sehe ich es sehr ähnlich und habe auch Erfahrungen so gesammelt in der Inhouse Entwicklung. Nur speziell für diesen Fall ist es nicht gegeben.

Ich hoffe für den TE das er jetzt nicht total Erschlagen ist von den ganzen Informationen.

Grüße

 

[Meniskusschaden]

Ich hoffe für den TE das er jetzt nicht total Erschlagen ist von den ganzen Informationen.

Ich vermute mal, dass wir seine letzten vagen Erfolgshoffnungen längst ruiniert haben.

Ich vermute ganz stark

Vermuten heißt nicht wissen.

Es gibt also doch noch Hoffnung.

 

[Danloc]

Auch nachdem ich den gasammten Thread gelesen und nochmals drüber nachgedacht habe, kann ich der Lösung ohne Datenbank nichts abgewinnen. Wenn es darum gehen würde, Daten in eine CSV Datei zu speichern und dann zusammenpassende Daten auszugeben, bräuchte man meiner Meinung nach nichts Programmieren.
Das kann Excel schon von Haus aus! Es kann daten in csv abspeichern. Es kann die Daten sortiert anzeigen. Es kann mithilfe von formeln zusammenpassende Daten ausgeben (Ja sogar bunt!). Also wenn das wirklich Sinn und Zweck wäre, bräuchte man nur ein paar Excel Formeln...

Ob er nun mit der Datenbank anfängt oder erst die Oberfläche entwickelt, sei mal völlig dahingestellt.

Also nochmal an den TE:
Ich hatte zu beginn geschrieben, dass du GENAU klären muss, was das programm können soll.
Das der Thread hier ausgeartet ist, sollte für dich keinesfalls ein Zeichen dafür sein, dass die Aufgabenstellung super kompliziert ist. Es zeigt einfach was passiert, wenn die Aufgabenstellung nicht 100% eindeutig ist. Denn viele Wege führen nach Rom!

 

[mrBrown]

Auch nachdem ich den gasammten Thread gelesen und nochmals drüber nachgedacht habe, kann ich der Lösung ohne Datenbank nichts abgewinnen.

Es geht um das Trennen von Datenbank und Programm - für viele ist das eines der Grundprinzipen guter Softwareentwicklung.
Weiter vorn ist ein Artikel verklingt, der das besser ausführt, als ich es könnte...

Wenn es darum gehen würde, Daten in eine CSV Datei zu speichern und dann zusammenpassende Daten auszugeben, bräuchte man meiner Meinung nach nichts Programmieren.
Das kann Excel schon von Haus aus! Es kann daten in csv abspeichern. Es kann die Daten sortiert anzeigen. Es kann mithilfe von formeln zusammenpassende Daten ausgeben (Ja sogar bunt!). Also wenn das wirklich Sinn und Zweck wäre, bräuchte man nur ein paar Excel Formeln...

Was könnte denn deine Lösung mit Datenbank mehr, als meine ohne Datenbank? (und was wäre das mehr, als rein Excel?)
(Excel + Macros ist Turingvollständig, von daher ginge damit sowieso alles )

 

[truesoul]

Ob er nun mit der Datenbank anfängt oder erst die Oberfläche entwickelt, sei mal völlig dahingestellt.

Aber das wird der entscheidende Punkt sein. Warum habe ich schon geschrieben.

 

[mrBrown]

Und ohne Datenbank kommt ja nicht in die Tüte weil dann würde es nicht zur Aufgabenstellungen gehören.

Steht btw nicht in der Aufgabenstellung, zumindest nicht in dem Teil, der hier steht

 

[Danloc]

Es geht um das Trennen von Datenbank und Programm - für viele ist das eines der Grundprinzipen guter Softwareentwicklung.

Bin ich ganz deiner Meinung, nur darum geht es nicht. Es geht darum, dass er Daten bearbeiten, anzeigen und nachhalten muss.
Ich bin mir vollends bewusst, dass es aus Sicht des Programmes egal sein sollte, wo die Daten nachgehalten werden. In diesem Fall also eine der zu erledigenden Aufgaben, das Programm so zu struktueren.

Das ändert aber nichts an der Tatsache, dass sich eine Datenbank, zum nachhalten der Daten, besser eignet.
In diesem Fall also die andere zu erledigende Aufgabe.

Was könnte denn deine Lösung mit Datenbank mehr, als meine ohne Datenbank? (und was wäre das mehr, als rein Excel?)

- Multiuserbenutzung
- Ein enziger Datenstand (Es gibt ein zentrales System, keine Datenquellen mit ähnlichen oder anderen Datenstand, wie z.B. Datei1 auf PC12, Datei2 auf PC1 und Datei3 auf PC5)
- Unabhängig vom Betriebssystem, auf dem das Programm installiert ist, Excel ist ein Microsoft Produkt! (z.B. mit Datenbank-Server)
- Bessere und zentrale Wartbarkeit
- Gewährleistung der Ausfallsicherheit ist leichter herzustellen
- Der user muss die Daten nicht physykalisch auf seiner Festplatte zur Verfügung stellen, er kann vom Stand aus mit der Datenbank verbinden
- Eine Datenbank kann nach belieben erweritert werden

Außerdem ist das Format der Daten in einer Datenbank klar definiert. Es kann nicht einfach vom user geändert oder gar gelöscht werden. Eine Excel Tabelle ist schnell einmal umformatiert, Datensätze hinausgelöscht oder gar vollständig gelöscht.

es gibt sicherlich noch sehr viele Dinge, ganz zu schweigen von Funktionen, die je nach Datenbank von bereitgestellt werden. Auch die Auswertung der Daten, gestaltet sich deutlich einfacher.

Ich habe nichts dagegen, wenn jemand so etwas in einem "Profi" Thread zur Sprache bringt und ausdiskutiert. Allerdings wurde dem TE zu beginn ein Softwaremodell vorgeschlagen und so dargestellt, als würde es absoulut keinen Unterschied machen, ob die Daten in einer csv Datei gespeichert sind oder in einer Datenbank und das ist grundlegend falsch!

 

[truesoul]

Steht btw nicht in der Aufgabenstellung, zumindest nicht in dem Teil, der hier steht

Stimmt, wurde vom TE in Erwägung gezogen.
Edit: Und von daher würde ich nicht zwingend sagen, dass die Aussage falsch ist.

 

[truesoul]

Ich wette gleich wird Sharepoint in den Raum geworfen wegen einziger Datenbestand

Und btw muss man für Makro's auch schon wieder vba beherrschen. Wenn es komplizierter werden soll. Und Aufzeichnung von Makros ist kein entwickeln.

 

[Danloc]

Ich wette gleich wird Sharepoint in den Raum geworfen wegen einziger Datenbestand

Der TE, stellt eine Frage zu einem Anfänger-Praktikumsprojekt und löst eine Grundsatzdiskussion über das Zusammenspiel von Datenbanken und Softwarekonzepten aus

Er geht bestimmt zu seinem Chef und sagt: "Die Aufgabe ist unlösbar!!"

 

[truesoul]

Ach mit Sicherheit oder er hat sich bestimmt eine unter die binde gekippt und denkt nach in die Klapse zu gehen.

 

[mrBrown]

Bin ich ganz deiner Meinung, nur darum geht es nicht.

Natürlich geht es darum (mir zumindest).

- Multiuserbenutzung
- Ein enziger Datenstand (Es gibt ein zentrales system, keine Datenquellen mit ähnlichen oder anderen Datenstand, wie z.B. Datei1 auf PC12, Datei2 auf PC1 und Datei3 auf PC5)
- Unabhängig vom Betriebssystem, auf dem das Programm installiert ist, Excel ist ein Microsoft Produkt! (z.B. mit Datenbank-Server)
- Bessere und zentrale Wartbarkeit
- Gewährleistung der Ausfallsicherheit ist leichter herzustellen
- Der user muss die Daten nicht physykalisch auf seiner Festplatte zur Verfügung stellen, Er kann vom Stand aus mit der Datenbank verbinden
- Eine Datenbank kann nach belieben erweritert werden

Gefühlt jeden dieser Punkte kann man auch negativ aufschreiben

- Es braucht zusätzlich eine dedizierten Server
- keine OS und DB-Unabhängigkeit mehr (eine csv kann auf jedem System geparsed werden, aber nicht jede Db bietet die gleichen Features oder ist System-Unabhängig)
- komplexere Wartbarkeit (Server + Datenbankserver + im Idealfall Webserver vor der Datenbank + Netzwerk + ...)

Ich habe nichts dagegen, wenn jemand so etwas in einem "Profi" Thread zur Sprache bringt und ausdiskutiert. Allerdings wurde dem TE zu beginn ein Softwaremodell vorgeschlagen und so dargestellt, als würde es absoulut keinen Unterschied machen, ob die Daten in einer csv Datei speicher oder in einer Datenbank und das ist grundlegend falsch!

Für die grundlegende Programmfunktionalität *ist es egal*.
Für den Entwicklungsprozess *ist es egal*.
Für das Design *ist es egal*. ...

Die Anforderungen sind eben nicht "Design ein passendes Datenbankschema", sondern das schreiben der Anwendung.
Für mich als Bewertenden ständen da ganz andere Dinge im Vordergrund, als das Datenschema - zB sowas wie Anforderungsanalyse, Entwurf, ...

MMn legt ein "du musst die Daten erstmal in MySQL importieren" sogar genau den falschen Fokus, weg von den relevanteren Dingen.

 

[JStein52]

Und wieder ist ein Tag seiner Praktikumszeit vorbei ...

 

[Meniskusschaden]

Er geht bestimmt zu seinem Chef und sagt: "Die Aufgabe ist unlösbar!!"

Auch wenn er in diesem Thread sonst noch nichts gelernt haben mag, dann doch zumindest, dass Overengineering eine reale Gefahr darstellt, die dazu führen kann, dass man am Ende mit leeren Händen da steht.
Es ist oft die bessere Entscheidung, einen dreckigen Ansatz zu wählen, weil man für die Umsetzung einfach viel weniger Know How braucht. Ob die Lösung jemals so groß wird, dass man vom prinzipiell besseren Weg überhaupt jemals profitiert, steht auch in den Sternen.

 

[Meniskusschaden]

Und wieder ist ein Tag seiner Praktikumszeit vorbei ...

Um vielleicht doch mal wieder etwas Konkretes vorzuschlagen: Ich würde ja ohnehin mit der DB beginnen. Der TE hat geschrieben, dass er sich mit SQL etwas sattelfester fühlt, als mit Java. Deshalb würde ich es in seinem Fall also erst recht so machen. Ich würde mich dabei auch nicht nur auf die Datenhaltung beschränken, sondern die gesamte Logik in SQL abbilden und nur einen ganz schlichten Java-Client für das GUI programmieren.

 

[Meniskusschaden]

Darüber hinaus würde ich die Vor- und Nachteile des Lösungsansatzes benennen und die Entscheidung eben mit den Vorteilen begründen. Dann spielt es für die Bewertung kaum eine Rolle, ob es die richtige Entscheidung war.

Ausserdem würde ich einen einfachen Stufenplan erstellen (z.B. DB-Schema erstellen, Datenimport, Logik entwickeln, GUI entwickeln). Dann hat sein Betreuer auch eine Chance, ihm eine akzeptable Note zu geben, wenn er nicht komplett, sondern nur in einzelnen Punkten fertig wird.

Das würde ich ohne Geschwafel ganz schlicht und banal halten. Hauptsache man sieht, dass es einen Plan gibt.

 

[truesoul]

Also ganz ehrlich die Diskussion warum Excel + Makros besser sein soll als eine DB ist total ....

Ich kann leider keine Umfrage starten aber ich wette die große Mehrheit ist für eine DB.

Gefühlt jeden dieser Punkte kann man auch negativ aufschreiben

- Es braucht zusätzlich eine dedizierten Server
- keine OS und DB-Unabhängigkeit mehr (eine csv kann auf jedem System geparsed werden, aber nicht jede Db bietet die gleichen Features oder ist System-Unabhängig)
- komplexere Wartbarkeit (Server + Datenbankserver + im Idealfall Webserver vor der Datenbank + Netzwerk + ...)

Das sind aber nicht viel mehr Contra's. Und auch ganz ehrlich sehr wenig überzeugend wie ich finde.

Oder wer meint noch so alles das Excel + Makros die bessere Lösung ist anstatt DB?

 

[mrBrown]

Also ganz ehrlich die Diskussion warum Excel + Makros besser sein soll als eine DB ist total ....

Das Excel + Macros besser sein soll, als eine DB hat doch auch niemand behauptet.

@Danloc fand nur Excel und Javaprogramm+Daten aus CSV lesen gleichwertig ^^

 

[Ranxus]

Guten Morgen liebes Forum,

seit letzter Woche habe ich meines Erachtens eine menge geschafft sprich das Grundgerüst des Programms steht soweit. Zu den aufgaben des Programms eine CSV-Datei (Ich habe es momentan so gelöst das ich die csv in eine txt Datei umwandle) wird importiert. Dann kann man sich wenn man einen Blenden Code einfügen und per Button Suchen alle Ergebnisse die mit dem gesuchten Code übereinstimmen werden dann in einem Ausgabefenster eingefügt. Wird ein falscher Code eingegeben, kommt eine Fehlermeldung der sagt es gäbe keine Übereinstimmung. Soweit ist das Programm erst einmal lauffähig ich hab meinem Chef das Programm gezeigt und er meinte er möchte das man nicht den gesamten Text für die Suche eingeben muss, Sprich anstatt 1-2-5-2-6-1-6-2 würde schon 1-2-5 oder 1-6-2 reichen. Ich meinte zu ihm das dadurch natürlich dann auch verschiedene Blenden ausgegeben werden könnten aber er möchte es so. außerdem möchte er einen neuen Button namens Umbuchen. Letzte Woche meinte ich ja dass das Umbuchen Manuell per Button und txtfeld Eingabe funktionieren soll. Dies möchte mein Chef jetzt aber doch Automatisch sprich man muss nur noch den Button Umbuchen drücken und schon werden von alle Blenden die in der importieren CSV enthalten sind und den gleichen Code haben die Blenden die eine Anzahl höher als 1 besitzen auf gleiche blenden die 0 mal vorhanden sind verteilt. Soweit so gut, meine Fragen sind momentan die folgenden 1. funktioniert das mit der Aufstückelung überhaupt weil im Grunde wird doch eine Datei die z. Bsp. in einem Array abgespeichert wird immer als ganzes aufgerufen sprich ich kann die Datei/Variable nicht so einfach Zerstückeln oder ? Frage 2 Apache POI ist ja ein Java Tool um Microsoft Dateien einzulesen gibt es dafür ein Tutorial was den Java Editor betrifft ? Es gibt viele Videos bezüglich POI die nutzen aber alle Eclipse was mir nicht viel bringt da ich nie damit gearbeitet habe. Frage 3 Gäbe es noch andere Möglichkeiten eine CSV einfach zu importieren/exportieren.Momentan Habe ich das importieren so gelöst das ich im Quellcode immer den namen der CSV (momentan ja txt.datei) auf den das Programm zugreifen soll verändern muss.

Finde es echt klasse das ihr versucht mir zu helfen.

lg Ranxus

 

[Ranxus]

Anbei die momentane grafische Oberfläche

 

[Ranxus]

Guten Tag Forum,
Ich habe mein Programm soweit lauffähig nur der Import funktioniert nicht so wie er soll. Hat jemand evtll. einen Lösungsvorschlag. Anbei sind Ausschnitte meines Programmes. Hoffe ihr könnt mir dabei vielleicht noch einmal helfen.

LG Ranxus

 

[mrBrown]

Dein Einlesen hat ja auch keinen Nebeneffekt, wie soll man da auch was von sehen?
Lass dir doch die Bücher (warum denn plötzlich Bücher?) nach dem Einlesen einfach mal anzeigen


(Und bitte niemals System.gc nutzen)

 

[Trjavnamen]

Wenn man eine CSV Datei eimal mit Exel öffnet und speichert werden Informationen über den Aufbau abgespeichert Damit ist die CSV datei gleichzeitig exportiert und importiert.Dann schau mal den LInk an da wird direkt in die CSV Datei (ist eigendlich eine Textdatei mit Komma oder Semikolon als Feldende/anfang und Zeilenumbruch als Datensatzende/anfang) geschrieben. https://www.csvreader.com/java_csv_samples.php https://www.csvreader.com/java_csv_samples.php

 

[Trjavnamen]

Ps: Die CSV Datei muß in einem Verzeichnis stehen auf die Java zugreifen darf

 

[JStein52]

... öffnet und speichert werden Informationen über den Aufbau abgespeichert

was meinst du da ? Welche Informationen über den Aufbau werden in die CSV-Datei geschrieben ?

Edit: wie @mrBrown schon geschrieben hat, in dem aufgeführten Beispielcode sieht man natürlich nichts weil ja nichts ausgegeben wird. Der Code selber sieht ja richtig aus und tut was er soll: zeilenweise einlesen, die Zeile beim ";" splitten und aus den Bestandteilen ein Objekt vom Typ Book erzeugen. Aber das ist ja sicher nur ein Beispiel und nicht sein Code denn er will ja Blenden handlen ..

 

[Trjavnamen]

Ich meine Exel speicher in den Eigenschaften der Datei informationen ab über Zeilenbreite und Überschrift und trennungsart.

 

[JStein52]

Ich meine Exel speicher in den Eigenschaften der Datei informationen ab über Zeilenbreite und Überschrift und trennungsart.

Nein, tut es nicht.Es speichert die Zeile mit den Spaltenüberschriften falls in Excel überhaupt vorhanden genau so "comma separated" ab wie die Daten.
Edit: und sein Beispielcode war schon richtig. Der hat funktioniert. Den muss er nur noch für seinen Dateiinhalt anpassen.

 

[mrBrown]

Nein, tut es nicht.Es speichert die Zeile mit den Spaltenüberschriften falls in Excel überhaupt vorhanden genau so "comma separated" ab wie die Daten.

Wobei man da unterscheiden muss zwischen Speichern als CSV und als "normale" Excel-Datei, wenn ich mich nicht irre wird eine geöffnete CSV bei erneuten Speichern standardmäßig als XLS(?) gespeichert

 

[JStein52]

wenn ich mich nicht irre wird eine geöffnete CSV bei erneuten Speichern standardmäßig als XLS(?) gespeichert

Dann ist es aber auch keine CSV-Datei mehr. Also Nebenkriegsschauplatz. Das Thema beim TE sind CSV-Dateien. Punkt.