Whiz-zarD

Ein Interface ist, wie der Name schon sagt, eine Schnittstelle. Mit Interfaces definiert man die Methodenköpfe, die eine Klasse implementiert. Über Schnittstellen lassen sich verschiedenartige Implementationen über die selbe Schnittstelle realisieren, ohne dass der Aufrufer gar nicht wissen muss, um welche konkrete Klasse es sich handelt. Wir hatten ja schon mal das IDisposable, was ebenfalls ein Interface ist. Das Interface besitzt lediglich nur die Methode Dispose(). Viele Klassen implementieren diese Schnittstelle. Ein anderes Beispiel wäre das IEnumerable<T>-Interface, was u.a. von Arrays und Listen implementiert wird und einen Enumerator zur Verfügung stellt und mit dem Enumerator haben wir dann die Möglichkeit, mit der foreach-Schleife über die Elemente zu iterieren. In meinem Beispiel habe ich nun ein Interface erstellt, was einen sehr simplen Logger darstellt. Über den Konstruktor vom CsvChanger reiche ich dann ein Objekt rein, was dieses Interface implementiert. Der CsvChanger weiß dann, dass dieses Objekt die Methode Log() besitzt und ruft diese Methode auf, Ansonsten weiß es gar nichts über dieses Objekt. Der CsvChanger ist somit unabhängig vom Logger, weil dieser Logger jetzt irgendeiner sein kann, der dieses Interface implementiert. Es kann, wie in meinem Beispiel, ein Logger sein, der die Logeinträge auf die Konsole loggt, oder in die Datenbank, als Datei oder E-Mail etc. Vielfach liest man auch, dass Interfaces für Mehrfachvererbung gedacht sind aber das ist nicht richtig und ich würde auch von dieser Meinung Abstand halten. Wer Mehrfachvererbung braucht, der macht schon was falsch. Ich bin noch nie in eine Situation gekommen, wo ich mir gewünscht hätte, C# oder Java könnte echte Mehrfachvererbung, wie es bei C++ der Fall ist. Mehrfachvererbung hat für mich den Charakter, dass eine Klasse zu viel macht.

Doch, genau das ist der Sinn der Sache. Man will ja in unterschiedlichen "Umgebungen" auf Fehler unterschiedlich reagieren. z.B. will man in einer Konsolenanwendung die Fehlermeldung auf der Konsole ausgeben oder bei einer Desktop-Anwendung mit grafischer Oberfläche eine MessageBox oder bei einer Webanwendung irgendwo als Hinweis-Text. Du hast aber die Exceptions schon in der CsvChanger-Klasse abgefangen und festgelegt, dass die Fehlermeldung auf der Konsole ausgegeben werden soll, was aber zur Folge hat, dass der Nutzer einer Desktop- oder Web-Anwendung gar nicht die Fehler mitbekommt. Vielleicht möchte man auch, dass der Nutzer entscheiden kann, im Falle eines Fehlers. z.B. du änderst Tausend CSV-Dateien und eine schlägt fehl. Man möchte vielleicht dem Nutzer die Möglichkeit bieten, die Aktion abzubrechen oder den Fehler zu ignorieren und weitermachen. Daher würde ich die ganzen Try-Catch-Blöcke weglassen und der Aufrufer soll die Fehler behandeln. Hier würden wir in den Bereich der sog. Dependency Injection kommen, denn in eine Datei zu loggen ist ja nicht die einzige Art des Loggings. Ein Logging kann auch auf der Konsole geschehen oder in eine Datenbank, als E-Mail, in eine Textbox einer grafischen Oberfläche, etc. Da sind also keine Grenzen gesetzt. Ein Benutzer einer Web-Anwendung hat durchaus ja keinen Zugriff auf eine Log-Datei. Anstatt also dass wir vorgeben, dass wir eine Datei schreiben, reichen wir als Abhängigkeit (engl: dependency) einen Logger in die Klasse über den Konstruktor rein. Dafür entwickelt man ein Interface und eine konkrete Implementierung und man arbeitet später dann nur noch mit dem Interface. Hier mal ein einfaches Beispiel für einen Logger: Das Interface: public interface ILogger { void Log(string message) } Eine konkrete Implementierung, die auf der Konsole loggt: public class ConsoleLogger : ILogger { public void Log(string message) { Console.WriteLine(message); } } Die Klasse CsvChanger: public class CsvChanger { private ILogger logger; public CsvChanger(ILogger logger) { this.logger = logger; } ... } Hier sieht man jetzt, dass ein Objekt in die Klasse als Abhängigkeit reingereicht wird, die das Interface ILogger implementiert. In der Main-Methode erzeugst du die Objekte, die der CsvChanger benötigt: public static void Main(string[] args) { ... ILogger logger = new ConsoleLogger(); CsvChanger changer = new CsvChanger(logger); ... } Später, bei der Verwendung vom Logger in der CsvChanger-Klasse schreibst du dann einfach folgenden Code: logger.Log("Das ist ein Text"); Jetzt ist die Klasse CsvChanger vom Logger unabhängig. Anstatt einen Konsolen-Logger kannst du jetzt nun auch einen Logger schreiben, der in eine Datei loggt und diesen dort reinreichen. Der Klasse ist das nun egal, da sie vom Logger nur das Interface kennt aber nicht die konkrete Implementierung. Ich glaube, du hast es nun zu wortwörtlich genommen. Ja, eine Methode soll nur eine Aufgabe erledigt. Die Aufgabe wird aber durch den Methodennamen beschrieben. Wenn die Methode ChangeFile() heißt, dann kann die Methode sehr wohl die Datei lesen, ändern und speichern, weil der Methodenname genau dies ausdrückt: Die Methode soll eine Datei ändern. Sie soll aber neben dieser Aufgabe nichts anderes machen. Die Methode ChangeFile() wird dann intern in weitere Teilaufgaben unterteilt. Nämlich Lesen, Ändern und Speichern. Der Aufrufer von ChageFile() bekommt aber davon nichts mit. Dieses Thema hat aber eigentlich nichts mehr mit Objektorientierung zu tun, sondern mit Clean Code. Natürlich kann man ChangeFile() auch wie ein Spaghetticode implementieren aber das ist nicht wirklich lesbar und vorallem nicht wartbar. Ein Entwickler verbringt mehr Zeit mit Code lesen anstatt mit Code schreiben und daher sollte der Code so lesbar wie möglich sein. Wenn die Methode ChangeFile() lediglich nur aus drei Zeilen Code besteht, dann versteht man die Arbeitsweise der Methode besser als wenn sie aus 100 Zeilen bestehen würde. Wer dann genauer in einen der drei Arbeitsschritte abtauchen muss, der schaut sich dann die Implementierung der jeweiligen Methode an, usw.

Warum so eine veraltete Technik (Win Forms)? Warum nicht eine Web-Anwendung? Und warum wird gefühlt bei jedem Projektantrag erwähnt, dass es eine MySQL-Datenbank sei. Die Datenbank sollte egal sein. Bei solchen Formulierungen habe ich immer das Gefühl, dass man die Datenbank nicht mittels einem O/R-Maper abstrahiert, sondern stumpf SQL-Queries schreibt und sie zur Datenbank schickt.

In der Klasse SettingsLoader fällt auf, dass du filename als private Member definiert hast, aber das brauchst du gar nicht. Also könntest du diesen auch löschen. iniText hat auch in Settings nichts zu suchen. Außerdem macht die Load()-Methode eigentlich noch zu viel. Schauen wir uns doch mal an, was sie macht: Sie liest die Ini-Datei ein Sie ermittelt Source Sie ermittelt Destination Sie gibt Settings zurück Das sind quasi vier Aufgaben und die ersten drei davon könnte man in separate Methoden packen, um den Code genauso lesbar zu machen, wie meine Aufzählung: class SettingsLoader { string iniText; public Settings Load(string filename) { this.iniText = this.ReadFile(filename); return new Settings { Source = this.GetSourceFromIniText(); Destination = this.GetDestinationFromIniText(); } } ... } Die Implementierungen der Methoden kannst du mal versuchen. Hierbei kannst du ja auch mal versuchen, das DRY-Prinzip (Don't Repeat Yourself) einzuhalten. Vielleicht fällt dir ja auf, dass das Lesen von Source und Destination quasi die selbe Aufgabe ist. Lediglich nur der reguläre Ausdruck ändert sich. Außerdem fällt in der Klasse CsvChanger auf, dass du zu viele Try-Catch-Blöcke drinnen hast. Die Catch-Blöcke geben auch immer was auf der Console aus. Damit ist die Klasse von Console abhängig. Für den Anfang kannst du es ja auch so lassen aber stelle dir mal die Frage, ob das so gut ist bzw. warum das nicht so gut sein könnte? Die Klasse CsvChanger würde auch einfacher zu lesen sein, wenn sie nur eine Datei bearbeiten würde. In der Hauptmethode könnte man ja die Dateien ermitteln und mittels einer Schleife iterieren und jedes Mal den CsvChanger aufrufen. Damit verlagert man die Logik weiter zum Aufrufer und die Klasse wird dadurch kompakter. Außerdem sehe ich, dass du dir mit Arrays ganz schön einen abbrichst. Informiere dir mal ein bisschen über Generics und dann über die Klasse List<T>. Ich verwende Arrays nur, wenn ich schon zur Entwicklungszeit exakt weiß, wie viele Elemente ein Array braucht. z.B. ein Schachbrett: Es hat immer 8x8 bzw. 64 Felder und das wird sich auch in hundert Jahren nicht ändern. Eine Anzahl von Dateien in einem Ordner kann sich sekündlich ändern und daher ist ein Array vielleicht nicht die beste Wahl. Außerdem schaue dir mal die foreach-Schleife an. Dann wirst du auch die hässlichen for-Schleifen los.

Das ist auch nur Teilweise richtig. Es ist zwar schon richtig, dass eine Sprache nur das Werkzeug ist aber auch das Werkzeug muss gut gewählt werden. Einen Nagel haut man ja auch nicht mit einem Schraubendreher in die Wand, sondern mit einem Hammer. Die Sprache muss also auch Frameworks besitzen, um das gewollte umsetzen zu können. Jemand, der eine Android-App schreiben möchte, wird also nicht C oder C++ dafür nehmen, sondern Java in Verbindung mit dem Android-SDK oder C# in Verbindung mit Xamarin. Allerdings sind die genannten Bedingungen von @Ronon Dex zu sehr allgemein, sodass man hier quasi jede gängige Sprache für nehmen könnte.

Und genau das würde ich nicht tun. Du machst dich da zu sehr abhängig und der Struktur der Klasse. Jeder, die die Klasse initialsiert, muss im Vorwege alles kennen. Du kannst die Klasse nicht Stück für Stück befüllen. Außerdem bietet C# da schon eine elegante Objektinitialisierung: return return new Settings { IniText = iniText, Source = source, Destination = destination };

Eine Datenstruktur ist ein Objekt zur Speicherung und Organisation von Daten. Dabei sollten solche Objekte so "dumm" wie möglich gehalten werden. Im Jahr 2000 brachte Martin Fowler den Begriff "POJO" in den Raum. Das steht für "Plain old Java Object". Abgelitten für die .Net-Welt gibt es den Begriff POCO, was für "Plain Old CLR Object" steht. Solche Objekte besitzen halt nur die Daten. Beispiel: Du willst Daten zu einer Person speichern: public class Person { public string Vorname { get; set; } public string Nachname { get; set; } public DateTime Geburtstag { get; set; } } Das ist jetzt die Datenstruktur für eine Person. Wenn du nun eine Menge an Personen hast, kannst du jetzt z.B. ein Array oder eine Liste mit Personen definieren. Beispiel: Person[] personen = new Person[10]; IList<Person> personen2 = new List<Person>(); So transporierst du lediglich nur die Daten der Person durch die Gegend. Der Vorteil von solchen Klassen ist, dass sie komplett keine Abhängigkeiten besitzen und können wiederverwendet werden. Angenommen du würdest in der Klasse Methoden hinzufügen, die die Daten aus einer Datenbank liest. Dann wäre die Klasse von der Datenbank abhängig. Analog kann man es ja mit deiner Settings-Klasse sehen. Du hast dort Methoden, die die Setttigs aus einer Ini-Datei ausliest. Unter Logik versteht man das, was du letzendlich machen möchtest. z.B. die Settings aus einer Ini-Datei oder Datenbank lesen.

Du erstellt mit HTML ein Tabelle und mit CSS passt du die mit deinem Designstil an. CSS ist eine Stylesheet-Sprache, mit der man das Erscheinungsbild von Elementen anpasst. Mehr ist CSS nicht. Kannst ja z.B. hier mal reinschauen, wie sie die Tabellen gestaltet haben

Mit CSS erstellst du keine Tabellen. Was genau hast du denn vor?

Dein Problem mit dem '\r' ist folgendes: Du hast ein String, der aus mehreren Zeilen besteht. Das Zeilenende unter Windows wird standardgemäß mit "\r\n" dargestellt. Das sind nicht-druckbare Steuerzeichen. Das \r steht für "cariage return" und das \n für "new line". Reguläre Ausdrücke werden aber standardgemäß pro Zeile ausgewertet und das eine Zeile wirklich beendet ist, leitet nur das \n ein. Somit bleibt \r stehen. Wenn du es unbedingt mit einen regulären Ausdruck ermitteln möchtest, dann musst du es so schreiben: Regex rsource = new Regex("(?<=Source\\=)[^\r]+"); Aber reguläre Ausdrücke würde ich persönlich vermeiden. Die versteht doch kein Schwein. Ich würde durch jede Zeile der Ini-Datei iterieren und jede Zeile per Split() mit dem '='-Zeichen teilen. So habe ich den Schlüssel und den Wert getrennt und kann damit arbeiten. Versuche aber mal die Settings und das Laden der Settings zu trennen. Also dass du eine Klasse Settings hast: public class Settings { public string source { get; set; } public string Destination { get; set; } } Und eine Klasse z.B. mit dem Namen SettingsLoader, die eine Methode bereitstellt, die die Settings aus der Ini-Datei lädt und dir eine Instanz vom Typ Settings zurückliefert. Also z.B: public class SettingsLoader { public Settings Load(string fileName) { ... } } So trennst du die Datenstruktur von der Logik. Angenommen, du hast neben der Ini-Datei als Quelle für die Einstellungen jetzt noch eine Datenbank. Dann müsstest du ja die Settings-Klasse um weitere Methoden aufblähen, die die Daten aus der Datenbank lesen und dann kommt vielleicht die dritte (z.B. aus Textboxen einer WinForms-Anwendung), vierte und fünfte Quelle. Dann wird die Klasse sehr riesig und unübersichtlich. Das möchte man aber nicht. Man sollte das Ziel verfolgen, eine Klasse so klein wie möglich zu halten. Einige sagen, eine Klasse darf nicht mehr als 200 Zeilen besitzen aber ich finde so dogmatisch sollte man es nicht halten, aber man sollte sich daran orientieren. Um also mehrere Quellen abzugrasen sollte man pro Quelle eine Klasse schreiben, die die Einstellungen einliest und zurückgibt.

Schiffbruch ist für mich noch was anderes. Schiffbruch ist, wenn das Produkt schon beim Kunden ist und es beim Kunden nicht erwartungsgemäß läuft. Vielleicht verstehe ich den TE auch nur falsch. Ich habe es so verstanden, dass der TE nicht mehr weiß, wo vorne und hinten ist. Also mit so vielen Spitzfindigkeiten beschäftigt ist, sodass kein stabiler Zustand erreicht werden kann. Jede Änderung provoziert dann den nächsten Fehler.

Ich sehe eigentlich keinen Grund, ein Fehlerfall nicht zu überprüfen. Wenn ein Fehler auftreten kann, so selten wie er auch sein mag, sollte man ihn auch abfangen. Man verrennt sich eigentlich nicht aufgrund der Menge der Fehler, die auftreten können, sondern aufgrund der Komplexität des Codes und die Komplexität erhöht sich wegen ganz anderen Dingen.

Wie wahrscheinlich ein Fehler auftritt, kann man häufig auch gar nicht beurteilen. Ich habs auch schon erlebt, dass ein gesamtes Entwicklerteam der Meinung ist, dass bestimmte Konstellationen selten bis gar nicht auftreten und schwupps hatte schon die ersten Kunden diese Konstellation. Viele Fehler lassen sich schon damit abfangen, wenn man Programmierregeln aufstellt.z.B. dass Listen niemals Null sein dürfen oder dass Null kein gültiger Rückgabewert ist. Auch hilft Praktiken, wie TDD schon sehr gut, sich kurz zu halten. Fehler, die auftreten könnten, können auch somit leichter getestet werden. Wer kleine Schritt macht, der kann dann auch zwischenzeitlich sein Code refaktorisieren und kann dabei alle Testfälle immer wieder laufen lassen.

Wenn man zu sehr in den Details feststeckt, dann sollte man sich überlegen, ob die Lösung überhaupt die richtige ist? Zu viele Details bedeutet oftmals auch zu viel Code, der auch instabil ist. Man will wohl zu viel auf einmal erledigen. Daher wäre es wohl ratsam, hier ein Schlussstrich runterzusetzen und noch mal die Aufgabe überdenken. Evtl. müssen die Teilschritte noch mal unterteilt werden. Ratsam wäre auch mit einem Kollegen über die Aufgabe zu sprechen. Oftmals kommen da Ideen, an die man nicht gedacht hat. Pair-Programming kann in solchen Situationen auch hilfreich sein.

Und was soll daran schlecht sein? Behaupten kann man vieles aber gibt es dafür auch konkrete Gründe? Für die praktische Erfahrung muss man eh noch Praktika absolvieren. Ja, einige meiner damaligen Kommilitonen, die die Schule nach dem zweiten Semester abgebrochen haben, fanden die Schule auch schlecht. Das lag aber auch nur daran, weil sie nicht mitkamen und nicht gleich angefangen wird, Klicki-Bunti-Anwendungen zu schreiben.

Wenn die Schule gut ist, ist dies gar nicht so unseriös. Zugegeben, der Kurvenverlauf ist wohl ein wenig zu steil aber das ist dennoch realistisch und würde sich auch mit meinen Erfahrungen decken. Vielfach habe ich das Gefühl, dass in Berufsschulen versucht wird, den letzten Deppen mitzunehmen, sodass man im Stoff gar nicht vorankommt, während in schulischen Ausbildungen der Unterricht straff getacktet ist und man weniger Rücksicht auf Schwächere nimmt. So kommt man im Stoff viel schneller voran und kann auch mehr Stoff einbringen. Meine Ausbildung dauerte 2 1/2 Jahre (5 Semester), wobei ich noch ein Semester rangehängt habe, um für die Abschlussprüfung genug Zeit zu haben. Ich habe im sechsten Semester also nichts anderes gemacht, außer Praktika und die Abschlussprüfung. In den 2 1/2 Jahren habe ich weitaus mehr gelernt, als viele FIAEler in den 3 Jahren. Das Entscheidene ist der Überblick, den man bekommt. Ein Azubi lernt in der Firma nur das, was die Firma auch einsetzt. Also ist die Qualität von der Firma abhängig und das schwankt sehr stark. Wenn eine Firma aber nur z.B. PHP und MySQL einsetzt, dann lernt der Azubi auch nur PHP und SQL. In meiner Assistenten-Ausbildung habe ich aber mehrere Sprachen gelernt: Pascal, Delphi, C, Java, PHP und SQL. Dann noch HTML, CSS und JavaScript nur rudimentär mit jQuery. Wir haben z.B. als Übung ein 2D Pacman und ein 3D Sokoban in C und OpenGL entwickelt. Mit PHP haben wir als Übung einen kleinen Bücher-Shop gebastelt. Als Seminar-Aufgabe musste ich in C ein Tool schreiben, was Bilder manipuliert (spiegeln, drehen, Graustufen bzw. Schwarz-weiß und skalieren). Die Algorithmen sollten wir selber dazu schreiben. Als weitere Aufgabe sollte ich das Spiel Carcasonne, mit grafischer Oberfläche (mit Delphi) programmieren. Darüber hinaus hat man uns noch Bildbearbeitung und Videoschnitt beigebracht (Die Adobe Produktpalette). Dazu zählte auch die Theorie, wie Bilder und Videos komprimiert werden. Es war ein großer Rundumschlag zum Thema "Medieninformatik" und vielen anderen Themen (z.B. Rechnernetze, Datenschutz, Marketing und Medienrecht) und das bietet keine betriebliche Ausbildung. Sehe ich genauso.

Leider gibt es nicht viele Informationen auf der Webseite aber sie klingt erst mal nicht schlecht und ich denke, nach der Schule ist eine zusätzliche Ausbildung nicht notwendig und ich halte das dann auch für schwendete Zeit. Wenn, dann würde ich eher nach einem Studium ausschau halten, wenn du meinst, dass es nicht reicht.

Erst mal habe ich zuvor eine betriebliche Ausbildung als Mechatroniker hinter mir. Ich kenne also das Leben als Azubi. Zweitens hatte ich im Laufe der Zeit schon einige Gesprächen mit so manchen FIAE-Azubis gehalten und irgendwie berichtet jeder von den selben Problemen. Drittens hatte ich mich mal in diesem Forum angemeldet, weil ich Informationen über die Ausbildung sammeln wollte, da ich vor habe, die Ausbildereignungsprüfung abzulegen aber in diesem Forum werden immer wieder die Dinge bestätigt, die auch zuvor die Azubis berichtet haben, mit denen ich gesprochen habe und das erschüttert mich doch sehr. Das mag vielleicht sein. Das kann ich so nicht beurteilen. Ich selber war auf einer Schule in Schleswig-Holstein und diese Schule genießt in Norddeutschland einen sehr guten Ruf und die Leute, die auf dieser Schule einen Abschluss gemacht haben, werden eher genommen, als jemand mit einer betrieblichen Ausbildung.

Du frage ist, wie die tatsächliche Bezeichnung heißt? Es gibt die "staatlich geprüften Assistenten für Wirtschaftsinformatik" und umgangssprachlich werden sie auch Wirtschaftsinformatiker bezeichnet. So eine Ausbildung ist auch mit einer Fachinformatiker-Ausbildung gleichrangig. Je nach Schule im Lehrstoff sogar höherwertiger. Ich bin staatlich geprüfter Assistent für Medieninformatik und habe diese Entscheidung nie bereut. Im Gegenteil. Ich bin sogar eher froh darüber, diesen Weg gewählt zu haben, anstatt eine betriebliche Ausbildung.

Wozu dann noch eine FIAE Ausbildung, wenn du später Wirtschaftsinformatiker bist? Das halte ich für Verschwendung. Darf ich fragen, welche schule du in Auge gefasst hast? Ich habe auch eine schulische Ausbildung abgeschlossen und würde diese Ausbildung einer betrieblichen Ausbildung immer wieder bevorzugen.

Es wäre besser, wenn du immer den kompletten Code hier reinschreiben würdest. Mit Schnipseln, die sogar noch unvollständig sind, kann keiner was anfangen. Auch solltest du auf die Formatierung achten. Der Code kann noch so gut sein aber wenn dieser schlecht formatiert ist, ist er quasi unlesbar. Was mir aber ins Auge sticht, ist die Methode GetSource(). Die hat kein Rückgabewert, obwohl sie mit "Get" anfängt. Das spricht gegen die Erwartungshaltung der Methode. Get deutet immer auf eine Methode hin, die irgendwas zurückliefert aber das tut sie hier nicht.

Die zweite Variante würde ich nicht empfehlen, weil die Methode TuEtwas() zwei Dinge macht: Sie tut etwas und setzt die Eigenschaft. Sie besitzt also einen Seiteneffekt. Das Verhalten der Klasse hätte was "magisches". Beispiel: A a = new A(); Console.WriteLine(a.Nummer); // würde 0 ausgeben a.Nummer = 10; Console.WriteLine(a.Nummer); // würde 10 ausgeben a.TuEtwas(15); Console.WriteLine(a.Nummer); // würde plötzlich 15 ausgeben Jemand, der die Klasse A nur verwendet und nicht weiß, wie sie intern aufgebaut ist, fragt sich, wieso Nummer plötzlich 15 ist. Außerdem wird es ja einen Grund haben, wieso du die Eigenschaft definiert hast. Sie ist ja offenbar eine Konfiguration für diese Klasse, die von außen beeinflussbar ist. Methoden in Klasse A sollten daher den Wert nicht überschreiben, damit eben nicht dieser "magische Effekt" entsteht. Wenn der Parameter hingegen nur in der Methode TuEtwas() benötigt wird, dann kannst du die Eigenschaft ja auch weglassen, und die nummer, wie im zweiten Beispiel, in die Methode reinreichen.

Ich nehme mal an, es handelt sich um eine FIAE-Ausbildung. Wieso bildet die Firma FIAEler aus, wenn keiner programmieren kann? Was lernst du in der Firma? Vor allem von wem?

Die Datenbank ist doch egal. Heutzutage unterstützen die meisten Anwendungen alle möglichen Datenbanken oder bringen die Datenbank selbst mit und wenn du schon in die Zukunft schaust, würde ich nicht auf mysql setzen, da die Zukunft um mysql ungewiss ist. Inzwischen geht der Trend weg von mysql. Wenn, dann solltest du lieber auf MariaDB oder PostgreSQL setzen.

Ich verstehe trotzdem das Problem nicht. Wenn sich die OracleDB ändern sollte, z.B. aufgrund eines softwareupdates, dann muss sich auch der sog. ETL-Prozess und ggf. auch die mysql Datenbank angepasst werden. Du hast hier so oder so aufwände. Es gibt auch Tools, mit denen man den ETL-Prozess konfigurieren und steuern kann. Z.B. Talend. Wenn ich noch richtig in Erinnerung habe, bietet talend auch eine Echtzeit Funktionalität. Vielleicht ist das ja das, was du suchst. Auch wäre es nicht schlecht, wenn du dich mal mit der rechtevergabe unter Oracle auseinandersetzt. Ich glaube, deine Befürchtung liegt eher darin, dass du Angst hast, jemand könnte die Daten manipulieren aber unter Oracle kannst du sehr feingranular die rechte vergeben. Du kannst auch einen read-only Nutzer anlegen, der nur lesezugriff auf bestimmte Tabellen bekommt.